• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 53 subscribers
  • Views 470 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC1200: Transparent Mode Sample Clock

Reggie Wilcox
Prodigy 40 points
Part Number: CC1200

Hi,

I am using a CC1200 in transparent mode to receive a 500kbps 2FSK signal. According to the transparent mode description, the CC1200 "does not do any timing recovery and just outputs the hard limited baseband signal", so I would expect the edges of the output data stream to match those of the original FSK signal (perhaps with a small processing delay). However, when I look at the output, I notice jitter on output data stream where the edges deviate from what I would expect. This jitter appears to manifest as 150ns early or late from what I would expect which leads me to believe that this output data stream is being latched by a ~6.67MHz clock.

I have not been able to find any information detailing the nature of this sampling clock in SWRU346B or the CC1200 datasheet. Is there any Application Notes or information detailing the internal clocks used by the CC1200 and how the sampling of the output signals works?

Also, any insight as to the nature of this jitter? To me, there are two possible sources for this data: noise in the edge transitions causing early/late errors, and a data clock which does not divide the sample clock, requiring the systematic insertion of extra clocks to match rates. Note that I am using this in a wired setting so SNR should be high. Are there any suggestions for how to mitigate this jitter?

Thanks,

~Reggie

  • 0
    TI__Guru**** 317180 points
    It's been some time since I looked at the details here but the output in transparent mode is a function of resampling which will cause jitter (not sure if it's 4*RX_BW or 8*symbolrate).

    Transparent mode generate jitter and hence you need the MCU that process the stream to oversample by at least 3x and do a majority vote to filter out the jitter.

    Why are you using transparent mode in the first place?
  • 0 in reply to TER
    Prodigy 40 points

    I'm looking into using the CC1200 for radar timing applications where alignment between the digital timing and (a separate) RF waveform must be maintained. These digital outputs are processed asynchronously so the absolute position of the transitions matters, not just relative to a clock edge. My idea was that the transparent mode would preserve the timing of the bit transitions relative to the RF waveform and match clock edge transitions.

    If it is impossible to remove this jitter from the transparent mode output, then I would need to resample the output anyway. At this point I would switch to serial mode and synchronise to a common distributed clock. Using the transparent mode had the benefit of reduced complexity and removing the need for a distributed clock.

    So would an accurate takeaway be that there will be an inherent jitter in transparent mode that will require resampling to remove?

  • 0 in reply to Reggie Wilcox
    TI__Guru**** 317180 points
    Yes, due to how the processing is done (or not done) internally the transparent mode will have some jitter.