- This topic has 0 replies, 5 voices, and was last updated 5 years, 2 months ago by Anonymous.
- January 13, 2017 at 9:46 pm #15376AnonymousInactive
I configured the logging for 4000Hz/64 samples/No Wait, which should equate to a rate of one record every 16ms, however the actual rate appears to be about 118ms. Any ideas what could cause this? If it makes a difference, the microSD card is a 32GB Class 4 device – could the fact that it’s a slow card really cause it to be this much slower?
Here is the start of the log:123456789101112131415161718192021222324PCB: 008ASM: 000LOT: 00000FW: 1477971088CH1: AUXV 1.2VCH2: VOLT 60VSMPL: 0064 4000HzUTC TIME SEC CH1 AUXV DC CH2 VOLT DC1484365868.336 -0.01619851 14.061381484365868.452 -0.01672644 14.067861484365868.573 -0.01559702 14.052691484365868.691 -0.01581367 14.035011484365868.807 -0.01728495 14.040441484365868.924 -0.01336471 14.058151484365869.043 -0.01551134 14.048951484365869.161 -0.01332778 14.046011484365869.278 -0.01892529 14.047931484365869.396 -0.01365752 14.017041484365869.514 -0.01619563 14.053751484365869.631 -0.01550643 14.043041484365869.753 -0.01375907 14.04168...
- January 14, 2017 at 10:08 am #15400
The card is the only explanation I can think of.
- January 14, 2017 at 10:51 am #15404AnonymousInactive
Probably. James, do you (plan to) use some buffering for the logging, or is this not possible (lack of memory, e.g.)?
- January 14, 2017 at 10:59 am #15405AnonymousInactive
Ok I guess I’ll try a faster card. How fast does it need to be in order to sustain a rate of one worse-case (longest) record every 8ms? (I’m using 125Hz/8ms here because that’s the fastest rate you seemed to say the meter should be able to keep up with – actually you seemed to imply it could go even faster) Suggestion: this seems to be fundamental information and should be added to the Wiki.
- January 14, 2017 at 12:35 pm #15406AnonymousInactive
I notice that the logging rate increases when I disconnect the phone from the meter – down to about 66ms now, which is a big improvement, but still nowhere near what it should be at 4000/64 – 16ms. Still using Class 4.
Is this the expected behaviour – the logging rate improves when the phone is disconnected?
In any case, it proves that the SD card is not the only bottleneck when the phone is connected.
- January 14, 2017 at 5:35 pm #15412AnonymousInactive
Tried again with Class 10 – no improvement whatsoever.
- January 15, 2017 at 1:43 am #15413AnonymousInactive
There is only one little microcontroller, which has to do everything.. Take samples to buffer (at the rate/size user selected!) –> process –> store –> transfer over ble –> probably something else that i don’t understand –> start from beginning.
Every step takes time, so mooshimeter could not log at the rate that sampling is set. There should be no harm in letting users select even 1 (odd, isn’t it :D ) as sample size though.. @GregS is now at 15Hz logging, there might be something to achieve with raw data without processing. At least more noise ;)
It would be nice if @admin revisits original spec-sheet. No, i dont mean to hide mistakes that has been causing trouble on the forum, but to explain what is behind those (partly unrealistic) statements. Like that example for max memory card size: ~”32GB would take over a week of log at 2x8kHz”. That is clearly just a worst case scenario to tell users that any card would be enough, not a realistic logging setup. And if we calculate what that really adds up, that would be 2ch x single raw sample per line. There is not a mode that would do it, and it would not be at constant 8kHz either, as single microcontroller (probably) would not do sampling + writing simultaneously.
As im reading the spec-sheet, frequency pops up.. Mooshimeter currently does not do that. Should it be able to do it alone, or is it something that phone would analyze from the buffer data? Odd waveforms etc might be hard, or some trigger level setup needs to be given to the user.. And yes, i know there is no hardware trigger available, but same problem exists in analyzing randomly timed buffers..
Applications section seems mostly to be bit hard for tiny processor to do by itself and mooshi-app is still missing quite a few of those. Free math would solve(/help in) several cases..
Sorry for the longish ot, this is just the way my head works :D
- January 15, 2017 at 2:09 am #15415AnonymousInactive
Ville: It’s really very simple. I asked what the maximum log rate was, and I got an answer from James himself:
moosh.im/f/topic/measuring-watt-hours/#post-15307 (including the entire link causes an ugly big graphic to cover up the rest of the message – trying a truncated link instead….)
If you set the buffer depth to 32 and sample rate to 4000Hz, then leave it to log, you’ll see a sample rate of just under 125Hz in the log. Is that what you’re looking for?
I’ve tested it, and so far, I am unable to reproduce that rate, so I am reporting this discrepancy. I am only trying to reproduce HALF that rate, by the way, so I’m even being nice. ;^)
- January 15, 2017 at 1:33 pm #15421
Hi GregS and Ville,
Greg – sorry my original answer here was very short. I didn’t dig in to this as much as I should have and was going off numbers on the top of my head. The logging feature was designed with long intervals (seconds or minutes) in mind, so these high speed logging scenarios are not something I think a lot about.
I am still of the belief that 125Hz logging to SD card is possible but haven’t tried it myself in a while, I have a memory of making a log at this speed as a test a few firmware versions ago.
Regarding logging faster when phone disconnected: yes this is what I expected to see, but not as drastically as you’re seeing it. Ville’s description of how the meter works is correct – there’s one little processor juggling all the tasks.
Actually, as I think this through, what I believe may be happening is an interaction between the sampling thread, the SD card writing thread, and a design decision I made to make the UI cleaner. If the sampling thread misses several samples in a row because of interruption, it pitches the data buffer and starts over again. I asked you to set it to 4000Hz, 32 samples instead of 125Hz, 1 sample because I eliminated the option for setting such low buffer depths on an earlier version of firmware, as it was not useful to the vast majority of users and was causing confusion. But my suspicion is that at 4000Hz, the interleaved writing-to-SD thread is causing the sampling thread to miss samples and forcing it to restart itself several times before a buffer gets written to memory.
As a test, could you try logging on 2000Hz 32 samples, or 1000Hz 32samples? My suspicion is that one of those will give you a sample rate much closer to what you’d expect (60Hz or 30Hz). If that’s the case I will evaluate re-adding the lower buffer depth options to the user interface.
Ville: Thanks for the accurate description of the meter’s function and recommendations on documentation :)
I hope this helps, thanks
- January 15, 2017 at 1:47 pm #15422AnonymousInactive
@2000Hz/32: Actual: ~20 records/s Theoretical max: 62.5
@1000Hz/32: Actual: ~14 records/s Theoretical max: 31.25
- January 15, 2017 at 2:18 pm #15426
Thanks for the quick experiment even though the result isn’t what I hoped. I’ll do a test on this in the coming week (I’m out of office right now since it’s the weekend).
- January 15, 2017 at 2:33 pm #15428AnonymousInactive
You’re welcome. Btw, regarding logging single samples, maybe a mid-way solution would be to allow us to save a single buffer’s worth of samples to the SD card, as part of the graphing functionality? I.e – you allow us to access single samples in graphing mode, so consider going one step further and allowing just 1 raw buffer to be saved to the log. (apologies in advance if it can already do this – I haven’t used graphing mode much yet so am unfamiliar with all the options, but I can’t *seem* to see a way to do this)
- February 26, 2017 at 12:02 pm #15928AnonymousInactive
I’d like to push this up because I’m interested in faster logging rates to. The fastest rate I got has been a little faster than 30/s.
- March 7, 2017 at 10:03 am #16005AnonymousGuest
The best I’ve been able to get is 27Hz. I bought a mooshimeter because the website says it will sample at 8kHz:
8kHz dual simultaneous sampling
4kHz analog bandwidth for most measurements
24-bit resolution max
>18 Effective bits at 125 samples per second
On Board Storage – SD Card
Up to 32GB
More than a week of constant logging two channels at 8kHz
Based on this, I thought the resolution may be way lower at 8kHz, but nowhere does it mention that it will downsample to 1/32 of 8kHz. And even if this was made clear, I’d still be unhappy because the real world performance I’m getting is actually 300 times worse than quoted.
The specifications page was last updated in 2015. Reading this forum, it is clear that the sampling limitations have been known for a long time:
It is unacceptable that people are still buying this product based on false marketing claims 18 months later.
James, the very next thing you should do is to update your specs page so that it is no longer misleading.
After that, could you wring any more out of the existing hardware, perhaps by sacrificing other functionality, or measurement resolution. Have you thought about making alternative firmwares or modes available that are optimised for particular tasks? How fast would it be able to sample to SD if it didn’t have to do anything else – you tell it to go dark and record at full speed for x seconds/minutes/hours before coming back online. Users could always hit the reset if they changed their minds and needed to reconnect.
- April 9, 2017 at 1:42 pm #16344AnonymousInactive
Hey, is there anything new on this topic? James wrote to do a test on January.