• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 53 subscribers
  • Views 2664 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.

Linux/CC1101-CC1190EM869RD: CC1101+CC1190 Frequency spread

Denis Davydov41
Prodigy 60 points
Part Number: CC1101-CC1190EM869RD
Other Parts Discussed in Thread: CC1190, CC1101

Tool/software: Linux

Hello! I designed a PCB based on your demo PC1101_CC1190EM 869MHz rev 2.1.0. I check on the spectral analyzer and do not really understand what is happening. There may be an error in the code when switching reception and transmission.

The board is not directly connected to the spectrum analyzer.

The board is installed on Raspberry Pi 3, using wiringPi SPI.

Software based on your Link2 example.

Base frequency: 869.524780 MHz

Xtal Freq: 27MHz

Data rate 38.4178 kBaud

Channel spacing: 207.641602 kHz

RX Filter BW: 105.468750 kHz

Deviation: 19.775391 kHz

Modulation: GFSK

TX Power (PA Table): 0xC0

Scheme

PCB 2-Layer

TOP Layer

BOTTOM Layer

Setting

uint8_t register_set_value[47] =
{
     0x07,  // IOCFG2              GDO2 Output Pin Configuration
    0x2E,  // IOCFG1              GDO1 Output Pin Configuration
    0x06,  // IOCFG0              GDO0 Output Pin Configuration
    0x0E,  // FIFOTHR             RX FIFO and TX FIFO Thresholds
    0xD3,  // SYNC1               Sync Word, High Byte
    0x91,  // SYNC0               Sync Word, Low Byte
    0xff,  // PKTLEN              Packet Length
    0x44,  // PKTCTRL1            Packet Automation Control
    0x05,  // PKTCTRL0            Packet Automation Control
    0x00,  // ADDR                Device Address
    0x00,  // CHANNR              Channel Number
    0x06,  // FSCTRL1             Frequency Synthesizer Control
    0x00,  // FSCTRL0             Frequency Synthesizer Control
    0x20,  // FREQ2               Frequency Control Word, High Byte
    0x34,  // FREQ1               Frequency Control Word, Middle Byte
    0x62,  // FREQ0               Frequency Control Word, Low Byte
    0xCA,  // MDMCFG4             Modem Configuration
    0x75,  // MDMCFG3             Modem Configuration
    0x13,  // MDMCFG2             Modem Configuration
    0x42,  // MDMCFG1             Modem Configuration
    0xF8,  // MDMCFG0             Modem Configuration
    0x34,  // DEVIATN             Modem Deviation Setting
    0x07,  // MCSM2               Main Radio Control State Machine Configuration
    0x30,  // MCSM1               Main Radio Control State Machine Configuration
    0x28,  // MCSM0               Main Radio Control State Machine Configuration
    0x16,  // FOCCFG              Frequency Offset Compensation Configuration
    0x6C,  // BSCFG               Bit Synchronization Configuration
    0x03,  // AGCCTRL2            AGC Control
    0x40,  // AGCCTRL1            AGC Control
    0x91,  // AGCCTRL0            AGC Control
    0x87,  // WOREVT1             High Byte Event0 Timeout
    0x6B,  // WOREVT0             Low Byte Event0 Timeout
    0xFB,  // WORCTRL             Wake On Radio Control
    0x56,  // FREND1              Front End RX Configuration
    0x10,  // FREND0              Front End TX Configuration
    0xE9,  // FSCAL3              Frequency Synthesizer Calibration                                 
    0x2A,  // FSCAL2              Frequency Synthesizer Calibration
    0x00,  // FSCAL1              Frequency Synthesizer Calibration
    0x1F,  // FSCAL0              Frequency Synthesizer Calibration
    0x41,       //RC Oscillator Configuration
    0x00,       //RC Oscillator Configuration
    0x59,        //Frequency Synthesizer Calibration Control
    0x7F,         //Production Test
    0x3F,       //AGC Test
    0x81,  // TEST2               Various Test Settings
    0x2D,  // TEST1               Various Test Settings
    0x09  // TEST0               Various Test Settings
};

 

Switching to transmission:

cc1101_StrobeCmd(SIDLE);
cc1101_StrobeCmd(SFTX);
cc1101_Write_BurstAccess(TX_FIFO, txBuffer, LENGHT_LENGHT_FIELD + txBuffer[0]); //DATA_LENGHT + CRC_LENGHT + LENGHT_LENGHT
cc1101_StrobeCmd(STX);

Switching to reception:

cc1101_StrobeCmd(SFTX);
cc1101_StrobeCmd(SIDLE);
cc1101_StrobeCmd(SFRX);
cc1101_StrobeCmd(SRX);

The transmission attempt is 5 times. On the screenshots of the spectral analyzer, you can see five transmissions. Why such a spread in frequency?

First send

Second

3

4

5

If you add a calibration before switching transitions, that is, like this:

Switching to transmission:

cc1101_StrobeCmd(SIDLE);
cc1101_StrobeCmd(SCAL);
cc1101_StrobeCmd(SFTX);
cc1101_Write_BurstAccess(TX_FIFO, txBuffer, LENGHT_LENGHT_FIELD + txBuffer[0]); //DATA_LENGHT + CRC_LENGHT + LENGHT_LENGHT
cc1101_StrobeCmd(STX);

