You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In other cases the UUID128 will be more thoroughly randomized and not an assigned number. In that case it can sometimes be used to associate a device with a particular vendor or product model (e.g. Fitbit examples in my recent talk slide 87).
But in other cases the UUID may be associated with a particular silicon vendor (e.g. the Nordic UART service6E400001-B5A3-F393-E0A9-E50E24DCCA9E, which AFAIK is currently only found on devices using Nordic chips (i.e. AFAIK no other vendor had decided to copy that interface for usage on other chips)).
Consequently once again this information is potentially valuable for research on inferring product companies, chip maker companies, or classes of device (e.g. UUID128s associated with printers or headphones.)
This picture from #614 shows an example of BT Classic with UUID128s advertised in addition to UUID16s:
The text was updated successfully, but these errors were encountered:
This data is rare enough that local collection or central aggregation of this data isn’t going to be priority for the project. This ticket will be left open in case someone in the community would like to take on the first step of adding local collection of this data to the app. Its implementation might be included as part of this other UUID issue.
Analogous to #614, one of the other types of data that can be advertised by BLE and BT Classic is a 128-bit UUID (which come in both "incomplete list" and "complete list" forms, like UUID 16s. (And once again those constants are also available in https://bitbucket.org/bluetooth-SIG/public/src/main/assigned_numbers/core/ad_types.yaml as 6 and 7 respectively.)
There are some assigned UUIDs, where the base pattern is "0000XXXX-0000-1000-8000-00805f9b34fb", where the XXXX can either be one of the same 16-bit Service UUIDs (https://bitbucket.org/bluetooth-SIG/public/src/main/assigned_numbers/uuids/service_uuids.yaml) or Member UUIDs (https://bitbucket.org/bluetooth-SIG/public/src/main/assigned_numbers/uuids/member_uuids.yaml) mentioned in #164. Essentially the 16-bit UUIDs from #164 are just a more compact way of advertising this longer 128-bit UUID.
In other cases the UUID128 will be more thoroughly randomized and not an assigned number. In that case it can sometimes be used to associate a device with a particular vendor or product model (e.g. Fitbit examples in my recent talk slide 87).
But in other cases the UUID may be associated with a particular silicon vendor (e.g. the Nordic UART service
6E400001-B5A3-F393-E0A9-E50E24DCCA9E
, which AFAIK is currently only found on devices using Nordic chips (i.e. AFAIK no other vendor had decided to copy that interface for usage on other chips)).Consequently once again this information is potentially valuable for research on inferring product companies, chip maker companies, or classes of device (e.g. UUID128s associated with printers or headphones.)
This picture from #614 shows an example of BT Classic with UUID128s advertised in addition to UUID16s:
The text was updated successfully, but these errors were encountered: