LoRaWan MAC version 1.0.3


#1

Hello @brocaar in the next release of loraserver do you plan to implement the LoRaWan MAC version 1.0.3 ?

No special need in the moment it’s just to be up to date with the software release of my devices wich is covered with this lorawan MAC version.

https://www.st.com/content/st_com/en/about/media-center/press-item.html/n4075.html

Thank you.


MACVersion, what is it?
OTAA failed / Debugging device activation OTAA issues
#2

Yes, it will be added to the next release :slight_smile:


#3

TiTop, super hard worker as usual thank you…


#4

Hello Guys,

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?

Thanks a lot


#5

This should not be an issue as Class A was not changed. I believe the changes were mostly Class-B related.


#6

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


#7

Any plans to support the new (v1.0.3) DeviceTime commands to support time-syncing of RTCs in LoRa node devices with the server’s time?

Thanks


#8

It is already supported since LoRa Server 0.25.0 when Class-B support was added :wink: (you do need a gateway with GPS for this!)


#9

@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?


#10

In case you are OK with less accuracy, you would need to change the packet-forwarder so that it includes the GPS time on uplink: https://github.com/Lora-net/packet_forwarder/blob/master/PROTOCOL.TXT#L134.


#11

@brocaar after reading your message more carefully, I think that you may be talking about a different thing.

With DeviceTime syncing I meant the DeviceTimeReq and DeviceTimeAns MAC commands that were added in the LoRaWAN v1.0.3 spec:


(From https://lora-alliance.org/sites/default/files/2018-06/lorawan1.0.3_final_0.pdf)

Searching through the code it looks like it’s supported:

Is this also what you were talking about?


#12

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!


#13

:slight_smile: 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).