advertising

[katyon]

Hi

I’ve downloaded     nRF5_SDK_11.0.0_89a8197 and starting with examples from \examples\ble_peripheral\???\pca10040\s132\arm5_no_packs\

I'm writing an application to be running on BLE.

the other "side" is an BLE application running on a cellphone.

the situation is:

In a given location there might be 1-20 BLE devices .all of them would be seen by the cellphone application.

each of my BLE devices has a different TYPE (say up to 10 types ).

the TYPE of a given device might change (not very often)  .

the cellphone application "would like" to search all devices ,sort only my devices, show a list of them, each with an icon. the icon is the TYPE of the device.

my suggestion to the cellphone app guys was to use appearance.

every time my TYPE changes- I'll use sd_ble_gap_appearance_set to change it.

their complaint is that in order for them to know all TYPES, they need to READ the appearance characteristic for each of my devices, and that would take them too long.

they suggest  to have a service that its uuid will be a function of the device's TYPE.

in that way- I'll will have a (say  empty) service that its uuid will a function of the TYPE.

all that's needed from them is to scan services , sort those that belong to me , and understand (from the uuid ) their TYPES.AVOIDING the need to actually preform  a READ into these services (characteristics).

the thing is- I don't see a function for service delete,characteristic delete, change of uuid foe service/characteristic.

How can I solve this?

Thanks

Yona

[tesc]

Hi,

First of all I highly recommend using the latest SDK version for nRF52 development.  Currently that is nRF5 SDK 15.0.0. Version 11 was the first version with nRF52 support, (for engineering versions of the nRF52832 if I recall correctly,) but there has been a lot of improvements since then. See the release notes of the current SDK for lists of added features and bugfixes over the years.

For identifying the different types I suggest using "manufacturer specific data" in the advertisements. It is an advertisement data type that is specifically made for this kind of use case. Then the central (or scanner) can read the type directly from the advertisement, and you do not even need to make a connection to do so.

Manufacturer specific data is mentioned in Bluetooth low energy Advertising, a beginner's tutorial, and although that tutorial is old (SDK v11) the concept is still the same and there are few (if any) changes to the manufacturer specific data part.

Regards,
Terje