An advertisement data that contains manufacturing data

[SunHuang]

Hi 

As shown in the title, I want to add manufacturing data(BT_DATA_MANUFACTURER_DATA) to the advertisement data.

The *.conf seems to only define the device name...

I want to be able to  modify manufacturing data dynamically. 

let me know if anything I need to change, thanks!

OS: windows 10
Hardware used: nrf5340 dk
example:C:\ncs\v2.5.1\nrf\samples\matter\lock

[Edvin]

Hello,

By dynamically, I assume you mean during runtime?

If so, you can have a look at this little side project I did once.

In main.c I only used the function simple_ad_start(), which is defined in the file remote.c.

It is a bit messy, but I hope it may give an idea for you to start with.

Best regards,

Edvin

[SunHuang]

Hi Edvin

The problem I am currently encountering is that the advertisement data of matter cannot be accompanied by manufacturing data.

when I turn on the discoverable over Bluetooth LE(Matter), the manufacturing data were disappeared

The dynamically changing advertisement data part should have been completed, but it seems that only work with "general" BLE broadcasts

void Sunion::BleService::SetManufData(uint8_t *buff)
{
	int err = 0;
    bt_le_adv_param advParams;
    advParams.id           = BT_ID_DEFAULT;
    advParams.options      = BT_LE_ADV_OPT_CONNECTABLE | BT_LE_ADV_OPT_ONE_TIME;
    advParams.interval_min = mAdvertisingRequest.minInterval;
    advParams.interval_max = mAdvertisingRequest.maxInterval;

	const bt_data scanResponseData[]    = { BT_DATA(BT_DATA_UUID128_ALL, kBTUuid, sizeof(kBTUuid)) };
	const bt_data * scanResponseDataPtr = sizeof(kBTUuid) > 0 ? scanResponseData : nullptr;
	const size_t scanResponseDataLen    = sizeof(kBTUuid) > 0 ? sizeof(scanResponseData) / sizeof(scanResponseData[0]) : 0u;

	const char *name = bt_get_name();
    const bt_data advertisingData[] = { BT_DATA(BT_DATA_FLAGS, &kAdvertisingFlags, sizeof(kAdvertisingFlags)),
                                        BT_DATA(BT_DATA_NAME_COMPLETE, name, strlen(CONFIG_BT_DEVICE_NAME)),
										BT_DATA(BT_DATA_MANUFACTURER_DATA, buff, 12) };


    // Restart advertising
    err = bt_le_adv_stop();
    // VerifyOrReturnError(err == 0, MapErrorZephyr(err));

    err = bt_le_adv_start(&advParams, advertisingData, sizeof(advertisingData) / sizeof(advertisingData[0]), scanResponseDataPtr,
                          scanResponseDataLen);
}

[Edvin]

How much data are you trying to push out through the advertising packet?

The Flags are only a couple of bytes, and then you have 12 bytes of manufacturer specific data. What is the CONFIG_BT_DEVICE_NAME? How many ascii-characters?

Remember that all BLE advertising is limited to 31 bytes, so if your device name is 20 characters, that leaves only 11 bytes for the rest. See if you can get the manufacturer specific data if you remove the BT_DATA_NAME_COMPLETE from your advertising data (as a test). 

If it doesn't work, what is the return value from bt_le_adv_start()? Try printing it to your log.

Best regards,

Edvin

[SunHuang]

Hi Edvin

I created a custom service similar to Nordic UART Service (NUS) and it broadcasts the device name(7 bytes) and manufacturing data(12 bytes) correctly.

But when I switch to matter broadcast, the manufacturing data disappears, only the device name remains.

I think they should be stored in different data structures，and I know that "bt_set_name" function can change the device name of matter broadcast.

[SunHuang]

Hi Edvin

I created a custom service similar to Nordic UART Service (NUS) and it broadcasts the device name(7 bytes) and manufacturing data(12 bytes) correctly.

But when I switch to matter broadcast, the manufacturing data disappears, only the device name remains.

I think they should be stored in different data structures，and I know that "bt_set_name" function can change the device name of matter broadcast.

The manufacturer data specification documented in 5.4.2.8 Manufacturer-specific data from Matter-Core-Specification, Version 1.2. 

[Edvin]

Hello,

After digging a while through the Matter advertising implementation, I see that it definitely has an impact on the advertising data. The reason the device name stays is that the Matter stack will use the device name as well. 

After talking to our Matter team, I got some info on how the BLE advertising part of the Matter stack works.

Basically, the Matter advertisements is it's own set. It doesn't matter what you put in your own advertising packets using the Bluetooth Stack directly. When you start advertising your Matter service, it will override whatever you were doing. If you want to keep your advertisements while using the Matter stack, you need to use it's API. The way that the Matter stack uses BLE advertisements is that it has several sets of advertisements, and it can only advertise one set at the time. The priority of the Matter advertising set is always the highest one. When it stops advertising with it's Matter set, it will then start with the next advertising set in the queue, with the highest priority. 

"It was designed in such a way, because the Matter advertising times out after 15 minutes, and sometimes the user may want to advertise longer or permanently (e.g. we do this in the NUS or DFU over BT SMP pusporses). It is not a problem that during the first 15 minutes we do not advertise NUS or SMP data, because the support for these services can be discovered using GATT discovery anyway.

The customer would need to modify modules\lib\matter\src\platform\Zephyr\BLEManagerImpl.cpp and add more data to the advertising data used during the Matter service advertising if they want to add custom data to the Matter service advertising set. In theory the advertising arbiter could try to combine the advertising data from N requests as long as they fit in 31 bytes, but we haven't done this so far."

So it is possible to add some custom data, but it is not straight forward. You can have a look at the BLEManagerImpl.cpp and see if you can fit any more custom data without overflowing the 31 byte limit. I think PrepareAdvertisingRequest() is the place to start. If that doesn't work, you will need to use a different advertising set, but you will not be able to use this at the same time as you are advertising your Matter service. 

Best regards,

Edvin

[SunHuang]

Hi Edvin

I can understand your reply, but I'm not sure that PrepareAdvertisingRequest()  is allowed to be modified.

[Edvin]

As I see it, you have two options.

1: Advertise with your custom data only whenever you are not advertising your Matter services (so when your Matter service advertising data times out, or stops due to another reason, like a connection or something).

2: Modify modules\lib\matter\src\platform\Zephyr\BLEmanagerImpl.cpp and add more data to the advertising data used during the Matter service advertising. 

These are the two options that our Matter team provided. 

If neither of these are suitable, you would need to implement something that alternates advertising with the Matter service and your custom advertisements. You can look at the ncs\nrf\samples\bluetooth\multiple_adv_sets for reference. However I am not sure exactly how to do that, since the advertising of the matter stack seems to be quite far down in the stack, so it will be difficult to do without changing anything in the Matter files.

Best regards,
Edvin