Google Find My Device Network implementation

[Nareshpatel]

Hello, 

I need to implement Find My Device for nRF52833. 

From Sample I could find "samples/bluetooth/fast_pair/Locator Tag" example. I tried to go through it. but I could not able to map with fast pair specification(Fast Pair  |  Google for Developers). 

I want to check in which function advertisement is prepared ?

How keys(account keys,anti-snoofing keys) are sent in encrypted ?

In the advertisement which data we are sending(like fast pair UUID, Model id, anti snoofing keys, unique mac address,salt field ) etc ?  

[Edvin]

Sorry, maybe I jumped to conclusions initally. Most people asking about this says that they don't see the fast pair popup in Android. I am not sure exactly how the keys are being used. It is based on Google/android specification, so I don't think there is much room for customization exactly there. 

I believe the advertisement data is set in NCS\nrf\subsys\bluetooth\services\fast_pair\fmdn\state.c, in e.g. fmdn_adv_data_async_update() it is set several places. At least there it calls bt_le_ext_adv_set_data().

Is it something in particular that you want to add in your advertising data?

Best regards,

Edvin

[Nareshpatel]

No problem edvin. Thank you for your support. 

I want to know do we use automatic advertisement or custom advertisement ? I need to use custom advertisement .  

If I need to change advertisement data where I implement custom advertisement in source code ? 

I also want to map Google Fast pair specification and source code.  Could you please help me on this ? 

[Edvin]

Hello,

Look at the bt_le_ext_adv_set_data(), which is called in ncs\nrf\subsys\bluetooth\services\fast_pair\fmdn\state.c.

I don't know what you want to add to your advertisements, but I would guess there are more restrictions if you are using fast pair. Is there a particular reason why you need to use that instead of normal BLE advertising? If you are using normal BLE advertising, you can put whatever you want to in your advertisement packets.

Best regards,

Edvin

[Nareshpatel]

Thank you for your reply. 

I want to add few more information like ble mac address, and some proprietary flag information so Our mobile APP team can understand it. 

Is there any restriction for fast pair frame ? Could you elaborate please Which parameters are mandatory in fast pair frame ? 

[Edvin]

The BLE/MAC address will always be visible (not on iOS, but I assume you are talking about Android, since we are discussing fast_pair). It is part of the advertising packet already.

I think it would be easier for you to modify a "normal" BLE sample first, and then you can apply it to the fast pair sample later. 

Take e.g. the peripheral_uart sample found in ncs\nrf\samples\bluetooth\peripheral_uart.

From there you can see how the advertising packet is generated near the top of main.c:

static const struct bt_data ad[] = {
	BT_DATA_BYTES(BT_DATA_FLAGS, (BT_LE_AD_GENERAL | BT_LE_AD_NO_BREDR)),
	BT_DATA(BT_DATA_NAME_COMPLETE, DEVICE_NAME, DEVICE_NAME_LEN),
};

static const struct bt_data sd[] = {
	BT_DATA_BYTES(BT_DATA_UUID128_ALL, BT_UUID_NUS_VAL),
};

Note that each of these (ad and sd) are limited to 31 bytes each, so you can't add whatever you like. But if you e.g. take away the name, that frees up a significant amount, so that you can add your stuff.

One quite flexible structure that you can use in your advertising packet is BT_DATA_MANUFACTURER_DATA. This is a field that you can use to add pretty much any data on any format that you like. The only thing is that the first two bytes needs to be your company's bluetooth ID. You can set it to 0xFFFF for testing, but for certification, you need to use your Bluetooth Company ID.

Something like this:

uint8_t my_data[20] = {0xff, 0xff, 0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef, 0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef, 0x01, 0x23};

static const struct bt_data ad[] = {
	BT_DATA_BYTES(BT_DATA_FLAGS, (BT_LE_AD_GENERAL | BT_LE_AD_NO_BREDR)),
	//BT_DATA(BT_DATA_NAME_COMPLETE, DEVICE_NAME, DEVICE_NAME_LEN),
    BT_DATA(BT_DATA_MANUFACTURER_DATA, my_data, sizeof(my_data)),
};

