CC1101 - last bit is longer

[johnrik1]

Hi,

I've noticed an issue with the CC1101 module - the last transmitted bit is twice as long as the normal width. This problem occurs when the last bit in the data is '1', but if the last bit is '0', the module does not append an extra '1'. I've tested this behavior with various Arduino libraries as well as using SmartRF Studio with a CC Debugger, and the issue persisted.

Does anyone have an idea why the module behaves this way?

Settings:

Modulation: OOK/ASK
Frequency: 443.8 MHz
Data rate: 10 kBaud
Fixed size, No preamble/sync, no CRC, Manchester off, Whitening off

Data: 0x01 0x01 0x01

Registers values from SmartRF Studio:

//
// Rf settings for CC1101
//
halRfWriteReg(IOCFG2,0x29);        //GDO2 Output Pin Configuration
halRfWriteReg(IOCFG1,0x2E);        //GDO1 Output Pin Configuration
halRfWriteReg(IOCFG0,0x06);        //GDO0 Output Pin Configuration
halRfWriteReg(FIFOTHR,0x47);       //RX FIFO and TX FIFO Thresholds
halRfWriteReg(SYNC1,0xD3);         //Sync Word, High Byte
halRfWriteReg(SYNC0,0x91);         //Sync Word, Low Byte
halRfWriteReg(PKTLEN,0x03);        //Packet Length
halRfWriteReg(PKTCTRL1,0x04);      //Packet Automation Control
halRfWriteReg(PKTCTRL0,0x00);      //Packet Automation Control
halRfWriteReg(ADDR,0x00);          //Device Address
halRfWriteReg(CHANNR,0x00);        //Channel Number
halRfWriteReg(FSCTRL1,0x06);       //Frequency Synthesizer Control
halRfWriteReg(FSCTRL0,0x00);       //Frequency Synthesizer Control
halRfWriteReg(FREQ2,0x11);         //Frequency Control Word, High Byte
halRfWriteReg(FREQ1,0x11);         //Frequency Control Word, Middle Byte
halRfWriteReg(FREQ0,0xB9);         //Frequency Control Word, Low Byte
halRfWriteReg(MDMCFG4,0xF5);       //Modem Configuration
halRfWriteReg(MDMCFG3,0x83);       //Modem Configuration
halRfWriteReg(MDMCFG2,0x30);       //Modem Configuration
halRfWriteReg(MDMCFG1,0x02);       //Modem Configuration
halRfWriteReg(MDMCFG0,0xF8);       //Modem Configuration
halRfWriteReg(DEVIATN,0x15);       //Modem Deviation Setting
halRfWriteReg(MCSM2,0x07);         //Main Radio Control State Machine Configuration
halRfWriteReg(MCSM1,0x30);         //Main Radio Control State Machine Configuration
halRfWriteReg(MCSM0,0x18);         //Main Radio Control State Machine Configuration
halRfWriteReg(FOCCFG,0x16);        //Frequency Offset Compensation Configuration
halRfWriteReg(BSCFG,0x6C);         //Bit Synchronization Configuration
halRfWriteReg(AGCCTRL2,0x03);      //AGC Control
halRfWriteReg(AGCCTRL1,0x40);      //AGC Control
halRfWriteReg(AGCCTRL0,0x91);      //AGC Control
halRfWriteReg(WOREVT1,0x87);       //High Byte Event0 Timeout
halRfWriteReg(WOREVT0,0x6B);       //Low Byte Event0 Timeout
halRfWriteReg(WORCTRL,0xFB);       //Wake On Radio Control
halRfWriteReg(FREND1,0x56);        //Front End RX Configuration
halRfWriteReg(FREND0,0x11);        //Front End TX Configuration
halRfWriteReg(FSCAL3,0xE9);        //Frequency Synthesizer Calibration
halRfWriteReg(FSCAL2,0x2A);        //Frequency Synthesizer Calibration
halRfWriteReg(FSCAL1,0x00);        //Frequency Synthesizer Calibration
halRfWriteReg(FSCAL0,0x1F);        //Frequency Synthesizer Calibration
halRfWriteReg(RCCTRL1,0x41);       //RC Oscillator Configuration
halRfWriteReg(RCCTRL0,0x00);       //RC Oscillator Configuration
halRfWriteReg(FSTEST,0x59);        //Frequency Synthesizer Calibration Control
halRfWriteReg(PTEST,0x7F);         //Production Test
halRfWriteReg(AGCTEST,0x3F);       //AGC Test
halRfWriteReg(TEST2,0x81);         //Various Test Settings
halRfWriteReg(TEST1,0x35);         //Various Test Settings
halRfWriteReg(TEST0,0x09);         //Various Test Settings
halRfWriteReg(PARTNUM,0x00);       //Chip ID
halRfWriteReg(VERSION,0x14);       //Chip ID
halRfWriteReg(FREQEST,0x00);       //Frequency Offset Estimate from Demodulator
halRfWriteReg(LQI,0x05);           //Demodulator Estimate for Link Quality
halRfWriteReg(RSSI,0x80);          //Received Signal Strength Indication
halRfWriteReg(MARCSTATE,0x01);     //Main Radio Control State Machine State
halRfWriteReg(WORTIME1,0x00);      //High Byte of WOR Time
halRfWriteReg(WORTIME0,0x00);      //Low Byte of WOR Time
halRfWriteReg(PKTSTATUS,0x00);     //Current GDOx Status and Packet Status
halRfWriteReg(VCO_VC_DAC,0x94);    //Current Setting from PLL Calibration Module
halRfWriteReg(TXBYTES,0x00);       //Underflow and Number of Bytes
halRfWriteReg(RXBYTES,0x00);       //Overflow and Number of Bytes
halRfWriteReg(RCCTRL1_STATUS,0x00);//Last RC Oscillator Calibration Result
halRfWriteReg(RCCTRL0_STATUS,0x00);//Last RC Oscillator Calibration Result

 

