{"id":1428,"date":"2018-09-03T18:22:34","date_gmt":"2018-09-03T17:22:34","guid":{"rendered":"https:\/\/ofalcao.pt\/blog\/?p=1428"},"modified":"2018-09-03T18:56:52","modified_gmt":"2018-09-03T17:56:52","slug":"sniffing-the-lego-wedo-2-0-motion-sensor","status":"publish","type":"post","link":"https:\/\/ofalcao.pt\/blog\/2018\/sniffing-the-lego-wedo-2-0-motion-sensor","title":{"rendered":"Sniffing the LEGO WeDo 2.0 Motion Sensor"},"content":{"rendered":"

Now that I have a working cable to intercept Powered Up signals I no longer need to cut a sensor cable to hijack it.<\/p>\n

So let’s start with a simple sensor: the 45304 LEGO WeDo 2.0 Motion Sensor<\/p>\n

<\/p>\n

Procedure:<\/p>\n

    \n
  1. connect the male plug of the Powered Up Interception Cable<\/a> to LEGO BOOST Move Hub (port C)<\/li>\n
  2. connect a WeDo 2.0 Motion Sensor to the “female” plug of the Interception Cable<\/li>\n
  3. connect the Bus Pirate to the “interception” 6-pin header<\/li>\n
  4. connect the Bus Pirate to a USB port and set it up as a Transparent UART Bridge (115200 bps, 8N1, floating inputs)<\/li>\n
  5. run jpnevulator<\/strong> to read traffic comming from the Bus Pirate<\/li>\n
  6. turn of the LEGO BOOST Move Hub<\/li>\n
  7. connect to it with gatttool<\/strong><\/li>\n
  8. enable notifications (‘char-write-req 0x0f 0100’)<\/li>\n
  9. enable the Motion Sensor on port C (‘char-write-req 0x0e 0A004101000100000001’) in mode ‘0’<\/li>\n
  10. watch, watch, watch<\/li>\n<\/ol>\n

    So everytime the measured distance change I get a notification in gatttool and a 3-byte message in jpnevulator. And it is simple:<\/p>\n

    00 => C0 00 3F\r\n01 => C0 01 3E\r\n02 => C0 02 3D\r\n03 => C0 03 3C\r\n04 => C0 04 3B\r\n05 => C0 05 3A\r\n06 => C0 06 39\r\n07 => C0 07 38\r\n08 => C0 08 37\r\n09 => C0 09 36\r\n0A => C0 0A 35<\/pre>\n
    A start byte (‘C0’) plus the payload\u00a0 plus and end byte (‘3F’ i.e. the complement of ‘C0’ minus the payload).<\/p>\n
    Great! Not even an initialization sequence!<\/p>\n
    So disconnect the Interception Cable male plug and replace the Bus Pirate with the FTDI Beefy 3 adapter, set ‘\/dev\/ttyUSB3’ to 115200 and raw mode and test several bash commands.<\/p>\n
    Not totally clear yet but this works:<\/p>\n
     <\/p>\n
    #!\/usr\/bin\/env bash\r\n\r\n# sync\r\nfor i in {1..50000}\r\ndo\r\n    echo -e -n \"\\x00\" > \/dev\/ttyUSB3\r\ndone\r\n\r\nfor i in {1..50000}\r\ndo\r\n    echo -e -n \"\\x02\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\" > \/dev\/ttyUSB3\r\ndone\r\n<\/pre>\n
    (that ‘echo’ command is just a line)<\/p>\n
    Now the usual voodoo explanation:<\/p>\n
    The first byte sent is like a read command. I got success with ’02’, ’04’, ‘0F’, ’27’ and ‘FF’ and 3 different behaviors.<\/p>\n
    The remaining 15 bytes (’00’) are like the inital synchronization commands… I don’t think they are valuable data and sending a ‘break’ to the TX line for enough time would do the same… but I just can’t find a way to send a break.<\/p>\n
    So the 3 different behaviors:<\/p>\n