Didn’t read the previous post from Julia before posting the above. Sounds like our problems are related. I believe my phone was disconnected from the meter during my logging sessions because I returned to the scan page as instructed after turning logging on. I’ll try again and quit from the app entirely.

After playing around a bit more, these are my conclusions:

(1) The 1 second and maximum sample rate settings are not usable. They both log about 3 readings/sec which are recorded in multiple files with time gaps between them.

(2) the 10s and 1 m rates work OK, but logging starts at the 3/s rate when logging is turned on, than reduces to approximately the nominal rate when back button to the Scan screen is pressed. On return from the Scan screen to the Meter screen, sampling goes to the 3/s rate. All the reading are recorded in the file, but those recorded at the nominal rate are separated from the others by a repeat of the headers. Even when the back button is pushed ASAP after the logging is turned on, 10 or more samples will be taken at the 3/s rate and will appear at the start of the file.

(3) The actual rate on the 10s setting ~11.059s and on the ~61.330s on the 1m setting with standard deviation of about 30ms. If you need to be accurate, using the time stamp values is important.

(4) AS others have mentioned, the flashing LED is useful as indicator that sampling is OK. On the 10s and 1m settings, it flashes each time a sample is taken. On the (not really functional) 1s and Max settings, it is on almost continuously but cycles through a pattern of brightness variation every 2-3s.

Suggestions: A software update that doesn’t initiate logging until the back is pushed would be a major improvement. Presumably there is a sampling rate faster than 10s that could run reliably without producing multiple files. It would useful to determine this and add modify available sample rates accordingly.

Jon

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