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.

CC1101 receiving TPMS data packets from Atmel ATA5754 and/or NXP (Freescale) FXTH871xD

Other Parts Discussed in Thread: CC1101, TEST2

Good Morning,

We have an ongoing challenge relating to the reliability of successfully receiving data from TPMS sensors containing the above RF transmitters.  We are using a C1101 connected via SPI to an STM32 micro.  We have been trying to resolve this (on and off) for about a year, this is the last ditch attempt to fix the issue before we start looking to using something other than the CC1101, I really hope somebody can spot something we have missed..

The TPMS sensors transmit at regular intervals (either every 30 or 60 seconds), they also have mode where they transmit an number of times instantly if rapid deflation occurs.

Our problem is that we are not able to successfully interpret data from the sensors reliably for every transmission, randomly, we will get a successful packet through every so often this could be every 30 secs, minute, 2 minutes, 3 minutes and so on.  We are seeing good RSSI, anything from -50dbm to -75dbm.

Here is the protocol for the sensor.....

1    Communicate parameter

 

CarrierCenterFrequency

433.92MHz

Modulation

Frequency Shift Keying (FSK)

Data Encoding

Manchester (G.E. Thomas) Encoding

Baud Rate

4.2 kbps ±5%

 

2    Protocal format

synchronization-head

Frame start

Frame Header

ID1

ID2

ID3

ID4

Pressure

Temperature

Sensor Status

REV

Checksum

end

0xFFFFFFFF

0xF6

0xF0

 

 

 

 

 

 

 

 

 

0x00

 

 

 

2.1 Frame Header:

Marks the start of data formatunder this protocol frame header is 0xF0.

 2.2 ID1, ID2, ID3ID4

Transmitter ID (4 Bytes). See an example below.

01B2027F 

2.3 Pressure: (in hexadecimal)

Formulas to convert actual pressure value:

  1. For sensor type 000 which means sensor pressure range 450Kpa(absolute

    pressure),actual pressure value(relative pressure)formula is:

             Tire pressure(in kPa)= value(in Decimal) *1.37

    b) For sensor type 001 which means sensor pressure range 700Kpa(absolute pressure),actual pressure value(relative pressure)formula is:

    Tire pressure(in kPa)= value(in Decimal) *2.35

    c) For sensor type 010 which means sensor pressure range 1400Kpa(absolute pressure),actual pressure value(relative pressure)formula is:

    Tire pressure(in kPa)= (value(in Decimal)-19)*5.5

    d) For sensor type 011 which means sensor pressure range 2000Kpa(absolute pressure),actual pressure value(relative pressure)formula is:

             Tire pressure(in kPa)= value(in Decimal) *8

     

    (Note: 1 kPa = 0.145Psi ,sensor type refers to 3.5 Sensor Status Register bit6-bit4)

     

    2.4 Temperature: (in hexadecimal)

    Formulas to convert actual temperature value:

    Tire temperature (in ℃)=value(in Decimal)-50

    (Note: Conversion between ℉ and ℃:F=9/5*C+32)

     

    2.5 Sensor Status Register:

Bit 7

Bit 6

Bit 5

Bit 4

Bit 3

Bit 2

Bit 1

Bit 0

0=awake;

1=normal

(Just for commercial sensor)

0 = no leakage 1 = leakage

 

Rev

Battery volume:

00=V<2.2V

01=2.6V>V≥2.2V

10=3V>V≥2.6V

11=V≥3V

Sensor type:

00=450kpa

01=700kpa

10=1400kpa

Else=REV

 

 

 

 

 

(NoteSensor just transmit the value of pressure and temperature. You can decide the warning value in your receiver. We suggest that receiver will give warning when pressure turns out either 20% lower or 30% higher than standard pressure. In this case the standard pressure is set as 6bar, so the receiver will give high pressure warning if pressure is higher than 7.8bar, and give low pressure warning if pressure is lower than 4.8bar. Receiver will give high temperature warning if temperature is higher than 80.)

2.6  Checksum:  

Checksum=ID1+ID2+ID3+ID4+Pressure_Status+Rev+1

Back in the distant past it was decided that a change to this protocol was required to have it work successfully with the CC1101, here are the details:

 

Original frame structure:

Synchronization Header
Frame
Start
Frame Header
Frame Data
CRC checksum
Frame End
0xFFFFFFFF
0xF6
0x00

 

 Modified version structure:

Synchronization Header
Frame
Start
Length
Frame Header
Frame Data
CRC checksum
Frame End
0xFFFFFF
0xF6
0x0A
0x00

 

