CC1101 doesn't transmit correctly

[rt28]

hi

I'm trying to send and receive data with cc1101 (rxq4) but there is a problem, here is my code:


register settings

Unsigned char RF_setting[48]=
{0x29,       // CCxxx0_IOCFG2       
0x2e,       //CCxxx0_IOCFG1
0x06,       //CCxxx0_IOCFG0
0x07,       //CCxxx0_FIFOTHR
0xd3,       //CCxxx0_SYNC1
0x91,       //CCxxx0_SYNC0
0xff,       //CCxxx0_PKTLEN
0x04,       //CCxxx0_PKTCTRL1
0x05,       //CCxxx0_PKTCTRL0
0x05,       //CCxxx0_ADDR
0x00,       //CCxxx0_CHANNR
0x0c,       //CCxxx0_FSCTRL1
0x00,       //CCxxx0_FSCTRL0
0x10,       //CCxxx0_FREQ2
0xb1,       //CCxxx0_FREQ1
0x3b,       //CCxxx0_FREQ0
0x2d,       //CCxxx0_MDMCFG4
0x3b,       //CCxxx0_MDMCFG3
0x13,       //CCxxx0_MDMCFG2
0x22,       //CCxxx0_MDMCFG1
0xf8,       //CCxxx0_MDMCFG0
0x62,       //CCxxx0_DEVIATN
0x07,       //CCxxx0_MCSM2
0x3f,       //CCxxx0_MCSM1
0x18,       // CCxxx0_MCSM0
0x1d,       // CCxxx0_FOCCFG
0x1c,       // CCxxx0_BSCFG
0xc7,       // CCxxx0_AGCCTRL2
0x00,       // CCxxx0_AGCCTRL1
0xb0,       // CCxxx0_AGCCTRL0
0x87,       // CCxxx0_WOREVT1
0x6b,       // CCxxx0_WOREVT0
0xfb,       // CCxxx0_WORCTRL
0xb6,       // CCxxx0_FREND1
0x10,       // CCxxx0_FREND0
0xea,       // CCxxx0_FSCAL3
0x2a,       // CCxxx0_FSCAL2
0x00,       // CCxxx0_FSCAL1
0x1f,       // CCxxx0_FSCAL0
0x41,       // CCxxx0_RCCTRL1
0x00,       // CCxxx0_RCCTRL0
0x59,       // CCxxx0_FSTEST
0x7f,       // CCxxx0_PTEST
0x3f,       // CCxxx0_AGCTEST
0x88,       // CCxxx0_TEST2
0x31,       // CCxxx0_TEST1
0x09,       // CCxxx0_TEST0
0xC0};       // CCxxx0_PATABLE

TX code:

for(i=0;i<5;i++)
                 {
                  CC_Idle();
                  delay_ms(20);
                  CC_WrReg(CCxxx0_TXFIFO,1);  //writing in 10 bytes of TXFIFO
                  CC_WrReg(CCxxx0_TXFIFO,1);
                  CC_WrReg(CCxxx0_TXFIFO,1);
                  CC_WrReg(CCxxx0_TXFIFO,1);
                  CC_WrReg(CCxxx0_TXFIFO,1);
                  CC_WrReg(CCxxx0_TXFIFO,1);
                  CC_WrReg(CCxxx0_TXFIFO,1);
                  CC_WrReg(CCxxx0_TXFIFO,1);
                  CC_WrReg(CCxxx0_TXFIFO,1);
                  CC_Cmd(CCxxx0_STX);

                  while (!PINB.3);    // Wait for GDO0 to be set -> sync transmitted  
                  while (PINB.3); 
               
                  CC_ClrTx();
                  delay_ms(500); 
                 }

RX code:

                      CC_Idle();
                      CC_RxOn();
                      delay_ms(10);
                      CC_RdRegs(CCxxx0_RXFIFO,RFData,10);  //reading 10 bytes of rxfifo and store it in RFData
                      CC_ClrRx();
                      delay_ms(1);
                      CC_RxOn();
                      delay_ms(5);
                    
                     
                     lcd_clear();  //  displaying on LCD
                     i=0;
                     lcd_puts("recieved");
                     delay_ms(1000); 
                       while(i<10)
                       {   
                       lcd_clear();
                       sprintf(buffer_lcd,"%d=",i);
                       lcd_puts(buffer_lcd);
                       sprintf(buffer_lcd,"%x   ",RFData[i]);
                       lcd_puts(buffer_lcd); 
                       i=i+1;
                       delay_ms(1000);
                       }

