Hi,
Here are a couple of blog posts I’ve made about my recent time experiments with MCCI LMIC on an AdaFruit M0 with LoRaWAN.
The first one covers using the get network time function to set the M0 RTC to something approximating the correct time.
The second one shows how to use the an oscillator and timer/counter to provide a steady 32.765 KHz tick source for LMIC that survives standby mode. Unfortunately this requires modifications to the LMIC source code.
There should be another post coming showing how to sleep while still allowing the LMIC job scheduler to work correctly. That requires a new function similar to os_queryTimeCriticalJobs()
, which I’m sure I nabbed from someone else showing how they went about solving the sleep problem. It won’t be the most efficient firmware ever, but at least it can sleep for long periods of time while still allowing MAC command conversations to be had with the server.
The third blog post is up showing how to determine how long the Feather can go into standby mode, while being awake around the times LMIC wants to run jobs.
My approach is to add the new function mentioned above which returns the ostime_t of the next runnable job. I think this is ok as long as LMIC isn’t going to add a new job except as a response to the currently running one, for example to reply to MAC commands. It may fail if the next job is longer in the future than the ticks roll-over, but I think that still gives a workable time of 18 hours between jobs.
I think my modifications are clean enough that I can keep a fork up-to-date by pulling the main repo into it, but are not suitable for merging back into the MCCI version. I don’t think the code I’ve changed is likely to change in the MCCI repo unless the os_ and hal_ stuff is revamped to make my changes obsolete.
I have not posted my version to github yet but the blog posts contain all the changes.
My changes would also make a 64-bit tick counter easy to do using a counter overflow interrupt, but that feels like a change that isn’t really necessary at this point and I don’t understand the LMIC tick system well enough to know what effect a 64-bit counter would have.
Another possible change is to halve the 32.768 KHz source using a pre-scaler so the tick overflow happens only half as often, but I can’t see any advantage to that. I think a 16.834 KHz frequency is just at the bottom of the allowable ticks/second range.