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? 

[Einar Thorsrud]

The pre-built hex files in the pc-ble-driver repo (here) are not complete or up to date. The easiest is to install pc-ble-driver-py via pip, and find it under <site-packages>\pc_ble_driver_py\hex\sd_api_v5. You can find the "site-packages" folder using 'python -m site'

[Moshe Baker]

Which hex file? I tried them all and always get the same device under Device Manager - "nRF52 SDFU USB (COM10)". Is this the one expected?

[Moshe Baker]

None of these hex files are doing any better. This is very tedious! How can we get more hands on support on getting the pc-ble-driver running?

[Einar Thorsrud]

Hi,

This is the correct place to get pc-ble-driver support (and support for any other nRF product). The error you are seeing match what you see when you use incompatible pc-ble-driver API version and connectivity firmware API version.

Which exact hex file and which exact example file did you try? Just to make sure the basics are working I suggest the following:

• Build the heart_rate_collector examples (using VisualStudio all variants are built in one go)
• Run the nRF Connect BLE app to make sure you have a working connectivity firmware (this will be API version 3).
• Run the API version 3 heart rate collector example like this (replacing the COM port with your number: ".\heart_rate_collector_sd_api_v3.exe COM6"

Then you should see an output similar to this:

λ .\heart_rate_collector_sd_api_v3.exe COM6
Serial port used: COM6
Baud rate used: 1000000
Info: Successfully opened COM6. 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: 0xF333BF1473AB
Received advertisement report with device address: 0x6A8691EE9176
Received advertisement report with device address: 0xF333723ED24C
Received advertisement report with device address: 0x66E795F64F45
Received advertisement report with device address: 0xF333723ED24C
Received advertisement report with device address: 0x0212DAE12FDF
Received advertisement report with device address: 0x4A7357CC6E17
Received advertisement report with device address: 0xF333723ED24C
Received advertisement report with device address: 0x62F5E2A7602A
Received advertisement report with device address: 0x0212DAE12FDF
Received advertisement report with device address: 0xF333723ED24C
Received advertisement report with device address: 0x6A8691EE9176
Received advertisement report with device address: 0xF333BF1473AB
Received advertisement report with device address: 0x0212DAE12FDF
Received advertisement report with device address: 0xF33365117774

You may not want to use the older API version, but if this works, then you know the basic setup is working. Then you can move on to trying a different API version and making sure you have programmed a corresponding connectivity firmware hex file.

[Moshe Baker]

I tried all of these and still the same. Can you state the exact hex file to use for the dongle? 

[Einar Thorsrud]

Hi,

Let's say you are using the v5 API instead (I don't recomend v6, since we do not use it yet and do not test it), then you should use connectivity_4.1.1_usb_with_s132_5.1.0.hex. You can use the heart_rate_collector_sd_api_v5.exe example to see that it works.

[Moshe Baker]

Thanks Einar!! it is working for me now! I am receiving notifications from the HRM! You made my weekend :)

[Einar Thorsrud]

I am glad to hear that. Have a nice weekend

[Moshe Baker]

Hi Einar, I am now trying to modify the HRM app for achieving max throughput test. I set the HRM timer to send notification every 100ms (instead of 1000ms), and tried to send 244 bytes instead of only 2 bytes, per measurement. I can actually see the data is sent when checking on nRF Connect on my Android phone log. But the pc-ble-driver is only receiving 20 bytes out of this. Where do I need to change the pc-ble-driver to receive all data? Am I going the right way here for a throughput test? I also tried to set a bigger MTU size by setting BLE_GATT_ATT_MTU_DEFAULT to 244, but this failed. What about the connection-interval? Please comment on these.

[Moshe Baker]

I changed some parameters in the HRM apps on both sides and reach 10KBps. This is still low. We are expecting over 100KBps. You said the throughput would be reduced due to pc-ble-driver. What throughput should we expect? Please respond. We are in POC phase and need to know if we can use this solution.