Sending many messages

[firmware_master]

Hi,

I am using the BLE UART central and peripheral to send 100 messages of size 65 bytes (64 bytes + new line) continuously to the peripheral in the hope that I can see the messages on the UART of the central device.

However, I notice that I get about 30-40 messages when sending from Peripheral to Central and about 50-60 messages from central to Peripheral.

I also see that when the transmission stops there is a APP_UART_FIFO_ERROR error at the sender. What is the size of the FIFO buffer?

This is consistent across many tests. In the peripheral device, it goes to the  NRF breakpoint condition and it has to reset to start and I have at that point lost the messages. This is not something I observe when I sent messages of size 33 (32+1) bytes. Can you think why this could be the case? Also is there a way I can get it to work,

Thanks

[Einar Thorsrud]

Hi,

I want to start with the first question that came to mind: have you started the crystal oscillator? That is generally a good idea when using UART. Failing to do so can result in a too large clock inaccuracy, leading to framing errors.

I also see that when the transmission stops there is a APP_UART_FIFO_ERROR error at the sender.

This could be caused by several things. Have you checked the additional error code in the app_uart_evt_t instance?

What is the size of the FIFO buffer?

 That is configured by the second and third parameters in APP_UART_FIFO_INIT().

[firmware_master]

I am using the given example and so I assume that the correct settings have been applied.

 I also see this issue when I send 16 & 32 bytes messages for a higher number of messages. So it looks like the FIFO gets filled no matter the size and the bigger size only makes the issue come up earlier.

This is surprising.

WIth a 115200 baud rate, I can sent 11520 bytes per second.

I am sending messages every 10ms so I should be able to send 115.2 or 115 bytes every 10ms. However, I am not able to send even 64, 32 or even 16 bytes. I haven't tried 8 bytes yet.

Thanks

[Einar Thorsrud]

Hi,

There can be a number of factors controlling this. What about the BLE link?

• What connection parameters are used?
• Connection interval, packet length, packets per connection event etc?
• Do you have a sniffer trace to show this?
• Are you using nRF52832 on both ends?
• Which SDK version are you using? Which modifications have you made to the example?

[firmware_master]

I am using the default connection parameters as per the example. I haven't changed anything in the code at all and I am using nRF52832 on both ends. I am using SDK 15.3.0. I do not have a sniffer trace to show this. I am running the example as it is.

[Einar Thorsrud]

How many packets do you attempt to send each second? BLE bandwidth depends on a number of factors, but generally, you will get higher throughput by trying to send fewer large packets compared to more short packets. Both due to overhead in the BLE link itself, and also due to a limited (but indirectly configurable) number of packet buffers (based on the NRF_SDH_BLE_GAP_DATA_LENGTH and NRF_SDH_BLE_GAP_EVENT_LENGTH parameters).