I have one additional question regarding devices based on 1.0.3 release.
Some of my devices will have to be working with a loraserver suite implementing only 1.0.2 (loraserver v0.25.1 and lora-app-server v0.19.0)… The thing is that this suite can’t be upgraded to last versions… since it does not have internet access.
Do you think that devices working with classA working on 1.0.3 might work?
Yes, except for some additional MAC commands that have been implemented, I thought two it would work… But an expert confirmation is always welcome!
Thanks
@brocaar GPS? Why is that needed for DeviceTime syncing?
EDIT: Reading the spec now. I guess it’s because GPS is a pretty accurate source of current time and the spec demands ±100ms accuracy? What If I’m OK with less accuracy? Any way to replace GPS as time source with some other time source?
Aaaah… after reading the implementation of handleDeviceTimeReq it all makes sense.
The loraserver just echoes back the GPS time that the DeviceTimeReq (uplink) message was received by the gateway. Hence your comment about that the packet forwarder needs to include the GPS time on uplink. Thanks!
Yes, that is correct. Please note that depending your setup there might quite some latency between the network-server and gateway (e.g. when it uses a cellular network). So the only accurate timestamp to use for this mac-command is the RX GPS time forwarded by the gateway (as for Class-B it is important that the timestamp is accurate, also note that the timestamp is expected to be the in GPS epoch time thus no leapseconds).
@brocaar I noticed you added a fallback (still on master) to send the NS time in case no GPS time and no “time” value is present in the frame. Thanks for that! Any ETA for the next release that will include this change? Thanks!