You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Gurpreet observes bug where our sample time stamps creep longer and longer, from the original period set. This is likely because we are scheduling the wake up next alarm signal interrupt for the DS3231 at the end of each sample cycle. But - if a sample cycle takes several seconds, those seconds will be added to the end of each period, delaying further and further.
Hardware in Use
Hypnos, in Loom and outside of Loom
To Reproduce
Use any of the data logging examples.
Expected behavior
Timestamps should be consistent to the period we wish (e.g. timestamp samples should be about 5min apart each time, not 5min +5sec)
Additional context
The proposed fix is just to change the place where we are scheduling all our sample alarms from the End of the sample cycle, to the very Start of the cycle, right after we Wake from the DS3231 interrupt signal. The DS3231 is powered on a coincell and never sleeps - so, we can set the next alarm even before everything else has been properly been powered on (power up cycle).
We need to Test this hypothesis is effective.
Then update all examples with the new order of operations.
The text was updated successfully, but these errors were encountered:
Describe the bug
Gurpreet observes bug where our sample time stamps creep longer and longer, from the original period set. This is likely because we are scheduling the wake up next alarm signal interrupt for the DS3231 at the end of each sample cycle. But - if a sample cycle takes several seconds, those seconds will be added to the end of each period, delaying further and further.
Hardware in Use
Hypnos, in Loom and outside of Loom
To Reproduce
Use any of the data logging examples.
Expected behavior
Timestamps should be consistent to the period we wish (e.g. timestamp samples should be about 5min apart each time, not 5min +5sec)
Additional context
The proposed fix is just to change the place where we are scheduling all our sample alarms from the End of the sample cycle, to the very Start of the cycle, right after we Wake from the DS3231 interrupt signal. The DS3231 is powered on a coincell and never sleeps - so, we can set the next alarm even before everything else has been properly been powered on (power up cycle).
We need to Test this hypothesis is effective.
Then update all examples with the new order of operations.
The text was updated successfully, but these errors were encountered: