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]

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.

[Einar Thorsrud]

Hi,

The pc-ble-driver-js is a layer on top of the pc-ble-driver, so you will not get better performance using that.

[Moshe Baker]

Thanks. I am receiving data packets of 244 bytes, which is the maximum as I understand. What else? I'm still at 80Kbps...

Also, can you point me to a PC NUS implementation I can use over API v5? I found some references, but still cannot get the correct descriptor UUID of 0x2902 for setting CCCD, I get 0x2803. This is my current PC log:

Serial port used: COM11
Baud rate used: 1000000
Info: Successfully opened COM11. Baud rate: 1000000. Flow control: none. Parity: none.
Status: 6, message: Target Reset performed
Status: 7, message: Connection active
Scan started
Received advertisement report with device address: 0xCB5E527FE36A
Connection established
Discovering primary services
Received an un-handled event with ID: 35
Received service discovery response
Discovering characteristics
Received characteristic discovery response, characteristics count: 2
Characteristic handle: 0x000C, UUID: 0x0002
Characteristic handle: 0x000E, UUID: 0x0003
Discovering characteristic's descriptors
Received descriptor discovery response, descriptor count: 1
Descriptor handle: 0x000E, UUID: 0x2803

[Einar Thorsrud]

Hi,

Moshe Baker said:

I am receiving data packets of 244 bytes, which is the maximum as I understand. What else? I'm still at 80Kbps...

There is nothing other to do than what we have discussed. Can you make a sniffer trace so that we can see what is actually happening on the link? That would make it easier to know in which direction to look further.

Moshe Baker said:

Also, can you point me to a PC NUS implementation I can use over API v5?

I don't have any PC side implementations, but the SoftDevice API is essentially the same regardless of using it directly or via the pc-ble-driver, so you could just refer to the SDK implementation. For version 5 API you could refer to <SDK 14.2>\components\ble\ble_services\ble_nus\ for the server implementation and <SDK 14.2>\\components\ble\ble_services\ble_nus_c\ client implementation, depending on which you need.

Moshe Baker said:

I found some references, but still cannot get the correct descriptor UUID of 0x2902 for setting CCCD, I get 0x2803.

Is this all of the log? As you know, 0x2803 is the assigned UUID for a characteristic declaration, and 0x2902 is for descriptor declaration. I would expect to see CCCD descriptors, so either there is an issue with your service discovery code or with the NUS server you are communicating with.

[Moshe Baker]

Hi, I've got the NUS PC side working, but it disconnects after a short time with: "Disconnected, reason: 0x22". Can you explain?

Also please advise regarding a sniffer. What HW setup do I need for it? Can I use Wireshark with no extra HW?

[Einar Thorsrud]

Hi,

Moshe Baker said:

Hi, I've got the NUS PC side working, but it disconnects after a short time with: "Disconnected, reason: 0x22". Can you explain?

What happens before the disconnect? There is an issue with some SoftDevice versions that it will report BLE_HCI_STATUS_CODE_LMP_RESPONSE_TIMEOUT as a disconnect reason when a TERMINATE_IND packet was not acknowledged, instead of BLE_HCI_LOCAL_HOST_TERMINATED_CONNECTION which would have been the correct. So perhaps it is just the peer disconnecting? You would see that from a sniffer trace.

Moshe Baker said:

Also please advise regarding a sniffer. What HW setup do I need for it? Can I use Wireshark with no extra HW?

No, but you can use the nRF Sniffer with an additional nRF DK if you have that available. This is based on Wireshark but needs the nRF DK to capture the BLE traffic.

[Moshe Baker]

I don't have a sniffer, so don't know what happens before the disconnect. In the pc-ble-driver console prints all is fine, and then suddenly disconnects. This happens with the pc-ble-driver on PC. With my Android phone nRF Connect, it behaves similarly, and reports Error 59 (0x3b) Unknown.

[Einar Thorsrud]

Hi,

0x3B is BLE_HCI_CONN_INTERVAL_UNACCEPTABLE (standard Bluetooth status code), so probably you need a higher connection interval for the Android phone to accept it.