for test i'm sending 1 in each ten bytes, but I'm receiving this:
0x(31,06,db,40,ff,82,f3,0e,3e, ... )

does anybody know what's wrong with my code?
I've checked anything I could think of.

thanks in advance for your help

 

[rt28]

I forgot to put RF settings so I corrected the first code.
has anyone worked with cc1101?

 

[rt28]

after some tests I found that all I'm receiving is just noise. I enabled the address check to just receive the transmitted data, and after that I got nothing, it means nothing is transmitted.

I read MARCSTATE after these command strobes:

CC_Idle(), MARCSTATE: 5f (CC_Cmd(CCxxx0_SIDLE))
CC_Cmd(CCxxx0_STX): 2f

this is my code for command strobes:

#define RF433_CS_UP    PORTB.4=1;
#define RF433_CS_DN    PORTB.4=0;
//PORTB.4 is connected to CSn

 unsigned char CC_Cmd(unsigned char Cmd)
{
    unsigned char Status;

    RF433_CS_DN;
    CC_Rdy();
    Status=CC_SpiWr(Cmd);
    RF433_CS_UP;
    delay_us(10);
    return Status;
}


void CC_Rdy()
{
     while(PINB.6);//PINB.6 is connected to SO(GDO1)
     return;
}

after issuing SIDLE strobe, MARCSTATE must be 0x01 and after STX strobe, it must be 0x13.

I couldn't find where the problem is. can anybody help,please?

 

[rt28]

I solve the problem I don't know exactly how, but I manged to read MARCSTATE and chip status byte correctly. now there is another problem.

MARCSTATE in TX is 0x13 and chip status byte is 0x20. TX code is placed above, in receiver GDO0 pin stays low, it seems that it doesn't receive any sync word, registers are all exactly the same in transmitter and receiver, this is RX code:

CC_Idle();
for(j=0;j<47;j++)
{
CC_WrReg(j,RF_setting[j]);
};
CC_WrReg(CCxxx0_PATABLE,RF_setting[47]);
delay_ms(20);
CC_RxOn();


for(i=0;i<62;i++)
{
RFData=0;
};
lcd_gotoxy(0,0);
read[2]= CC_RdStatus(CCxxx0_MARCSTATE);
sprintf(buffer_lcd,"MS2=%x",read[2]);
lcd_puts(buffer_lcd);

while (1)
{

if(PIND.3) //PIND.3 is connected to GDO0
{
while (PIND.3);


iLen= CC_RdReg(CCxxx0_RXFIFO); //variable packet length
Addr=CC_RdReg(CCxxx0_RXFIFO); // address check enabled
lcd_gotoxy(0,1);
sprintf(buffer_lcd,"iLen=%x ",iLen);
lcd_puts(buffer_lcd);

sprintf(buffer_lcd,"Addr=%x",Addr);
lcd_puts(buffer_lcd);

if (iLen!=0&&iLen<64&&Addr==5)
{
CC_RdRegs(CCxxx0_RXFIFO,RFData,iLen-1);
CC_ClrRx();
delay_ms(1);
CC_RxOn();
delay_ms(5);
conter1=0;
PORTC.3=1;

lcd_clear();
lcd_gotoxy(0,0);
for(i=0;i<iLen-1;i++)
{
sprintf(buffer_lcd,"%d",RFData);
lcd_puts(buffer_lcd);
}
}


else
{
CC_ClrRx();
delay_ms(1);
CC_RxOn();
delay_ms(5);
};
}
};


MARCSTATE in receiver is 0X0D and chip status byte is 0x10, but it receives nothing

does anybody know where the problem is?

 

[rt28]

how can I be sure that CC1101 is transmitting? is it enough to read MARCSTATE 0x13? or there might be some other problem?

 

[FvM]

To avoid jumping into conclusions, I prefer to monitor the transmitter RF output with a SA or wideband oscilloscope to check transmit operation and correct carrier frequency.

I must confess that I'm not very motivated to go through your register settings to check their consistency. I assume that you generated the settings with RF Studio? But you didn't tell about your hardware platform. Is it a TI evaluation kit or a customer design? In the former case, you would want to use known working example applications as starting point.

 

[rt28]

