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: CC1200 Receiving Packets

Part Number: CC1200
Other Parts Discussed in Thread: MSP430FR5994

Dear Sirs:

 

    I’ve been using the cc1200 in sniff mode.  There is a glitch that I don’t understand.  With code that

 

waits for gpio0 to go high (PKT_SYNC_RXTX)

 

waits for one byte to be received then reads it.  This is our Message Type byte.

 

Waits for two more bytes to be read then reads these two bytes.  

 

     Well it should be through by now.  Works fine on first reception after power up but on additional transmissions seems to hang up without even producing gpio0 (PKT_SYNC_RXTX).

 

     Now if the code merely reads the no bytes in the fifo after this is completed, the unit does not hang up but will then read any number of transmission packets.

 

     I have no idea what is causing this, but probably one of your experts will see easily what I’m doing wrong.

 

 

Thanks,

 

John Moore   

 

 

The Receive Code is:

 

 

registerConfig();       //configure radio

// Calibrate radio

trxSpiCmdStrobe(CC120X_SCAL);   //in TranscInit.c

 

// Wait for calibration to be done (radio back in IDLE state)

do {

    cc120xSpiReadReg(CC120X_MARCSTATE, &marcState, 1);

    } while (marcState != 0x41);

 

// Calibrate the RCOSC

calibrateRCOsc();

 

// Infinite loop

while( 1)                       //Receive loop

