iOS Question iBLE Characteristic Size when notifications are in use.

[mdehrnsb]

When designing with BLE2 for Android, I noticed that when ReadData() is called, the characteristics map is the count size of all of my characteristics for that service, as expected. When I had one or more notifications enabled, the size count dropped to 1, specifically for that notifying characteristic.

When using iBLE, the characteristics map count size is ALWAYS the full number of service characteristics, regardless of the use of ReadData() or the use of one or more notifications. This causes excessive testing of characteristics even though only one notifying characteristic may be in use.

Is this a function of iOS? Is there a way to make the characteristics map size variable similar to Android?

Any assistance is appreciated.

 

[Erel]

When you call ReadData2 only the specified characteristic is read. The map will return with all the characteristics however it doesn't slow down your app.

 

[mdehrnsb]

When you call ReadData2 only the specified characteristic is read. The map will return with all the characteristics however it doesn't slow down your app.

Erel,

To be more specific, the problem that I am having is that since the characteristic map returns with all characteristics, even though only one has new data, all of the characteristics are examined. There is no way for me to know which characteristic actually has the new data since the map has all of the characteristics.

To provide a more concrete example, here is what I am doing:

Two of my characteristics provide a float value relating to pitch and roll for a real world application. My app provides two graphics, one for pitch and one for roll to graphically represent the real world object's attitude. The pitch and roll characteristics along with 3 other Short sized characteristics are updated via notifications from my custom embedded system every ~100 ms. The characteristic notifications are updated independently on the embedded device.

The problem is that when only one notification is involved, the entire map is populated and causes all of by graphic functions to execute even though only one characteristic has been updated with new data. These excess graphic updates are somewhat time consuming and do not give me the fluid motion that I would prefer. I have worked around this problem by keeping a copy of the last data received for each characteristic in question and comparing it to the new data. If the results are different, then I process it and save a new "last data" value for the next comparison.

I have a total of 22 characteristics in my custom service, many of which do not change but notifications cause all 22 characteristics to be passed in the map and then must be handled. With the Android BLE2, notifications only pass the changed characteristic in the map and so the map is only one element in size. The excessive testing is not required.

I hope this explanation is helpful in understanding my difficulty. If altering the iBLE is not possible to change the characteristic map size for notifications, can you recommend any other alternatives for processing the map data efficiently.

Thank you.

 

[Erel]

I see your point. I've added a LastUpdatedCharacteristic property: https://www.b4x.com/android/forum/threads/updates-to-internal-libraries.48179/page-3#post-410651

You can use it to find the relevant characteristic.

 

[mdehrnsb]

Thank you Erel