Open lollopes opened 4 years ago
GrumpyOldPizza
commented
4 years ago 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
commented
4 years ago 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
commented
4 years ago 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
commented
4 years ago 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
commented
4 years ago Is this still an issue ?
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