Yep. Set 600 seconds, get ~10,18 seconds.

Hmm.. Tried with 60 second intervals and got within 50 ms for hundreds of lines. Most of those were in 5 ms accuracy.

But of course, i screwed the results by changing what i was logging and it was with much slower sampling. Now I need to try again. Accurate timing was with both channels logging internal temperature at 125Hz/64smpl (auto).

600 s setting, which produced lines with ~10,18 s intervals, was logging temperature and ac-voltage at 4kHz/256smpl.

I now set it to log temp+acv at 60s/4kHz/256smpl. I’ll try to remember to check it after couple hours.

Non related, but with battery indicator showing 19%, trying to start logging crashed mooshimeter. Both batteries were at 1,05 volts when measuring while in mooshimeter, ~minute after removing raised to 1,1 volts. Those only lasted for 1,5 years :D .. Just realized, that i forget to write this date to those new ones, should do it now –>

10 s and 60 s intervals with 4 kHz/256 smpl produced stable timestamps.

Hmm.. I think I found out what is happening. There has to be wrong type of variable somewhere. App source has logging interval options in milliseconds, so one minute is 60000. Unsigned 16 bit integer goes up to 65535 and one minute interval just fits in. 10 minutes goes over that (actually 9 times) and then leaves 10176 milliseconds as logging interval.

Now we need @admin or anyone who knows anything about coding to help. I have now idea how to track where this happens and if it is in the firmware, only James could solve this..

MrPeak – thank you for investigating. Regarding your earlier question about the timing drifting slightly, your analysis is correct that the logging system in firmware is waking up, setting an alarm, then going back to sleep, and that the variance in wakeup time is causing the slow drift. I think it’s more pronounced with logging period of 60s because when the logging period is long, the meter puts the SD card to sleep and wakes it up every time, which I’ve learned from experience is a very variable process.

Ville – your analysis of the 10minute logging interval problem is 99.9% correct and I can’t believe I made such a mistake. Internally in the meter, it’s a 16 bit integer storing the logging interval, but it’s stored in seconds. I made it that way because I wanted to avoid overflow, which you are right to be concerned about. But the internal timing mechanisms of the firmware deal in milliseconds, and I performed the conversion wrong. Here is the offending line:
osal_start_timerEx( APP_TID, SBP_LOG_TIMER_EVT, (meter_state.log_settings.interval_s)*1000 );
Since meter_state.log_settings.interval_s is a uint16, the compiler does a 16 bit multiply with 1000, which overflows of course. And the result of that overflow is (600*1000) mod (2^16-1) = 10.185 seconds, exactly as MrPeak reported!

I’ve corrected the firmware. Before I release though I should update the apps to make firmware updates opt-in instead of opt-out, because I don’t think this change merits the struggle of a firmware update for most users.

Thank you again for your diagnosis – please email me if I can send you any swag (test leads? extra cases?), I really appreciate the help.

~James

James, you should set up a trust fund for the coding of holy grail* of mooshimeter for the whole community, starting with saved postal fees of the package you do not need to send me for this ;)

* The free math channel(s)!

And as we touched the area of mathematics, I’d like to have my lost 0,1% back ;D There should not be that “-1” in that mod-formula.. Zero is a value too, and counts as such for every overflow round.

There are various problems but the most glaring is a malfunction of the zero ohm balance on the first channel, I do not know if it is a problem on the latest version of the software (I do not know if it existed before).
– in the first box (current) if you set resistance, short-circuit the test leads to set the reading to zero, the memorization is lost when the test leads come back (ie the written setting remains but the reading does not take it into account).
In practice, the zero ohm correction no longer works.
– in the second panel (voltage) this function is OK

Forgive for the bad translation

—–
Ci sono vari problemini ma la più clamorosa è un malfunzionamento del bilanciamento zero ohm sul primo canale, non so se è un problema sull’ultima versione del software (non so se esisteva pure prima).
-nel primo riquadro (current) se imposto resistenza, cortocircuito i puntali per impostare a zero la lettura, la memorizzazione si perde quando i puntali tornano aperti (cioè rimane l’impostazione scritta ma la lettura non ne tiene conto).
In pratica la correzione dello zero ohm non funziona più.
-nel secondo riquadro (voltage) tale funzione è OK

Just realized there’s new firmware (1522204715).

Tried to update, two mooshimeters, two android phones, many tries and it just wont work. There’s nothing on progress bar, just steady blinking of led on the meter. Strangely, RevH meter led blinks at about 1 sec on, 1 sec off and RevJ meter at 0,5 second rate.

Aaargh. reCAPTCHA (which by the way needs upgrade) and couple external distractions made me close a tab without submitting my text.

I tried to update again with:
OnePlus 2, Android 6.0.1
LG Spirit (H440n), Android 6.0

Both failed, seems like the app hangs just before it should start transferring firmware to the meter. It just says “Programming…” for ever, where it should have transferring status in numbers beside progress bar. I did let it stay there for 30 minutes and nothing happened. Just steady blink from led, as in bootloader mode. If i cancel programming, touching anything else than start programming button hangs the app and system offers “not responding” notification.

I dug older phone from scrap pile and tried with:
HTC One, Android 5.0.2

App update, realized it offers older fw, joined beta, another app update and fw-update worked on a first try (with legacy mode). I was feeling lucky and updated another meter without legacy mode and it seems to also work.

Both of my meters are on fw-1522204715 now. I’m not yet scrapping that old phone, as we should have another fw just around the corner. James told earlier this week he has fixed reboot recovery for aux channel settings, but for some reason its not out yet.

So, there is something wrong at least around android 6 and fw updates. All of these phones have been able to do it before, cheapest one (lg) was actually first that i was able to do updates with (it was on android 5 then), before there were legacy mode available, which then helped that HTC to do it.