0

I use bluetoothctl (a Linux command line tool based on BlueZ) to read a BLE GATT heart rate sensor (I select the heart rate measurement attribute then use "notify on").

In the previous bluetoothctl version, here was an output sample:

[CHG] Attribute /org/bluez/hci0/dev_F7_AD_24_25_D4_05/service000c/char000d Value: 0x00 //flags
[CHG] Attribute /org/bluez/hci0/dev_F7_AD_24_25_D4_05/service000c/char000d Value: 0x40 //HR

In the current version, here is another output sample:

[CHG] Attribute /org/bluez/hci0/dev_A0_9E_1A_3B_6F_24/service0026/char0027 Value:
  00 4c                                            .L

So, all bytes are now on the same line, OK, but there is now an extra byte at the end (".L") whose meaning I don't know (not in the GATT spec) but whose content varies. The bluetoothctl documentation is unfortunately rather sparse (https://docs.ubuntu.com/core/en/stacks/bluetooth/bluez/docs/reference/gatt-services) and is of no help to me.

Does anyone know if this byte has any meaning, and if so, how to interpret it?

Arinelle
  • 3
  • 2

1 Answers1

0

It seems to first print the bytes in hex and then in ascii. It prints "." for the 0x00 byte and "L" for the 0x4c byte.

Emil
  • 16,784
  • 2
  • 41
  • 52
  • Thank you @Emil for your answer. "L" being equivalent to 0x4c makes total sense and corroborates well with other examples on hand. I still don't understand how 0x00 might correspond to "." (0x2E), though… But anyway, this would mean there's no additional hidden info, which is what I wanted to know! – Arinelle Oct 28 '19 at 15:06
  • Hexdump and similar tools usually replace "unprintable" characters such as NULL (0x00) with "." to denote that there is a character at this position. – Emil Oct 28 '19 at 15:24