24 hour timer
Hello
We are currently facing a weird issue that we can not explain.
We are using multiple boards which we program for offline use with an Android App.
This App creates a timer which fires every 24 hours.
Most of the times. this works as expected. But sometimes the cylce of the timer seems to change, meaning that, for example, when the 24 hour timer was firing every day at 6 o'clock, it changes and continues to fire at 8 o'clock instead.
Weirdly, it does not seem to happen consistently. The only clue that we found was that it seems to only happen when the switch was pressed in between two cycles.
The switch also starts another timer - so maybe this influences the 24hour timer?
Do you have any explanation what could cause this issue?
All boards are from type MetaMotion R and are running firmware 1.4.1
Thank you very much for your help!
Greetings from Vienna
Jodli
Comments
Can you post your code and replicable steps?
Post the relevant timer code you are running.
Ah sorry. I should have thought about the code by myself. Unfortunately the code is pretty long and complex. I tried to reduce it as much as possible, but I also wanted to leave in as much as possible so you can maybe spot something that I missed. I hope it is clear enough to read:
Code for the switch:
Code for the timer:
It does not happen consistently which makes it so hard to pinpoint the issue. We have a feeling that it only happens on specific boards, but even there it does not happen consistently (it neither happens every time nor is the change similar).
The weird thing is that almost every time the first cycle of the timer is correct (and in the few instances where it is not, it is only off by a few minutes). It is also not consistent WHEN the cycle changes. There were instances where the cycle of a timer was correct for several days and then changed. Other boards changed almost every day. The only consistency I can see is that when the cycle changed, the switch was pressed somewhere in between this cycle and the cycle before.
But there were also instances where the switch was pressed without the cycle changing. So whatever effect the switch has on the timer, it is not consistent either
Is it possible that we are facing some kind of hardware defect?
I havent tried it with shorter periods yet. Could there be an issue with very long timer-cycles?
Thank you very much for your help!
Jodli
The code looks fine to me.
There is also a lot going on in your code. To get to the bottom of this, it would be very helpful to:
Thank you very much for your reply. I did some further testing and it seems that the problem persists if I reduce the 24-hour timer to only 5 minutes and that the 3-seconds-timer from the switch seems to cause the problem.
I logged the exact times when the board vibrated and had minor fluctuations in seconds (almost every time).
When I just removed the lines from the switch-logic:
timer.stop();
timer.start();
Then the seconds where absolutely exact.
I will try to reduce the code as much as possible so you can replicate it easier
Ok I reduced my code as much as possible and tested a bit. There definitely is something fishy going on.
My code creates a route to the battery to logs its output and then creates a loop-timer which just reads the battery state. I did this to have a way of logging the exact timings of my loop-timer.
Then, a 3 second "dummy"-timer is created, which is started when pressing the switch.
This is my code, you should be able to just use it as is, to replicate my issue:
Code for downloading:
In theory, the timestamps for the battery logging should be exactly 10 seconds apart. And in fact, when I just run my code, let the timer fire for a few times and then download the log data, there are only minor fluctuations in the timestamps (2 ms at max):
But when I just press the button in between each loop, then all timestamps fluctuate up to 500 ms. And as far as I can see, that should be impossible because the switch is doing nothing that should interfere with the loop-timer:
Another interesting find is that when I only remove the line "timer.start()" from the code - meaning that the "dummy"-timer is not started by the switch anymore - then all timestamps seem to be exact again.
So I guess that starting a timer while another timer is running, for some reason interferes with the already running timer.
Do you have an idea how I could overcome that problem?
Am I overlooking something?
A small difference in ms is not a big deal for us. But it seems that the longer the timer, the longer the possible fluctuations. This means, that a timer that fires every 24 hours can fluctuate over several hours
Thank you for any tips or remarks
Jodli
Thanks for the code snippet, which looks fine to me. We'll try to replicate the issue on our end with your code.
Thank you very much! I am looking forward to hear from your findings
Confirmed the behavior with your code. I have forwarded the issue to the firmware dev.
Thank you. Good to know, that I was not going crazy
Just so we can plan accordingly: Do you have an estimation when a fix can be expected?
Thanks again!
Sorry to bump again, but I wanted to ask about the timeline for a possible firmware upgrade regarding the issue above. We have a large scientific project here on the start (using 180 wearables from mbientlab) and cannot start without having this issue solved.
I will check with the firmware Dev.
The timer fix is still a WIP. In the meantime, you can use the light sensor as a fake timer by sampling data at 1s intervals. Once you have 3 samples, you know 3 seconds has elapsed.
Hmm thank you very much for that suggestion. Unfortunately we are already using most of the boards ressources and can not afford setting up any additional routes. Also, we need to conserve as much battery as possible. So I fear that setting up another route to an additionnal sensor will not do us any good
But thanks. We will try to make due with the current situation and hope that your update will be out soon
Hello, I am sorry again.
We realised that this firmwarebug causes a lot more problems for us than we initially anticipated.
Has there been any progress?
As an IT-guy I totally understand that developement can not and should not be rushed. So I get that "it is done when it is done". I just hope I can increase the priority on this issue a bit - if possible
Thanks again for your support!
Yes, our firmware dev published a release candidate. Barring any unforeseen issues, it should be available for the public tomorrow.
Uh that sounds great. Thank you very much for the heads up!