cancel
Showing results for 
Search instead for 
Did you mean: 

B-L072Z-LRWAN1 LoRa RxTimeOut

Sully Mind
Associate
Posted on June 19, 2018 at 15:16

Hello everyone,

I have a discovery board B-L072Z-LRWAN1 running the End Node LoRa application provided in the

I-CUBE-LRWAN

package.

My problem is the next :

- The join procedure works well.

txDone

rxDone

JOINED

- But when a frame is sent, the following messages are displayed :

txDone

rxTimeOut

rxTimeOut

whereas the frame is correctly received in the backend.

Does someone know the solution of this issue please ?

#b-l072z-lrwan1
1 REPLY 1
Maxime DEWASMES
Associate II
Posted on July 06, 2018 at 11:41

By default the I-Cube-lrwan package does not enable Confirmed Uplinks without modifying some values in the code, that is because you shouldn't try to ask confirmed uplink if you send a lot of messages.

The 'issue' you are seeing here is not an issue, that's the actual program running...

Let me explain:

During the join procedure, the node will send an uplink and if the gateway receive it, it'll send back a message confirming the join and sharing some keys in order to validate the join procedure (not quite sure about the whole process)

After your node has joined a network (the gateway or a public network, which is TTN in your case i guess?) it will send unconfirmed uplinks every now and then (depending on your duty cycle), these messages will not have the ACK bit request enabled so the gateway will not bother trying to confirm the message, but that does not mean you won't receive the payload on your gateway... The node will always try to open 2 Rx windows after a Tx, because if it did not it wouldn't be able to receive messages or even to re-join a network if needed...

The RxTimeout just means the node hasn't received any information from the gateway during the required time and is going back to sleep after shutting down its radio module.

View it that way: opening Tx or Rx windows is not very power consumption friendly, so it's mandatory to keep these to a minimum. When your node is not trying to send message, it shutdown its radio in order to save energy, that's why you can only try to send a message back to your node after it sent a message, because you know that it'll have 2 Rx windows to receive it before returning to sleep.

This is normally pretty much working out of the box so you won't have to do anything to make this work.

I think i went out of the way a bit much here, but in case this could help any future readers i will leave it as is !

Oh and one more thing: the parameter to force the node to request ACK is defined in the main.c :

LORAWAN_DEFAULT_CONFIRM_MSG_STATE

You'll need the state LORAWAN_CONFIRMED_MSG (which is 1) to force it.

However i would like to remind you that you shouldn't request more than 8 downlinks from TTN per day on a working device (if you are still in the prototyping phase, don't bother too much about these limitations)

TL;DR: this is not an issue, this is the correct behaviour of the program!