Then the picture of the spectrum changes. I have not yet checked for data reception, but I'm still wondering if this is the correct behavior of the transmitter.

Here are all 5 transmission attempts.

How to properly switch between receiving and transmitting and correctly adjust the chip?

  • 0
    TI__Guru**** 317180 points
    As far as I can see from your settings you are not using PA ramping. In the time domain switching on and off the PA will look like a square wave. In the frequency domain this will look like a sinc. By using PA ramping the transition from IDLE to TX will be smoother.

    Please measure this according to EN300 220 "Transient Power"
  • 0 in reply to TER
    Prodigy 60 points

    Ok, I setup PA Ramping on chip:

    static uint8_t patable[6] = {0x27,0x28,0x36,0x57,0x55,0x54};

    FREND0.PA_POWER = 0x15

    When the SCAL strobe is installed, the picture is as follows:

    Without the SCAL strobe, the picture is as follows:


    Look at the waterfall. That is, nothing has changed. 

  • 0 in reply to Denis Davydov41
    TI__Guru**** 317180 points
    In this case you can try to use auto calibration (meaning that the radio always do a calibration before it goes into RX or TX. When using max output power on this board CC1190 gets hot and a temperature change could cause a shift in frequency which could explain why you see a shift for each packet transmitted without calibrating between each time you do to TX.

    But is the spectrum if you use the SCAL strobe between each packet unexpected?
  • 0 in reply to TER
    Prodigy 60 points

    No, board temperature is normal, not hot. Without a strobe SCAL, the frequency is ambiguous. Yes, I use the SCAL strobe before each data send. I ask you to help. How to properly configure the chip and what to do before sending the data?

  • 0 in reply to TER
    Prodigy 60 points

    I set automatically calibrate and commented out manually calibrate, but the pattern remains the same spectrum. MCSM0.FS_AUTOCAL = 0x02; MCSM0 = 0x28;

    The waterfall seen five packets transmitted.

    By the way, if I transmit with Low Gain Mode (LGM) on a chip, then the signal is less than -80dBm. So it must be, is it not too little?

    I remind you, i use your code example Link2.

    Here is a piece of code:

    case TX_START:
            
            //std::cout << "TX_START\n";
            CC1101_TX_HGM; //Use High or Low gain mode CC1101_TX_LGM
            INTERRUPT_EXTI_SETUP(CC1101_GDO0, INT_EDGE_FALLING);
            INTERRUPT_EXTI_SETUP(CC1101_GDO2, INT_EDGE_FALLING);
            gdo0Active = LOW_FALLING_GDO;
            gdo2Active = LOW_FALLING_GDO;
            cc1101_Write_SingleAccess(0x02, IOCFG2);

            flagsHandler.ModeTrasmission = TX_MODE;
            if (txBuffer[0] < FIFO_SIZE) //if Lenght < 63
            {
                      flagsHandler.INTERRUPT_GDO2 = DISABLE;

                      cc1101_StrobeCmd(SIDLE);
                       //cc1101_StrobeCmd(SCAL);
                       cc1101_StrobeCmd(SFTX);
                       cc1101_Write_BurstAccess(TX_FIFO, txBuffer, LENGHT_LENGHT_FIELD + txBuffer[0]);
                       cc1101_StrobeCmd(STX);
            }
            else
             {
                        flagsHandler.INTERRUPT_GDO2 = ENABLE;
                        cc1101_StrobeCmd(SIDLE);
                        //cc1101_StrobeCmd(SCAL);
                        cc1101_StrobeCmd(SFTX);
                        cc1101_Write_BurstAccess(TX_FIFO, txBuffer, FIFO_SIZE);
                        cc1101_StrobeCmd(STX);
                        txData.bytesLeft = (LENGHT_LENGHT_FIELD + txBuffer[0]) - FIFO_SIZE;
                         txData.pBufferIndex = txBuffer + FIFO_SIZE; 
                         txData.iterations = (txData.bytesLeft / AVAILABLE_BYTES_IN_TX_FIFO);
                         if (!txData.iterations)
                                        txData.writeRemainingDataFlag = 1;
              }
                        flagsHandler.HandlerState = TX_WAIT;
                break;

                case TX_WAIT:
                etc....
  • 0 in reply to TER
    Prodigy 60 points
    Well, I'll ask differently, how should the ideal and actual spectrum look on this range?
  • 0 in reply to Denis Davydov41
    TI__Guru**** 317180 points

    I did some tests using this code: . I used the code as is with two changed:

    - I exported the 38.4 kbps settings from SmartRF Studio and used those in the code

    - I changed the IO to  {CC1101_IOCFG2,      0x06},

    I haven't added control of CC1190 in the code, I just strapped PA_EN high and LNA_EN low.

    If I send 5 packets in a row, all packets are sent on the same frequency. Spectrum for cont. Tx with 38.4 kbps. 

    CC1101-CC1190_38.4.WMF