static const struct bt_data sd[] = {
	BT_DATA_BYTES(BT_DATA_UUID128_ALL, BT_UUID_NUS_VAL),
};

It is also possible to update the data. Just stop the advertisements, update the my_data array, and start it again.

Best regards,

Edvin

[Nareshpatel]

Thank you very much for your detailed explanation.

I want to implement Fast Pair. So I am referring Locator Tag example from Sample. I have checked Sample Advertisment of fast pair. 

It does not include MAC address. In Google's document MAC address is part of the advertisement.

Does MAC address not required for Fast Pair ?

Which fields are mandatory for fast pair frame ?

How Google identify each device uniquely ? 

[PaKa]

So the locator sample in the nRF Connect SDK includes all the mandatory features to make a FMD tag. There are restrictions on what you are allowed to do with the transmitted frames when using FMD, this as the solution should not allow user to track the devices outside the FMD ecosystem. Devices are uniquely identified on the device owner device side, not on "any device" side. This is again to protect privacy.

Adding the MAC address to the frame would break privacy hard so I would seriously doubt that will be allowed to do.

The Google FMD spec is available in the open so if you want to modify the frames then I suggest checking that before determining the solution.

Can you share why you want to do this? There may be other ways of fixing it than transmitting the MAC address.

[Edvin]

The MAC address is part of every advertising packet, but it is not part of the payload in RAW data. 

I am not sure exactly what Google requires you to include in the fast pair advertisements. I guess it depends on the use. It seems that at least you need to include the Service UUID of the Fast Pair Service, 0xFE2C.

This according to Google's own documentation:

https://developers.google.com/nearby/fast-pair/specifications/bledevice

Particularly mentioned here.

I can try to break down the advertisement packet for you. As you can see, all elements in a BLE packet consists of 1 byte for length of the element, one byte for the element "type", and the remaining data in that element is the payload of that type. 

So the first element is 0x06162CFE4A436B. 

Length 6 (including the byte describing the type), type 0x16, and the remaining 5 bytes are the payload: 0x2C FE 4A 43 6B

That gives you the list in your screenshot. 

The different types are described in the "Assigned Numbers" document from Bluetooth SIG (Section 2.3)

Type:

0x16: Service Data
0x01: Flags
0x0A: TX power level
0x09: Complete Local Name

So the last 3 are quite straight forward. The first one, however, is up to the owner of that service, which in this case is Google (you can tell from the Assigned Numbers document. Search for FE2C, belonging to Google LLC). So Google decides the format of this data. The first 2 bytes, 2CFE (the bit order is a bit confusing) is the 16 bit service, and the remainding data is, according to the Core Specification Supplement, section 1.11: "Any remainder contains additional service data."

So from there, I can only point to the first link in this reply. 

Best regards,

Edvin

[Nareshpatel]

Thank you for your response. I am mapping find my protocol ble message frame with "Locator Tag" sample.   

Find My Device Network Accessory Specification  |  Fast Pair  |  Google for Developers

I would like to map specification of Google's FMDN and nordic "locator tag". How I would map message frame ? Please guide me. 

Please help me to understand FMDN technology to track item. Suppose I have manufacturer 100 quantities ble devices(same hardware model). I would like to track each device. How Google identify each device uniquely ?

[PaKa]

All of this is covered by the FMD specification so you will need to look at that. The nRF Connect SDK implementation is a spec compliant implementation so if you start to change the frame content than I would expect you will fail compliancy tests and it won't work as an FMD tag.

The technology uses the ephemeral data to uniquely identify the tag and allow the owner to track it. This is encrypted data so can only be used by the owner, you can't change how this works as that will break the FMD compliance.

Maybe you could explain why you want to break down these features as there may already be a solution for what you want to do, or we may already know this can't be done.