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.

CC2650 compatibility with CC2400

Other Parts Discussed in Thread: CC2400, CC2650

Hi everyone,

I'm working with my company on the update of an old radio product based on the CC2400 transceiver to a single MCU solution using the CC2650 in proprietary mode. I have been able to write a receive test program that is able to receive packets from the old radio.

My problem is that the old product uses the 8b\10b line encoding to whiten the data to be transmitted. The encoder is inside the CC2400 and I couldn't find any documentation about the details of how the encoder works. I tried to decode the data using the 8b\10b encoding\decoding specifications from IBM but packet is not correctly decoded.

Disabling the 8b\10b encoding on the old radio allows me to receive the packets correctly, so I'm assuming that there is something in the encoding protocol that is not clear to me.

Does anyone know any details about the CC2400 8b\10b encoder?

Thank you.

  • Matteo, 

    I have checked and the CC2650 does not support 8/10 encode and decode functions in hardware. This would need to be done by the main system processor.

    I recommend disabling CRC check on the CC2650 and look at the entire received message from the CC2400 and then create a function on the main processor that can convert the data between the two formats.

    Regards,
    /TA

  • Thanks for the reply,

    I was aware of the lack of support for the 8b/10b encoding in the CC2650. I already did what you suggested (disabling CRC check on the CC2650) and I am able to receive data from the CC2400.

    My problem is that I cannot decode the data coming from the CC2400. I basically looks like the CC2400 is not following the standard 8b/10b encoding scheme described by IBM. I'd like to know if anyone could provide me better insight about how the CC2400 hardware codec works, so that I can write the right software coding/decoding functions.

    Thanks.

  • Can you publish the payload sent from the CC2400 and the payload as received by the CC2650.

    Regards,
    /TA
  • Hi, here is is the packet as sent from the CC2400

    [0]	unsigned char	0x01 (Hex)
    [1]	unsigned char	0x95 (Hex)
    [2]	unsigned char	0xFF (Hex)
    [3]	unsigned char	0xFF (Hex)
    [4]	unsigned char	0xFF (Hex)
    [5]	unsigned char	0xFF (Hex)
    [6]	unsigned char	0xFF (Hex)
    [7]	unsigned char	0xFF (Hex)
    [8]	unsigned char	0x00 (Hex)
    [9]	unsigned char	0x00 (Hex)
    [10]	unsigned char	0x00 (Hex)
    [11]	unsigned char	0x00 (Hex)
    [12]	unsigned char	0x00 (Hex)
    [13]	unsigned char	0x00 (Hex)
    [14]	unsigned char	0x8B (Hex)
    [15]	unsigned char	0x84 (Hex)
    [16]	unsigned char	0xC6 (Hex)
    [17]	unsigned char	0xD0 (Hex)
    

    And here is the packet received by the CC2650

    [0]	unsigned char	0x1C (Hex)
    [1]	unsigned char	0xA5 (Hex)
    [2]	unsigned char	0xAA (Hex)
    [3]	unsigned char	0xC6 (Hex)
    [4]	unsigned char	0xB1 (Hex)
    [5]	unsigned char	0xAC (Hex)
    [6]	unsigned char	0x6B (Hex)
    [7]	unsigned char	0x1A (Hex)
    [8]	unsigned char	0xC6 (Hex)
    [9]	unsigned char	0xB1 (Hex)
    [10]	unsigned char	0x9D (Hex)
    [11]	unsigned char	0x27 (Hex)
    [12]	unsigned char	0x49 (Hex)
    [13]	unsigned char	0xD2 (Hex)
    [14]	unsigned char	0x74 (Hex)
    [15]	unsigned char	0x9D (Hex)
    [16]	unsigned char	0x27 (Hex)
    [17]	unsigned char	0x48 (Hex)
    [18]	unsigned char	0xD9 (Hex)
    [19]	unsigned char	0xD9 (Hex)
    [20]	unsigned char	0xC4 (Hex)
    [21]	unsigned char	0xF4 (Hex)
    [22]	unsigned char	0x45 (Hex)
    [23]	unsigned char	0xE7 (Hex


    I hope this data can help you.

    Thank you

  • Matteo,

    I think I have most of it figured out, I use this table here:

    Then I used the 0x00 and 0xFF to identify the repeating patterns, which helped to figure out that the encoding is backwards.

    8-10bit_encoding.xlsx

    I have not solved the entire thing for you, I am still having issues correlating some of the values. But I think you are on the right track here.

    Regards,
    /TA

  • Thank you,
    I indeed managed to decode the 0x00s and 0xFFs, but unfortunately it looks like these are the only bytes that comes out correctly. I was hoping that somebody could point me in the correct direction to decode the rest of the packet.
    Thanks for your effort.
  • Actually the 0xA9 is 0x95 backwards.

    Can you just have the CC2400 send out a know sequence of data and they use this same algorithm to decode them. I will go hunting for the actual algorithm used on the CC2400, but it will likely take until some time next week for me to find anything.

    /TA
  • You are actually right, I didn't notice the reversed byte thing. I still have to figure out why the first byte is wrong. It looks like the first bit received is always zero instead of 1, but I guess I should dig into it more deeply. In the meantime if you could find the actual algorithm it would be very helpful.
    Thanks for your support.
  • Hi again,

    after your suggestions I was able to correctly decode the packets I received, but I still have some problems:

    The rate of correct packets received is very low, around 13%-15%.

    Most of the time as the first byte instead of 0x9C I receive 0x1C or 0x1D (as it happend in the exaple data I sent you)

    Do you think it might be because of slightly wrong settings in the radio configuration? In that case, Could you help me configure it correctly?