- This topic has 0 replies, 3 voices, and was last updated 5 years, 7 months ago by Anonymous.
- January 21, 2017 at 11:48 am #15531AnonymousInactive
In my last measurement I set the logging interval to 10m (600s), but the interval which was used by the Mooshimeter, was only 10s.
Using FW Build 1477971088 and the android beta app (1.0.34 (2115)).
It’s reproducible by starting a new measurement.
- March 19, 2018 at 7:40 pm #19706AnonymousInactive
Just some minutes ago, I run into the same problem (which I’ve reported one year ago), I can still not use a log interval of 10 minutes. Firmware is the same, Android App is 1.0.38 (2214).
Anyone can confirm this?
- March 20, 2018 at 11:47 am #19710AnonymousInactive
Yep. Set 600 seconds, get ~10,18 seconds.
- March 22, 2018 at 9:53 am #19720AnonymousInactive
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 –>
- March 22, 2018 at 12:28 pm #19721AnonymousInactive
I’m using 60s interval most of the time, it’s stable so far, but sometimes it steps a little bit more than 60s. Seems that the logging is using something like a sleep/delay() function and not an alarm (maybe not possible).
It would be interesting to know if IOS user have the same problem with the 600s interval, maybe it’s only the Android App which is sending wrong data to the mooshimeter.
- March 23, 2018 at 6:14 am #19725AnonymousInactive
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..
- March 24, 2018 at 5:52 am #19727AnonymousInactive
Wow, reasonable analysis.
Regarding the 60s timestamps, when I wrote about time steps, I mean that I notice a drift in longer periods (days).
1520900660.065, 2.942138E002, 3.004225E000
1520900720.702, 2.941372E002, 2.988049E000
[… 5 days]
1521395325.604, 2.887384E002, 2.444784E000
1521395385.603, 2.887443E002, 2.444766E000
- March 26, 2018 at 12:43 pm #19734adminKeymaster
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.
- March 27, 2018 at 7:47 am #19736AnonymousInactive
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.
- April 4, 2018 at 5:38 am #19760AnonymousGuest
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
- April 10, 2018 at 8:43 am #19773AnonymousInactive
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.
- April 19, 2018 at 1:55 pm #19781AnonymousInactive
I can confirm that the 600s logging with 1522204715 was working like expected. Firmware update was problematic, I need many tries and only the legacy mode was working (even if my phone was running Android 8.1).
- April 21, 2018 at 12:34 am #19782AnonymousInactive
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.