Slow Reading Characteristics

[DonPancoe]

I've got a peripheral I'm working on that is admittedly slow in reporting its characteristics due to a pretty heavy processor load. I am working on optimizing the embedded code to speed it up, but I'm wondering if there is any thing I can do on the Evothings side since there is a time crunch to get a working demo ready in short order.

Here is an example from the log of the Evothings Client trying to connect to the device...

Code: Select all

LOG: Scanning...
LOG: found device: FitlySP
LOG: Found FitlySP
LOG: Connecting...
LOG: Connected
LOG: Reading services...
LOG: Connected
LOG: Reading services...
LOG: Connected
LOG: Reading services...

I've read on this forum that you should never hard-code the handles since they could change every time you connect to the device, but since the process of reading the characteristics to match a UUID seems to be what is hanging up, might I get away with it here? I can connect to the device with an advanced tool called the CySmart BLE Dongle, and that always tells me the same UUIDs are in the same handle each time. So, as long as the Evothings client is not connecting to more than this one peripheral, that should also be true on the client/central side, yes?

Thanks,
Don

[Fredrik]

Short answer: sorry, no.


Long answer:
There are different types of handles.

One type is a low-level BLE 8-bit handle, which identifies a characteristic or a descriptor in the radio packets. I believe these handles are reported by your dongle. The mapping between these low-level handles and UUIDs are determined by the peripheral firmware, and may, as in your case, be constant.

Another type of handle is the integers reported by the evothings.ble plugin. They have no relation whatsoever to the previously mentioned low-level handles. They are assigned from an incrementing counter during the Service Discovery process, and are the keys to a native-side map of BLE objects (such as devices, services, characteristics and descriptors). Therefore you must wait until that process is complete until using those; otherwise the native side of the plugin won't recognize them.

They may be identical from one run of a program to the next, but they will change inside a run if you disconnect and then reconnect to a peripheral.

It should also be noted that the Android/iOS BLE APIs require service discovery to complete before they'll let you access anything.

[DonPancoe]

Thank you for the information. As it turns out, I was able to speed up the firmware enough to where this was no longer an issue, but this is all still good to know.

Don