DeviceTimeReq LoraWAN 1.0.3
Home › Forums › Lora Network Server › DeviceTimeReq LoraWAN 1.0.3
Tagged: DeviceTimeReq 1.0.3
- This topic has 2 replies, 2 voices, and was last updated 6 years ago by
Guy.
-
AuthorPosts
-
March 13, 2019 at 8:19 pm #27396
Guy
ParticipantHey
I am trying to get LoraWAN 1.0.3 DeviceTimeReq / DeviceTimeAns working on the Conduit LoraWAN Network Server. My understanding is that this is now supported on the latest version.I am running AEP 1.7.0 and the LoRa Network Server version shown on the LoRaWAN Network Settings Page is now 2.2.12
The devices are set using End Device Profile LW102-OTA-AS923 which is set to Mac version 1.0.2 (the default).
So I am wondering:
1) Does the AEP version indeed support DeviceTimeReq in this version, or do I need to use the mLinux device;
2) Do I need to obtain a different End Device Profile for LW103 to activate LoRaWAN 1.0.3 Mac commands, and if so where do I get it.FYI – my devices do currently work and are tested on an Actility network. I can see that the Conduit is not sending the DeviceTimeAns MAC response 0x0D
Thanks
March 14, 2019 at 7:36 am #27407Jason Reiss
KeymasterProfiles can be defined on the LoRaWAN > Profile page.
The LW102-* profiles are provided as examples.If a device is set to MAC Version: 1.0.3 a DeviceTimeAns should be sent in the first downlink after join or when DeviceTimeReq is received.
mLinux and AEP use the same network server.
Looking at mqtt output on Conduit I see if a 0x0D is received a response is sent. The device profile should not matter.
admin@mtcdt:~# mosquitto_sub -v -t lora/+/+ ... lora/00-80-00-00-00-00-c9-54/mac_recv {"appeui":"16-ea-76-f6-ab-66-3d-80","deveui":"00-80-00-00-00-00-c9-54","gweui":"00-80-00-00-a0-00-15-8e","id":13} ... lora/00-80-00-00-00-00-c9-54/mac_sent {"appeui":"16-ea-76-f6-ab-66-3d-80","deveui":"00-80-00-00-00-00-c9-54","gweui":"00-80-00-00-a0-00-15-8e","opts":"0db10cb54996"}
March 18, 2019 at 10:52 pm #27455Guy
ParticipantThanks Jason. I managed to get this to work.
Just to close the loop for those who may run into this issue:
I had a mismatch on the DownlinkDwellTime settings on the MultiTech Conduit versus my LoraWAN stack (STM/Semtech). So I was not processing any downlinks at all, Mac commands included.
The Actility stack can start with DwellTime 1 on AS923 (default for Semtech stack) and then sets it to 0 with a MAC command on the first downlink. This gets the device in a better config for packet size.
The Conduit requires that the LoRaWAN settings match the stack and does not attempt to change it.
So I needed to change the AS923 regional parameters settings in the Semtech stack to DwellTime = 0 and set the Conduit accordingly.
-
This reply was modified 6 years ago by
Guy.
-
This reply was modified 6 years ago by
-
AuthorPosts
- You must be logged in to reply to this topic.