Now writing a small Arduino sketch using lib version 3.4.2-rui3_22q1_update.112 and applying the very same AT commands above results in +EVT:JOIN_FAILED_TX_TIMEOUT 4 seconds after command (using example LoRaWan_OTAA brings same result). What do I miss? Any background of the error_msg that may help?
I did and its same result. I have seen the strange problem after playing with lora p2p.seems that this changes some internal settings. The error message may reveal more.
I am very much willing to understand your issue. RUI3 allows you to run AT Commands and custom FW simultaneously. Though looks like a nice feature due to its flexibility, the trade off is that there can be multiple of edge case that could pop out. I am thinking if you can give more info about your scenario so I can try to replicate it.
I tried your sequence above and all seems to work fine both on AT Command and via RUI3 APIs. Maybe there is some setting you enabled that causes the JOIN fail callback.
I think the special situation with my application is that I use lorawan and p2p mode together. After boot the device tries to get into lorawan. If this fails it switches to p2p, reboots and communicates p2p. After power on the same thing again.
It looks to me that the device has some internal variables in flash that get mixed up this way. I have in front two 3172S board with identical firmware. One board sends the JOIN_FAILED_TX_TIMEOUT event, the other just reboots when try to join. The command api.system.restoreDefault() with or without power sometimes helps to get out of the error but not always.
Whenever you need more specific help or any bug you think within RUI3, just let us know so we can have a look and fix if needed.
Btw, I am not sure how you manage your switching like when to move from LoRa P2P to LoRaWAN (vice versa) but I believe this should be possible but only one at a time.
Well, I do need help. The situation now is that after view times switching between p2p and lorawan the modules become unusable since they don’t join anymore.(either by RX_TIMEOUT or by reboot). A closed source with limited docu its impossible to debug this. If you are interested I can send you the whole code in PN(how ?)
What would help?
A way to clean all internal status variables/cache/flash to get the device back to factory default. api.system.restoreDefault() only seems to be a partial solution for this. May be its possible to directly write the portion of memory, so that I make a backup when booting first time and rewrite directly into memory on every mode-change
You can directly send me the sketch/code [email protected] (hopefully not thousand lines )
I will try to do replicate your LoRaWAN and LoRa P2P switching setup and see if I can see the issue you have. This will be helpful for us if the issue is repeatable easily.
Hi, I spent two more days trail and error on the stack and I guess I got some insights. The stack seem to have a minimum time between JOIN or P2PSetup and sending first packets, something between 3…8 seconds guess. If this is violated the stack does not respond with an error message but reboots.
What is the minimum time. For production testing I we will send a LoRap2p ping/pong to test rssi, antenna etc. Waiting for 10 sec is something the Chinese workers don’t like.
Another question: Is it allowed/recommd to use sleep() inside lora callbacks ?
)