I'm using Rxq4, so I thought it must be software problem. i didn't generate register settings with RF Studio, I've been reading and working with registers for about two weeks and I chose the value of each register carefully. but since it doesn't work I must consider everything including using a known working example to see if it's a hardware problem, can you guide me to one of these applications?

I can take picture of my circuit board or anything else that is needed. I just don't know what else to check, I really appreciate your help.

 

[g_shyam1682]

Hi Friend,

First of all, you can target only transmission section and send continuous transmission pulse of data in air and measure using signal analyzer. Development of RF application is very hard if you don't have right testing instrument.

For register setting, you have to must use RF studio software.

best of luck,

 

[rt28]

thanks for replying
I don't have spectrum analyzer, can I use oscilloscope? is there any test that can be done by an oscilloscope? nevertheless I'll try to get to a spectrum analyzer

for register setting I'll check their consistency with RF studio software.

 

[rt28]

Hi, problem solved.

I generated my code with RF Studio software, now it's working. I really made big mistake not using the software.

thanks a lot for your help

 

[rt28]

hi again
i faced another problem:
I want to sent 30 byte of data, address checkand variable data length are enable:

transmitter:

CC_WrReg(CCxxx0_TXFIFO,0X1F);
CC_WrReg(CCxxx0_TXFIFO,5);
CC_WrRegs(CCxxx0_TXFIFO,DataAES,30);
receiver:

iLen= CC_RdReg(CCxxx0_RXFIFO);
Addr=CC_RdReg(CCxxx0_RXFIFO);

if (iLen!=0&&iLen<64&&Addr==5)
{
CC_RdRegs(CCxxx0_RXFIFO,DataAES,iLen-1);
...
}

I receive first to sixteenth bytes correctly then 3 bytes wrong values then the other 11 bytes correct again.
first I thought it's noise but this 3 bytes wrong values are always the same for a specific data. and it's always bytes number 17-19.
does anybody knows why this is happening?

unsigned char RF_setting[48]=
{0x29,       // CCxxx0_IOCFG2       
0x2e,       //CCxxx0_IOCFG1
0x06,       //CCxxx0_IOCFG0
0x47,       //CCxxx0_FIFOTHR
0xd3,       //CCxxx0_SYNC1
0x91,       //CCxxx0_SYNC0
0x3d,       //CCxxx0_PKTLEN
0x05,       //CCxxx0_PKTCTRL1
0x05,       //CCxxx0_PKTCTRL0
0x05,       //CCxxx0_ADDR
0x00,       //CCxxx0_CHANNR
0x06,       //CCxxx0_FSCTRL1
0x00,       //CCxxx0_FSCTRL0
0x21,       //CCxxx0_FREQ2
0x62,       //CCxxx0_FREQ1
0x76,       //CCxxx0_FREQ0
0xf5,       //CCxxx0_MDMCFG4
0x83,       //CCxxx0_MDMCFG3
0x13,       //CCxxx0_MDMCFG2
0x22,       //CCxxx0_MDMCFG1
0xf8,       //CCxxx0_MDMCFG0
0x15,       //CCxxx0_DEVIATN
0x07,       //CCxxx0_MCSM2
0x3f,       //CCxxx0_MCSM1
0x18,       // CCxxx0_MCSM0
0x16,       // CCxxx0_FOCCFG
0x1c,       // CCxxx0_BSCFG
0xc7,       // CCxxx0_AGCCTRL2
0x00,       // CCxxx0_AGCCTRL1
0xb0,       // CCxxx0_AGCCTRL0
0x87,       // CCxxx0_WOREVT1
0x6b,       // CCxxx0_WOREVT0
0xfb,       // CCxxx0_WORCTRL
0xb6,       // CCxxx0_FREND1
0x10,       // CCxxx0_FREND0
0xe9,       // CCxxx0_FSCAL3
0x2a,       // CCxxx0_FSCAL2
0x00,       // CCxxx0_FSCAL1
0x1f,       // CCxxx0_FSCAL0
0x41,       // CCxxx0_RCCTRL1
0x00,       // CCxxx0_RCCTRL0
0x59,       // CCxxx0_FSTEST
0x7f,       // CCxxx0_PTEST
0x3f,       // CCxxx0_AGCTEST
0x81,       // CCxxx0_TEST2
0x35,       // CCxxx0_TEST1
0x09,       // CCxxx0_TEST0
0xC8};       // CCxxx0_PATABLE

