getting max S132 connectivity fw throughput

[gkovelman_tap]

Hi,

I'm trying to transmit data at about 500kbps from custom nRF52 board (peripheral, s132 v5, SDK14.0) to a PCA10040 board with a connectivity FW (based on v3.0.1) connected to a PC and pc-ble-driver (central).

Currently, with the max throughput settings,

• ATT MTU at 247,
• PDU at 251,
• tried conn interval at different settings (11.25, 15, 30, 45),
• max event length at 320 (on both sides)
• hvn_tx_queue_size (on peripheral side) at 20
• transmitting 2 packets of 240 bytes in size every ~8ms

I can reach 40 KBps (320 kbps).

I keep getting NRF_ERROR_RESOURCES from sd_ble_gatts_hvx on the peripheral side.
I'm not sure where the bottleneck is or whether it's bad configuration.

Any known issues with the connectivity FW? Could this be feasible?

I'll appreciate the help.

[Bjørn Kvaale]

Regarding the NRF_ERROR_RESOURCES, this devzone case could be helpful. Have you taken a look at the high throughput demo? You should be able to get a lot more than 320 kbps. Might be useful to try a connection interval of 7.5 ms. What is the throughput then?

There might be an issue with the connectivity FW, but I am not sure about this. Have you tested with a different connectivity FW (for example the nrf connect connectivity FW when you open nrf connect)? Does that work?

[gkovelman_tap]

Hi,

max event length is indeed at 320, like in that case.
High throughput is my guide for this activity. What I also tried, as high throughput demo suggested, was to change PHY to 2Mbps, but the actual throughput did not increase.

Connection interval of 7.5 didn't increase throughput; it's a little bit lower now, at ~38Kbps.

Connectivity FW is connectivity_2.0.1_1m_with_s132_5.0.hex. I'm not aware of other version that would with pc-ble-driver v3.0.1. Any other FW to try? Should I downgrade pc-ble-driver to 2.2.1? Let me know If I should put effort into it.

Thanks.

[Bjørn Kvaale]

I have asked the developers of the pc_ble_driver to take a look at this case. Before I start asking you to start trying different things, I think it would be easier if they gave you some tips, as they are more experienced in regards to this firmware.

Update: As stated in this devzone case, the bottleneck in this case is the relaying of the UART via the JLink OB. The throughput via the pc_ble_driver will be quite low because of this. If you have a logic analyzer, you will be able to see the traffic over the UART lines & see more of the data flow between the pc & the connectivity FW.

[gkovelman_tap]

I tried routing the nRF52 to PC via an UART-to-USB adapter instead of the JLink OB, but throughput was the same, so it's not the JLink itself.

Increasing the connection interval and receiving multiple packets per connection interval should make it work. But it doesn't seem to do so with conn interval is higher.

Then, any idea on how to achieve high throughput? Could controlling the burstiness of the data on the peripheral side help with the pc-ble-driver design?

[Bjørn Kvaale]

Like I mentioned, we have done tests regarding this & it all points to the fact that the relaying of the UART via the JLink OB is the bottleneck. I would say you want to keep the connection interval as low as possible to increase throughput. Unfortunately, I am not sure it is practically possible to increase the throughput using the pc-ble-driver. It might work better if you are somehow able to have a buffer in your nrf device that is connected to the pc-ble-driver, which can store some of the data to allow a higher throughput. I am not sure this will work, but it might be worth a shot.

[gkovelman_tap]

Thanks for the answer.

Any suggestions on how to queue the message on the FW side?