This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2564MODN: Interprete HCI Event for RSSI & Link Quality

Part Number: CC2564MODN

Hello,

can you help me by providing a  document or description how to interpete the reteurn valuse of HCI commands Get_RSSI and Get_Link_Quality? 

(Bluetooth module CC2564MODN)

Thanks,

Dietmar Sierk

Siemens Healthineers

  • Hi Dietmar,

    Do you mean the commands HCI_VS_Read_RSSI and HCI_Read_Link_Quality commands?

    The HCI_VS_Read_RSSI command is a vendor-specific command, and documentation on vendor specific commands can be found here:

    https://tidrive.ext.ti.com/u/-9MRXEDTEUnp0xFd/98ec7908-5d1e-4d80-a27b-a2456f7feda2?l

    The HCI_Read_Link_Quality command is part of the BT core spec, and its return values and full documentation can be found in section 7.5.3 of Vol 4, Part E of the v.5.2 spec. You can find the full spec here: https://www.bluetooth.com/specifications/specs/core-specification/

    Let me know if you need additional information on those commands.

    Regards,

    Michael

  • Hi Michael,

    thanks for your very fast response. Yes, I mean these both commands.

    And yes, may you can help me with additional information of those commands:


    RSSI: I've checked the hardware RF spec of the module, but did not find a definition of the golden Range in dBm. Chapter 5.7.4.1.1 "Bluetooth Receiver—In-Band Signals " gives the info about the sensitivity, thus I would expect rough a golden range around -20 to -70 dBm? Is it somewhere specified more in detail?

    Link Quality: The core spec gives also the hint regarding  vendor specific implementation ("The higher the value, the better the link quality is.
    Each Bluetooth module vendor will determine how to measure the link quality.").  Befor we change to the TI-module, we had a CSR bluecore in our product. There wars a very spcific coding of the Bit error rate by using some bits of the return parameter of the CI_Read_Link_Quality command. Does TI also code the Bit error rate or represents this value more a "scaled" value between good and bad?

    Thanks

    Dietmar

  • Hi Michael,

    thanks for your very fast response. Yes, I mean these both commands.

    And yes, may you can help me with additional information of those commands:


    RSSI: I've checked the hardware RF spec of the module, but did not find a definition of the golden Range in dBm. Chapter 5.7.4.1.1 "Bluetooth Receiver—In-Band Signals " gives the info about the sensitivity, thus I would expect rough a golden range around -20 to -70 dBm? Is it somewhere specified more in detail?

    Link Quality: The core spec gives also the hint regarding  vendor specific implementation ("The higher the value, the better the link quality is.
    Each Bluetooth module vendor will determine how to measure the link quality.").  Befor we change to the TI-module, we had a CSR bluecore in our product. There wars a very spcific coding of the Bit error rate by using some bits of the return parameter of the CI_Read_Link_Quality command. Does TI also code the Bit error rate or represents this value more a "scaled" value between good and bad?

    Thanks

    Dietmar

  • Hi Dietmar,

    The HCI_VS_Read_RSSI command returns the raw, non-golden range adjusted value. If you use the regular HCI_Read_RSSI command, some info on the golden range can be found here:

    https://e2e.ti.com/support/wireless-connectivity/bluetooth/f/bluetooth-forum/519868/what-s-the-lower-threshold-and-the-upper-threshold-of-the-golden-receive-power-range

    The returned link quality measurement is something I'm still looking into.

    Regards,

    Michael

  • Ok,
    thanks a lot for the golden range information. That helps. 

    It would be nice to hear you again, if you find some more details for the Link Quality reply.

    Thanks,

    Dietmar

  • Hi Dietmar,

    Looking at the controller code that handles the Link Quality command, it is indeed a scaled value between MIN_LINK_QUALITY and MAX_LINK_QUALITY (0-255).

    Roughly speaking, the algorithm looks like so:

    Link_quality = 255 - 20 * x - 5 * y

    x = number of packets with bad header in last 400ms

    y = number of packets with bad CRC in last 400ms.

    The link quality updates every 400ms, and if the Link_quality result is negative, it is set to the MIN_LINK_QUALITY value of 0.

    Those are the basics, and there are some adjustments to the basic formula above for optimizations and edge case handling, but I hope that information is helpful.

    Regards,

    Michael