search

kmartinez / dgpstracker2

4 stars 1 forks source link

Pyboard configuration with sleep mode and RTC #2

Open sua-dev opened 2 years ago

sua-dev commented 2 years ago

Going back to the previous issue that was talked about: utilising the RTC to force the device to wake up every 59 minutes to run its operations. Both the base and rover have to be in sync for this operation to fully work. We have been doing a little bit of testing with the pyboards using the pyb module and its associated functions linked with callback functions for now. If we can achieve a proper method that would force the device to wake up using either .stop() or .standby() that would work nicely and would mark off a task from the list of things we need to complete.

sua-dev commented 1 year ago

Having spent some time on this, there are additional issues to consider but are definitely solvable. pyb.RTC() uses the datetime() function to be able to store any incoming real-time information to update its settings. The issues that I've spotted with this, are that it needs 8 arguments, but we only retrieve 7. Along with this, I spotted that the UTC time we get from the GPS is slightly off... I'm a bit puzzled as to why that's the case but I'll do some digging either way... If I can at least get the timing written onto the RTC and get it to work from certain intervals throughout the day, this issue should be closed.

sua-dev commented 1 year ago

Modifications have been made since. rtc.datetime() now accepts the tuple correctly and the RTC has been updated. The issue now is to try and test out sleep mode. Since we can guarantee that the RTC works without any concerns, the challenge is to ensure that the device can wake up out of sleep mode using rtc.wakeup(). This should be straightforward but has been very questionable in the past due to forcing myself to hard reset the board. Thus, caution needs to be taken when playing around with these functions.

sua-dev commented 1 year ago

There is a rather annoying issue which should be addressed regarding the inconsistent timing. GPS time returns the format in UTC, which is fine, they seem to be out of sync with the actual UTC time by roughly 2.5mins. I'm confident this has to do with converting the byte-formatted messages to readable strings using .decode() after testing it a few times. The question is: Is there a different way to convert these messages and prevent these delays from happening in the first place?