This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Sniffing a Bosch laser tape 2

Hi.

I`m trying to figure out a way I can control a Bosch GLM120C laser measure device using a micro controller.

I`m a stage where I can activate  the laser(1st command) and take a measurement(2nd command) using NRF connect app on my phone.

Service UUID: 2A6C0D0-0451-4000-B000-FB3210111989

Command I`m writing "c05601001e"  first time it activates the laser and 2nd time it takes a measurement. 

While the app from Bosch does get the distance value. I can`t seem to figure out what packet  the data is being sent back in, I`m using Wireshark and BLE sniffer(52 dongle).

https://www.dropbox.com/s/z97dv8qdbm8emja/514mm%282%29.pcapng?dl=0

Any input would be much appreciated. 

Thanks Guys.

Parents
  • Since I got an nRF sniffer and I am interested in Bluetooth LE I took a peek at the communication of the Bosch GLM120C and figured how the measurement data can be acquired.

    As Dainius G mentioned before, performing a write access using the hex byte sequence c0 56 01 00 1e to characteristic
    [UUID: 02a6c0d104514000b000fb3210111989]
    in
    [Service UUID: 02a6c0d004514000b000fb3210111989]
    starts the laser. The device will then generate two indications (have to be enabled) on the characteristic. It seems the value data in the first two indications after firing up the laser can be ignored.

    When the laser is on and the same byte sequence is written to the characteristic again, as metioned above, the laser is turned off and two more indications are generated on the characteristic we performed the write access on.
    The first indication contains the byte sequence:
    Value: 000082
    It seems this data is not interesting. Right after confirmation of the indication, another indication will be generated for the same characteristic - this one contains the measurement data.

    This is the relevant indication value data from the GLM120C (aka GLM400C in the US) I acquired using nRF Sniffer with Wireshark (both are great tools!):

    Bluetooth Attribute Protocol
        Opcode: Handle Value Indication (0x1d)
        Handle: 0x001e (Unknown: Unknown)
            [Service UUID: 02a6c0d004514000b000fb3210111989]
            [UUID: 02a6c0d104514000b000fb3210111989]
        Value: c0551006XXXXXX2c439c3e000000000000000036

    the value bytes XXXXXX above have been redacted - they might contain personal information (unlikely, but still).

    Supposed meaning of the second indication value data by index/offset (most of it is speculation, but I am certain about the the actual measurement data):

    0x00 - 0x01: 0xC0 0x55  Header (speculation)
    0x02: 0x10 Length (speculation) This seems to be the number of the following bytes before the supposed 8-Bit CRC in the packet.
    0x03: This byte had the value 0x06 so far, when there was non-zero (valid?) measurement data. Otherwise, when the laser was just started and measurement data was zero / invalid, this byte was 0x02 in my attempts.
    0x04 - 0x06:??
    0x07 - 0x0A: 32-bit floating point value (IEEE-754, little endian) representing the measured length in meters. In the example above case the byte sequence is 2C 43 9C 3E. The laser tape showed 0.305 meters when I did the measurement. Given that this is little endian, we reverse the byte order 0x3E9C432C and can feed it to an online converter (like this one):
    https://www.h-schmidt.net/FloatConverter/IEEE754.html
    0x3E9C432C gives a measurement of 0.305199980736
    I did a few attempts with different distances and the result always matched the reading on the display of the GLM120C.
    0x0B - 0x12: ?? These bytes have always been 0x00 in my case.
    0x0C: CRC/Checksum?? Seems to be some additional non-standard 8-Bit CRC / Checksum. Can be ignored (BLE has its own CRC anyway).

    There's a good chance that the same service is used on other Bosch laser tapes like the GLM50C.
    Maybe this helps.

Reply
  • Since I got an nRF sniffer and I am interested in Bluetooth LE I took a peek at the communication of the Bosch GLM120C and figured how the measurement data can be acquired.

    As Dainius G mentioned before, performing a write access using the hex byte sequence c0 56 01 00 1e to characteristic
    [UUID: 02a6c0d104514000b000fb3210111989]
    in
    [Service UUID: 02a6c0d004514000b000fb3210111989]
    starts the laser. The device will then generate two indications (have to be enabled) on the characteristic. It seems the value data in the first two indications after firing up the laser can be ignored.

    When the laser is on and the same byte sequence is written to the characteristic again, as metioned above, the laser is turned off and two more indications are generated on the characteristic we performed the write access on.
    The first indication contains the byte sequence:
    Value: 000082
    It seems this data is not interesting. Right after confirmation of the indication, another indication will be generated for the same characteristic - this one contains the measurement data.

    This is the relevant indication value data from the GLM120C (aka GLM400C in the US) I acquired using nRF Sniffer with Wireshark (both are great tools!):

    Bluetooth Attribute Protocol
        Opcode: Handle Value Indication (0x1d)
        Handle: 0x001e (Unknown: Unknown)
            [Service UUID: 02a6c0d004514000b000fb3210111989]
            [UUID: 02a6c0d104514000b000fb3210111989]
        Value: c0551006XXXXXX2c439c3e000000000000000036

    the value bytes XXXXXX above have been redacted - they might contain personal information (unlikely, but still).

    Supposed meaning of the second indication value data by index/offset (most of it is speculation, but I am certain about the the actual measurement data):

    0x00 - 0x01: 0xC0 0x55  Header (speculation)
    0x02: 0x10 Length (speculation) This seems to be the number of the following bytes before the supposed 8-Bit CRC in the packet.
    0x03: This byte had the value 0x06 so far, when there was non-zero (valid?) measurement data. Otherwise, when the laser was just started and measurement data was zero / invalid, this byte was 0x02 in my attempts.
    0x04 - 0x06:??
    0x07 - 0x0A: 32-bit floating point value (IEEE-754, little endian) representing the measured length in meters. In the example above case the byte sequence is 2C 43 9C 3E. The laser tape showed 0.305 meters when I did the measurement. Given that this is little endian, we reverse the byte order 0x3E9C432C and can feed it to an online converter (like this one):
    https://www.h-schmidt.net/FloatConverter/IEEE754.html
    0x3E9C432C gives a measurement of 0.305199980736
    I did a few attempts with different distances and the result always matched the reading on the display of the GLM120C.
    0x0B - 0x12: ?? These bytes have always been 0x00 in my case.
    0x0C: CRC/Checksum?? Seems to be some additional non-standard 8-Bit CRC / Checksum. Can be ignored (BLE has its own CRC anyway).

    There's a good chance that the same service is used on other Bosch laser tapes like the GLM50C.
    Maybe this helps.

Children
  • Hi Sparkybert,

    I am trying to apply your info on a GLM50C. And it seems to be working. Almost.

    At the moment I able to send the request and the laser turns on and gets a value. According to Dainius G. post ("send the bytes twice").

    However, I do not get a response back (including the measured value), unless I connect the device to the official application first (I connect the device with the app, I disconnect it and there it is... ).

    I have turned on the indications on the characteristic but there is no hex with the measurement value. The moment I connect the device to the official app (MeasureOn) and disconnect it (even without taking any measurement), I am able to receive hex with the correct value.

    By the way, it is the same when using nRF connect (in case you are not familiar, an android app to sniff bluetooth, but i assume it's the same as nRF sniffer you mentioned on your post).

    ( this following section might be irrelavent, but in any case ....

    I tried sniffing the bluetooth with my android phone, and one thing to mention that might help is that as soon as the indication flag is set on the characteristic:

    the official app       sent write request, handle 0x001e with value c05502

    the device              rcvd write respons, handle 0x001e              and then

    the device              rcvd handle value indication, handle 0x001e with value 001000

    the official app       sent handle value confiramation, handle 0x001e

    )

    Any help would be much appreciated.

    Thanks.

Related