{"id":1342,"date":"2018-07-27T11:41:11","date_gmt":"2018-07-27T10:41:11","guid":{"rendered":"https:\/\/ofalcao.pt\/blog\/?p=1342"},"modified":"2018-07-29T23:11:49","modified_gmt":"2018-07-29T22:11:49","slug":"the-ble-properties","status":"publish","type":"post","link":"https:\/\/ofalcao.pt\/blog\/2018\/the-ble-properties","title":{"rendered":"The BLE properties"},"content":{"rendered":"
This post is part 2 of 2 of \u00a0LEGO Powered Up Remote Control<\/a><\/div>

First things first: the Remote Control BT Address and friendly name:<\/p>\n

A4:34:F1<\/a>:CE:DC:A2\u00a0 “Handset”<\/p>\n

The BT address is not a LEGO one like the BOOST (00:16:53<\/a>, “LEGO System A\/S IE Electronics Division”) or the Powered Up (90:84:2B<\/a>, “LEGO System A\/S”). It’s a Texas Instruments chipset, probably something like the CC2640<\/a>, a ARM microcontroller with embedded BLE functions.<\/p>\n

The usual browsing of properties with gatttool reveals 3 primary services and a few characteristics:<\/p>\n

primary\r\nattr handle: 0x0001, end grp handle: 0x0007 uuid: 00001800-0000-1000-8000-00805f9b34fb\r\nattr handle: 0x0008, end grp handle: 0x0008 uuid: 00001801-0000-1000-8000-00805f9b34fb\r\nattr handle: 0x0009, end grp handle: 0xffff uuid: 00001623-1212-efde-1623-785feabcd123<\/pre>\n
characteristics \r\nhandle: 0x0002, char properties: 0x02, char value handle: 0x0003, uuid: 00002a00-0000-1000-8000-00805f9b34fb\r\nhandle: 0x0004, char properties: 0x02, char value handle: 0x0005, uuid: 00002a01-0000-1000-8000-00805f9b34fb\r\nhandle: 0x0006, char properties: 0x02, char value handle: 0x0007, uuid: 00002a04-0000-1000-8000-00805f9b34fb\r\nhandle: 0x000a, char properties: 0x1c, char value handle: 0x000b, uuid: 00001624-1212-efde-1623-785feabcd123<\/pre>\n
char-desc \r\nhandle: 0x0001, uuid: 00002800-0000-1000-8000-00805f9b34fb\r\nhandle: 0x0002, uuid: 00002803-0000-1000-8000-00805f9b34fb\r\nhandle: 0x0003, uuid: 00002a00-0000-1000-8000-00805f9b34fb\r\nhandle: 0x0004, uuid: 00002803-0000-1000-8000-00805f9b34fb\r\nhandle: 0x0005, uuid: 00002a01-0000-1000-8000-00805f9b34fb\r\nhandle: 0x0006, uuid: 00002803-0000-1000-8000-00805f9b34fb\r\nhandle: 0x0007, uuid: 00002a04-0000-1000-8000-00805f9b34fb\r\nhandle: 0x0008, uuid: 00002800-0000-1000-8000-00805f9b34fb\r\nhandle: 0x0009, uuid: 00002800-0000-1000-8000-00805f9b34fb\r\nhandle: 0x000a, uuid: 00002803-0000-1000-8000-00805f9b34fb\r\nhandle: 0x000b, uuid: 00001624-1212-efde-1623-785feabcd123\r\nhandle: 0x000c, uuid: 00002902-0000-1000-8000-00805f9b34fb\r\nhandle: 0x000d, uuid: 00002901-0000-1000-8000-00805f9b34fb<\/pre>\n
More details from the Nordic nRF Connect app:<\/p>\n
The first primary service (1800, Genneric Access) has 3 chars:
\nDevice Name: Handset
\nAppearance: Unknown
\nPeripheral Preferred Connection Parameters: Connection Interval: 100.00ms-200.00ms, Slave Latency:0, Supervision Timeout Multiplier: 1000<\/p>\n
The second primary service (1801, Generic Attribute) is empty. Not unusual since it is optional.<\/p>\n
The last primary service has the same UUID already present on BOOST and Powered Up hubs (i.e. “00001624-1212-efde-1623-785feabcd123”). And like those it has only one characteristic, “LWP ProtocolChar”.<\/p>\n
(side note: LWP might mean Light Weight Process or LEGO Wireless Protocol or just Lets Worsen your Pain)<\/p>\n
Thats good: since this “Handset” shares the same primary service UUID of the other PF2 \/ Powered Up devices, it might also work in the same way.<\/p>\n
So lets enable notifications and see what we got:<\/p>\n
char-write-req 0x0c 0100\r\nNotification handle = 0x000b value: 0f 00 04 00 01 37 00 00 00 00 10 00 00 00 10 \r\nNotification handle = 0x000b value: 0f 00 04 01 01 37 00 00 00 00 10 00 00 00 10 \r\nNotification handle = 0x000b value: 0f 00 04 34 01 17 00 00 00 00 10 00 00 00 10 \r\nNotification handle = 0x000b value: 0f 00 04 3b 01 14 00 02 00 00 00 02 00 00 00 \r\nNotification handle = 0x000b value: 0f 00 04 3c 01 38 00 00 00 00 10 00 00 00 10<\/pre>\n
Yeap! 4 devices on 5 different ports:<\/p>\n
    \n
  • Device ’37’ on ports ’00’ and ’01’<\/li>\n
  • Device ’17’ present on port ’34’<\/li>\n
  • Device ’14’ present on port ‘3B’<\/li>\n
  • Device ’38’ present on port ‘3C’<\/li>\n<\/ul>\n
    Nathan already told me that device ’37’ is associated to the buttons. So two “pads” of buttons, one on port ’00’ and other on port ’01’.<\/p>\n
    Device ’17’ is the RGB LED on the BOOST. I’ll look to it later.<\/p>\n
    Device ’14’ and ’38’, like Nathan pointed, seem Voltage and Current readings. We can activate each with:<\/p>\n
    char-write-req 0x0b 0a0041[3B\/3C]000100000001<\/pre>\n
    The first (3B) will generate regular messages like ’06 00 45 3b a5 0b’ and the second (3C) also generates regular messages like ’05 00 45 3c cc’<\/p>\n
    So the payload is ‘3B A5 0B’ and ‘3C CC’, reverting and converting to decimal it gives<\/p>\n
    0BA53B = 763195 = 7.63\u00a0 Volt ? hard to believe with just 4 AAA batteries<\/p>\n
    converting to float = 0.00503671 = 5.037 Volt? Perhaps<\/p>\n
    CC 3C = 52284 = 52 mA ? Why just two bytes and not 4? Hmm….<\/p>\n
    We can also deactivate with<\/p>\n
    char-write-req 0x0b 0a0041[3B\/3C]000100000000<\/pre>\n
    Really not important, at least for now. Let’s look to the button pads and the RGB LED and give them a good use:<\/p>\n
    char-write-req --handle 0x0b --value 080081341151000X<\/pre>\n
    The command works like the BOOST (just changed the port, ’32’ to ’34’) and it accepts the same 10 values:<\/p>\n
    OFF=0\r\nPINK=1\r\nPURPLE=2\r\nBLUE=3\r\nLIGHTBLUE=4\r\nLIGHTGREEN=5\r\nGREEN=6\r\nYELLOW=7\r\nORANGE=9\r\nRED=9\r\nWHITE=A<\/pre>\n
    Once again, not sure about the color names but those above are good enough for me…<\/p>\n
    Now the buttons, we activate them with:<\/p>\n
    char-write-req 0x0b 0a004100000100000001 (Left or 'A')\r\nchar-write-req 0x0b 0a004101000100000001 (Right or 'B')<\/pre>\n
    so we now receive a notification each time there is a state change:<\/p>\n
    Left or A+ on then off:<\/p>\n
    05 00 45 00 01\r\n05 00 45 00 00<\/pre>\n
    Left or A- on then off:<\/p>\n
    05 00 45 00 ff\r\n05 00 45 00 00<\/pre>\n
    Left or A Red on then off:<\/p>\n
    05 00 45 00 7f\r\n05 00 45 00 00<\/pre>\n
    And the same happens for Right or B, just the fourth byte is now ’01’ instead of ’00’.<\/p>\n
    So we can use our new ‘Handset’ with whatever BLE capable device we want.<\/p>\n
    Next bash shell loops through the 10 RGB possible values:<\/p>\n
    #!\/usr\/bin\/env bash\r\n\r\n#colors\r\nOFF=0\r\nPINK=1\r\nPURPLE=2\r\nBLUE=3\r\nLIGHTBLUE=4\r\nLIGHTGREEN=5\r\nGREEN=6\r\nYELLOW=7\r\nORANGE=9\r\nRED=9\r\nWHITE=A\r\n\r\nfunction remoteLED () {\r\n    gatttool -b A4:34:F1:CE:DC:A2 --char-write-req --handle 0x0b --value 080081341151000$1\r\n}\r\n\r\n# activate notifications and keep changing colors\r\ngatttool -b A4:34:F1:CE:DC:A2 --char-write-req --handle 0x0c --value 0100\r\n\r\nwhile :\r\ndo\r\n    for color in $OFF $PINK $PURPLE $BLUE $LIGHTBLUE $LIGHTGREEN $GREEN $YELLOW $ORANGE $RED $WHITE; do\r\n        remoteLED $color\r\n        sleep 1\r\n    done\r\ndone<\/pre>\n