C# PC app development with nRF52840-dongle

[Moshe Baker]

Our purpose is to integrate BLE 5 in our embedded application, and do it quickly.. We basically need to send/receive data with maximum throughput. 

Per thread below, we are planning to use the ble_app_uart on the embedded side.

For developing the PC app side, assume we are using the nRF52840-dongle you recommended in thread below, where can I find a code example in C# for doing this, implementing the NUS profile? I see there is JS/Node.js code of nrf-connect, but this is somewhat distant from our .NET environment.

Also i see in the Android app - nRF Toolbox - there is a UART app. So basically I'm looking for an equivalent C#/Windows code sample.

Does the pc-ble-driver in C++ cover the NUS service?

Spun off from:

Getting started with MBN52832 BLE Module

[Einar Thorsrud]

Hi,

For developing the PC app side, assume we are using the nRF52840-dongle you recommended in thread below, where can I find a code example in C# for doing this, implementing the NUS profile? I see there is JS/Node.js code of nrf-connect, but this is somewhat distant from our .NET environment.

Nordic does not provide any C# bindings for the pc-ble-driver, unfortunately. We only supply is the pc-ble-driver (C++) and JS and Python bindings.

Does the pc-ble-driver in C++ cover the NUS service?

No. The pc-ble-driver itself just provides the PC side of the SoftDevice API, and it does not incorporate any functionality that is not part of the SoftDevice. That means that you need to implement services yourself, as well as other higher-level functionality if needed (such as bond management, equivalently to what the peer manager library does in the SDK).

Lastly, please note that if you need high throughput, it might be better to use a natively supported Bluetooth device on the PC side rather than the nRF52840 dongle, since the pc-ble-driver and the rest of the SoftDevice serialization system introduces a significant overhead that reduces the throughput. (The nRF52840 is a good development tool though, when used together with the nRF Connect for Desktop BLE app or nRF Sniffer.)

[Moshe Baker]

Thanks Einar. What do mean by "a natively supported Bluetooth device on the PC side"? Can you give an example of such a device? 

[Moshe Baker]

I set the MTU to 250.

Is 10KBps/80Kbps the limit to expect? Should I modify anything else? please respond.

[Einar Thorsrud]

Hi,

Using long packets and a connection interval of 7.5 ms, you may be able to achieve up to 263 kbps, as described in this post. But that is the absolute maximum. (Normally you would use several packets per connection event in order to increase throughput, but that is not possible with serialization due to delays in the serialization).

[Moshe Baker]

Which post? Where do I set the connection interval? I tried to set minimum-connection-interval to 7 on the embedded side, but the PC failed with this value. After setting it to 10 it worked OK. How do i use "long packets"? Make the characteristic size/buffer larger?

[Einar Thorsrud]

Hi,

I forgot to insert the link. Her it is (I also update the previous post). You need to initiate a data length update procedure in order to increase the GAP packet length. That is described here.

[Moshe Baker]

The number of 263Kbps was theoretical, not measured I see. Marten mentioned he achieved 250Kbps using nRF Connect, not pc-ble-driver. are they the same? I still cannot improve the 80Kbps I'm getting using the HRS app with my variations. The connection-interval is set to 7.5. Any larger number reduces the throughput in a clear fashion. The payload data sent is 244 bytes. The same configuration brings me to 480Kbps with my Android phone.

Can you explain how I improve this, mainly on these points:

• PHY being used (LE 1M vs. LE 2M vs. LE Coded (S=2 or S=8))
• Maximum number of packets per connection interval
• Data Length Extension (DLE)

250Kbps might fly, but 80Kbps will not. Please help to improve this and achieve 250Kbps.

Thanks, Moshe

[Einar Thorsrud]

Hi,

Yes, 263 kbps is theoretical, but the mentioned 250 kbps is practically achieved. This is using the pc-ble-driver, as that is used by nRF Connect (via pc-ble-driver-js).

Moshe Baker said:

PHY being used (LE 1M vs. LE 2M vs. LE Coded (S=2 or S=8))

The 1M PHY is used. 2M would not improve the situation, even though you should spend less time "on air" as you still get one packet per connection event.

Moshe Baker said:

Maximum number of packets per connection interval

Normally you can have as many packets per connection event as the event length allows, provided that both peers can handle more data. However, it is not possible with the pc-ble-driver due to the latency of the serialization layer, and you are always limited to one packet per connection event.

Moshe Baker said:

Data Length Extension (DLE)

This allows you to transfer up to 247 bytes per packet, instead of only 20 bytes without it. Please note that this is a negotiation, so you may just get (say) 120 bytes per packet, or even just 20 if the peer does not support DLE at all.

What is the actual connection parameters used on the link? This may not be what you configure in the nRF, depending on the negotiation. You could either log the results of these procedures or make a sniffer trace to see the actual connection parameters, data length etc. that is used on the link.

[Moshe Baker]

How do I determine the actual connection parameters? I put a break-point in on_connected() in pc-ble-driver and see many values there in the context object, but no connection-interval.

Should i find in the embedded side with a break-point? Where?

[Moshe Baker]

I stopped at this break-point, and can see min/max conn interval are 6->7.5ms. Does that concur that the actual connection-interval is 7.5ms?

Are you there?

[Moshe Baker]

Another clarification - Could using pc-ble-driver-js provide better throughput performance than using the pc-ble-driver C++? Is the JS a layer above pc-ble-driver or a different implementation? 

[Einar Thorsrud]

Hi,

Sorry for the late reply.

Yes, since you are implementing the central, this will be used, and the connection interval is 6 * 1.25 ms = 7.5 ms. But as discussed earlier this is not the only thing that defines the throughput, you also need a large ATT MTU and large link-layer packets (using DLE). These are the result of negotiations.