We’ve recently tested the RAK11720 for lorawan and RS485 and here are some observations/questions:
1)We tried to use Serial1 for 485 at 19200 baud rate, and we forgot to set Serial0 to 115200. It turned out setting Serial1’s baud will also affect Serial0’s. That created a lot of problems for us and we were not able to download new program to the board. We tried different methods like doing AT+BOOT, pulling up BOOT pin, etc with no luck. And after several attempts the processor was bricked. We are now waiting for the Jlink adapter to see if we can recover it. We are quite convinced the Serial bug was causing the problem and we were not recovering it the right way. We replaced the core and set Serial0 explicitly to 115200 and so far we do not have any problem.
2)We tested Lorawan with a local chirpstack server with the following config: band=AS923, ADR=true. Confirm=true, rety=7, class=A.
a)We observed that if we didn’t set DR explicitly after JOIN sometimes api.lorawan.send() failed consistently. The server does receive some unconfirmed uplinks with no data. Also the send callback was never called. We have set DR=3.
b)We switched off the server intentionally to try the retry mechanism and saw the frame counter incremented for each retry, which we believe is not correct. Sometimes the server received the data but the device did not receive the confirmation. If frame counter increments for every retransmit the frame counter check will not work and server will receive duplicated data.
3)We are using the RUI best practice example in our program so we destroyed the main loop task and use only a timer to run our 485 and uplink occasionally, from the forum we believe we can save power by using api.system.lpm.set(1), but we also saw there are options to turn the lora radio or everything off by calling api.system.sleep.xxxx(). Do we need to do that or api.system.lpm.set(1) will be enough? And do we need to call api.system.lpm.set(0) to turn off low power mode when we need to use the 485 and lorawan or bluetooth? What should we do to achieve the lowest power consumption when we are not transmitting?
That is all we have seen so far. I understand there are quite a few subtopics already and I will be happy to put them under different topics if it is necessary. Many thanks for your help!
What RUI3 version are you using?
It is the first time I hear about a problem with baudrate.
I was using the RAK11720 in a soil sensor test with RS485 and there was no such problem with baudrate settings on Serial and Serial1.
For debug output I used Serial, not Serial0, for RS485 I used Serial1.
If you choose the DR too close to your uplink packet size, the uplink can fail, because sometimes the LoRaWAN stack adds additional information to the packet, device status info that is requested by the LNS.
If using api.system.lpm.set(1) you can leave it just on. It does not influence the functionality of API calls to use Serial1.
Yes it’s Serial but I think they are the same. The problem came about when you only set Serial1 but not Serial in the program. I believe this is repeatable but we don’t dare try again.
I am using DR3 but we are only sending 20 bytes now. We have just found a new problem that if we turned off the server and then turned on again, the api.lorawan.send() kept failing with an error code of (4) and can never recover. I could only reset the MCU for it to work again. Strangely even with this failure sometimes we got a send callback which indicated TX_OK(but server never received anything).
Occasionally after several resent attempts we got an error code of (1) and later the send action becomes successful again. But lately it was not happening.
For every sent packet, the callback came back with an error code of 2, but a +EVT:TX_DONE event was also received and the server did receive the data. However, if we turned off the server and on again, the server never received any data again but we got the same return messages.
Please let me know if you need more info. For the new firmware release after 4.2.1, is it possible to make sure the frame counter doesn’t increment for a retry?
Error 2 is strange, it means TX timeout, I never saw this error ever.
The errors you are seeing are more than strange.
The fCount is handled inside the LoRaWAN stack, there is no function “to make sure it doesn’t increment”. It is handled by the stack following the LoRaWAN protocol.
All you problems are very strange and make no sense.
Can you share your code?
I found that api.system.lpm.set(1) was the culprit. With this on even the confirmed packets are not getting any confirmation and will try to resend. It seems the lpm function sleeps the device too soon. With lpm turned off, now unconfirmed packets are getting successfully sent message from the callback. But the server is still not able to receive any data packets after a restart. For confirmed packets we are getting the confirmation back when lpm is turned off.
So what is the best way to save power between transmission?
I believe the lorawan stack is not supposed to increment the frame counter for the retransmission of the same uplink message if the device doesn’t get an acknowledgement to prevent replay attack. Could you please kindly check? Thank you.
We tried both lpm(1) and sleep(time). For lpm if we ever set it to 1 even after setting it back to 0 later Lorawan confirmed send will fail. For sleep(time), after wakeup Lorawan confirmed send will also fail. Maybe when your colleagues are testing the new firmware they could test this scenario also. It is very important for us that we can put the device to low power when not sending packets. Many thanks!