unreliable communication on Seeed XIAO nRF52840 Sense

[pszczolo-jamnik]

Hi, thanks for a great library!

I observe weird timing for auto-ack transmission, is this expected? Below is measured time for write() Boards are 2x XIAO ble sense, about 10cm apart Settings: NRF_1MBPS, NRF_PA_LOW, NRF_CRC_8

setAutoAck(false)

setAutoAck(true)

[TMRh20]

From my blog at https://tmrh20.blogspot.com/2016/08/rf24-addressing-review-of-nrf24l01.html

Acknowledgements (ACKs):

The radios support an automatic acknowledgement feature, enabled by default, in which the receiving radio switches into transmit mode after reception, and acknowledges reception of data.

1. A sends to B
2. B responds to A
3. A is now aware that B received the payload successfully

The acknowledgment process is very important to understand, because correct addressing is required for this feature to function properly.

This takes time when a packet fails and the radio has to retry. You can configure the retries and duration. See https://nrf24.github.io/RF24/classRF24.html#a4c6d3959c8320e64568395f4ef507aef

[pszczolo-jamnik]

But is it normal to have retries at such short distance? Besides, with acks disabled, I don't see any signs of missing data at rx side..

[2bndy5]

But is it normal to have retries at such short distance

It is recommended. The best answer: It depends on your usage's environment (ie temperature, humidity, ambient RF signals).

Besides, with acks disabled, I don't see any signs of missing data at rx side.

Congrats! But not everyone's environment is as conducive as yours. So, we tend to recommend using auto-ack to prevent arbitrary data loss.

[TMRh20]

If you are transmitting large payloads (over 32 bytes), the timeouts here need to be adjusted, (controls the wait time for acks) else there may be problems with acks not being received in time. https://github.com/TMRh20/nrf_to_nrf/blob/main/src/nrf_to_nrf.h#L22

At short distances there should be very minimal loss, you can also try different radio channels to weed out interference.

Also keep in mind the nrf52x is software driven (no radio IRQ support in Arduino cores), so you need to be calling available() regularly for acks to be sent properly.

[pszczolo-jamnik]

Things I've tried:

• 3 different frequencies
• increased ack timeout from 200 to 400us
• NRF_PA_HIGH
• decreased retry time to 1 (258us)
• increased retry attempts to 32

I still can't get 100% reliable transmission, when I move away 5m or so in an open space, in the logs I see retransmission count rises and then eventually fails. Could you please suggest what's going on?

edit: rx side is calling available() every 30us or so

[TMRh20]

Are you running the getting started sketch or your own code? How does it perform with this sketch?

[pszczolo-jamnik]

I've tried GettingStarted.ino, starts failing (retry limit exceeded) at ~5m with some transmissions succeeding. Measuring RSSI (like testCarrier() but return NRF_RADIO->RSSISAMPLE) gives 127 all the time (???) Could it be an issue with antenna on XIAO BLE Sense?

[TMRh20]

I think you've got something odd going on. The devices should be able to communicate over 5m very easily, with very little loss.

What I think I would try next is disable auto-ack, then test out one-way communication on both devices. One device should have success, one should have failures if only one device is damaged. You will see the results only on the receiving device, since the sender will always say succcess with AA disabled.

[pszczolo-jamnik]

What I think I would try next is disable auto-ack, then test out one-way communication on both devices.

Same (bad) results with both devices

Got info from XIAO support that it's not supposed to be like this (though they are testing BLE with a smartphone) Seeed_XIAO_BLE_nRF52840_BLE_Communication_Distance_Test_Report.pdf

I'm moving my project to nRF24 for now, thanks for help!