BLE Advertising Data

[dlech]

I just made an interesting discovery about the BLE manufacturer-specific advertising data on the BOOST Move Hub and Powered Up Smart Hub.

The first byte seems to indicate the button position. Normally it is 0x00, but if the button is pressed, it changed to 0x01. (On the Smart Hub, some of the other bytes change too, but I haven't figured out what that means).

Here are some other speculations:

Hub	Boot Mode	Example Advertising Data
Move Hub	Normal	0x004006FE4100, 0x014006FE4100
Move Hub	Firmware Update	0x000000104002
Smart Hub	Normal	0x004107004300, 0x014107006300
Smart Hub	Firmware Update	0x000000104002
Handset	Normal	0x00420A134100, 0x01420A004100, 0x00420A006100

Interpretation of Normal mode data:

• 1st byte is button state (0x00 for released, 0x01 for pressed).
• 2nd byte is Hub ID (matches 5th byte in firmware update mode advertising data and matches the value returned by the 0x0B device info command). 0x40 = Move Hub, 0x41 = Smart Hub, 0x42 = Handset.
• 3rd byte is alternate Hub ID? 0x06 = Move Hub, 0x07 = Smart Hub, 0x0A = Handset.
• 4th byte is connection ID? - at least on Smart Hub and Remote. When you "reset" the hub (by pressing and holding the button for 5 sec during power up until the LED turns pale purple) this value is reset to 0x00. When you link a Handset to the Smart Hub, this seems to be assigned a random number that matches on both devices. Resetting and re-linking results in a different number each time.
• 5th byte??? On Smart Hub bit 0x20 of this byte is set when the button is pressed and is cleared when the button is released (after a delay). On Handset, bit 0x20 is set when the button is released and cleared after a delay.
• 6th byte (0x00) means normal firmware boot mode?

Interpretation of Firmware Update mode data:

• 1st-4th bytes look like a version number as in the 0x03 device info command (i.e. 1.0.00.0000).
• 5th byte is hub id (see 2nd byte in Normal mode).
• 6th byte (0x02) means firmware update boot mode?

Note: Firmware Update mode is what you get when you press and hold the button for 5 seconds when powering on and the light turns pale purple. Once a connection is made, the lights change to alternating red, green, blue to indicate that firmware update is in progress. The Handset does not have bluetooth active in this mode, so presumably the firmware cannot be updated on that device - it just seems this is used to reset the channel selection.

Anyone have any other insights? Anyone have a Duplo hub (what is the advertising data there)?

[cpseager]

A couple of complete advert/scan response data dumps to compare against. My manufacturer data (FF), LEGO company identifier (97 03) data for boost was

  00 40 07 00 41 00

and for hub no.4 was

 00 41 07 00 43 00

Dumps (via BLED112 dongle:

   //*** boost dump ***

  //2017.08.05 11:19:48.403 ble_evt_gap_scan_response packet_type: 0 (0x00) sender:de89a3531600 address_type: 0 (0x00) bond: 255 (0xff) data:09ff9703004007004100020106110723d1bcea5f782316deef121223160000
  //2017.08.05 11:19:48.403 RX: 802a0600cf00de89a353160000ff1f09ff9703004007004100020106110723d1bcea5f782316deef121223160000
  //2017.08.05 11:19:48.403 ble_evt_gap_scan_response packet_type: 4 (0x04) sender:de89a3531600 address_type: 0 (0x00) bond: 255 (0xff) data:051210002000020a000e094c45474f204d6f766520487562
  //2017.08.05 11:19:48.418 RX: 80230600cf04de89a353160000ff18051210002000020a000e094c45474f204d6f766520487562

  //*** boost data ***
  //09 ff 97 03 00 40 07 00 41 00
  //02 01 06
  //11 07 23d1bcea5f782316deef121223160000

  //05 12 10002000
  //02 0a 00
  //0e 09 4c45474f204d6f766520487562 ='LEGO Move Hub'

  //*** hub 4 dump ****
  //2018.08.07 15:59:47.121 ble_evt_gap_scan_response packet_type: 0 (0x00) sender:7ebd022b8490 address_type: 0 (0x00) bond: 255 (0xff) data:020106110723d1bcea5f782316deef12122316000009ff9703004107004300
  //2018.08.07 15:59:47.122 RX: 802a0600c3007ebd022b849000ff1f020106110723d1bcea5f782316deef12122316000009ff9703004107004300
  //2018.08.07 15:59:47.124 ble_evt_gap_scan_response packet_type: 4 (0x04) sender:7ebd022b8490 address_type: 0 (0x00) bond: 255 (0xff) data:051210002000020a000909485542204e4f2e34
  //2018.08.07 15:59:47.125 RX: 801e0600c3047ebd022b849000ff13051210002000020a000909485542204e4f2e34

  // *** hub 4 data ***
  //02 01 06 
  //11 07 23d1bcea5f782316deef121223160000
  //09 ff 97 03 00 41 07 00 43 00 

  //05 12 10002000
  //02 0a 00
  //09 09 485542204e4f2e34 ='HUB No.4'

Here is some related info for the advert - Why just the one UUID service?

The main reason one UUID is preferable is hidden away in the boost/pup advertising header:

     //09 ff 97 03 00 40 07 00 41 00
     //02 01 06
     //11 07 23d1bcea5f782316deef121223160000

Note the 0x07 entry - Complete List of 128-bit Service Class UUID

Having all of the 128 bit UUIDs predefined in the advertising header completely eliminates the (time consuming) peripheral/central handshaking requirement to discover any other services during the connection process (because the Central already has what it needs from the advertising packet). This can therefore significantly reduce the connection time when compared to, for instance, wedo2 with its multiple UUIDs/services to handshake and discover.

The length of packet available for the peripherals advertising header is very limited, therefore in practise to use this trick you can only really have one UUID.

[cpseager]

It would be interesting to pair two hubs to one remote and see if byte 4 gets the same byte on all 3 devices? Does the same value always show the same color on the LED, as different colors are used to show which network you are connected to.

[dlech]

Ah yes. In my first comment I only mention the manufacturer-specific advertising data. Here is the rest in more readable form:

[dlech]

LEGO has two service UUIDs used on Powered Up devices:

• The Normal mode UUID 00001623-1212-efde-1623-785feabcd123
• The Firmware update mode 00001625-1212-efde-1623-785feabcd123

[cpseager]

Agreed, but only one is ever used in each mode, in effect they look like two completely separate ble devices depending on which mode It is in. You certainly can't discover the firmware service uuid when in normal mode.