Maintain serial port connection (new to BLE dev)

[JBrakefield]

I'm struggling to understand many aspects of this code, as I'm new to development (and BLE). I'm a data analyst who has been tasked with establishing a BLE serial port connection for another program to use.

I have looked at the uart_service example, but it doesn't seem to be doing what I need (and I can't get it to run, possibly because I'm still using Python 3.9). Even with 3.9, I have successfully scanned devices and extracted manufacturer information that I need as well as mac address. I just can't find the code to establish a connection with one of those services and keep it there while another program does its thing.

I looked through the documentation, but I have trouble following how to correctly use many of the features. For example, I see there is an option to 'pair' a device, but is this necessary to use a service such as uart? So far I have seen no examples that even use 'pair'. Any and all help would be greatly appreciated.

[dlech]

If you are getting manufacturer information from the device, then you should be good to go as far as the install is concerned.

Perhaps a simpler example to start with would be trying get_services.py or service_explorer.py.

If you are still having trouble connecting with those, the next step is to enable debug logging to try to see what is going on.

It depends on the specific device you are using if you need to pair or not before using it. If it uses secure/encrypted communication, then you need to pair, otherwise you don't need to.

[JBrakefield]

I have used those two examples successfully already. What they don't show you how to do is use a service once you've got it. I have the uuid for the service (Nordic UART Service 6e400001-b5a3-f393-e0a9-e50e24dcca9e). I have my device mac addresses. I don't know how to "connect" to the service.

The service_explorer.py example seems to "connect" long enough to get detailed information about the service, and this runs for me, but I don't know how to maintain that long enough for another program that requires a serial port connection to run.

[dlech]

Technically speaking, "connecting" happens when the async with BleakClient(device) as client: blocks starts and disconnection happens when the block ends, so to stay connected, you will need some kind of loop inside of the block to keep it from exiting. In this loop, you will need to wait for the other program to have something to send, then write it with await client.write_gatt_char(UART_RX_CHAR_UUID, data)

How does the other program expect the serial port connection to work (e.g. do you pick a COM port from a menu or something like that)?

[JBrakefield]

The UUIDs for TX and RX seemed to be switched from what I find in the documentation here: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk51.v9.0.0%2Fble_sdk_app_nus_eval.html

[JBrakefield]

However, the write_gatt_char needs to use TX, not RX, if the UUIDs are to follow that documentation. I just switched them and got my code to work. I should note that my code is very different from this example, and I had to establish a pairing to get the writing to work. I used the philips_hue.py example as a guide.

[dlech]

Glad you figured it out. And we would be happy to take a pull request to fix the mistake in the example.

[Carglglz]

The UUIDs for TX and RX seemed to be switched from what I find in the documentation here: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk51.v9.0.0%2Fble_sdk_app_nus_eval.html

I think that documentation is outdated 🤔 and the UUIDs are now switched.

Here is the latest documentation:

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v14.0.0%2Fble_sdk_app_nus_eval.html
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/include/bluetooth/services/nus.html

The UUIDs of the Nordic UART Service and RX, TX Characteristics are already in the uuid128_dict of bleak/uuids.py, and it is just one line to get them,

from bleak.uuids import uuid128_dict
NUS = {v.split()[-1]:k for k,v in uuid128_dict.items() if "UART" in v}

>>> NUS['Service']
'6e400001-b5a3-f393-e0a9-e50e24dcca9e'
>>> NUS['TX']
'6e400003-b5a3-f393-e0a9-e50e24dcca9e'
>>> NUS['RX']
'6e400002-b5a3-f393-e0a9-e50e24dcca9e'

👍

[dlech]

To make things more interesting, it looks like Adafirut is sticking with the old naming. https://learn.adafruit.com/introducing-the-adafruit-bluefruit-le-uart-friend/uart-service

As it says on that page (which has been recently edited):

Characteristic names are assigned from the point of view of the Central device

The names really depend on the point of view. On a real UART, TX of one device is connected to RX of the other device and vice versa.

So to be unambiguous, the names should probably rather be something like "central tx, periperal rx" and "central rx, periperal tx".

[Carglglz]

The names really depend on the point of view. On a real UART, TX of one device is connected to RX of the other device and vice versa.

That's actually true.

So to be unambiguous, the names should probably rather be something like "central tx, periperal rx" and "central rx, periperal tx".

I think this would be the best to avoid confusion.
And just to be clear something like:

# central tx, periperal rx : 6e400002-b5a3-f393-e0a9-e50e24dcca9e. --> Write to this characteristic
# central rx, periperal tx: 6e400003-b5a3-f393-e0a9-e50e24dcca9e --> Read/Start notify on this characteristic

Commented in the example would be helpful.