Home › Forums › Mooshimeter Support › Logging ; multiple files, wrong sample rate
- This topic has 5 replies, 2 voices, and was last updated 7 years, 1 month ago by admin.
Trying to use logging function for the first time, with iOS and a new SanDisk 32GB SDHC card. No matter what sampling time I enter, I get 3 samples/s. I also get multiple files. Some contain many samples, others just a few. On the last attempt with the sample rate set at 1/minute, and running for about 30 minutes, I got 28 files. Several files/minute during the first three minutes, most containing only a few readings, then a gap of 25 minutes before the final file, which only contains 2 readings. The batteries are fine, and I’ve tried multiple resets, restarted the app, etc. Any suggestions?
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.
You had the same assumptions as Julia when using the logging function, and I think your assumptions are more natural than mine so I will try to change the behavior of the meter to meet yours. It’s easy to develop tunnel vision when you’re working on a product.
An approximate list of changes I have on the to-do list:
– When connected over BLE, only write to the SD card at the rate set by the logging interval (presently every sample taken by the meter is written to SD, the logging interval just determines how long to sleep when disconnected)
– Account for sampling and wake time in the logging interval: samples taken with 10s logging interval should end up 10s apart in the log file. The extra 1.3 seconds you’re seeing is the sampling time and the wake time.
Thanks again for the feedback, these kinds of interactions really do drive the product development.
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.
I wholeheartedly agree with your analysis, thank you. I don’t think the behavior you’re seeing from the MAX and 1s rates is typical though, the Mooshimeter only breaks up log files when there’s been some kind of error writing to the SD card , or if the user presses “LOGGING:OFF” and “LOGGING:ON” again.
Can you tell me what firmware build is on your meter?