I’m trying out the Stm32 LRWAN1, using their official “Cube” libraries (v1.2.0). I noticed that the end node example is making the Device Time MAC request when it sends a packet. However it seemingly is not getting a response back as it reports an error.
I’m somewhat unsure where the problem might be. What is required on the server side for this to work? Any clues as to where I should start debugging? What does the Gateway need? Any flags I need to activate on loraserver?
Hi, I tried out the End Node example also and it didn’t work. However, I found that the AT command example worked well. Apparently, it was a problem with lora.c file. This file is different in both examples. When I transfer the code (main.c) manually from End Node to AT command example, then everything (means making the AT command example into the End Node example) is fine.
I’m not sure if we’re looking at the same issue here…
However comparing both lora.c files, doesn’t seem to show any particularly pertinent differences in regards to deviceTimeReq. The main changes are only providing functions to the AT interface, allowing configuration of lorawan parameters, and a simple copy shouldn’t really work.
regarding your issue, in lora.c of i-cube-lrwan_V1.2.0 you have a switch line 59:
* Select either Device_Time_req or Beacon_Time_Req following LoRaWAN version
* - Device_Time_req Available for V1.0.3 or later
* - Beacon_time_Req Available for V1.0.2 and before
They’re functionally the same, I guess, but semantically beacon time should only be used for Class B
The beacon time was deprecated, I believe at the time Class-B was still experimental. The device-time request is a more general way of communicating time.
The problem is that not all the gateways have a GPS and report the RX time. When it does not have a GPS, it only reports the internal RX timestamp, which does not relate to a real time. What I understood from last LoRa Alliance meeting is that the network-server MUST always respond to the device-time request. I think the best I could do is use the server time, which depending on the latency between the gateway and network-server could not be accurate, but at least it is something.