Topic | How are ideal logging rates calculated?

Home Forums Mooshimeter Support How are ideal logging rates calculated?

Viewing 4 reply threads
  • Author
    • #19872 Reply

      I’m considering buying a Mooshimeter for a my final year engineering uni project.

      I need to log at least 30 samples per second for voltage and current from a small DC generator for 30 seconds or more per test.

      After reading through various threads on here there seems to be issues with the logging rates where they are affected by SD class speed, whether the meter is connected to the app or not and the various sample rate / buffer settings.

      Is there a guide or formula to how the logging rate is calculated when the pre-set 1s, 10s, 1min, etc logging intervals aren’t used?

      Could we maybe get a thread stickied with a guide to logging rates?


    • #19876 Reply

      1/sample rate [in Hz]
      * samples [number of samples taken under the hood and hidden from user]
      + ~0,1 [processing time]
      = time in seconds it takes for one line of log to appear at “no wait”.

      1/125 * 256 + 0,1 = 2,148 s (slowest possible for reference)
      1/125 * 32 + 0,1 = 0,356 s
      1/4000 * 32 + 0,1 = 0,108 s (fastest with stable results)
      1/8000 * 32 + 0,1 = 0,104 s (might generate random errors in data)

      0,1 s is just a bit longer than it actually takes for processing and saving results, but you get to the ballpark with that nice round number. 8 kHz is possible, but it has been a bit unstable and in most cases you get more usable and less noisy results at 4 kHz. And as my calculations above state, you cant get that much faster with 8 kHz anyway, that you should tolerate it adding random spikes in your results.

      But then, there is this thing called buffer mode “hidden” in settings for graphs. There you can see actual live samples taken as a graph. 50/60 Hz mains sine wave is easily recognized and that is probably what makes some people think that mooshimeter could be used as an oscilloscope. There is no way of aiming or triggering, you just need to wish for the best and let mooshimeter shoot in the dark. 8 kHz sample rate would give you 160 (for 50 Hz, 133 for 60 Hz) points per full mains wave, so it still looks quite smooth and you might see when the waveform is not what it should be etc. Now guess what you see when frequency starts to rise. 16 points from 500 Hz wave is close to useless, it might be possible to tell what frequency that graph is supposed to represent. Anything higher and you most likely need something other than a multimeter. I think i know a device that would help and it is called an oscilloscope.

      And as always, what was the question? Some day I should try to answer to someone and not just ramble something :D

    • #19877 Reply

      Thanks for all the info ville.

      If a 60Hz sine wave can be easily recognizable via the graphing function of the Mooshimeter app, I’m thinking I will be able to read the values from the graph without too much trouble instead of reading the values from the logs.

      My little project involves a DC generator driven by a swinging pendulum with a period of oscillation of about 1 second. Peak voltage shouldn’t net me much more than 10 volts.

      Can I get your advice on if you think the graphing ability of the app will be sufficient for this?


    • #19878 Reply

      As I said, using buffer mode is like shooting in the dark. Only way to save results is grabbing screenshots on the fly, as there isn’t even a pause button for it. Mooshimeter just takes the samples, sends those to phone and starts again, while phone shows resulting graph and waits for more.

      I’m not saying that your project cant be done with mooshimeter, it might just be bit hard and you will need multiple tries.

      I would start at 125 Hz and 256 samples, which are the slowest possible settings. Then your screen will show data of just over 2 seconds, you should have plenty of time to grab screenshot and get one full uninterrupted swing per view. You will “lose” some data between those buffer bursts, as sampling has to stop while processor is busy dumping data over bluetooth to your phone. In my last answer i told that processing/transferring/etc took 0,1 seconds, in this case its much longer. Instead of 2 values, you are now waiting for 512 (as there are two channels) and that has to take more time. I tried to keep an eye on timeline while buffer mode was on and there seems to be just under 1 second gaps between graphs.

      Its hard to explain, but next number-mess is simplest way I can come up without drawing anything :D

      First line is “reality” and numbers are supposed to express your experiments swings (1-9) in time (1 character is 1/3 of oscillation period)

      122233 455566 788899

      That second line expresses timing of three consecutive screenshots. So you would get all values of swings 2, 5 and 8. In reality it wont be that simple, there will be some random component in timing.

      Speculation of how to improve(?) mooshi-app for these kind of experiments:

      1. It might be possible to slow sampling to even lower than 125 Hz. Maybe its just a number that application tells to multimeter and we could get to something like 25 Hz and 256 samples, so we could get 10 seconds of uninterrupted data.

      2. logging option for buffer mode on phone side, so we could analyze data in number form.

      3. At least pause button would be nice. Does not really help in experiments of this thread, but i have many times hoped for one.

    • #19879 Reply

      Blaah. That number thing looked fine while writing, as this text editor box has fixed width font. Forum even removed some spaces that i put there. Maybe its more readable in code-tags:

      Strange that i cant edit my post, so if this test fails, it still stays here :D Preview would help, its strange to post blind :D

      Oh. I can edit this while its still fresh. I was too tired last night to even check what i send :D

Viewing 4 reply threads
Reply To: How are ideal logging rates calculated?
Your information:

This site is protected by reCaptcha and the Google Privacy Policy and Terms of Service apply.

The reCAPTCHA verification period has expired. Please reload the page.