RUI3 4.0.6 RAK3172
I’m getting an AT_BUSY_ERROR after a AT+PSEND=
What could cause this error?
Here is the sequence.
+EVT:RXP2P:-12:13:…
+2.2ms
AT+PRECV=0
+0.5ms
OK
+82ms
AT+PSEND=…
+34ms
AT_BUSY_ERROR
Now I do have another radio transmitting at the same settings. Could it be receiving a packet from that radio just before it closes RX mode?
I’m only waiting 2.2ms before closing RX mode.
Knowing how the radio works there is a delay of before +EVT message is received. Would another packet being received cause this AT_BUSY_ERROR just before the RX mode was closed, in that gap?
How to prevent this? Can the radio be flushed before the AT+PSEND?
Guess you have CAD avtivated. Then the message means the packet was not send because CAD couldn’t find a free time on the frequency to send the packet.
(as discussed in our other thread)
You can see here that AT+PSEND= is tried three times before success (OK). It’s 32 ms + AT+PSEND= delay, for a total 46 ms per try, or 92 ms total.
So it works pretty good. I have a while loop and will try until success. In my situation packets are typically a few hundred ms, not likely to take more than few seconds before success.
Thanks for that test. I still think the CAD functionality can be improved. I hope we can get something even better in the next release (or a staging version in between)
According a paper by Semtech about the CAD (AN1200.125) it should take [tsymbol + )32/BW)].
i measure 32ms. Tsymbol = 2.048ms, 32/125000 = 0.25ms. Why then does CAD take 32ms?
I do not have an immediate answer. I will ask our R&D team.
The RUI3 sources are open, you can have a look by yourself how CAD works in RUI3 and how the timing is setup.
I have attached the document.
My feeling is all the internal handling of the CAD and the routine may look at the CAD a few times
to increase the probability of detected a LoRa carrier results in the the 32ms delay.
I my case after monitoring the scope for a a few days, I’ve seen a few occasions where are there are several attempts before the the PSEND succeeds. Every attempts shifts the sequence by 32ms, thus changing the sequence by 120ms, which is the approximate air time of the second LoRa broadcast. I have 2 nodes running, one at 5s and the other at 30s.
Thank you.
(Attachment cad-ensuring-lora-packets.pdf is missing)
Hi @frank_r
Can you send the document as direct message to me. It seems the forum didn’t attach it to your message.
I checked the documents I have, and 32 ms is definitely too long. If you have time, can you try the custom AT command firmware I attached in my last message?
