It doesn’t look like this works for me. I also started with a clean DeepSleep example, changed MAX_SAVE, added the three keys, commented out the code like you suggest.
Still takes a full minute before I see the JoinRequest. JoinAccept is sent by the network but Wisblock doesn’t do anything. It just hangs there. No periodic transmits or Join retries.
I had the same thought, but the duplicate uplink and used nonce are both related to me having multiple gateways around. Some of the gateways have high latency. This causes the same uplink to be seen multiple times by the network. The delayed uplinks are correctly seen as duplicates, and therefore also already used nonces.
First JoinRequest is received
Join accept sent for this DevNonce
Delayed duplicate of JoinRequest received
DevNonce already used, ignored
This however do not explain why this wisblock takes a full minute after startup before it starts joining.
I’ll download fresh copies of the BSP and sx126x library and test again.
Note in the above log how it takes 5 seconds for the device to join.
The RAK4631_DeepSleep_LoRaWAN example (with if (!xTaskCreate(loraTask,... commented out) takes a minute before it tries to join, the join seems to fail, and then it gets stuck, never transmitting again:
As a sanity check I took a fresh RAK4631 out of a packet, updated the firmware, and wrote the DeepSleep example to it. The behaviour is the same, where a join only happens after 1 minute, and the firmware hangs after printing LoRaWan init success.
Because the new board is not in its enclosure, I am able to see the LEDs better. I’m seeing the RED LED pulsing brighter sometimes. This is in the current state after LoRaWan init success is printed.
Hello @jpmeijers@carlrowan
The red LED is the charge indicator, it is not controlled by the MCU, only by the charger chip. It flickers while charging or if no battery is attached.
More important, I found the 1 minute delay.
In lora_handler.cpp look for
And change LORAWAN_DUTYCYCLE_ON to LORAWAN_DUTYCYCLE_OFF.
This removes the 1 minute delay for me.
Why on EU868 LORAWAN_DUTYCYCLE_ON triggers a 1 minute delay is something I still have to find out. It looks like the DutyCycle is enforced and the sending is delayed by 1 minute. Looking into it right now.
@nmcc My library is based on Semtech’s code as well.
So far I could only find that if DutyCycle is enabled, it delays the first join request by 65 seconds. Still trying to find out why it does it. And it seems to be linked to EU868.
My ‘mess’ is that it joins promptly but then the module concerned silently drops the first uplink if it’s too soon after the join. And then there is another mandatory delay required before I can send the second uplink.
This makes sending a boot/config/status message and then first set of sensor data a bit tricky.
I either want feedback to know it didn’t actually send or to know exactly what delay the firmware can tolerate - but it’s not RAK so it’s not an issue for here as such, more of general concern for those using LoRaMac-node.
Chaning to LORAWAN_DUTYCYLE_OFF indeed makes the JoinRequest being sent much sooner. But the join still doesn’t succeed. One can also see that the LoRaWan init success is not printed to Serial (at least not within 10 minutes).
To eliminate another variable I am now in a location with only a single gateway connected to TTN. That also didn’t change the behaviour.
DeepSleep vs normal example
The normal example joins immediately, and joins successfully. Only the DeepSleep example has the issue - and also only since the the BSP and sx126x update. Both of these examples use the same lora configuration and library. Why does the deepsleep fail and the normal one not? Has to be the deepsleep code?
Does the DeepSleep example disable the timer used for the LoRaWAN timing? Or maybe change its period?
Can you send me the sketch that you are using at [email protected]? I’ll change the EUI/Key and try it.
Mine is working ok and not stopping. It does then the 2minute interval uplink. Though I have the same issue on 1minute delay before joining but it is gone now when the dutycyle is set to off.
It tested it in two RAK4631 (using same keys/EUI).
I’ve sent it to you, although it is just the example with the lorawan task commented out, serial debug enabled, and my keys added. But please try it on your side and let me know.
I’ve also included a compiled hex version which you can try. It is possible that we are using different versions of the toolchain, even though mine says it is fully updated.
I tried your example and it doesn’t work to me. Got the same issue you experienced. Have you tried the modifications suggested above by @beegee ? Those works for me and solve the issue. Sorry I wasn’t able to track the changes and I thought we are aligned in the code.
Here is the code that works for me. Can you try? You can change the EUIs and Key.
Also commenting out the attachInterrupt in addition to the xTaskCreate indeed solves the problem where the firmware stops after the JoinRequest. That solves the major part of this issue.
The one minute delay when duty cycle is enabled is however still a concern. Also strange that this is only a problem with DeepSleep and not the Normal example.
A strange thing that I see here is that OnRadioRxDone => FRAME_TYPE_JOIN_ACCEPT is only printed before the next TX 2 minutes later, not directly after the JoinRequest.
The examples in the Arduino BSP will only be updated when I release the next version of the BSP (which is in testing right now). I am talking about our WisBlock examples repo.
This is not strange. Serial is linked to the loop() task. If the loop() task goes into sleep, there is no Serial output until the loop wakes up. This is an FreeRTOS thing and I cannot change it.
A (very bad) work-around is to put a delay(100) after the Serial.println() in the callbacks. This gives the Serial time to send the data before the loop() goes back to sleep.
Again, not strange. The LoRaWAN_OTAA_ABP.ino has LORAWAN_DUTYCYCLE_OFF as default. If you change it to LORAWAN_DUTYCYCLE_ON you see the same delay.
