Why is switching between TX and RX slow? 3172

Now i’m trying make half duplex Serial UART ustin P2P.

it seems that module slow to change mode TX to RX and back.
the maximum switching speed is approximately 1 second?

i’m intresing to send and recive 20bytes on maximum speed P2P.

Not sure what Serial UART has to do with P2P ???

When sending/receiving over LoRa P2P you don’t need to switch modes. You can use AT+PRECV=65533 or api.lorawan.precv(65533); to stay in RX mode and still can send packets out without stopping RX mode of LoRa P2P.


Also keep in mind that AT+SEND or api.lorawan.send() are not blocking. They return immediately and the packet is enqueued for sending. Depending on your P2P settings and packet size it can take time before TX is finished.


Well, I would have done that code different, but that’s just me.

What are your LoRa P2P settings? Where do you see a delay?


Did a quick test with your code, but slightly changed.
(1) use api.lorawan.precv.set(65533); // Stay in RX mode, but enable TX
(2) on TX side, only wait for RX confirmation from receiver, then send next package, no delay(2000)

With this code the TX is sending a packet in less than 200ms interval (measured 118 to 183ms)
Which is expected with my LoRa P2P settings:

  • BW 125kHz
  • SF 7
  • CR 4/6
  • Preamble Length 8 symbols
  • Payload length 14 bytes

With this settings the SX1261 Calculator tool gives me ~52ms air time. Two packets times 52ms == 114ms and the difference is the code run time, depending on what RUI3 is doing in the background.

RX-P2P.ino (1.5 KB)
TX-P2P.ino (1.5 KB)

@beegee you’re great!

that working.
now i added on TX side , when recived data lost.

if (rx_done||count_waiting_recv>200000)

but, if count less 2000000 rx_done every time FALSE
How can I do this better?

What is count_waiting_recv counting?

Can you give me a code snippet to show where it is counting up?

Do you want it like a “time out” if the other side is not responding to a sent packet from TX device?

TX-P2P_v2.ino (1.6 KB)

Do you want it like a “time out” if the other side is not responding to a sent packet from TX device?

there was no need to transfer data; there was no confirmation of receipt of the data ( rx_done =False some times! ). it does not send data RX does not receive and the entire transmission freezes.

You define

int count_waiting_recv;

int is signed 16 bit, so the counter overflows after 32765 and gets negative. And it will get there very fast, because you have no delay in your loop().

If you need large values like 200000, you should use uint32_t for that variable.

Instead of a counter, I would use millis() and compare the time elapsed to detect an timeout.

TX-P2P_v3.ino (1.9 KB)

Thanks a lot!!!

пн, 12 февр. 2024 г. в 14:57, Bernd Giesecke via RAKwireless Forum <[email protected]>:

Hello @beegee

How to catch RECIVE ERROR ?


Not sure, never saw an RX error with P2P, but I am not using P2P a lot.
In the case you see +EVT:RX_P2P_RECEIVE_ERROR do you get anything on the RX callback function.

there is nothing about the possibility of obtaining status.

A reception error may occur and incorrect data may be received, how can I track this?

Maybe there is an EVT message handler callback?

I have to check with the R&D team. I am not aware of any special callbacks in case of a receive error.