- This topic has 0 replies, 1 voice, and was last updated 6 years, 10 months ago by Anonymous.
- July 10, 2015 at 8:10 am #4160AustinGuest
I’ve noted that logging at higher speeds is unreliable after disconnecting. I’m trying to log data at the max rate available, which when setting “8000Hz” and “MAX” on the logging, gives a variable sample rate between 50 and 77 Hz. However, typically after a few minutes the logging stops or changes rate without any outside inputs. The LED will stop blinking, and when I connect via the app, logging shows “OFF”. Is my meter defective or is this just bugs in the firmware?
- July 10, 2015 at 2:07 pm #4173
Pushing it to the limit! I like it. I hadn’t tried this experiment. But I don’t think you’ll get the behavior you’re looking for…
The logging mode is not really built for high frequency logging. It’s all built around the assumption that the meter will have to wake up, log a sample, then go back to sleep for a while. Waking up and logging a sample can take between 10 and 500ms, so that’s what really dominates the maximum logging frequency. The actual sampling time is only a very small part of it.
So to sum up, I suspect there may be a bug that gets activated when sampling in that extreme of a case because the firmware was written with the implicit assumption that sampling would be pretty slow. I’ll run this experiment next time I’m doing an update. Can you try slowing it down in the meantime, or is that not useful for your purposes?
- July 13, 2015 at 6:11 am #4288AnonymousGuest
Typically the signals I’m trying to log are somewhat dynamic, so higher frequency logging is required. For this particular case I was reading an analog output pressure sensor trying to capture a transient spike, so I needed the fastest rate the mooshi could deliver. For what its worth, I’ve found the logging to be pretty reliable if I keep my phone connected via the app.
Your response explains why I see highly variable sample times in the logged data, especially when pushing the mooshi up to the maximum speed.
The curse of the developer is everyone has different (usually conflicting) requirements; mine would be for a mooshi that can log reliably (and somewhat evenly) at 100Hz. I’m less concerned about battery life, as our tests typically run less than 3 hours. Streaming of the log files (or logging in the app) would be a great addition too. Overall the mooshi is a great tool for adding some last minute instrumentation in a hard to reach spot. Keep up the good work!
- July 16, 2015 at 11:39 am #4307AnonymousGuest
Follow up question:
What triggers the mooshi to start a new log file? I’ve been running some lower rate tests just to see if they are reliable (and they have been), but I’m getting 2 or more files over the course of a couple of hours, even though the file size in minuscule (<100KB). I can consolidate the files, but it would be nice if there was just one per logging session.
- July 16, 2015 at 12:36 pm #4308
Thanks for the positive feedback :)
Regarding: What triggers the mooshi to start a new log file?
There are two conditions under which it will start a new log file:
1. Logging is turned on after being off.
2. A write error occurs to the SD card, in which case the mooshimeter will wait for a few seconds and then restart the logging routine, which involves creating a new logfile.
You’re not the only one who’s reported multiple split logs. What this indicates is that there’s some sort of intermittent fault in writing to the SD card. In the last few days I found the fault almost always occurs when waking up the card from sleep. So I’ve added some retry logic to make that part a little more fault tolerant. I’ll try to get that the new firmware image out by the weekend, hope it helps.
- July 16, 2015 at 4:47 pm #4312
I found some time this afternoon and pushed a new firmware build that should reduce the number of spurious little log files as I discussed above.
If you’re on iOS, just close and restart the app. Note that closing the app is different from backgrounding – you will need to double tap the home button and swipe away at the Mooshimeter tile to get it to close (I dislike this about iOS). Then run a firmware update, you should end up with a firmware version starting with 147xxxx.
If you’re on Android, update your app to get the latest firmware version, since the binary is bundled with the app.
Let me know if it changes things for you, I am optimistic.
- July 17, 2015 at 8:02 am #4319AnonymousGuest
Great! I got the new firmware, I will test it out today.
BTW, with the iOS app I had to hit the reset button on the mooshi and then connect to get the firmware to update.
- July 17, 2015 at 9:37 am #4325AnonymousGuest
Ran a test today with logging with the new firmware. Still got a split log file…
Sample rate: 1000Hz
logging rate: MAX
once I disconnected, the sample rate reverted back to default and I got ~1 Hz logged data. After about 5 minutes, a new log file was created with about a 10 second time gap from the end of the first.
- July 19, 2015 at 12:03 pm #4344
Hmmm… your description made me investigate deeper. The test I had done with this release (1437089929) was to set up logging temperature with 125Hz sample rate, 32 sample depth, 1s sample interval, for 2 days. It all worked nicely and produced one long logfile.
With the new firmware I set to 8000Hz rate, 1 depth, and no interval and I confirm I see something similar to you. Definitely splitting up the logs. I’ll check this out but for now is it useful to just back off the settings a little? The logs don’t seem to split when I run at 125Hz and 16 samples and the effective sample rate ends up higher than the 8kHz case because the error rate is lower. I hope that helps until I get to the bottom of this edge case.
- July 20, 2015 at 11:45 am #4352AnonymousGuest
I tried the following this morning: sample rate at 125Hz, logging “max”, sample depth 16, and I still got split files.
I’m also confused on your comment about getting higher effective sample rates. I haven’t seen that effect… the logged rate gets more and more variable as the sample rate increases. I’m using a SanDisk Ultra 32GB microSD Class 10 card for reference…