Handling different offset in BaseUUID and pc_ble_driver

[gtorres]

Hi,

I'm trying to use the pc_ble_driver_py framework and an NRF51/52 dongle to connect to a BLE device. The BLE device in question has some custom defined services for operation and DFU (not a nordic device).

The custom services UUID offset works slightly differently than what Nordic specifies, which is causing some incompatibilities. The offset in the BLE device is set at the end, instead of in the first 32bits like in Nordic. To illustrate:

Nordic UUIDs:

84e5xxxx-15d2-44a5-9572-eddc58a48483

BLE Device UUIDs:

84e5e4bc-15d2-44a5-9572-eddc58a4xxxx

Where the xxxx is where the offset sits.

This makes it so I can't build a proper Base UUID and then build offsets for each characteristic (mostly Notify and Write chars). I worked around this for one characteristic by creating a base service for each characteristic and then offsetting by some constant. The problem is that you can only use the ble_vs_uuid_add so many times due to memory constraints (according to the errors I'm seeing).

Is there anyway to build custom UUIDs without needing to build a baseUUID? Do they need to be added with ble_vs_uuid_add before they can be subscribed to? I'm still not very clear as to what ble_vs_uuid_add does and I have not found docs explaining it.

Thanks!

-Gabe

[tesc]

Hi,

The system with base UUIDs that are combined with a 16 bit value to form a full 128 bit UUID are made specifically to use bytes 12 and 13 as the shorter 16 bit portion of the full 128 bit UUID. This is handled internally in the SoftDevice and cannot be changed.

That means you must do as you describe and manually create a set of base UUIDs and 16 bit UUIDs in order to compose the actual 128 bit UUIDs that you need. And, as you wrote, accept the memory usage resulting from such an approach.

Regards,
Terje

[gtorres]

Terje,

Thanks for the reply. Can you point me in the right direction as to where I can change the base uuid limit? I'm not sure if that is part of the softdevice that is flashed to the dongle or part of the shared library that the python bindings use.

-Gabe

[tesc]

Hi,

If you use the SoftDevice Handler from our SDK (which most SDK examples do) then it is NRF_SDH_BLE_VS_UUID_COUNT in sdk_config.h.

Edit: Whoops, sorry, didn't realize the python comment. Are you using pc-ble-driver-py?

Regards,
Terje

[gtorres]

Terje,

Yes, I'm using pc-ble-driver-py

[tesc]

Hi,

Then I think there should be a call somewhere to BLEEnableParams() where you set vs_uuid_count. See for instance the pc-ble-driver-py heart rate collector example, heart_rate_collector.py, lines 69 to 73. That should be the way to configure the SoftDevice in pc-ble-driver-py.

Regards,
Terje

[gtorres]

Terje,

That worked, but it does not allow me to tell which characteristic is actually triggering a notification. I can subscribe to two different base UUIDs with the same offset (because bytes 12 and 13 are constant). The "on_notification" function gets called with a uuid parameter that is the same for both characteristics, even though they have different bases. When inspecting the uuid object passed, it looks like the base uuid is not populated (set to None). 

Without a meaningful way to tell which characteristic is triggering a notification, its nearly impossible to piece together a message. Do you know if there is a way to tell them apart?

In my example, the UUID field is simply set with `e4bc` for both characteristics.

Thanks,

Gabe

[gtorres]

I am going to expose the attr_handle through the python interface. I think that's what is missing.

Thanks Terje.