Connect uart_peripheral with Windows 11

[Neil Benn]

Hello,

  I've taken the peripheral_uart sample and ripped all of the uart stuff out so that it currently just connects and logs anything received to the console - the simplest example.  I can connect with my phone (Android), no problem.  However when I try to connect with windows 11 using either the system connection, Bluetooth LE Explorer, examples using Bleak (python library) and pyble I consistently get a loop of:

00> [00:06:58.461,090] <inf> brikwiz_base: Connected D4:D8:53:4C:5D:23 (public)
00> [00:06:58.792,205] <inf> brikwiz_base: Disconnected: D4:D8:53:4C:5D:23 (public) (reason 19)

  I understand that the reason 19 is that the client has disconnected but I cannot understand what is happening.  I've looked around the internet and there doesn't seem to be a solution.  Can you assist to provide any advice as to why you cannot connect to the peripheral_uart example with windows please?

Cheers,

Neil

[Einar Thorsrud]

Hi Neil,

The disconnect reason indicate that the peer (PC) disconnected for some reason, but does not tell us why. You will need to look more on the side that disconnected (PC) to understand more about that. I don't know the details of how Bluetooth LE Explorer work and why it would choose to disconnect in some cases. Is it possible to get more logging from it? Other than that, I suggest asking Microsoft support for details on Bluetooth LE Explorer as it is their product. As an alternative if you need a BLE tool for testing from a computer you could consider nRF Connect for Desktop BLE.

Einar

[Neil Benn]

Hello,

  Thanks for that - I've tested with multiple python packages and BLE explorer - they all do the same thing.  I have tried nrfConnect for Desktop with the nrf52840 Dongle and that does indeed connect to teh uaryt_peripheral running on the nrf52dk board.

   However; I need to write code to test the NRF52dk package and I can't do that with nrf Connect for Desktop BLE - all I can do is send a few bytes back and forth.

  This seems like a fairly simple example and windows is quite common - are there any use cases where uart_peripheral connected to from windows is actually working?  Is there any way we can determine what the nrf52dk is actually sending to the windows computer?

Cheers,

Neil

[Einar Thorsrud]

Hi Neil,

Neil Benn said:

This seems like a fairly simple example and windows is quite common - are there any use cases where uart_peripheral connected to from windows is actually working?

There is no native support for the Nordic UART service (NUS) which is used in the peripheral_Uart sample on Windows, as this is a custom service designed by Nordic. So to use it with Windws you either need some form of test application (for which BLE explorer is a simple variant of) or write your own PC side application. From what I know the BLE explorer application is not much used and we do not have much experience with it nor knowledge of its implemnetation or limitations.

Neil Benn said:

Is there any way we can determine what the nrf52dk is actually sending to the windows computer?

The normal way to invesitgate such things is with a BLE sniffer. Even if you don't have a dedicated BLE sniffer,  you can use the nRF Sniffer as long as you have an extra nRF52 series DK or dongle.

Einar

[Neil Benn]

Hello,


  Thanks for your response, to note - I'm not using BLE Explorer; this was just one of the examples of test applications which cannot interact with the nrf52dk including the windows native system (just to pair and connect) and a couple of python-based applications.  I'm also not looking for native support in Windows but not sure how native support for a simple example like this would work anyways as it has no functionality but to receive a few bytes and dump them on the log.  However I do want to write a piece of code which can communicate to the uart_peripheral running on a nordic nrf52dk.  The eventual aim is to have a windows program that can communicate to the device embedded in a product based around the nordic system.

  I just wanted to make the above clear as the BLE Explorer application is confusing matters, so moving on:

  I've use the BLE sniffer as in the instructions and the following packets are detected:

1885	32.016	Intel_4c:5d:23	LE 1M	LE LL	34	151µs				0	CONNECT_IND
1886	32.032	Central_0x3316f157	LE 1M	LE LL	9	15343µs	0	0	False	0	Control Opcode: LL_FEATURE_REQ
1887	32.032	Peripheral_0x3316f157	LE 1M	LE LL	0	150µs	0	1	False	0	Empty PDU
1888	32.077	Central_0x3316f157	LE 1M	LE LL	0	44619µs	1	1	False	1	Empty PDU
1889	32.077	Peripheral_0x3316f157	LE 1M	LE LL	9	150µs	1	0	False	1	Control Opcode: LL_FEATURE_RSP
1890	32.122	Central_0x3316f157	LE 1M	LE LL	23	44619µs	0	0	False	2	Control Opcode: LL_ENC_REQ
1891	32.122	Peripheral_0x3316f157	LE 1M	LE LL	0	150µs	0	1	False	2	Empty PDU
1892	32.167	Central_0x3316f157	LE 1M	LE LL	0	44507µs	1	1	False	3	Empty PDU
1893	32.167	Peripheral_0x3316f157	LE 1M	LE LL	13	149µs	1	0	False	3	Control Opcode: LL_ENC_RSP
1894	32.212	Central_0x3316f157	LE 1M	LE LL	0	44588µs	0	0	False	4	Empty PDU
1895	32.212	Peripheral_0x3316f157	LE 1M	LE LL	0	149µs	0	1	False	4	Empty PDU
1896	32.257	Central_0x3316f157	LE 1M	LE LL	0	44691µs	1	1	False	5	Empty PDU
1897	32.257	Peripheral_0x3316f157	LE 1M	LE LL	3	150µs	1	0	False	5	Control Opcode: LL_REJECT_EXT_IND
1898	32.302	Central_0x3316f157	LE 1M	LE LL	9	44667µs	0	0	True	6	Control Opcode: LL_LENGTH_REQ
1899	32.302	Peripheral_0x3316f157	LE 1M	LE LL	0	150µs	0	1	False	6	Empty PDU
1900	32.302	Central_0x3316f157	LE 1M	LE LL	2	150µs	1	1	False	6	Control Opcode: LL_TERMINATE_IND
1901	32.347	Central_0x3316f157	LE 1M	LE LL	2	44373µs	1	1	False	7	Control Opcode: LL_TERMINATE_IND
1902	32.347	Peripheral_0x3316f157	LE 1M	LE LL	9	150µs	1	0	False	7	Control Opcode: LL_PERIPHERAL_FEATURE_REQ

   The last communication is regarding encryption and the central sends to the peripheral LL_LENGTH_REQ which times out I thing; then the link is disconnected.  Can you please advise as to what the possible cause could be?

  UPDATE - I've run the same code from a linux box and the difference is that the encryption request opcode isn't sent from the linux box; the length_req opcode is still ignored by the peripheral but then we launch straight into feature discovery.

UPDATE 2 - there was an old paring left over from the bluetooth system attempt to previously pair which the peripheral.  If this is removed the windows python code now works.  Though I still need to understand what went wrong in the first place.

Cheers,

Neil

[Einar Thorsrud]

Hi Neil,

That seems to match the trace (though I don't see the context of the packets), the nRF recjects encryption probably probalby as it does not have the bonding data, and for that reason, the central disconnecs. This is expected behaviour.

Neil Benn said:

Though I still need to understand what went wrong in the first place.

Do you mean why the PC has a bond and the nRF does not? A typical reason is that the nRF was re-programmed, and in the process, the flash was erased, including the bond(s). Could that be what happened?