2.   FrameRegularReport

Sensor send regular pressure and temperature report RF frame:

Frame Header
Frame Data
Checksum
0xF0
ID1
ID2
ID3
ID4
Pressure
Temperature
Sensorstatus
Reserve
Checksum
 
 

 

These are the Register settings for the CC1101 we are using (although other variations have been tried)

 

static const u8_t cc1101_valor_registers[] = {
  // CC1101_IOCFG2   0x00 GDO2 Output Pin Configuration
  0x0E, // Carrier Sense
  // CC1101_IOCFG1   0x00 GDO1 Output Pin Configuration
  0x2E, // tri-state high impedence
  // CC1101_IOCFG0   0x00 GDO0 Output Pin Configuration
  0x06, // Asserts when sync word has been sent / received, and de-asserts at the end of the packet.
        // In RX, the pin will also de- assert when a packet is discarded due to address or maximum
        // length filtering or when the radio enters RXFIFO_OVERFLOW state.
        // In TX the pin will de-assert if the TX FIFO underflows.
  
  // CC1101_FIFOTHR  0x03 RX FIFO and TX FIFO Thresholds
  0x40 /* ADC retention */ | 0x01, /* tx fifo threshold of 57, rx fifo threshold of 8 */

  // CC1101_SYNC1    0x04 Sync Word, High Byte
  0xF6, // XX sync-word

  // CC1101_SYNC0    0x05 Sync Word, Low Byte
//  0xF6, // TPMS sync-word
  0x0A, // PMS sync-word

  // CC1101_PKTLEN   0x06 Packet Length
//  0x0C, // TPMS packet length - NOTE - THIS IS IGNORED IN INFITIE PACKET LENGTH MODE
  0x0A, // TPMS packet length - NOTE - THIS IS IGNORED IN INFITIE PACKET LENGTH MODE

  // CC1101_PKTCTRL1 0x07 Packet Automation Control
  0x04, // CRC autoflush disabled, append 2-byte RSSI/CRC status, no address check

  // CC1101_PKTCTRL0 0x08 Packet Automation Control
//  0x02, /* data whitening off, use FIFOs, disable CRC, infinite packet length mode */
  // 6 - WHITE_DATA
  // 5:4 - PKT_FORMAT Format of RX and TX data
  //        00 - Normal mode, use FIFOs for RX and TX
  //        01 - Synchronous serial mode, Data in on GDO0 and data out on either of the GDOx pins
  //        10 - Random TX mode; sends random data using PN9 generator. Used for test. Works as normal mode, setting 0 (00), in RX
  //        11 - Asynchronous serial mode, Data in on GDO0 and data out on either of the GDOx pins
  // 2 - CRC_EN
  // 1:0 - LENGTH_CONFIG
  //        00 - Fixed packet length mode. Length configured in PKTLEN register
  //        01 - Variable packet length mode. Packet length configured by the first byte after sync word
  //        10 - Infinite packet length mode
  0x00, // fixed

  // CC1101_ADDR     0x09 Device Address
  0x00, /* broadcast address */

  // CC1101_CHANNR   0x0A Channel Number
  0x00, // channel number

  // CC1101_FSCTRL1  0x0B Frequency Synthesizer Control
  0x10, // intermediate frequency = 26000000/2^10 * 0x10 = 26000000/1024 * 0x10 = 406.250 kHz

  // CC1101_FSCTRL0  0x0C Frequency Synthesizer Control
  0x00, // frequency offset

  // CC1101_FREQ2    0x0D Frequency Control Word, High Byte
  // CC1101_FREQ1    0x0E Frequency Control Word, Middle Byte
  // CC1101_FREQ0    0x0F Frequency Control Word, Low Byte
  // carrier frequency = 26000000/2^16 * FREQ = 26000000/65536 * 0x10B071
  // = 26000000/65536 * 1093745 = 433.919830 MHz (valor is 433.92)
  0x10, 0xB0, 0x71,

  // CC1101_MDMCFG4  0x10 Modem Configuration
  // 7:6 - CHANBW_E
  // 5:4 - CHANBW_M
  // 3:0 - DRATE_E
//  0x98, // 162 kHz channel filter bandwidth
  0x88, // 203 kHz channel filter bandwidth
//  0xF8, // 58 kHz channel filter bandwidth
//  0x08, // 812 kHz channel filter bandwidth
//  0xC8, // 102 kHz channel filter bandwidth

  // CC1101_MDMCFG3  0x11 Modem Configuration
  // 7:0 - DRATE_M - also has a 9th bit always set to 1
//  0x85,
  0x83,

  // CC1101_MDMCFG2  0x12 Modem Configuration
  // 7 - DEM_DCFILT_OFF = Disable digital DC blocking filter before demodulator
  // 6:4 -  modulation format
  //        0 - 2-FSK
  //        1 - GFSK
  //        3 - ASK/OOK
  //        4 - 4-FSK
  //        7 - MSK
  // 3 - Enables Manchester encoding/decoding.
  // 2:0 -  Sync mode
  //        0 - no preamble/sync
  //        1 - 15/16 sync word bits detected
  //        2 - 16/16 sync word bits detected
  //        3 - 30/32 sync word bits detected
  //        4 - no preamble/sync, carrier-sense above threshold
  //        5 - 15/16 sync word bits detected + carrier-sense above threshold
  //        6 - 16/16 sync word bits detected + carrier-sense above threshold
  //        7 - 30/32 sync word bits detected + carrier-sense above threshold
  0x0A, // manchester coding enabled, 16/16 sync word bits detected
//  0x09, // manchester coding enabled, 15/16 sync word bits detected

  // CC1101_MDMCFG1  0x13 Modem Configuration
  // 7 - Enable Forward Error Correction (FEC) with interleaving for packet payload
  // 6:4 -  minimum number of preable bytes
  //        0 - 2 preamble bytes
  //        1 - 3 preamble bytes
  //        2 - 4 preamble bytes
  //        3 - 6 preamble bytes
  //        4 - 8 preamble bytes
  //        5 - 12 preamble bytes
  //        6 - 16 preamble bytes
  //        7 - 24 preamble bytes
  // 1:0 - CHANSPC_E - 2-bit exponent of channel spacing
  0x22, // 4 byte preamble, CHANSPC_E = 2

  // CC1101_MDMCFG0  0x14 Modem Configuration
  // 7:0 - CHANSPC_M
  // channel spacing = 26000000 / 2^18 * (256 + CHANSPC_M) * 2^CHANSPC_E
  // = 26000000 / 262144 * 504 * 4 = 199.951172 kHz
  0xF8,

  // CC1101_DEVIATN  0x15 Modem Deviation Setting - 2-FSK, GFSK, 4-FSK only
  // 6:4 - DEVIATION_E
  // 2:0 - DEVIATION_M
  // frequency deviation = 26000000 / 2^17 * (8 + DEVIATION_M) * 2^DEVIATION_E
  // = 26000000 / 131072 * 15 * 16 = 47.607422 kHz
  0x47,

  // CC1101_MCSM2    0x16 Main Radio Control State Machine Configuration
  // 4 - RX_TIME_RSSI - Direct RX termination based on RSSI measurement (carrier sense)
  // 3- RX_TIME_QUAL - When the RX_TIME timer expires, the chip checks if sync word is found when RX_TIME_QUAL=0, or either sync word is found or PQI is set when RX_TIME_QUAL=1.
  // 2:0 - RX_TIME - Timeout for sync word search in RX for both WOR mode and normal RX operation. The timeout is relative to the programmed EVENT0 timeout.
  0x07, // RX_TIME = until end of packet

  // CC1101_MCSM1    0x17 Main Radio Control State Machine Configuration
  // 5:4 - CCA_MODE
  //        00 - always
  //        01 - if RSSI below threshold
  //        10 - unless currently receiving a packet
  //        11 - if RSSI below threshold unless currently receiving a packet
  // 3:2 - RXOFF_MODE Select what should happen when a packet has been received
  //        00 - IDLE
  //        01 - FSTXON
  //        10 - TX
  //        11 - Stay in RX
  // 1:0 - TXOFF_MODE Select what should happen when a packet has been sent (TX)
  //        00 - IDLE
  //        01 - FSTXON
  //        10 - Stay in TX (start sending preamble)
  //        11 - RX
  0x30, // CCA_MODE - if RRSI below threshold unless currently receiving a packet

  // CC1101_MCSM0    0x18 Main Radio Control State Machine Configuration
  // 5:4 - FS_AUTOCAL Automatically calibrate when going to RX or TX, or back to IDLE
  //        00 - Never
  //        01 - When going from IDLE to RX or TX (or FSTXON)
  //        10 - When going from RX or TX back to IDLE automatically
  //        11 - Every 4th time when going from RX or TX to IDLE automatically
  // 3:2 PO_TIMEOUT Programs the number of times the six-bit ripple counter must expire after XOSC has stabilized before CHP_RDYn goes low.
  //        00 - 1 count - approx 2.3-2.4 us
  //        01 - 16 counts - approx 37-39 us
  //        10 - 64 counts - approx 149-155 us
  //        11 - 256 counts - approx 597-620 us
  // 1 PIN_CTRL_EN Enables the pin radio control option
  // 0 XOSC_FORCE_ON Force the XOSC to stay on in the SLEEP state
  0x18, // PO_TIMEOUT = 64 counts, auto calibrate when going from IDLE to RX or TX (or FSTXON)

  // CC1101_FOCCFG   0x19 Frequency Offset Compensation Configuration
  // 5 - FOC_BS_CS_GATE If set, the demodulator freezes the frequency offset compensation and clock recovery feedback loops until the CS signal goes high.
  // 4:3 - FOC_PRE_K The frequency compensation loop gain to be used before a sync word is detected.
  //        00 - K
  //        01 - 2K
  //        10 - 3K
  //        11 - 4K
  // 2 - FOC_POST_K The frequency compensation loop gain to be used after a sync word is detected
  //        0 - Same as FOC_PRE_K
  //        1 - K/2
  // 1:0 - FOC_LIMIT The saturation point for the frequency offset compensation algorithm
  //        00 - 0
  //        01 - BW/8
  //        10 - BW/4
  //        11 - BW/2
//  0x76, // 3K, K/2, BW/4 - *** ORIGINAL - BAD ***
  0x36, // 3K, Same as FOC_PRE_K, BW/4 - *** GOOD ***
//  0x1A, // 4K, Same as FOC_PRE_K, BW/4 - *** ? ***

  // CC1101_BSCFG    0x1A Bit Synchronization Configuration
//  0x6D,
0x62,

  // CC1101_AGCCTRL2 0x1B AGC Control
  0x03, // target amplitude: 33dB - Maximum possible LNA + LNA 2 gain - All gain settings can be used

  // CC1101_AGCCTRL1 0x1C AGC Control
  0x40, // LNA gain decreased first
 
  // CC1101_AGCCTRL0 0x1D AGC Control
  0x91, // Medium hysterisis - Filter Samples: 16 - Normal AGC operation

  // CC1101_WOREVT1           0x1E High Byte Event0 Timeout
  0x87,

  // CC1101_WOREVT0           0x1F Low Byte Event0 Timeout
  0x6B,

  // CC1101_WORCTRL           0x20 Wake On Radio Control
  0xF8,

  // CC1101_FREND1            0x21 Front End RX Configuration
  0x56,

  // CC1101_FREND0            0x22 Front End TX Configuration
  // 2:0 - PA_POWER - Selects PA power setting. This value is an index to the PATABLE, which can be programmed with up to 8 different PA settings.
  0x10,

  // CC1101_FSCAL3            0x23 Frequency Synthesizer Calibration
  0x99,

  // CC1101_FSCAL2            0x24 Frequency Synthesizer Calibration
  0x0A,

  // CC1101_FSCAL1            0x25 Frequency Synthesizer Calibration
  0x20,

  // CC1101_FSCAL0            0x26 Frequency Synthesizer Calibration
  0x0D,

  // CC1101_RCCTRL1           0x27 RC Oscillator Configuration
  0x27,

  // CC1101_RCCTRL0           0x28 RC Oscillator Configuration
  0x28
};