[BradtheRad]

What the final datum arrives then something needs to be different so the receiver knows it's the final datum.

An overly lengthy 1 could notify the data is finished. However when the final datum is 0 then something needs to be different. What is sent when the final bit=0? What tells the receiver that the final bit is 0?

Years ago it was common to end a transmission with 'eot'. Did you try doing this?

 

[Aussie Susan]

I am trying to use the same chip so this may or may not be relevant (I'm still very much a beginner understanding this device).
As I understand it, the OOK (and ASK) mode takes whatever is on the GDO0 pin as long as the chip is in the TX mode and transmits that.
Also (and this part I'm struggling with so could be very wrong) the chip does not use the packet concept for OOK/ASK. (Section 27.1 on page 63 has a paragraph that starts "When asynchronous transfer is enabled, several of the support mechanisms for the MCU that are include in CC1101 will be disabled, such as packet handling hardware.....".)
Therefore what I'm imagining is that you are leaving the final '1' on the GDO0 pin while you send the SIDLE strobe to stop the transmission. (You don't show that part of the code so that is a guess on my part.)
Susan

 

[FvM]

As far as I understand, in selected mode TX Data is generated by data FIFO and packet generator, not GDO pin. At first sight, I don't understand why the apparent extra 1" bit is generated. I wonder why it matters at the receiver side?

I'm using CC1101 and similar chips in FSK mode, I didn't yet notice irregular behaviour.

Did you ask the question in TI forum?

 

[Aussie Susan]

@FvM - My apologies. What I said is true if the OP was using asynchronous mode (which is what I'm using).
Looking at the PKTCTRL0 value in the first post, it looks like the OP s using the packet format - I missed that when reading earlier.
Susan

 

[johnrik1]

@BradtheRad The receiver does not need this information because I configure it to expect packets of 3 bytes in length, as I am using fixed packet length mode. It can also determine the start of the data based on the transmitted preamble.

For the data 0x01 0x01 0x02:

@Aussie Susan I am not using the GDO0 or GDO2 pins.

@FvM I haven't asked on the TI forum.


Could someone check if they also encounter the same issue with the register configuration provided above?