Ah maybe relevant, I forgot to mention that I’m using the Android App and be on the beta channel (actually v1.0.36 (2133)) :)

And I registered a account so that i get an email if someone replies here. :)

Oh and while I was searching, I read the following article and just realized that the raw logfile you offered there, even was logged in 2s steps (or 2,3s to be precise)… that is not very kind, options you obviously use yourself (and therefore may be useful) not to give to your customers. ;)

Haha, just wanted to mention this, pls don’t take it too serious. :)

This article: https://moosh.im/2015/11/profiling-a-aa-battery/

Hey Richard,

yes it’s mainly because of post-processing the data. I use google docs spreadsheets for that, and with that much data it’s not very pleasant to work with. ;)

But on the other way It’s also because why not? This is an accurate and not cheap measuring device, so I don’t want to be limited in it’s capabilities. Ant to have just 5 options for logging feels a bit like patronized. And why not benefit from the direct contact to the developer…? :)

Btw, after a another while of reading I learned now, that this value actually is not the logging time, but the time the meter sleeps for after each logging event. So on my 3. post I was wrong and this log file was recorded with the 1s option. So sry for my assumption there. :)

So I don’t think it would be too much work to implement a additional field, where I e.g. can enter a custom “sleeping” value in seconds.

But thx for your script, I didn’t know this software yet and will take a look on it when I have the time.

Hi Harry.

Your assumptions about logging intervals might be little bit screwed, as the way that selected interval is used has changed a while ago. Example(?) log from James that you referred probably was saved by code where mooshimeter did its thing of measuring and saving the result, slept for the whole interval-time and then did its thing again. Current code tries to generate log lines ~precisely at set intervals, so actual measurement also happens inside that time frame.

If only problem is too much data at 1s intervals, you might be able to slow actual sampling down to bit over 2 seconds. Manually set sampling to 125Hz/256smpl and logging interval to “no wait” (i’m not actually sure how 1s setting would handle those sampling settings, as it would not be able to keep up). This method only works in DC measurements, but in that case you would get more accurate and smoother results.

Just had a thought that James might have done just the thing i mentioned above, but then i checked that file and it has 125Hz/32smpl settings. I have no idea how that would generate lines 2,3 second apart.. And then there are 0,3 sec lines also, mostly at the beginning of logging instances. And that log file is quite different than the newer ones..

@Richard Yes that was me. Damn, it was a bit oft text because I hade/have a question and 2 comments to the code. Seems to be lost yes (although post counter on topic is on 2 and refers to my post https://moosh.im/f/topic/scilab-script-for-visualization-of-mooshimeter-log-files/#post-18712 – which shows nothing), I didn’t get anything from my locale cache either, so I have to re-write the text later. -.-

But thx for the hint.

PS: Does something like this happen more often here? Because I noticed another bug when viewing with chromium based web browsers (Vivaldi and Chrome in my case), if there is a link to another topic in this forum in a post, a “preview like image” is drawn straight below and so the rest off the post is unreadable.

@ville Thx for the hint, I tried this settings and it worked. So I have at least a workaround for a 2 second period – not perfect but better than nothing. :)

But why in that case I would get more accurate and smoother results? compared to, I assume, the default settings? Could you explain me that a bit, I’m yet not very deep into these sampling settings but I really would like to understand how this works. :) And I didn’t found a page here yet, that describes these two parameters well. :/

For my understanding, on standard DC settings 125/64, the µc will make 64 measurements every 8ms, do math on them (I assume average value on dc), and return the result (So give 1 value, based on 64 measurements, every 8ms).
On 125/256 it would do 256 Measurements every 8ms (more values to calculate average off gives more precise result – that seems logical) but why do this result in 2 second period?

I can calculate 0,008s x 256 Samples = 2,048 seconds – but this would mean that every Sample/measurement will take 8ms (and not 256 Measurements every 8ms) – so how can this be more accurate and give smoother results. I’m a bit confused in there… ^^

If your measured thing is stable, adding more samples should result in better accuracy. At least it would reduce noise in the end result, so it should be possible to see more stable decimals. So there is that smoothness and accuracy i meant. And you were right at the end, value in Hz means how often single sample is taken. So your math of
1/[samplerate]*[samplesize]
gives the time it takes just for sampling.

If you are hunting quick changes in values, then you probably wont need that accurate values, you just need lot of them, so you might want to go for faster sample rate and reduce the amount of samples taken, so for example 4kHz*/32smpl. Its again that 8ms, but this time all 32 samples are taken in that time. It wont result in 125 lines of log per second, as it takes time to process/save/show the values, so if i remember correctly, it would be something like 10 values per second on a memory card, if logging is set to “no wait”.

I dont know what i am babbling about, and i think i should not read the question again, as i might have written something totally irrelevant and need to erase it all :D

It is nice that we could alter the sampling settings of mooshimeter. That way, if you somewhat know how the data is gathered and processed, you could “attack” your measurements with right rates and get results that are hard to see or boring to gather with regular multimeter.

* – There is option of 8kHz for speedfreaks, but it is not stable and might generate random spikes in logs. You have been warned, just dont use it in serious cases..

Yes I noticed, that if switched from 125 to 265 smpl, there is one decimal added to the values.

Thanks for the information, your “babbling” is very interesting for me :D – and yes to get results that are hard to see or boring to gather with regular multimeter – was, beside of the logging 2 channel logging funcionality, the reason why I bought this nice piece of hardware. And although it’s still a bit buggy, because I don’t use it for professional purpose, I’m still happy with it. :)

Although, for my point of view, the documentation could be done better (there you notice that this is the work of an “crazy-tech-guy”). It would be really nice if eg. the smpl functionality would be well described in the documentation, but luckily they have this forum and kind people inside, so it takes time to gather all information but it’s possible… with time and passion.

And from another point of view you don’t get as much information how the thing works from other devices…

Hi guys,

So the logging interval is set by sending a number of seconds to the meter, so the firmware can handle it. The limitations are in the app. I chose 0, 1 second, 10 seconds, 1 minute and 10 minutes because they sounded sensible, but behind the scenes the app is just saying “set logging interval to X milliseconds”. If you’re interested in adding another button that would pop up a little window where you can put in a custom number of milliseconds it should be pretty easy, the file is LoggingPreferencesActivity.java.

Also, if you’re concerned about battery life, you won’t get much better performance moving from 1 second interval to 2 or 3 seconds. The reason is that the meter has an internal reference that takes about 2 seconds to settle, so if the interval is shorter than the settling time of the reference the meter basically never turns off.

Hope this is useful, best
~James