• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 18 subscribers
  • Views 275 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC2500: Synchronous crosstalk issue

Cherry Zhou
Mastermind 22235 points
Part Number: CC2500

Hi Team,

Product: Indoor Photolamp equipment 

Packet definitions and basic concepts:

The customer's packet contains two bytes of sync word. Normally, the sender automatically inserts the sync word, and the receiver detects if the received sync word is the same as the agreed sync word. If yes, the CC2500 will automatically upload the data packet to the master MCU; if not, the cc2500 will not upload any information to the master MCU.

In the customer's product, the sync word is called ID. A total of 100 IDs have been defined.

Issue: Communication frequency point settings on both transmit and receive side. However, some IDs can also communicate with each other in cases where the ID settings are different.

For example, the receive side is set to ID0, regardless of the transmit side is set to ID0, ID1, ID3, Either ID7 or ID7, can communicate with the receiving end. Communication is best with the transmit side set to ID0; setting to ID1, ID3, ID7 has a small possibility to communicate.

The associated IDs are defined as follows: 

ID0 ID1 ID3 ID7
0xC368 0X61B4 0X30DA 0X186D
Could you help check this case? Thanks.
Best Regards,
Cherry
  • 0
    TI__Mastermind 20210 points

    Hi,

    Make sure the SYNC words (IDs) are maximal length PN sequences for maximum auto-correlation by the receiver. That will mitigate cross talk to a greater extent.

    Regards

  • 0 in reply to FI
    TI__Mastermind 22235 points

    Hi,

    Thanks for your support.

    The customer used maximum length, 32-bit (cc2500 feature--automatically copy 16-bit id to 32-bit) .

    Thanks and regards,

    Cherry

  • +1 in reply to Cherry Zhou
    TI__Expert 4620 points

    Hi Cherry,

    Is the customer also using the Preamble Quality Threshold (PQT) function?

    One thing to note with those words, each is just a binary right shift of the previous word. For example 0xC368 >> 1 == 61B4. So there's a strong similarity between each of the bit patterns. As my colleague noted above you want a maximal length pseudorandom (PN) sequence. This isn't referring to the length of the bit-sequence but to the properties of the bit-sequence. If you're unfamiliar, you can look up the term maximal length sequence and there's quite a bit of background information available online.

    In any case, even with an optimal system there still is some non-zero chance that you could receive an unintended packet. You could also look at incorporating packet filtering, see section 15.2 of the data sheet www.ti.com/.../cc2500.pdf

    -Jake

  • 0
    Expert 2635 points

    Part Number: CC2500

    Hi TI Teams,

    We set the 32bits sync word according to CC2500 packet format as the ID of different devices. Under normal circumstances, the transmitter will automatically insert the sync word, and the receiver will check whether the received sync word is consistent with the agreed ID, and if yes, it will send the received data to the MCU, otherwise the date packet will be ignored.

    However, we have encountered a crosstalk problem between different IDs when the sync word is multiplicative. For example, we have set different IDs as follows, but they can communicate with each other.

    We suspect that the sync word overflow is causing this problem, can u hlep to confirm it?

    Thanks,

    Kind Regards

  • 0 in reply to Lumina Gui
    TI__Expert 3380 points

    Hi Lumina,

    We will look into this. Please allow us until the end of the week to follow up.

    Best regards,

    Bun

  • 0 in reply to Bun Kuch
    TI__Expert 3380 points

    Hi Lumina,

    I am not sure if this thread is actually resolved or if it was an accident.

    Using the CC2500EM and TrxEB samples.ti.com, I can't replicate the crosstalk under any multiples of the original sync word. Can you replicate the issue using SmartRF studio 7? This would help exonerate the software. If it not the software, then we would have to look into the design/layout.

    Best regard,

    Bun