best practice in data logging

I have been data logging different things and have been doing it at intervals such as 15-30 minutes. The technique I have used to do this has been with the delay() in the main loop. Today I am data logging GPS (tinyGPS) and it has forced me to question if that's the best method, as if I use the delay in the main loop, as I have been, then there is no guarantee (and probably little chance) that on that next loop after the delay, I am going to get an updated GPS value.

So I consider method 2:

I could let the main loop keep looping and check a timer at each iteration to see if it's time to log the data.

Which method is more common?

I assume power consumption could be a factor. Some of my previous data logging has been done with battery power, and I believe the delay() in the loop may help conserve power, but I'm not sure.

Thanks for any thoughts.

I may have posted this in the wrong forum area. Should a mod move it?

moderator: done

MakoMaker: I may have posted this in the wrong forum area. Should a mod move it?

Maybe, but PG is probably OK.

For most things you intend on representing in softwares, you should forget that delay() exists!

You can therefore base your logging on elapsed time (once per time period) or on numerical checks (once per some external event.)

As an example of the latter, consider a temperature sensor where you only log the time, date, temperature when the sensor is a full degree (higher or lower) than the previous log event.

Ray

Look at the demo several things at a time which illustrates how to use millis() to manage time rather than using the delay() function. When you use delay() the Arduino can do nothing else until the time expires. In general it is best not to use it at all.

...R

The delay() function does not help in any way to reduce power consumption. The only thing that will help with power is to turn off hardware that isn't needed. On the Arduino processor that is done with various 'sleep' modes.

Here is a low-power data logger that I designed that puts the MCU to sleep between logging events. An alarm is set in an external RTC that generates an interrupt to wake the MCU for the next logging cycle.

Low power operation may not be critical in other applications. Here is another logger I designed that runs continuously.

I'd say that "best practice" is relative to the requirements. "Data logging" in general covers quite a broad area.

I don't believe I ever said this. But thanks for all of that good information. That helps tremendously.