thanks in advance for your help

 

[rt28]

i'm reading PARTNUM value ff and VERSION f. does this mean that the chip is partially dead?

 

[mr.tea]

@ rt28
i'm currently devp around a few CC1101 , so if you want that i check some regs on my side so you can compare to yours for ex see if the chip versions are different etc no pblem just let me know

may i ask did you find why in your case using RF settings taken from app examples it was not working , but with RF Studio's generated setting it was working ?

 

[FvM]

i'm reading PARTNUM value ff and VERSION f. does this mean that the chip is partially dead?

You mean, the same chip still is transmitting? That's really unlikely, I would a expect a software problem. I presume you are using the right register addresses (0xF0..)?

 

[rt28]

hi
thanks for replying, here are the differences: software settings is in Bold italic form.

FSCTRL1: F_IF 0x 06 (152.34375 KHz) (0X0C: 304.6875 KHz )

FREQ2 : 0x21 F.carrier : 867.999939 MHz 0x10 433.9999695 MHz
FREQ1: 0x62 0xb1
FREQ0 : 0x76 0x3b

MDMCFG4: 0xf5 BW: 135.4166667 0x2d BW: 541.6666667
MDMCFG3: 0x83 DataRate: 1.199483871 0x3b DataRate: 249.9389648 kBaud


DEVIATN : 0x15 f.dev : 5.157470703 KHz 0x62: f.dev : 126953.125


FOCCFG: 0x16
Freq. compensation loop gain before sync word: 3K
Freq. compensation loop gain after sync word: K/2
Saturation point (max compensated offset): ±BW_CHAN/4

0x1d:
Freq. compensation loop gain before sync word: 4K
Freq. compensation loop gain after sync word: K/2
Saturation point (max compensated offset): ±BW_CHAN/8


FSCAL3: 0xea
it affects: the charge pump output current :IOUT = I_0•(2^FSCAL3[3:0]/4)
0xe9

I don't have enough experience to find out what was the problem, I assume that I didn't set the right frequency or BW.

You mean, the same chip still is transmitting? That's really unlikely, I would a expect a software problem. I presume you are using the right register addresses (0xF0..)?

sorry, I made a mistake in reading the registers.the addresses were right, I used the wrong function to read them out. now I'm reading their values correct

I wanna try something, I want to bypass those three wrong bytes. I mean sending 33 bytes and remove them on the receiver. I'll let you know as soon as I finish testing this idea.

thanks

- - - Updated - - -

It worked !!!

I don't know what's wrong. it might be something wrong with TXFIFO or RXFIFO registers. do you have any idea why this is happening? can it be a hardware problem?

 

[rt28]

any ideas?
I have made it work, but there is always an error of 3 bytes and that would decrease the performance. has anybody ever had this problem? could it have something to do with register settings?

thanks

- - - Updated - - -

the chip status byte value in receiver is 10, it means FIFO_BYTES_AVAILABLE is 0 ! it's zero on the transmitter side too. I think maybe it's because I used variable length mode. should FIFO_BYTES_AVAILABLE be zero or something is wrong?

 

[rt28]

when I read TXBYTES (0x3A) the value is F ! but I used variable length mode and the first thing that I write in TXFIFO is 0x1F(31) 30 bytes data length and 1 byte address check.

is there any other setting that must be done here, that I missed?

- - - Updated - - -

oh, sorry
again i used the wrong function. TXBYTES value is 0x21(33) and RXBYTES value is 0x20(32)

 

[rt28]

I found the problem, I had two functions to read from RXFIFO, one for burst reading and one for one-byte read. I was using the burst read, when I used the one-byte read function in a loop, there was no error.

but I still don't know why burst read causes such errors.

 

[Taner]

Hi,
In the variable lenght mode, the first byte after two sync bytes, should indicates the exact byte counts in the RX packet.
And set the cc1101 chip after reception of the whole packet, to go automatically into IDLE Mode.
When all packet bytes are in the RX FIFO, and device is in the IDLE mode, then read TX FIFO in burst mode.

Regards

 

[FvM]

There are some problems in register access related to a CC1101 design fault, see the errata sheet. I'm not sure if it possibly plays a role in your way of doing a burst read.

I'm not using the same packet mode, because I designed for backward-compatibility with existing radio modules. There may be specific problems with the variable length mode I'm not aware of.