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.

CC256XQFNEM: CC2564 Register address list to be used with HCI_VS_Read_Hardware_Register

Part Number: CC256XQFNEM
Other Parts Discussed in Thread: CC2564C

Hi,

We are testing audio quality on HFP profile (CVSD and mSBC) with a TI CC2564C module running Bluetopia. In order to do this we would need to get the PER or the number of Missed/received SCO/eSCO packet. It seems that we can get access to inner register that may (or not) contains the desierd information by using the VS Command  HCI_VS_Read_Hardware_Register (0xFF00)

However, I was unable to find a list of register with their corresponding address and meaning.

  1. Is it available or is it not disclosed on purpose?
  2. How can I check the packet count typically for SCO (HFP) use case?

Best regards,

  • Hi,

    Othmar John said:
    • Is it available or is it not disclosed on purpose?

    The internal register information is not disclosed. For all tests and/or use-cases the HCI interface must be used.

    Othmar John said:
    • How can I check the packet count typically for SCO (HFP) use case?

    When running a complete HFP use-case, you can use a Bluetooth sniffer to find out this information. 

    BR,

    Vihang

  • Hi Vihang,

    Thank you for your answer.

    We are testing audio distortion/quality in a regression test environment, we do make audio analysis to detect problem on the audio chain in our ends.

    Packet loss information help us decide if the PER is too high and to discard the audio analysis (PLC kicks in and distortion would be too high).

    In order to do the same with the TI it would be much easier to get such information. Hooking a BT sniffer 24/7 is quite overkill only to track SCO packet error rate thus my question regarding internal register.

    Is such register accessible with the HCI_VS_Read_Hardware_Register ?

    Would it be possible to have only this register so I can deal with audio analysis in a clever way?

     

    Many thanks in advance,

    Othmar

  • Hi Othmar,

    No such register is accessible. Moreover, the AVPR in the CC256x devices have PLC implementation. So the if the PCM path is being used for the SCO data, the output from the controller would already have PLC applied on it.

    I guess I am missing the big picture here. Could you share some details regarding how the SCO is configured in your system? and what purpose would this PER information serve? Would the host processor need to read the PER? I can discuss internally to see if there is any other way.

    Best regards,
    Vihang

  • Hello Vihang,

    Yes, we have the CC2564C connected over the PCM path. We are testing the SCO+CVSD as well as the eSCO+mSBC against a third party Bluetooth Classic Baseband+Controller Stack (also running the Bluetopia Host stack).

    We are monitoring any regression on the audio path of the third party solution (audio distortion or gaps for instance), audio received at TI side is also analyzed. When a packet is missing the PLC will start to filed the gap on the missing signal, but this action will already modify the audio signal in such way that we will be able to "see" signal degradation. In order to filter out false positive, we would like to take into account also the missing n-consecutive SCO/eSCO frame in order to skip the audio check is such situation.

    Monitoring the global BT Classic PER is also an option if we can't get access to the SCO/eSCO reception statistic.

    Best regards,

    Othmar

  • Hello Othmar,

    Unfortunately, I do not see any other way of getting the PER/BER data of an active eSCO connection without sniffing the connection.

    BR,
    Vihang