S130 ble_app_uart missing data

[Davy]

When I use the example of ble_app_uart(SDK : nRF5_SDK_11.0.0_89a8197) to measure data througput ,I find that i cannot get the complete packet of 20 bytes. The operation is that : I send 20 bytes at one time to my board by uart terminal ,the frequency i send is 50Hz.My board is flashed with the example of ble_app_uart.The baudrate is 115200 without hardware flowctrl. The result is that: I often cannot get the complete packet.Always miss one or two bytes.I was confused.

please tell me why.Thanks!!

[Nguyen Hoan Hoang]

Transmitting over BLE is slow. You need to have a big fifo for the UART not to overrun. Something around 256 to 512 bytes. iPad can read the data fast enough. None of the BLE dongle we tried on PC with Bluez are able to handle it without drops. Softdevice central role is worst, much slower. We use the UART code from the EHAL library. SDK uart code could not keep up the speed.

So at 50Hz :

• iMAC, iPad can keep up (but still
• marginal) PC USB dongles drops
• Softdevice central role no way.

See this video. IMU data 20 bytes packet are sent at 50Hz from Freescale over UART at 115K (Freescale MCU does not have CTS/RTS pins) to nRF51. Which then forwards it to BLE. No drops.

[RK]

Not sure why people keep trying to run UARTs at 115,200 baud with no hardware flow control and then wonder why they lose data, especially on a system which has high priority interrupts going on all the time.

You didn't say nrf51 or nrf52 so I'll assume whatever is receiving from the UART is interrupt-driven and not DMA-based. The softdevice is doing the work it needs to do, you're blocked for a short time, but long enough for the UART buffer to overrun because the UART interrupt doesn't get serviced before 4 characters have come in. Now you lose data.

The nRF52 using DMA would be able to manage this, it would receive the data and then interrupt you once to tell you it has it.

So either use the nRF52 with DMA, use hardware flow control or use a lower baud rate.