C# PC app development with nRF52840-dongle

RE: C# PC app development with nRF52840-dongle

Einar Thorsrud — Wed, 27 May 2020 13:55:51 GMT

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.

RE: C# PC app development with nRF52840-dongle

Moshe Baker — Wed, 27 May 2020 13:36:10 GMT

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.

RE: C# PC app development with nRF52840-dongle

Einar Thorsrud — Wed, 27 May 2020 13:16:45 GMT

Hi,

[quote user="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?[/quote]

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.

[quote user="Moshe Baker"]Also please advise regarding a sniffer. What HW setup do I need for it? Can I use Wireshark with no extra HW?[/quote]

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.

RE: C# PC app development with nRF52840-dongle

Moshe Baker — Wed, 27 May 2020 12:38:05 GMT

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?

RE: C# PC app development with nRF52840-dongle

Einar Thorsrud — Mon, 25 May 2020 09:40:08 GMT

Hi,

[quote user="Moshe Baker"]I am receiving data packets of 244 bytes, which is the maximum as I understand. What else? I'm still at 80Kbps...[/quote]

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.

[quote user="Moshe Baker"]Also, can you point me to a PC NUS implementation I can use over API v5?[/quote]

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.

[quote user="Moshe Baker"]I found some references, but still cannot get the correct descriptor UUID of 0x2902 for setting CCCD, I get 0x2803.[/quote]

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.

RE: C# PC app development with nRF52840-dongle

Moshe Baker — Mon, 25 May 2020 09:16:41 GMT

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

RE: C# PC app development with nRF52840-dongle

Einar Thorsrud — Mon, 25 May 2020 09:12:07 GMT

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.

RE: C# PC app development with nRF52840-dongle

Einar Thorsrud — Mon, 25 May 2020 09:11:18 GMT

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.

RE: C# PC app development with nRF52840-dongle

Moshe Baker — Thu, 21 May 2020 13:33:57 GMT

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?

RE: C# PC app development with nRF52840-dongle

Moshe Baker — Thu, 21 May 2020 11:29:31 GMT

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?

RE: C# PC app development with nRF52840-dongle

Moshe Baker — Wed, 20 May 2020 13:24:25 GMT

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?

RE: C# PC app development with nRF52840-dongle

Einar Thorsrud — Wed, 20 May 2020 10:09:55 GMT

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).

[quote user="Moshe Baker"]PHY being used (LE 1M vs. LE 2M vs. LE Coded (S=2 or S=8))[/quote]

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.

[quote user="Moshe Baker"]Maximum number of packets per connection interval[/quote]

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.

[quote user="Moshe Baker"]Data Length Extension (DLE)[/quote]

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.

RE: C# PC app development with nRF52840-dongle

Moshe Baker — Tue, 19 May 2020 20:14:25 GMT

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

RE: C# PC app development with nRF52840-dongle

Einar Thorsrud — Tue, 19 May 2020 12:23:36 GMT

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.

RE: C# PC app development with nRF52840-dongle

Moshe Baker — Tue, 19 May 2020 09:32:57 GMT

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?

RE: C# PC app development with nRF52840-dongle

Einar Thorsrud — Tue, 19 May 2020 09:04:43 GMT

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).

RE: C# PC app development with nRF52840-dongle

Moshe Baker — Tue, 19 May 2020 07:09:36 GMT

I set the MTU to 250.

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

RE: C# PC app development with nRF52840-dongle

Einar Thorsrud — Mon, 18 May 2020 20:46:21 GMT

Hi,

The most important for increasing throughput using the pc-ble-driver is increasing the ATT MTU. However, the pc-ble-driver has significant overhead due to the serialization and all packets being backed on the UART/USB transport, so you will not get very high throughput.

RE: C# PC app development with nRF52840-dongle

Moshe Baker — Mon, 18 May 2020 17:32:39 GMT

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.

RE: C# PC app development with nRF52840-dongle

Moshe Baker — Sun, 17 May 2020 20:37:15 GMT

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.

RE: C# PC app development with nRF52840-dongle

Einar Thorsrud — Fri, 15 May 2020 14:13:25 GMT

I am glad to hear that. Have a nice weekend 🙂

RE: C# PC app development with nRF52840-dongle

Moshe Baker — Thu, 14 May 2020 18:17:05 GMT

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

RE: C# PC app development with nRF52840-dongle

Einar Thorsrud — Thu, 14 May 2020 17:55:29 GMT

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 devzone.nordicsemi.com/.../connectivity_5F00_4.1.1_5F00_usb_5F00_with_5F00_s132_5F00_5.1.0.hex. You can use the heart_rate_collector_sd_api_v5.exe example to see that it works.

RE: C# PC app development with nRF52840-dongle

Moshe Baker — Thu, 14 May 2020 17:06:39 GMT

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

RE: C# PC app development with nRF52840-dongle

Einar Thorsrud — Thu, 14 May 2020 16:31:39 GMT

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.