CC1101 doesn't transmit correctly

[rt28]

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

hi
thanks, problem solved. when I used one_byte read and then I switched back to burst read, suddenly there were no errors! but thanks for the tip, I forgot about that. I'm gonna need that later.

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.

thanks for replying. I had seen errata sheet, it didn't help.

from what I've gathered, I think when I used one-byte read over those wrong bytes (17-19) somehow they became active!! I know it may sound funny but I didn't do anything else except this to make it work, no change in register setting, no change in hardware. that's a little odd.

thanks for your help and notice

 

[mr.tea]

hi Fvm
i'm also working on compatibility of CC1101 (acting as Recv) with another RF chip the Si4432 (acting as Transmitter only)
i've managed to get RF carrier detection but still working on the correct data issues
bytway i used syncword 0xD391 & a low data rate

 

[rt28]

hi again

I wanted to sent data longer than 64 bytes. I've read the datasheet and Design Note DN500, here are the steps for transmitting:

TX:
1. Start by writing 64 bytes to the TX FIFO
2. Strobe TX
3. Poll the status byte or the TXBYTES register at a given rate to see if there is space
available in the TX FIFO.
4. Write to the TX FIFO whenever there is room for more bytes
5. Repeat 3 and 4 until the whole packet is written to the TX FIFO

this is the code for packets<64 bytes: (packet length: 60)

                  CC_Idle(); 
                  CC_WrReg(CCxxx0_TXFIFO,61);             
                  CC_WrReg(CCxxx0_TXFIFO,5);
                  CC_WrRegs(CCxxx0_TXFIFO,DataAES,61,0);

                  CC_Cmd(CCxxx0_STX);
                            
                  while(!PIND.3);
                  while(PIND.3);

I tried to implement the steps above in my code. but i failed to get valid result for packets more than 64. where should I Poll the TXBYTES and at what rate?
when the chip transmits one byte, it means that one byte of txfifo is free, so I can write next byte in it, right? so I should poll TXBYTES in the last loop, where the completion of packet transmission is being checked.


i changed the code to this: (for 120 bytes of data)

CC_Idle(); 
                  CC_WrReg(CCxxx0_TXFIFO,121);             
                  CC_WrReg(CCxxx0_TXFIFO,5);
                  CC_WrRegs(CCxxx0_TXFIFO,DataAES,62,0);
                   
                  
                  CC_Cmd(CCxxx0_STX);
                  
                  GL=62;
                                            
                  while(!PIND.3);
                         
                  while(PIND.3)
                                {
                              
                                  while(GL<121)
                                    {  
                                    while(CC_RdStatus(CCxxx0_TXBYTES)<50)
                                            {
                                            z=64-CC_RdStatus(CCxxx0_TXBYTES);
                                            GL=GL+z;
                                            CC_WrRegs(CCxxx0_TXFIFO,DataAES,GL,GL-z); 
                                            }
                                             
                                    }
                                }

has anyone worked with packet length longer than 64

I set MCSM1 0x32 for TX and 0x3C for RX

PKTLEN is 0xff and PKTCTRL0 is 0x05


thanks

 

[rt28]

any ideas? i tried sending packets longer than 64 bytes using the MCU itself, it means first I send 62 bytes, flushing TXFIFO, and then again next 62 bytes of data. the information about the remaining bytes to send is fit into each 62 bytes. it worked but I think it may affect the max data rate that can be used and of course it's not the method that I should be using and I may face some unknown problems later.

has anyone implemented sending longer than 64 bytes using TXBYTES and RXBYTES ?

I really appreciate your help.
thanks

 

[FvM]

The below construct worked in my test for packets up to 77 bytes:

  for (i=0;i<sbuflen;i++)
  {
    stat = _spi_write(0x3f,sbuf[i]);
    if ((stat & 0xf) < 3)
      short_sleep(5); // 5 ms
  }

There's a certain risk that the FIFO_BYTES_AVAILABLE information is incorrect due to the SPI read synchronization errata, but it's apparentyl sufficient for the intended purpose.

 

[rt28]

thanks for replying,
where do you apply it? is it right to put inside the while(PIND.3) , where the MCU is checking for the completion of packet transmission?


another question: how can I test the data rate of my transeiver? i don't have enough experience to find out the data rate. I know the data rate of the chip, but I wanna know how the MCU is affecting it.

thanks a lot for your help

 

[FvM]

where do you apply it? is it right to put inside the while(PIND.3) , where the MCU is checking for the completion of packet transmission?

Something like this. In my test application, the processor goes to sleep after scheduling the send packet.

how can I test the data rate of my transeiver?

I found that the settings are correctly calculated by RF Studio, as the device has no problem to communicate with existing RF modules.

 

[rt28]

I found that the settings are correctly calculated by RF Studio, as the device has no problem to communicate with existing RF modules.

yes, that's right, but I wanted to know how the MCU affects the the total data rate. because there are some delays in the MCU code and so many lines and functions. I think that may affect the data rate of the whole system. I wanted to know if there is a way to calculate the data rate (for example sending a specific data and calculate the timing) so that if the MCU is decreasing the data rate, I try to optimize my code.

 

[FvM]

That will depend on the processor, I'm using a PIC24 in the present design. I'm using moderate data rates and surely won't run into processor limitations. Otherwise you should think about monitoring/debugging methods to visualize the available speed margin.