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