Google's new Find My Device Network - is it possible to add Eddystone frame type 0x40/0x41 to the bluetooth numbers database?

[vaubaehn]

Hi everybody,

Google is currently rolling out their Google Find My Device Network (FMDN) - as a complement to Apple's FindMy.

For their network to locate BLE accessory tags, they revived Eddystone. According to their specs, any FMDN-capable accessory should advertise their frame of type 0x40 or type 0x41 (formerly reserved, before they shut down their Eddystone project some years ago).

The specs can be found here: https://developers.google.com/nearby/fast-pair/specifications/extensions/fmdn#advertised-frames

In the wild, you will currently find Eddystone frames also differing in their flags set (octet 02, according to the specs linked above): Accessories have set their flag set to 0x06, and Android mobile phones have their flag set to 0x02, when they're offline (no WiFi/no mobile data) but advertising with Bluetooth enabled.

As Google's FMDN has recently started to roll out, currently there is much debugging on the way everywhere...

To facilitate debugging, it would be nice when BLE scanner apps are able to parse and reflect the FMDN specifications by displaying associated information. As far as I understood, the database in this repository is also the base of information that is downloaded on app start and then displayed associated with scanned BLE frames in nRF Connect Android/iOS.

Did I understand it right, that these new FMDN Eddystone specifications/characteristics could be added to bluetooth numbers database so that they can be parsed with related apps? If yes, is there someone who could add these to the database? Otherwise I'd propose to create a PR, but I would need a guiding/helping hand to find the correct places where these data could be added.

Thanks in advance!

[dinesharjani]

Hello,

I can be your guide :)

So, originally this was designed to be a "numbers" database, mostly for UUIDs. What you say makes sense. And you're also correct in that Nordic apps like nRF Connect for iOS download the listing here. Android version I'm not sure if it was updated but, NFC uses files inside the /experimental folder.

My proposal would be, make a PR that adds the Eddystone into /experimental, and I'll help you out. We'll work on it together.

[dinesharjani]

I think you can start with https://github.com/NordicSemiconductor/bluetooth-numbers-database/blob/master/v1/gap_appearance.json as a basis for what the Eddystone JSON looks like.

[vaubaehn]

Hi @dinesharjani ,

thanks for your guidance! :)

I was looking into the gap_appearance.json that you pointed me to, and after that I also peeked into the other files, and currently I doubt a bit, that what I proposed above can be achieved by additions/changes in this repository here.

I am trying to illustrate what I am actually talking about:

Eddystone frames/their 16-bit UUIDs are already added to the numbers database, see https://github.com/NordicSemiconductor/bluetooth-numbers-database/blob/cbca5a3deb43775ec09df7263ec8546252d40a2b/v1/service_uuids.json#L97

Advertisements of Eddystone Find My Device frames are partly parsed and displayed in nRF Connect Android/iOS, like (for Android) (MAC address and ephemeral identifier are pseudo-random and frequently changing per device, but to not provoke any complaint I blurred them...)

The problem here is, that Google revived their Eddystone format, and they're now making use of the formerly reserved frame types 0x40 and 0x41 for for their Find My Device Network service. It would be nice, when also the frame type is gracefully parsed and the association with the new Find My Device Network would be displayed in the apps accordingly. Also, in this special use case, the device type (here displayed as UNKNOWN, may probably be derived from the BLE capability flags (0x06 for accessories and mobile phones when powered off, 0x02 for offline Android devices when powered on, 0x1A for other FMDN-capable devices (I don't know type/state yet).

If you look to the raw data payload, you see that the frame type indicating FMDN service is following after the 16-bit Service UUID FEAA (here 0x40).

Similarly, nRF Connect iOS parses an FMDN frame as Eddystone frame type 40 (reserved):

So, when I opened this issue, I was hoping that the Bluetooth Numbers Database here also holds values associated with friendly names for specific services like the frame type for Eddystone frames, so that any app relying on this database is able to parse/detect Eddystone FMDN frames and to display the friendly names of their characteristics accordingly. But I guess, this is not possible? As nRF Connect is not OSS, I also couldn't see whether and how is parsing is done in these apps...

But I guess, you'd recommend me to open enhancement requests in their repositories?

Kind regards!

[philips77]

Thanks for letting us know! I didn't know Find My Device extended Eddystone. Unfortunately, parsing of packets is still hardcoded in the apps. We will update them, but as we entered vacation period, this will take a while.

[vaubaehn]

Hi @philips77 & @dinesharjani , thanks for the clarification. So I will close this issue here and open corresponding ones in the nRF Connect iOS/Android repos. A nice vacation time to you all!

[dinesharjani]

@vaubaehn actually, as Filip said, we are hard-coding these values. But your idea still has plenty of merit - if there's a place to add those Eddystone values, it's here. My idea was that we add those definitions here, and then we update the apps. (For context: I handle nRF Connect for iOS, and @philips77 does Android) so, you're essentially speaking to the same people :)