Thanks for your reply. Obviously, the sampling time will vary depending on the rate and sample number, and can be easily calculated. I don’t know if the wake time is consistent, but would guess that it is the major source of variation in when the sampling actually begins. From my point of view, the important thing to know is the relationship between the time stamp and the start of sampling. Knowing this, I could easily calculate the mid point of the sampling period, etc. It isn’t critical that the logging rate correspond precisely to the number on the button because the actual times are available via the time stamp, although this would be nice. It is more important that there are no button values that don’t produce useful data, since trying to use these wastes time and causes aggravation. This applies to the MAX and 1 second logging rates in the current configuration as these produce useless multiple files with time gaps between them. This happens even when I set the number of samples to 1, so it can be used at any sample rate/number combination. I think the highest priority should be to find the fastest robustly reliable logging rate, and add a button for that, and get rid of anything faster. The fastest logging rate won’t be compatible with all sampling rate/number combinations, so the usable sampling period at this fastest logging rate should be specified.

Jon