TimeBase objectives
We are looking for a solid definition of the TimeBase for LoraLight.
We should not be too strict as it will complicate deployment at low cost for many devices.
We should not be too easy either as we would prevent good airtime efficiency.
I think a 100ms granularity for timekeeping is the desired level based on the below arguments. Feel free to disagree and weigh in why. (this is a continuation of the Slack discussion based on additional research)
Considering typical transmissions for uplink will be between 31 and 400ms (5-255B PhyPayload,SF7125kbpsCR45) (51B and 120B give 100ms and 200ms)
Considering we can have a feedback mechanism on transmission success rate and an ecosystem where most devices will be deterministic, our node+appserver can 'search' for a time slot that is not colliding with others. If it would be successful together with its 'peers' then we could stack 10 devices that send 51B in a 1 second time slot. Or 5 which send 120B etc.
Now, it might take time to evolve to half this sophistication, but it does not hurt to now define the 100ms granularity. Initial devices can just choose to send at x.0 seconds out of laziness. Future devices can then be smarter and use the still available x.3-9 opportunities.
How about the possibilities of accurate timekeeping? There are normal RTC chips (e.g. DS3231) that incorporate temperature correction in case temperature is an issue. They also typically incorporate means to adjust the rate by changing the same capacitor banks based on user settable registers. And we have a mechanism where we can calibrate these registers because we can receive perfect) time all the time!* My opinion is that this way our device can achieve a drift of less than 10ms per day at no excessive cost. The DS3231 can adjust its clock speed with a 0.1ppm granularity! The PCF2129 1ppm. The non temperature compensated PCF8523 can correct with 4ppm granularity.
The practical matter of waking up at such a granularity can be solved by storing time by a known offset or simply waiting up to 0.9 second after waking up.
If the R factor for DevTrm is a multiple of 100ms we need 3 bytes to describe D and R. The maximum for D is then 256^3 = ****1677721.6s~20 days With two bytes and 1s the maximum is 65535s=18h which is anyway too short.