BLE Advertising Data about boostreveng HOT 5 OPEN

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.

from boostreveng.

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.

from boostreveng.

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

from boostreveng.

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

from boostreveng.

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.

from boostreveng.