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.

CC2564: CC2564

Part Number: CC2564

Hello,

 

We are developing BT RF FCC Modes firmwares on CC2564 following the wiki:

http://processors.wiki.ti.com/index.php/CC256x_Testing_Guide#BT_RF_FCC_Modes

 We have firmwares ready both in Continuous TX and Packet TX/RX sub modes with different frequencies and different modulations. We can measure the quality of signal with a spectrum analyser.

 

We have issues for the Hopping mode:

1-      In Continuous TX sub mode, the Hopping mode seems not available ☹.

2-      In Packet TX/RX sub mode, the amplitude of signal is weak in DH5, 2DH5 and 3DH5 modulation so we aren’t able to release a firmware in Hopping mode (for information, we have similar amplitude to Continuous RX mode in DH5 modulation in single frequency mode).

Do you have any idea or experience in Hopping mode for DH5, 2DH5 and 3DH5 modulation?

 

Regards,

Emmanuel

  • Emmanuel,

    Emmanuel SAVY said:
    1-      In Continuous TX sub mode, the Hopping mode seems not available ☹.

    The data transmitted in the continuous TX mode is not packetized. Thus, no hopping mode.

    Emmanuel SAVY said:
    In Packet TX/RX sub mode, the amplitude of signal is weak in DH5, 2DH5 and 3DH5 modulation so we aren’t able to release a firmware in Hopping mode (for information, we have similar amplitude to Continuous RX mode in DH5 modulation in single frequency mode).

    All 3 packet types mentioned above are larger packets. Have you verified that the RBW and VBW of your spectrum analyzer are set appropriately for this type of packets? Exactly how low of an amplitude do you see on these tests? Any FW logs (User's Guide)?

    Best regards,

    Vihang

  • Hi,

     

    The bit we find unclear is the example given

    HCI_VS_DRPb_Tester_Packet_TX_RX 0xFD85, 0x01, 0, 0xFF, 0, 2, 0, 27, 15, 1, 0x01FF

    doesn’t match the specification in the vendor specific commands.

     

    The parameters in the below example make a total of 11 bytes but looking at:  http://processors.wiki.ti.com/index.php/CC256x_VS_HCI_Commands#HCI_VS_DRPb_Tester_Packet_TX_RX_.280xFD85.29

     

    There are 12 bytes of parameters, which one is correct? We are assuming it’s the 11 byte version because we never get a response when sending 12 bytes as in the VS spec in the link above.

    We would like to send :

    0xFD85, 0x00, 0, 0xFF, 0x08, 2, 0, 0x03FD, 15, 0, 0x000 (12 parameters as described in datasheet) -> No acknowledgement

    We have weak power in Hopping mode with acknowledgment

    0xFD85, 0x00, 0, 0xFF, 0x08, 2, 0x0040, 15, 0, 0x000 (11 parameters - we were thinking 1st that reserved was not used)

    We were able to get an acknowledgement and an Hopping mode working by testing "strange" values but with a 11-parameter command:

    0xFD85, 0x00, 0, 0xFF, 0x08, 2, 0, 0x40, 15, 0, 0x000 (11 parameters)

    Our guess is that we should use 11-parameter command (length coded on only 1 byte?) and the there's a mistake in the datasheet.

    We are on the case the get consistent parameters...

    Does any one get the same problem with the HCI_VS_DRPb_Tester_Packet_TX_RX command?

    Regards,

    Emmanuel

  • Emmanuel,

    There are 10 parameters (that total to 12 bytes) in this command.

    i.e.

    HCI_VS_DRPb_Tester_Packet_TX_RX 0xFD85, 0x00, 0x00, 0xFF, 0x08, 0x02, 0x00, 0x02A7, 0x0F, 0x01, 0x01FF

    The byte stream for this command would look like the following.

    0x01 0x85 0xfd 0x0c 0x00 0x00 0xff 0x08 0x02 0x00 0xa7 0x02 0x0f 0x01 0xff 0x01

    Best regards,

    Vihang