Hi all,
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?
Hello,
several users of couple Cube_LRWAN / loraserver have encountered a problem with this version of cube v1.2.0.
I didn’t yet investigate why but the previous version of LRWAN cube that is to say v1.1.x works well.
The release of cube V1.2.0 was in july 2018, I think this concerns if I’m not mistaken updating of Class B rules.
So normally this should not concern class A devices, except that we can observe that since this release class A devices no longer works on the loraserver…
Stay tune because sooner or later I will have an answer 
I’ve found that normal messages work fine with loraserver, they reach the server.
The only issue I’ve encountered is that the node states that this mac command does not. Are there other issues that I’m not aware of?
Ok so much for me, at the last news several people on this forum have encountered a problem with this version.
If it’s works except your issue so much better, so I’m going to try to implement it again.
Do you encountered a delay to send an uplink after a join server more than 2 min or after a join you can received directly your uplink ?
Yes. It sends one uplink immediately after joining, then there is a long delay, where the send message function runs, but the node does nothing. After a while it starts sending uplinks regularly.
Is there a solution for that?
Hello,
you can see a previous post (particularly last message) where I talk about a delay after join server.
https://forum.loraserver.io/t/delay-before-receive-first-uplink-after-otaa/2520/6
don’t hesitate if it’s not clear.
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…
That’s interesting.
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.
Hello,
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
*/
#define USE_DEVICE_TIMING
Plz comment #define USE_DEVICE_TIMING
I known quite by chance through another topic 
Of course, but loraserver should understand the latter as it is 1.03 compatible.
They’re functionally the same, I guess, but semantically beacon time should only be used for Class B
Hello,
@brocaar what do you think about it?
According to you the problem comes from the server or device?
Julien, Orne won’t be available for a couple of days, probably till the weekend or next week.
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.
Feedback is welcome 
This change makes the device-time mac-command possible without GPS / when the GW does not provide a RX timestamp: