Downlink stop working

[lollopes]

Dear GrumpyOldPizza,

Following your last commit to the library something has happen with downlink messages in class A. I was able to have downlink payloads coming to my end node for the past 4 months. After your new commits I can not receive any downlink message. Do you have any clue of what is going on ?

Regards,

Lorenzo

[GrumpyOldPizza]

When did you update the code last time from the github ?

I am rather certain that there is nothing outstanding in terms of TX/RX1/RX2 timing with the lastest source.

Downllinks had been checked on EU868 and US915. RX1 and RX2.

[lollopes]

Dear GrumpyOldPizza,

I actually checked and I do not have the latest version on the package directory of arduino. Therefore the problem should come from my side. I think you can close the issue.

Nevertheless, in the past I experienced some inconsistency issues on downlink messages as listed below:

• Lets assume I send a message every 3 minutes to the grasshopper: some packets seems to get lost but once another packet is received the downlink counter seems to increase of one extra value. I.E Send one message -> wait max 3 min to receive -> no packet received -> counter = 0 -> send another packet -> packet is received -> counter = 2. How is that happening shouldn't the counter be at 1 ? It seems like the queue Is aware of the missing packet. I was wondering if there some time constraits that you think I am not taking account of ?

• I am using these lines in the setup() function:

  LoRaWAN.setLinkCheckLimit(16); LoRaWAN.setLinkCheckDelay(8); LoRaWAN.setLinkCheckThreshold(4);

I am not really able to understand what these limits and threshold are as I found them in the example code but they seems to have an impact on the amount of downlink packet that are lost. By having them commented or not I have noticed a difference in packet loss. Do mind explaining what these functions are for and if in your opinion they might have an impact on downlink consistency ?

Is there a chance you can help me with all that ?

Regards,

Lorenzo

[GrumpyOldPizza]

The setLinkCheck* APIs are for injecting LINK_CHECK commands into the uplinks to force a response from the gateway. That is used to detect whether there is still a connection to the gatewat. This is a fallback in the absense of ADR (which requires a downlink every so often), and confirmed transmissions.

Should not have anything to do with your problem.

What is your gateway (hardware, is it TTN by chance ?) ?

[lollopes]

Dear GruumpyOldPizza,

First of all thank you so much for your time and support. Unfortunatelly I am not using a TTN gateway. I am using a Tektelic Pico. I did not highlighted before that the test conditions are always the same in the sense that the distance between gateway and end node is not varied. I do not understand what do you mean when you say that ADR requires downlink every so often. Our server sends downlink payloads every 3 minutes and I tried to activate the ADR since I know that ADR is activated by the node and not by the nework server operator. This did not solve my issue anyway: even with ADR I am not able to be consistent in the downlink. It seems to be very umpredictable. I will give you another example. Before I can be sure that my end note will receive data without loss every 3 min I have to make sure that the node can receive 3/4 downlink messages. As a matter of facts it seems that a reset of the grashopper affect something in the network since I need multiple reset before I can get to a consistent (no packet loss) downlink session. Given that I am using arduino I can't really see what is going on behind the scenes and I can't conclude if this is a problem caused by the LoRa WAN server provider or if it is in the mote. Do you have any ideas or suggestions ? Do you want me to share the code I am using to get downlink messages ?

Regards,

Lorenzo

[GrumpyOldPizza]

Is this still an issue ?