Open NetSensors opened 5 years ago
Same issue here. Have you been able to solve it @NetSensors ?
I am also experiencing the same issue, has anyone solved the problem ?
Can confirm, the issue still stands, and even without saved sessions, downlink works only a fraction of the time.
I have not been able to confirm missing downlinks in any case. Remember that there is always packet loss over the air. Perhaps this is what you are seeing. In my local testing the gateway is always close by ...
Same issue here (Europe/Netherlands/KPN), are other using same region/provider? Gateway close by or at longer distance does not seem to matter. Analysis suggests the Rx1DrOffset parameter is not persistent over resets. This causes downlink messages which are transmitted in RX1 to be not received after a reset....
Additionally I also regularly experience problems with network level messages causing OnTransmit callbacks. Below a screendump of a power analyzer showing currents of an IoT device indicating the ongoing LoRa radio communication. First a join is made. Then 3 'application' uplink messages are sent (back to back), each transmission having data in the RX2 window and each uplink correctly followed by an OnTransmit callback at the end of the RX2 window. Then two network level uplink messages are sent (not application initiated!). Then an additional/erroneous OnTransmit callback is called....
I have one of those oki power analysers best piece of test kit I have bought.
Sent from my iPhone
On 15 Oct 2020, at 16:04, nelisse notifications@github.com wrote:
Same issue here (Europe/Netherlands/KPN), are other using same region/provider? Gateway close by or at longer distance does not seem to matter. Analysis suggests the Rx1DrOffset parameter is not persistent over resets. This causes downlink messages which are transmitted in RX1 to be not received after a reset....
Additionally I also regularly experience problems with network level messages causing OnTransmit callbacks. Below a screendump of a power analyzer showing currents of an IoT device indicating the ongoing LoRa radio communication. First a join is made. Then 3 'application' uplink messages are sent (back to back), each transmission having data in the RX2 window and each uplink correctly followed by an OnTransmit callback at the end of the RX2 window. Then two network level uplink messages are sent (not application initiated!). Then an additional/erroneous OnTransmit callback is called....
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.
Further investigating into the RX1 downlink problem suggests the following:
Some initial trials with a fix from the application side, showed this could indeed be the cause of the problem. The fix is now recoded in (hopefully) the proper place in the LoRaWAN.cpp file, additional trials are now ongoing. Maybe others can do the same?
In function LoRaWANClass::_joinOTAA(LoRaWANCommissioning *commissioning) change lines 2625-2634 to:
if ((_session.DevAddr == 0) || !_Save || !_restoreParams())
{
return _rejoinOTAA();
}
else
{
_restoreADR();
// Push restored params to Semtech stack
_setParams();
return _rejoinABP();
}
Thanx for finding that. I checked throu the whole logic over and over again and did not see that.
Great to be of any help! I assume the additional OnTransmit callbacks are not related to this param restore? But I think they are indeed triggered by the MAC information exchange between node and provider, any hints for me for code paths to look into?
I'm getting some strange behaviour with downlinks not being received when LoRaWAN.setSaveSession(true);
The first downlink seems to be received after a new session is created then after a reset and continuation of session it doesn't accept downlinks.
I'm using the example code with a receive callback added. See below