• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 2 answers
  • Subscribers 52 subscribers
  • Views 1069 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.

CC2543: Spectral emissions for packet TX

npb17
Expert 1615 points
Part Number: CC2543

We are using the CC2543 to transmit ~30byte packets at roughly 500us intervals using 2Mbps GFSK +/-500kHz modulation.

We've noticed that there is quite a bit of spectral emission at the start of each packet transmit.   We believe unwanted emission is occurring during the synthesizer warmup or preamble period.

Below is a screenshot of the spectrum when transmitting at 2400MHz.  The device was cabled to the spectrum analyzer (e.g. no outside over-the-air noise sources).


--> Is there an advised delay from setting PRF.CHAN.FREQ to calling SEND_LLE_CMD(CMD_TX)?  Our custom software is calling those functions one after the other prior to each packet transmit.  There are no delays or other instructions between.  

--> Is this amount of spurious noise expected?

  • 0
    TI__Guru** 106705 points
    Hi,

    This is not expected. Can you try controlling your board through SmartRF Studio? Is this a TI EVM or custom HW?

    Cheers,
    Fredrik
  • 0 in reply to Fredrik K
    Expert 1615 points

    Hi Fredrik,

    This is with the EM.  I did try SmartRF Studio to put the module in Packet TX mode, same modulation scheme.  The spectrum looks clean in that case.  I assume my software is different somehow.  Or maybe the slower packet interval when using SmartRF Studio cleans up the emissions.

    I'll take a look at the PER code again and see if my software is missing any register settings upon TX start/end.

  • 0 in reply to npb17
    Expert 1615 points
    The PER code works fine down to 500us packet intervals. Good spectral quality.

    Is it possible that using other timers (Timer 1 or Timer 3) would introduce noise on the transmit spectrum? The PER example code uses Timer 2.
    My code is using Timer 3 for starting TX at a regular interval.
  • 0 in reply to npb17
    Expert 1615 points

    bad_spectrum_tx.zip

    Attached is a minimal example based on PER code where Timer 3 is used to initiate packet TX at roughly 500us intervals on the 2400MHz channel.  This replicates the spectral irregularities I'm seeing.

  • 0 in reply to npb17
    Expert 1615 points

    I have a few of these demo boards to try. I'm noticing some variation among the boards running the same software.  Some EMs are more prone to emitting noise, others have a cleaner spectrum.  Perhaps we have a batch of bad chips?

    The board that is noisiest has a clean spectrum when using SmartRF Studio to trigger transmit.  So I think the key is replicating register writes/order that SmartRF Studio uses.

  • 0 in reply to npb17
    TI__Guru 56590 points
    Hello,
    As described in halRfSetFrequency help text the LLE must be idle while changing frequency. Could this be the cause? Please refer to the halRfDisableRadio function in hal_rf_proprietary.c to see how to check LLE status.

    I suspect the issue is related to incorrect radio command/control sequence somewhere in your code flow...
  • 0 in reply to Eirik V
    TI__Guru 56590 points

    A few more suggestions:

    • Also check the LLE status before you issue CMD_TX to the radio.
    • Perhaps change the sent variable into a volatile variable.
    • You can also profile your while loop with GPIO output signals.
    • You can halt the processor in your while loop and let the interrupts trigger further execution.

  • 0 in reply to Eirik V
    Expert 1615 points

    Hi Eirik,

    If I set PRF.PKT_CONF.START_TONE = 0, the spectrum cleans up nicely. We had been enabling that in accordance with the PER example code for 2Mbps modulation.

    Does AGC still work properly with that disabled? Section 23.9.2.2 of the UG indicates the tone is used for AGC calibration on the receiver. Will AGC still adjust with just preamble, no tone?

  • 0 in reply to npb17
    TI__Guru 56590 points
    The AGC will work with preamble bytes only and start tone disabled, but you must use enough bytes for the AGC to work properly. The characterization was done with 13 preamble bytes.
  • 0 in reply to Eirik V
    TI__Guru 56590 points
    The AGC should be able to work with only 3-4 preamble bytes as well.