{

LED2(0);                    //turn off grn led

// Set radio in RX Sniff Mode

trxSpiCmdStrobe(CC120X_SWOR);    //Start automatic RX polling sequence (Wake-on-Radio). TranscInit.c

 

//wait for packetsync_rxtx to arrive:

Sync= P1IN & 0x4;               //check gpio0 for sync semaphore

while(Sync ==0)

     Sync=P1IN & 0x4;

// Wait for packet to be received

//while(packetSemaphore != (1 ))//Rx Comes from irq but having probs with it

 

LED2(1) ;                   //turn on grn led

// Clear semaphore flag

packetSemaphore = ISR_IDLE;     //0

 

 

while(rxBytes ==0)

     cc120xSpiReadReg(CC120X_NUM_RXBYTES, &rxBytes, 1);  //Read no bytes in Rx FIFO.  subs.c

 

cc120xSpiReadRxFifo(rxBuffer, 1); //read first byte has type.  in subs.c

MessType= rxBuffer[0];

 

 

//while( (GPIOPort) !=0)

//   GPIOPort= P1IN & 0x4 ; //wait for GPIO0 to go low indicating end of packet

 

// Read all the bytes in the RX FIFO

while(rxBytes !=2)

    cc120xSpiReadReg(CC120X_NUM_RXBYTES, &rxBytes, 1);  //Read no bytes in Rx FIFO.

cc120xSpiReadRxFifo(rxBuffer, (rxBytes)); // already read first byte. 

 

  

//The following statement is necessary to prevent ‘hanging’ on subsequent transmissions:

cc120xSpiReadReg(CC120X_NUM_RXBYTES, &rxBytes, 1);  //test Read no bytes in Rx FIFO.  subs.c

 

  • Hi
    Not quite sure I understand what exactly the problem is. Do you receive the first packet but not the second?
    If we shall be able to debug this we would need to know your register settings, and it would also be useful to see spi plots of your receiver when you receive a packets and the code hangs.
    Are you using any kind of filtering of the RX packet? If so, your code might hang in the

    while(rxBytes ==0)
    cc120xSpiReadReg(CC120X_NUM_RXBYTES, &rxBytes, 1);

    As you will have the sync interrupts but nothing will be put in the FIFO.
    I will strongly recommend that you start by using the CC1200_rx_sniff_mode example found here: www.ti.com/.../swrc274 and then change your settings by using SmartRF Studio and the sniff mode tab.

    BR
    Siri
  • Thanks, Siri:

    Sorry I missed your post until now.  Anyway without the extra read NumBytes at the end, the software hangs up after receiving the first packet and won't read any additional packets.  Also there is no hardware sync out of the cc1200 chip (gpio0).  With the extra read, the receiver works very well indefinately.

    Did notice that it is sensitive to reading the correct number of bytes in the message.  When this is mismatched it gets out of "sync" and tries to read parts of other packets.

    John Moore

    Following is the config file:

    /***************************************************
    150Mhz Sniff mode
    Rx filter=19.84khz, 2 GFSk, 2.68k dev, 2.4kbps
    sync= 06,a6 11bits ,no seq no, fixed 3 byte 0bit
    7 byte preamble Sends to MCDT rec and ti rec

    TI receiver evb: RF current=5.4ma, mcu current=2.6ma
    ****************************************************/

    const registerSetting_t preferredSettings[]=
    {
    {CC120X_IOCFG2, 0x13}, //sniff 150M
    {CC120X_IOCFG0, 0x06},
    {CC120X_SYNC1, 0x00}, // 7:0 sets MSB sync
    {CC120X_SYNC1, 0x05}, //05 7:0 sets MSB sync. Orig 06
    {CC120X_SYNC0, 0x56}, //56 sets lsb of sync in 7:0. Orig A6
    {CC120X_SYNC_CFG1, 0x28}, //sets length of sync
    {CC120X_DEVIATION_M, 0x8D},
    {CC120X_MODCFG_DEV_E, 0x08},
    {CC120X_DCFILT_CFG, 0x5D},
    {CC120X_PREAMBLE_CFG1, 0x24},
    {CC120X_PREAMBLE_CFG0, 0x8A},
    {CC120X_IQIC, 0xCB},
    {CC120X_CHAN_BW, 0x95},
    {CC120X_MDMCFG1, 0x60}, //Man mode=20
    {CC120X_MDMCFG0, 0x05},
    {CC120X_SYMBOL_RATE2, 0x4F},
    {CC120X_SYMBOL_RATE1, 0x75},
    {CC120X_SYMBOL_RATE0, 0x10},
    {CC120X_AGC_REF, 0x31},
    {CC120X_AGC_CS_THR, 0x09},
    {CC120X_AGC_CFG1, 0x40},
    {CC120X_AGC_CFG0, 0x83},
    {CC120X_FIFO_CFG, 0x00},
    {CC120X_SETTLING_CFG, 0x03},
    {CC120X_FS_CFG, 0x1B},
    {CC120X_WOR_CFG0, 0x20},
    {CC120X_WOR_EVENT0_MSB, 0x03},
    {CC120X_WOR_EVENT0_LSB, 0xEC},
    {CC120X_PKT_CFG2, 0x00}, //norm mode, CRc disabled, no status byte
    {CC120X_PKT_CFG1, 0x0}, // adx check & crc disabled. This line needed to rec MCDT!
    {CC120X_PKT_CFG0, 0x10}, //10 orig 00. fixed length=00 in bits 6:5, bit len in bits 4:2
    {CC120X_RFEND_CFG0, 0x0C},
    {CC120X_PKT_LEN, 0x02}, //pktlen, packet length 02 +4 bits for emids
    {CC120X_IF_MIX_CFG, 0x1C},
    {CC120X_FREQOFF_CFG, 0x22},
    {CC120X_MDMCFG2, 0x0C},

    {CC120X_FREQ2, 0x5A},
    {CC120X_FREQ1, 0x00},
    {CC120X_FREQ0, 0x00},

    {CC120X_IF_ADC1, 0xEE},
    {CC120X_IF_ADC0, 0x10},
    {CC120X_FS_DIG1, 0x07},
    {CC120X_FS_DIG0, 0xAF},
    {CC120X_FS_CAL1, 0x40},
    {CC120X_FS_CAL0, 0x0E},
    {CC120X_FS_DIVTWO, 0x03},
    {CC120X_FS_DSM0, 0x33},
    {CC120X_FS_DVC0, 0x17},
    {CC120X_FS_PFD, 0x00},
    {CC120X_FS_PRE, 0x6E},
    {CC120X_FS_REG_DIV_CML, 0x1C},
    {CC120X_FS_SPARE, 0xAC},
    {CC120X_FS_VCO0, 0xB5},
    {CC120X_XOSC5, 0x0E},
    {CC120X_XOSC1, 0x03},
    };

  • Siri:
    I started with swrc274 and converted it to Code Composer. Will look into the while() you mentioned.

    Thanks,
    John Moore
  • Siri:

    Re:   The while statement you mentioned:  

                         while( (rxBytes ==0) && (uFixedMode == RxMode) )
                                cc120xSpiReadReg(CC120X_NUM_RXBYTES, &rxBytes, 1); //Read no bytes in Rx FIFO. subs.c

        I suppose this needs a timeout, but what should it do after timing out?

    Thanks,

    John

  • Siri:

         Maybe I can answer my prev question:

    We're using the chip in sniff mode.  3.2.4 of user guide states that when the unit goes to sleep it flushes the receive and transmit fifos.  

    Thus I do need a timeout of some sort so that my receive software can get ready for the next receive packet later on.  Otherwise it will  be hung.

         Might be able to just monitor pkt_sync_txrx.  If it goes away the unit is in sleep mode??  and that receive show is over??

    Thanks,

    John Moore

  • Siri:

         I am using the sniff mode example.

         Added a timeout to the while statement you mentioned, but it still hangs without the final nbytes read at the end which should be unnecessary.

    John Moore

  • Hi

    There is a lot of information here, and I am still not sure I have the full overview of what is going on but I will try to make some general comments based on your settings.

    I do not understand why you do not use interrupt. The whole idea behind Sniff mode is that the MCU can sleep while the radio listens for the packets. Waking up the MCU as soon as you start receive something does not make sense as this will increase current consumption.

    If you have looked at CC1200 sniff mode code example you see that it uses CRC_OK as an interrupt (rising edge). You cannot use this since you are not using CRC, so  what you should do instead is to have a falling edge on a GPIO configured for sync received, packet received. When you get this interrupt you can read NUM_RXBYTES and then read the complete FIFO. With your settings you do not have any kind of filtering so you will never get this interrupt with an empty FIFO.

    I have used Studio to generate settings based on your input. The only difference is that I am testing on  900 MHz. Attached are settings and  implementation changes done to the Sniff example. Please notice that with your settings you will probably often get false sync words or sync in the wrong place. The reason for this is that you have a both a very short sync word and also a sync word that looks like your preamble.  

    static const registerSetting_t preferredSettings[] = {
        {CC120X_IOCFG2,	        0x06},
        {CC120X_SYNC1,	        0x05},
        {CC120X_SYNC0,	        0x56},
        {CC120X_SYNC_CFG1,	        0x28},
        {CC120X_DEVIATION_M,	0x8D},
        {CC120X_MODCFG_DEV_E,	0x08},
        {CC120X_DCFILT_CFG,	        0x5D},
        {CC120X_PREAMBLE_CFG1,	0x24},
        {CC120X_PREAMBLE_CFG0,	0x8A},
        {CC120X_IQIC,	        0xCB},
        {CC120X_CHAN_BW,	        0x95},
        {CC120X_MDMCFG1,	        0x60},
        {CC120X_MDMCFG0,	        0x05},
        {CC120X_SYMBOL_RATE2,	0x4F},
        {CC120X_SYMBOL_RATE1,	0x75},
        {CC120X_SYMBOL_RATE0,	0x10},
        {CC120X_AGC_REF,	        0x31},
        {CC120X_AGC_CS_THR,	        0x09},
        {CC120X_AGC_CFG1,	        0x40},
        {CC120X_AGC_CFG0,	        0x83},
        {CC120X_FIFO_CFG,	        0x00},
        {CC120X_SETTLING_CFG,	0x03},
        {CC120X_FS_CFG,	        0x12}, // Different freq band
        {CC120X_WOR_CFG0,	        0x20},
        {CC120X_WOR_EVENT0_MSB,	0x02},
        {CC120X_WOR_EVENT0_LSB,	0xE2},
        {CC120X_PKT_CFG2,	        0x00},
        {CC120X_PKT_CFG1,	        0x00},
        {CC120X_PKT_CFG0,	        0x10},
        {CC120X_RFEND_CFG0,	        0x0C},
        {CC120X_PKT_LEN,	        0x02},
        {CC120X_IF_MIX_CFG,	        0x1C},
        {CC120X_FREQOFF_CFG,	0x22},
        {CC120X_MDMCFG2,	        0x0C},
        {CC120X_FREQ2,	        0x5A},
        {CC120X_IF_ADC1,	        0xEE},
        {CC120X_IF_ADC0,	        0x10},
        {CC120X_FS_DIG1,	        0x07},
        {CC120X_FS_DIG0,	        0xAF},
        {CC120X_FS_CAL1,	        0x40},
        {CC120X_FS_CAL0,	        0x0E},
        {CC120X_FS_DIVTWO,	        0x03},
        {CC120X_FS_DSM0,	        0x33},
        {CC120X_FS_DVC0,	        0x17},
        {CC120X_FS_PFD,	        0x00},
        {CC120X_FS_PRE,	        0x6E},
        {CC120X_FS_REG_DIV_CML,	0x1C},
        {CC120X_FS_SPARE,	        0xAC},
        {CC120X_FS_VCO0,	        0xB5},
        {CC120X_XOSC5,	        0x0E},
        {CC120X_XOSC1,	        0x03},
    }
    
    static void runRX(void)
    {
        static uint8 rxBuffer[3] = {0};
        static uint8 rxBytes;
        
        uint8 marcState;
    
        // Connect ISR function to GPIO2
        ioPinIntRegister(IO_PIN_PORT_1, GPIO2, &radioRxISR);
    
        // Interrupt on falling edge
        ioPinIntTypeSet(IO_PIN_PORT_1, GPIO2, IO_PIN_FALLING_EDGE);
    
        // Clear ISR flag
        ioPinIntClear(IO_PIN_PORT_1, GPIO2);
    
        // Enable interrupt
        ioPinIntEnable(IO_PIN_PORT_1, GPIO2);
    
        // Update LCD
        updateLcd();
    
        // Calibrate radio
        trxSpiCmdStrobe(CC120X_SCAL);
    
        // Wait for calibration to be done (radio back in IDLE state)
        do
        {
            cc120xSpiReadReg(CC120X_MARCSTATE, &marcState, 1);
        } while (marcState != 0x41);
    
        // Calibrate the RCOSC
        calibrateRCOsc();
    
        // Infinite loop
        while(TRUE) {
    
            // Set radio in RX Sniff Mode
            trxSpiCmdStrobe(CC120X_SWOR);
    
            // Wait for packet to be received
            while(packetSemaphore != ISR_ACTION_REQUIRED);
    
            // Clear semaphore flag
            packetSemaphore = ISR_IDLE;
    
            cc120xSpiReadReg(CC120X_NUM_RXBYTES, &rxBytes, 1); // Will always be 3 with your settings
    
            // Read all the bytes in the RX FIFO
            cc120xSpiReadRxFifo(rxBuffer, rxBytes);
            
            // implement som check of the received packet as you do not have any CRC
            updateLcd();
        }
    }

    Hope this helps

    Siri

  • Thanks very much, Siri, you're a lifesaver:

         I first had this trouble with my breadboard which consisted of a small cc1200 eval board wired into an MSP430FR5994 launch pad. 

    I got a lot of software working including transmit and receive and uart and timer etc.  However the problem we're talking about surfaced in this platform. 

    It originally had a rising edge interrupt on P1.2 which worked but not flawlessly for a long time.  Then I took out the interrupt and just looked for a rising edge

    on P1.2.  I was able to get around the problem on this platform it by some of the fixes which are bothering you.  These kind of fixes usually come

    back to haunt you.  

         Now I'm trying to bring up the real pc board.  I got it to transmit and do uart and all the software of the breadboard except receive. 

    Was able to have it briefly receive a few packets.  With it the problem is much worse.  Tonight I was able to see the gpio0 pulse on the scope consistently but was unable

    to have it be detected by (P1IN & 0x04) = P1.2.   It won't detect this by using the interrupt or by just reading the port.  Won't work either way.

    I don't seem to be doing anything wrong in the software.  Plan to devise a test tomorrow to make sure my code IS ok.  It's hanging on one instruction, P1IN.

        Noticed that there is rf on the gpio0 line coming out of the CC1200.  This is making me wonder if I might have a metastability problem on the input pin of the MSP 430,

    pin P1.2.   This is roughly how metastability could show up.   There is a Schmidt trig on the input but rf on the line might cause it to violate its setup and hold times anyhow. 

    Of course there could be something wrong with the 430 but believe I've seen the same with the breadboard as well.  Amplified rf is always present during this time in the cc1200 (preamble and sync).

         Believe I had a metastability problem way back when was making a hardware QRS detector.   The comparator output went to a D input that was clocked.  Needed 

    a pulse out of it so ran the /Q output around to the reset input with an RC delay which was supposed to cause it to produce a controlled pulse width output.  Well it didn't work 

    correctly and I wound up changing the R to an L so that the Q output pulse would actually overshoot the reset input for a sufficient logic level.  This worked.

    So may try something like that.

    Thanks,

    John

        

  • Siri:

    Well, the problem isn't metastability. There is one pulse on gpio0 after reset and before configuration but all the bytes are 0. The unit transmits but doesn't receive. There is rf on pins 19 and 20. Would be good if the receive status could be read.

    John Moore
  • Hi

    Not sure what to suggest. I might be a good idea for you to take one step back and simply implement RX and TX as it is done in the easylink example (without using WOR). This way you can confirm that the RF settings you are using is OK, that your HW is OK and that you are receiving all packets OK. You will also be able to check that your interrupts are working as expected. Once this is up and running, you can re-write your RX code to implement sniff mode. When debugging a sniff mode application, I strongly recommend to monitor the LNA and PA signals on both transmitter and receiver, to be able to figure out what is going on if thing does not work as expected. You can also output the CHIP_RDYn signal. This way you can monitor the GPIOs and know if the radio is in SLEEP, IDLE, RX or TX.

    BR

    Siri

  • Thanks, Siri:

        Brought up another pc board and after writing the great American novel it began receiving some packets.  The main problem turned out to be that the frequency was mismatched 

    with the remote transmitter.  

       Adjusted the freqoffset roughly and got it to receive nearly all packets.  The freq offset is the difference in frequency between the receiver and the transmitter.  But which transmitter?

    The local transmitter or the remote transmitter?  ie is this the right way to finely adjust frequency?  

    Actually plan to use a TCXO which should make FCC no problem but will probably still need to adjust center frequency.

    Also have both interrupts running.  

    You're a lifesaver!

    John Moore

  • By how much was the frequency mismatched? Is it within the expected based on the inaccuracy of the xtal used?

    If you have a star network with a concentrator and nodes the frequency offset compensation has to be done on the node side.

    Typically, node1 sends a packet to concentrator. This calculate the offset, this is sent back to node1 which adjust for this for the next transmission.
  • The above only works if a node and a concentrator can actually set up a link. If the frequency offset is too high then a link cannot be established and frequency offset compensation as outlined above will not work. You need to ensure that the programmed RX filter BW + FB2PLL is wide enough to capture the transmitted signal even at extreme frequency offset. 

  • Siri:
    It was off 8.5khz.
    This is a good reason to use a 2ppm TCXO.
    Can't I manually calibrate the crystal oscillator, though?

    John
  • The rx filter is supposed to be 19.8khz
    John
  • If you operate on 868 MHz, 8.5 kHz is 10 ppm off?
  • Thanks, Siri:

        I'm operating at 150Mhz so 8.5khz is 56ppm off.  When I added the Freq off of 10 to the MSB, it started receiving nearly all of the packets.

    That's with a crystal.

        With a TXCO the transmit frequency is exactly on 150Mhz but for some reason two units won't receive anything.

    John

  • Ok, didn't check the LODIV setting.

    Note that the frequency offset out of the box is only dependent on your reference (xtal). If the xtal has a 10 ppm offset you will get a 10 ppm offset on the air. But a xtal should not have a 56 ppm offset.

    - What is the tolerance of the xtal you are using?
    - If the tolerance is less than 56 ppm => Do you use the correct load caps for your xtal?

    In other words, before you do too much else you have to figure out why you have a large offset.
  • Dear TIR:

        The crystal I'm using is a kyocera cx3225sb that has +-15ppm tolerance and spec'd for load cap of 8pf.  The circuit uses two 15pf caps.

    The tolerance is much too high but the plan is to use a TCXO that is low ppm.  Just started out with a crystal with the pcboards because it would

    be minimal changes from the TI eval board.

        Have built 3 boards:  one with crystal and 2 with TCXO's (KT2520F40ECV28TAK clipped sine 40Mhz, 2ma).  All 3 units transmit packets to one of our existing transceivers using SEIWG protocol.  The two TCXO units have zero error on their transmit spectrum.

       Anyway the first pcb used a crystal and it didn't receive at first but then started receiving packets most of the time. I messed with the freq offset and thought it made a difference but now am not sure.

    Neither of the 2 units with TCXOs will receive packets.  The last one had its solder touched up including the ground pad under.

    I tried configuring GPIO3 to EXT_OSC_EN (dec 60) but the tcxo units won't work at all with this.

    Don't know what you mean by LO DIV setting??

    Hope you see something.

    Thanks,

    John Moore

  • Excuse me, TER:

    On one of the TCXO units the spectrum analyzer can sniff a faint 150Mhz CW spike over the TCXO. I assume this is the receiver LO. Its exactly on frequency.

    John
  • LODIV: The VCO frequency divided by a factor to get the correct frequency band, basically the FS_CFG register.

    Ok, since you plan to use TCXO anyway lets look at the TCXO boards only.
    - You write that you see the transmit spectrum at the correct frequency. If you send a CW, what is the ppm number? Do you get the expected output power?
    - Since you manage to send something the TCXO gives the correct signal to the chip. The EXT_OSC_EN can be used for TCXOs with an enable pin. If the TCXO input was not correct you would not be able to communicate with the chip over SPI.
    - Would you be able to connect the SPI interface to a CCDebugger or a TRXEB? With this you will be able to control your board via SmartRF Studio that would simplify the debugging some since then you will remove potential errors in the code as potential error sources.
  • Thanks, TER:

    The ppm number with my spectrum analyzer using TCXO is about 9hz out of 150Mhz or about .06 ppm.

    The pulsed packet power is 5V pp into 50ohms using scope which is about 1.77 Vrms
    or 18dbm which is plenty.

    I have 2 IAR smart transceiver eval boards which I'm updating with the current software so that one can send and the other receive as a check.

    I'll have to figure out how to use smart rf studio.

    Thanks,

    John

    The Config file:/***************************************************
    150Mhz Sniff mode GPIO0 not pulsing
    Rx filter=19.84khz, 2 GFSk, 2.68k dev, 2.4kbps
    sync= 06,a6 11bits ,no seq no, fixed 3 byte 0bit
    7 byte preamble Sends to MCDT rec and ti rec

    TI receiver evb: RF current=5.4ma, mcu current=2.6ma
    ****************************************************/

    const registerSetting_t preferredSettings[]=
    {
    //{CC120X_IOCFG3, 0x3c}, //dec 60. read ext osc enable. Doesn't work
    {CC120X_IOCFG2, 0x06}, //sniff 150M
    {CC120X_IOCFG0, 0x06},
    {CC120X_SYNC1, 0x00}, // 7:0 sets MSB sync
    {CC120X_SYNC1, 0x05}, //05 7:0 sets MSB sync. Orig 06
    {CC120X_SYNC0, 0x56}, //56 sets lsb of sync in 7:0. Orig A6
    {CC120X_SYNC_CFG1, 0x28}, //sets length of sync
    {CC120X_DEVIATION_M, 0x8D},
    {CC120X_MODCFG_DEV_E, 0x08},
    {CC120X_DCFILT_CFG, 0x5D},
    {CC120X_PREAMBLE_CFG1, 0x24},
    {CC120X_PREAMBLE_CFG0, 0x8A},
    {CC120X_IQIC, 0xCB},
    {CC120X_CHAN_BW, 0x95},
    {CC120X_MDMCFG1, 0x60}, //Man mode=20
    {CC120X_MDMCFG0, 0x05},
    {CC120X_SYMBOL_RATE2, 0x4F},
    {CC120X_SYMBOL_RATE1, 0x75},
    {CC120X_SYMBOL_RATE0, 0x10},
    {CC120X_AGC_REF, 0x31},
    {CC120X_AGC_CS_THR, 0x09},
    {CC120X_AGC_CFG1, 0x40},
    {CC120X_AGC_CFG0, 0x83},
    {CC120X_FIFO_CFG, 0x00},
    {CC120X_SETTLING_CFG, 0x03},
    {CC120X_FS_CFG, 0x1B},
    {CC120X_WOR_CFG0, 0x20},
    {CC120X_WOR_EVENT0_MSB, 0x02},
    {CC120X_WOR_EVENT0_LSB, 0xE2},
    {CC120X_PKT_CFG2, 0x00}, //norm mode, CRc disabled, no status byte
    {CC120X_PKT_CFG1, 0x0}, // adx check & crc disabled. This line needed to rec MCDT!
    {CC120X_PKT_CFG0, 0x10}, //10 orig 00. fixed length=00 in bits 6:5, bit len in bits 4:2
    {CC120X_RFEND_CFG0, 0x0C},
    {CC120X_PKT_LEN, 0x02}, //pktlen, packet length 02 +4 bits for emids
    {CC120X_IF_MIX_CFG, 0x1C},
    {CC120X_FREQOFF_CFG, 0x02}, //FOC_EN=x20, FOC_KI_Factor=02
    {CC120X_MDMCFG2, 0x0C},

    {CC120X_FREQ2, 0x5A},
    {CC120X_FREQ1, 0x00},
    {CC120X_FREQ0, 0x00},

    {CC120X_IF_ADC1, 0xEE},
    {CC120X_IF_ADC0, 0x10},
    {CC120X_FS_DIG1, 0x07},
    {CC120X_FS_DIG0, 0xAF},
    {CC120X_FS_CAL1, 0x40},
    {CC120X_FS_CAL0, 0x0E},
    {CC120X_FS_DIVTWO, 0x03},
    {CC120X_FS_DSM0, 0x33},
    {CC120X_FS_DVC0, 0x17},
    {CC120X_FS_PFD, 0x00},
    {CC120X_FS_PRE, 0x6E},
    {CC120X_FS_REG_DIV_CML, 0x1C},
    {CC120X_FS_SPARE, 0xAC},
    {CC120X_FS_VCO0, 0xB5},
    {CC120X_XOSC5, 0x0E},
    {CC120X_XOSC1, 0x03},
    };
  • Thanks, TER:

    Got our smart Trx EBs working running the demo IAR code from TI. One is a transmitter and one is a receiver. The transmit evb transmits correctly to the receive evb which receives the packets correctly with a debug break. Sometimes it does get confused. (because of debugging??) The transmit TrxEB also transmits correctly to our standard receiver which receives the packets correctly. The packets are
    xD4, xC0, 0x80. However when the pcb with tcxo is also set up as a receiver, it receives nothing just as it has been doing.
    The spectral data on the trxEB transmitting is:
    center frequency is low by only 550 hz (3.7ppm). The spectral bandwidth is
    about 7.5Khz.

    Thanks

    John

    The tx code is:

    /*******************************************************************************
    * @fn runRX
    *
    * @brief Puts radio in RX Sniff Mode and waits for packets. A packet
    * counter is incremented for each packet received and the LCD is
    * updated
    *
    * @param none
    *
    * @return none
    */
    static void runRX(void) {

    uint8 rxBuffer[128] = {0};
    uint8 rxBytes;
    uint8 marcState;

    // Connect ISR function to GPIO0
    ioPinIntRegister(IO_PIN_PORT_1, GPIO0, &radioRxISR);

    // Interrupt on falling edge
    ioPinIntTypeSet(IO_PIN_PORT_1, GPIO0, IO_PIN_RISING_EDGE);

    // Clear ISR flag
    ioPinIntClear(IO_PIN_PORT_1, GPIO0);

    // Enable interrupt
    ioPinIntEnable(IO_PIN_PORT_1, GPIO0);

    // Update LCD
    updateLcd();

    // Calibrate radio
    trxSpiCmdStrobe(CC120X_SCAL);

    // Wait for calibration to be done (radio back in IDLE state)
    do {
    cc120xSpiReadReg(CC120X_MARCSTATE, &marcState, 1);
    } while (marcState != 0x41);

    // Calibrate the RCOSC
    calibrateRCOsc();


    // Infinite loop
    while(TRUE)
    {

    // Set radio in RX Sniff Mode
    trxSpiCmdStrobe(CC120X_SWOR);

    // Wait for packet to be received
    while(packetSemaphore != ISR_ACTION_REQUIRED);

    // Clear semaphore flag
    packetSemaphore = ISR_IDLE;

    while( (rxBytes ==0) )
    cc120xSpiReadReg(CC120X_NUM_RXBYTES, &rxBytes, 1); //Read no bytes in Rx FIFO.

    cc120xSpiReadRxFifo(rxBuffer, 1); //read first byte has type. in subs.c
    MessType= rxBuffer[0];

    //while( (GPIOPort) !=0)
    // GPIOPort= P1IN & 0x4 ; //wait for GPIO0 to go low indicating end of packet
    // Read all the bytes in the RX FIFO

    while( (rxBytes !=2) )
    cc120xSpiReadReg(CC120X_NUM_RXBYTES, &rxBytes, 1); //Read no bytes in Rx FIFO. subs.c

    cc120xSpiReadRxFifo(rxBuffer, (rxBytes)); // already read first byte. in subs.c

    cc120xSpiReadReg(CC120X_NUM_RXBYTES, &rxBytes, 1); //test Read no bytes in Rx FIFO. subs.c


    // Update LCD
    updateLcd();
    }
    }



    The Tx code is:


    /*******************************************************************************
    * @fn runTX
    *
    * @brief Transmits a packet every time a button is pushed. A packet
    * counter is incremented for each packet sent and the LCD is
    * updated
    *
    * @param none
    *
    * @return none
    */
    static void runTX(void) {

    static uint8 marcState;

    // Initialize packet buffer of size PKTLEN + 1
    uint8 txBuffer[PKTLEN + 1];

    // Connect ISR function to GPIO0
    ioPinIntRegister(IO_PIN_PORT_1, GPIO0, &radioTxISR);

    // Interrupt on falling edge
    ioPinIntTypeSet(IO_PIN_PORT_1, GPIO0, IO_PIN_FALLING_EDGE);

    // Clear ISR flag
    ioPinIntClear(IO_PIN_PORT_1, GPIO0); // (01,80)

    // Enable interrupt
    ioPinIntEnable(IO_PIN_PORT_1, GPIO0); // (01,80)

    // Update LCD
    updateLcd();

    // Calibrate radio
    trxSpiCmdStrobe(CC120X_SCAL); //calibrate freq synthesizer and turn it off (0x33) in hal_spi_rf_trxeb.c

    // Wait for calibration to be done (radio back in IDLE state)
    do {
    cc120xSpiReadReg(CC120X_MARCSTATE, &marcState, 1);
    } while (marcState != 0x41);

    // Infinite loop
    while(TRUE) {

    // Wait for button push
    while(!bspKeyPushed(BSP_KEY_ALL));

    // Create a random packet with PKTLEN + 2 byte packet counter + n x random bytes
    createPacket(txBuffer);

    // Write packet to TX FIFO
    cc120xSpiWriteTxFifo(txBuffer, sizeof(txBuffer));

    // Strobe TX to send packet
    trxSpiCmdStrobe(CC120X_STX);

    // Wait for packet to be sent
    while(packetSemaphore != ISR_ACTION_REQUIRED);

    // Clear semaphore flag
    packetSemaphore = ISR_IDLE;

    // Update LCD
    updateLcd();
    }
    }


    /*******************************************************************************
    * @fn radioTxISR
    *
    * @brief ISR for packet handling in TX. Sets packet semaphore
    * and clears interrupt flag
    *
    * @param none
    *
    * @return none
    */
    static void radioTxISR(void) {

    // Set packet semaphore
    packetSemaphore = ISR_ACTION_REQUIRED;

    // Clear ISR flag
    ioPinIntClear(IO_PIN_PORT_1, GPIO0);
    }


    /*******************************************************************************
    * @fn initMCU
    *
    * @brief Initialize MCU and board peripherals
    *
    * @param none
    *
    * @return none
    */
    static void initMCU(void) {

    // Init clocks and I/O
    bspInit(BSP_SYS_CLK_8MHZ);

    // Init LEDs
    bspLedInit();

    // Init buttons
    bspKeyInit(BSP_KEY_MODE_POLL);

    // Initialize SPI interface to LCD (shared with SPI flash)
    bspIoSpiInit(BSP_FLASH_LCD_SPI, BSP_FLASH_LCD_SPI_SPD);

    // Init LCD
    lcdInit();

    // Instantiate transceiver RF SPI interface to SCLK ~ 4 MHz
    // Input parameter is clockDivider
    // SCLK frequency = SMCLK/clockDivider
    trxRfSpiInterfaceInit(2);

    // Enable global interrupt
    _BIS_SR(GIE);
    }


    /*******************************************************************************
    * @fn registerConfig
    *
    * @brief Write register settings as given by SmartRF Studio found in
    * cc1200_rx_sniff_mode_reg_config.h
    *
    * @param none
    *
    * @return none
    */
    static void registerConfig(void) {

    uint8 writeByte;

    // Reset radio
    trxSpiCmdStrobe(CC120X_SRES); //cc120x_SRES= 48d

    // Write registers to radio
    for(uint16 i = 0;
    i < (sizeof(preferredSettings)/sizeof(registerSetting_t)); i++) {
    writeByte = preferredSettings[i].data;
    cc120xSpiWriteReg(preferredSettings[i].addr, &writeByte, 1); //in cc120x_spi.c
    }
    }


    /*******************************************************************************
    * @fn createPacket
    *
    * @brief This function is called before a packet is transmitted. It fills
    * the txBuffer with a packet consisting of a length byte, two
    * bytes packet counter and n random bytes
    *
    * The packet format is as follows:
    * |--------------------------------------------------------------|
    * | | | | | | |
    * | pktLength | pktCount1 | pktCount0 | rndData |.......| rndData|
    * | | | | | | |
    * |--------------------------------------------------------------|
    * txBuffer[0] txBuffer[1] txBuffer[2] ......... txBuffer[PKTLEN]
    *
    * @param Pointer to start of txBuffer
    *
    * @return none
    */
    static void createPacket(uint8 txBuffer[]) {

    //txBuffer[0] = PKTLEN; // Length byte
    //txBuffer[1] = (uint8) (packetCounter >> 8); // MSB of packetCounter
    //txBuffer[2] = (uint8) packetCounter; // LSB of packetCounter

    // Fill rest of buffer with random bytes
    //for(uint8 i = 3; i < (PKTLEN + 1); i++) {
    // txBuffer[i] = (uint8)rand();

    // AssembleMess(); //puts the message into TxBuffer[i] in RFsubs.c

    txBuffer[0]= 0xD4 ; //this is a valid message
    txBuffer[1]= 0xc0;
    txBuffer[2]= 0x80;

    }




    The config for both tx and rx is as follows:

    #ifndef CC120XRX_SNIFF_MODE_REG_CONFIG_H
    #define CC120XRX_SNIFF_MODE_REG_CONFIG_H

    #ifdef __cplusplus
    extern "C" {
    #endif
    /******************************************************************************
    * INCLUDES
    */
    #include "hal_spi_rf_trxeb.h"
    #include "cc120x_spi.h"

    /***************************************************
    150Mhz Sniff mode GPIO0 not pulsing
    Rx filter=19.84khz, 2 GFSk, 2.68k dev, 2.4kbps
    sync= 06,a6 11bits ,no seq no, fixed 3 byte 0bit
    7 byte preamble Sends to MCDT rec and ti rec

    TI receiver evb: RF current=5.4ma, mcu current=2.6ma
    ****************************************************/

    const registerSetting_t preferredSettings[]=
    {
    //{CC120X_IOCFG3, 0x3c}, //dec 60. read ext osc enable
    {CC120X_IOCFG2, 0x13}, //pkt_crc_ok prob needed for iar evbs sniff 150M
    {CC120X_IOCFG0, 0x06},
    {CC120X_SYNC1, 0x00}, // 7:0 sets MSB sync
    {CC120X_SYNC1, 0x05}, //05 7:0 sets MSB sync. Orig 06
    {CC120X_SYNC0, 0x56}, //56 sets lsb of sync in 7:0. Orig A6
    {CC120X_SYNC_CFG1, 0x28}, //sets length of sync
    {CC120X_DEVIATION_M, 0x8D},
    {CC120X_MODCFG_DEV_E, 0x08},
    {CC120X_DCFILT_CFG, 0x5D},
    {CC120X_PREAMBLE_CFG1, 0x24},
    {CC120X_PREAMBLE_CFG0, 0x8A},
    {CC120X_IQIC, 0xCB},
    {CC120X_CHAN_BW, 0x95},
    {CC120X_MDMCFG1, 0x60}, //Man mode=20
    {CC120X_MDMCFG0, 0x05},
    {CC120X_SYMBOL_RATE2, 0x4F},
    {CC120X_SYMBOL_RATE1, 0x75},
    {CC120X_SYMBOL_RATE0, 0x10},
    {CC120X_AGC_REF, 0x31},
    {CC120X_AGC_CS_THR, 0x09},
    {CC120X_AGC_CFG1, 0x40},
    {CC120X_AGC_CFG0, 0x83},
    {CC120X_FIFO_CFG, 0x00},
    {CC120X_SETTLING_CFG, 0x03},
    {CC120X_FS_CFG, 0x1B},
    {CC120X_WOR_CFG0, 0x20},
    {CC120X_WOR_EVENT0_MSB, 0x02},
    {CC120X_WOR_EVENT0_LSB, 0xE2},
    {CC120X_PKT_CFG2, 0x00}, //norm mode, CRc disabled, no status byte
    {CC120X_PKT_CFG1, 0x0}, // adx check & crc disabled. This line needed to rec MCDT!
    {CC120X_PKT_CFG0, 0x10}, //10 orig 00. fixed length=00 in bits 6:5, bit len in bits 4:2
    {CC120X_RFEND_CFG0, 0x0C},
    {CC120X_PKT_LEN, 0x02}, //pktlen, packet length 02 +4 bits for emids
    {CC120X_IF_MIX_CFG, 0x1C},
    {CC120X_FREQOFF_CFG, 0x02}, //FOC_EN=x20, FOC_KI_Factor=02
    {CC120X_MDMCFG2, 0x0C},

    {CC120X_FREQ2, 0x5A},
    {CC120X_FREQ1, 0x00},
    {CC120X_FREQ0, 0x00},

    {CC120X_IF_ADC1, 0xEE},
    {CC120X_IF_ADC0, 0x10},
    {CC120X_FS_DIG1, 0x07},
    {CC120X_FS_DIG0, 0xAF},
    {CC120X_FS_CAL1, 0x40},
    {CC120X_FS_CAL0, 0x0E},
    {CC120X_FS_DIVTWO, 0x03},
    {CC120X_FS_DSM0, 0x33},
    {CC120X_FS_DVC0, 0x17},
    {CC120X_FS_PFD, 0x00},
    {CC120X_FS_PRE, 0x6E},
    {CC120X_FS_REG_DIV_CML, 0x1C},
    {CC120X_FS_SPARE, 0xAC},
    {CC120X_FS_VCO0, 0xB5},
    {CC120X_XOSC5, 0x0E},
    {CC120X_XOSC1, 0x03},
    }
  • Thanks, TER:

       Well, I also have an MSP430 Launch pad wired into a small cc1200 evb which was used to develop the orig software.  It also receives the 

    packets correctly from the IAR transmitter txxEB.   Also the one pcb that I have that uses a crystal also receives the IAR correctly.  

    So the IAR transmitter successfully transmits to everything except the two pcbs having tcxo.   Obviously there is something wrong with the hardware on the two tcxo pcbs.  It would be tempting to connect the tcxo directly to the osc input at pin 30.

         For the tcxo unit, its crystal is out and the two 15pf caps are out and its pin 30 is grounded.  There is a .047 on DCPL_XOSC pin 29.

    I can see rf at LNA_P and LNA_N.

    Thanks,

    John

  • A Clue, TER:

    On the tcxo unit the bias on the lna filter pin 23 is 0.05 V. On the unit with crystal it is 0.47V. On a working EVB board it is 0.33V.
    Also the Icc on the tcxo unit is only 30ma while on the receiving crystal unit it is 60ma.
    So the bias on the tcxo LNA is about 1/10 what it should be and its power supply is half what it should be.

    John
  • I need to see the schematic for the TCXO version to understand this one (ideally the layout too). Could you send me a friend request enabling you to send the schematic private?
  • Thanks, TER:

    I'd like to send the schematic and layout. Please send the email address.

    Thanks,
    John
  • TER:

    Please send to jmoore@qual-tron.com

    Thanks,

    John Moore
  • Dear Sirs:
    I don't know how to send a friend request!

    Thanks
    John Moore
  • The schematic looks like a copy of the reference design except for the value of L11. Exactly which point are you referring to by "bias on the lna filter"?

    For the layout: Do you do the same type of routing under the chip on both versions? The die paddle is fairly large and routing under the chip could cause issues.
  • Thanks very much, TER:

         The bias I was referring to is at pins 23 and 24 where the LF coupling is.  Assume one is an output and the other an input.  Both must probably be biased.  However

    the working evb has .33V whereas the PCB was around 1/10 of this on pin 23.

         I also noticed their might not be enough clearance around the ground pad.

    Will have to remove a chip and maybe reduce the size of the pad.

    One other thing:   Friday I brought up another board having crystal oscillator.  It did not work & had wrong current and appears to possibly have defective soldering.

    Thanks,

    John Moore

     

  • I've never looked at the voltages on pin 23 and pin 24. If I'm not mistaken either 23 or 24 is the output of the charpump meaning that the voltage on one node should be pulses and the other side a filtered version. 0 V sounds like a short.
  • Ter:

         The receiver that works has a 1 V pulse on pin 23 that lasts for 5.3ms having period of 18.4ms.  It is related to the sniff.  See nothing on the other side of the 1500pf cap on pin 24 for some reason.  Pin 24 has 190 ohms to ground and pin 23 is open to ground with power off.

         The pcbs that don't work don't have a pulse on pin 23 but don't seem to have a short either.

    Is there a systematic way of checking this out?

    Thanks,

    John

  • Ter: I should also report that all our pcbs were built with 1uf between pins 23 and 24 when it should be 1500pf.
    Don't suppose this could have damaged the chip?

    Thanks,
    John
  • No, a wrong cap here should only impact functionality/ performance.
  • Thanks, TER:

    Pin 24 has 200 ohms to ground with a DVM. So there may be only a 200 x 1500E-12 = 0.3us pulse on pin 24,
    so may have missed it.


    John
  • Thanks, TER:

        Should I program FS_CFG to 0B to select the correct band?

    John

  • Use SmartRF Studio to give you the settings, the tool will calculate the required FS_CFG for your band.
  • Hi, TER:
    The tool didn't program FS_CFG at all.
    Just noticed that the only ground for the chip is the pad underneath. Is there a good way to measure and see if it is connected?

    Thanks,
    John
  • Hi again, TER:

    Looks as though we could use the trx switch in transmit mode to check the ground pad.

    John
  • Hi, TER:

         Hope I'm not wearing you out.  I still have only one of the 4 units that receives (and that not well).  All of them transmit.  Two have crystals and two have tcxos.  

    The one that works has a crystal.  Its frequency is exactly on to 150 Mhz, low by only 1Hz using a sniffer.  Had previously thought it was off by 56ppm.

    In probing an eval board that works and is wired into the software on a launch pad, It appears that

    (in rec mode)                      Eval bd                             #5                               #1                       #4 (receives)

    p14  RBias                       pulses                               no                              pulses                    pulses

    p21 DCPL_VCO               pulses                               no                             pulses                    pulses

    p23  LPF0 charge pump   pulses                               no                             pulses                    pulses

    p31 crystal                        pulses w 40Mhz                -                                pulses                    pulses

    By "pulses" I mean the duration seems the same as the sniff mode duty cycle and rx turn on.

         Believe the information in this table can be used to troubleshoot except that the various pins are not documented as to how 

    they tie into the chip.

    John

  • Some board data, TER:

    We noticed there are traces under the chip that shouldn't be there because the ground pad is over them. Removed a chip and found that its solder mask was good and there was nothing apparantly wrong.
    I believe that this sort of thing affects the solder flowing and contributes to poor soldering. Also I see the ground pad as providing a "ground plane" for the rf chip which can probably run inside at 10-20Ghz.
    The soldering on the chips has a good appearance but a few pins look questionable. Probing indicates they are all making connection to the pin pads.

    There is another error on the layout. The boad's ground pad that mates with the chip pad is grounded by a cluster of 4 feedthrus that are close together. They are only about 6-8mils in dia. So the grounding to the pad is questionable. The small diameter holes have considerable inductance.

    Poor grounding could cause erratic operation. If that is the problem our only recourse is to re run the boards with these artwork corrections made.

    Need to talk with an expert on this and the soldering.

    Thanks, TER

    John
  • PLease check the reference designs for recommended layout and the use of vias under the chip to get a good ground. Even if you are not shorting the tracks under the chip you can risk a fairly large parasitic cap that could impact the performance.
  • Thanks, TER:

    I agree with you. We're changing the layout.
    I also believe that any irregularity in layout re the qfn can't be tolerated because there is essentially 0 tolerance
    for error on a qfn.

    John