#endif  // _CC1101_AXSCEND_VALOR_REGISTERS_H

 

  • I notice that you use a 16 bit sync word. If you put CC1101 in RX a sync word will be detected within noise within seconds. There is therefore a finite probability that the chip will be pre-occupied processing a false packet when the real packet is being transmitted. I understand you cannot use a 32 bit sync word, but suggest you gate sync word detection by carrier sense. This is done in register MDMCFG2.

    Also, I do not get the MDMCFG4 and MDMCFG3 settings to match the bit rate. I would assume you want a symbol rate of 8.4 ksps, but this is not what I get when I enter your values into SmartRF Studio,

    I also believe AGCCTRL2.MAGN_TARGET is too low. Try with AGCCTRL2 = 0xC7.

    You do not write what the TPMS deviation is. You have programmed 47 kHz deviation. Is this correct? Please note that the programmed deviation is also used in RX so register DEVIATN needs to match the actual transmitted deviation.

    Change also FSCTRL1 = 0x08, FREND1 = 0xB6, TEST2 = 0x81, TEST1 = 0x25 (don't expect this to fix the issue, but these are the recommended values for 232 kHz RX BW)
  • Hi Sverre, Thank you for such a comprehensive and prompt reply. FYI, I have just been doing some legwork for my FW engineer who had hit a brickwall with this. I will pass this on to our FW engineer to try out and let you know the results.
  • Sverre,

    You questioned the bit rate.....This is what we were advise by the sensor manufacturer.....

    B)      Baud rate:

    There are difference in the understanding of the baud rate between TPMS manufacturer and CC1101. See below. That’s why you see 4.2kbps in ours and 9.6kbps in yours.

  • Tim,

    You state that the bit rate is 4.2 kbps. Thus, since you use Manchester encoding the symbol rate is 8.4 ksps (or kBaud).

    The figure above shows 2 Manchester encoded 0's. Manchester encoding (as per G.E. Thomas)  maps a "0 bit" into two symbols (i.e 0-1). 

    In order to find the true symbol rate (8.4 or 9.6) you can set CC1101 into serial asynchronous mode and look at the raw data output (i.e. no data decision nor synchronization) using an oscilloscope. Program the chip for 8.4 kbps and use NRZ (i.e. MODEMCFG2.MANCHESTER_EN = 0). Each symbol will no be treated as a bit. If you get close to 50% duty cycle the symbol rate is 8.4 ksps.

  • HI Sverre,

    We tried the changes to the Register's as you suggested, unfortunately there was no noticeable difference in the reliability of receiving data from the sensors.  You can see the new settings as per your advice on the attached spreadsheet.

    cc1101_settings.xlsx

    I'd like to clarify a couple of things.  

    We were originally advised by the sensor manufacturer that the Baud Rate was 4.2 kbps.  We then received subsequent advice from them explaining that there was a misunderstanding of the term Baud rate (this was the figure shown in my comment Dec 7th @ 3:10pm).  It didn't quite make sense to us at the time since by implication of their diagram the CC1101 setting should be 8.4kbps not 9.6kbps as they explicitly advised, unless of course the original advice of 4.2kbps was a typo and should have been 4.8kbps.  I am seeking clarity from them on this.  Anyway it works (albeit unreliably) at 9.6kbps and not at all 8.4kbps therefore we have determined it is 9.6kbps by the fact it sort of works and the manufacturers advice (despite the haphazard provision of information).

    Secondly

    When we ran into difficulties with the CC1101 the sensor manufacturer did some work for us trying to get one talking reliably to the other.  The upshot of this was they advised us that they would have to change their sensor protocol because they were unable to successfully disable the length field check on CC1101 using SmartRF (see protocols on attached sheet).  They advised that the CC1101 is capable of having the packet length field disabled but that it does not retain or commit the setting. It would I think have been less risky to use the manufacturers original protocol since this had been tried and tested, in any event using the CC1101 we have not yet been able to prove the new FW/protocol on the sensor is good.   Is there indeed a reliable way to disable packet length field check on the CC1101 which has been overlooked ?  

    Also, do you have a reference C implementation for receiving data we could use to ensure we are handling the cc1101 state machine correctly.

    Could you clarify the why you advised setting TEST2 and TEST1, these are not really described in the data sheet.

    Are there any Field Apps engineers in the UK that could help resolve this at our lab ?

    Kind Regards

    T

  • Tim,

    You did not enable carrier sense prior to sync word search. Instead of MDMCFG2 = 0xA try with 0xE. The idea is to reduce the likelihood that the chip spends time processing false packets (in this scenario the chip could be busy processing a false packet when the real one is being transmitted). Not sure what the carrier sense (CS) threshold is with your current settings, but the link will most likely not work down to the sensitivity limit. Anyway, suggest you try this to see if this improves matters. We can always work on the CS threshold later.

    Is the Frame Header always 0x0A? If yes, why not use this as part of the sync word? That is, use 0xF6 0A instead of 0xFF F6. I would expect the former to have better correlation properties than the latter (sorry - haven't actually simulated this; it is merely an educated guess).

    The CC1101 can be used with fixed packet length or with variable packet length.
    - Fixed packet length: Packet length is set in register PKTLEN. PKTCTRL0.LENGTH_CONFIG = 0. If you use this option the Frame Header can be part of the sync word as explained above
    - Variable packet length: Packet length is the first byte after the sync word. PKTCTRL0.LENGTH_CONFIG = 1.

    There are SW examples on TI web: www.ti.com/.../toolssoftware => Software (CC110 CC1101 Examples Libraries)

    TEST2 and TEST1 are both related to the ADC. TEST2 fine-tunes the ADC reference current and TEST1 adjusts ADC DAC feedback current.

    There is no apps in the UK that can come to your lab to help with testing. I will befriend you on E2E to discuss options.