Hi Greg,

The card is the only explanation I can think of.

~James

Probably. James, do you (plan to) use some buffering for the logging, or is this not possible (lack of memory, e.g.)?

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

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 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).

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:

Specs

Sampling

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

MicroSD 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:

High frequency logging unreliable

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.