- This topic has 0 replies, 5 voices, and was last updated 6 years, 5 months ago by
.
- Posts
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...Probably. James, do you (plan to) use some buffering for the logging, or is this not possible (lack of memory, e.g.)?
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.
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.
Tried again with Class 10 – no improvement whatsoever.
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
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. ;^)
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
Thanks James.
@2000Hz/32: Actual: ~20 records/s Theoretical max: 62.5
@1000Hz/32: Actual: ~14 records/s Theoretical max: 31.25You’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)
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.
The best I’ve been able to get is 27Hz. I bought a mooshimeter because the website says it will sample at 8kHz:
Sampling
8kHz dual simultaneous sampling
4kHz analog bandwidth for most measurements
24-bit resolution max
>18 Effective bits at 125 samples per secondOn Board Storage – SD Card
MicroSD Card
Up to 32GB
More than a week of constant logging two channels at 8kHzBased 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.
Hey, is there anything new on this topic? James wrote to do a test on January.
