So, I commented out all instances of NewSerial,print. And got this message when I uploaded.
Sketch uses 15,714 bytes (48%) of program storage space. Maximum is 32,256 bytes.
Global variables use 1,557 bytes (76%) of dynamic memory, leaving 491 bytes for local variables. Maximum is 2,048 bytes.
Low memory available, stability problems may occur.
With the buffer still at 850, I got this result.
Observed time distribution (in ms):
100 13649
103 1
200 244
ratio 56:1
That’s looking better thinks I, lets try increasing buffer to 1024
this is the upload message.
Sketch uses 15,714 bytes (48%) of program storage space. Maximum is 32,256 bytes.
Global variables use 1,731 bytes (84%) of dynamic memory, leaving 317 bytes for local variables. Maximum is 2,048 bytes.
Low memory available, stability problems may occur.
And this was the result.
Observed time distribution (in ms):
100 38988
200 2593
ratio 15:1
so bigger buffer is worse, maybe it’s all these global variables? I’m worried by the low memory, instability warnings. could this be part of the problem, can I decrease the global variables
Hi Decrepit - Whew. That is a rough one. You are doing all the right things. I’m not sure I have anything to recommend. You may be at the limits of OpenLog. Most of the OpenLog testing (https://github.com/sparkfun/OpenLog/blo … arking.ino) was setup to run a series of large text transfers at 9600, 57600, 115200 and look for errors. We would test over a series of seconds (~30s) not hours and days so I’m not sure if you’ll ever get to 100% record.
That said, we should try
What GPS module are you using and what datums are you trying to record? I personally would use a SAM-M8Q or other Ublox module and configure the device to output the bare minimum of NMEA data that needed to be recorded. Perhaps you could even preprocess the GPS data so you are not recording bare NMEA sentence but just the GPS lat/long. (Perhaps you are already doing this). The goal is to cut down on the number of bytes needed to be recorded at 10Hz.
If speed is what you need then the real solution is to get away from the ATmega328 on the OpenLog. I don’t have a product I’d recommend for you at this moment, but you have me thinking about a new one.
Thanks Nathan, I’m using a ublox 8 series, I think it’s an m8m from memory.
I’m using it for our windsurfing, GPS team challenge competition. We need verifiable doppler speed results, so I’m not using NMEA that is miles too big a sentence. Intestead we use the NAV PVT sentence, gives us doppler and accuracy data. Those tests above were usually about an hour long and typically 4mb, so about 6kb a sentence (according to my maths). We can’t get any lower than this.
I have another unit using the logomatic that does the 10hz fine, even with NAV SAT ever second as well. That produces files about twice the size, so you already have a device that will dothe higher speed.
But it 's heavy on battery, and much more expensive. There’s the odd sailor in the competition doing 24hr distance records, the logomatic version I have will only do about 5hrs. Openlog is nice and light on battery, we can probably push that to 24hrs with a big enough battery.
5hz is accurate enough for our purpose, and I’ll go back to using that. But I guess I’m just trying to get as much accuracy as possible.
If you do come up with an alternative, that’s light on battery and capable of more than 60kb/s, I’d be interested in trying it out/involved in testing.
Our problem is a lack of commercial products that meet our needs, one of them has got a bad reputation for using inferior materials, and the other looks very promising but is in early stages of one man production and can’t keep up with demand.
