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: RTL-SDR and CC1101 wmbus

Part Number: CC1101
Other Parts Discussed in Thread: WMBUS,

Hello,

My goal is to be able to read the wmbus packets coming from my cc1101 based radio with a RTL2832 SDR based dongle. 

First, to make sure the sdr is working i tested it with a 434.475 MHz radio from a 3rd party and with the RC1140-MBUS3 module. Both worked fine. I used the xaelsouth software for demodulating and decoding the T1 mode packets.

I can also read the wmbus packets coming from my cc1101 with the RC1140-MBUS3 module.

The problem is that i couldnt read my packets with the RTL2832 SDR. I cant figure out what is happening. 

Here is my cc1101 config ->

// Product = CC1101
// Chip version = A   (VERSION = 0x04)
// Crystal accuracy = 10 ppm
// X-tal frequency = 26 MHz
// RF output power = + 10 dBm
// RX filterbandwidth = 325.000000 kHz
// Deviation = 38 kHz
// Datarate = 32.630920 kBaud (will change to 100 kbaud when operating in T1 mode)
// Modulation = (0) 2-FSK
// Manchester enable = (0) Manchester disabled
// RF Frequency = 434.475 MHz (this is the fc for wmbus when operating in my country)
// Channel spacing = 199.951172 kHz
// Channel number = 0
// Optimization = -
// Sync mode = (5) 15/16 + carrier-sense above threshold
// Format of RX/TX data = (0) Normal mode, use FIFOs for RX and TX
// CRC operation = (0) CRC disabled for TX and RX
// Forward Error Correction = (0) FEC disabled
// Length configuration = (0) Fixed length packets, length configured in PKTLEN register.
// Packetlength = 255
// Preamble count = (2)  4 bytes
// Append status = 0
// Address check = (0) No address check
// FIFO autoflush = 0
// Device address = 0


const RF_CONFIG_T tModeRfConfig = {
                                   0x08,   // FSCTRL1   Frequency synthesizer control.
                                   0x00,   // FSCTRL0   Frequency synthesizer control.
                                   0x10,//0x21,   // FREQ2     Frequency control word, high byte.
                                   0xB5,//0x6B,   // FREQ1     Frequency control word, middle byte.
                                   0xE8,//0xD0,   // FREQ0     Frequency control word, low byte.
                                   0x5C,   // MDMCFG4   Modem configuration.  - 103 kBaud
                                   0x04,   // MDMCFG3   Modem configuration.
                                   0x05,   // MDMCFG2   Modem configuration.05
                                   0x22,   // MDMCFG1   Modem configuration.
                                   0xF8,   // MDMCFG0   Modem configuration.
                                   0x00,   // CHANNR    Channel number.
                                   0x44,   // DEVIATN   Modem deviation setting
                                   0xB6,   // FREND1    Front end RX configuration.
                                   0x10,   // FREND0    Front end RX configuration.
                                   0x18,   // MCSM0     Main Radio Control State Machine configuration.
                                   0x2E,   // FOCCFG    Frequency Offset Compensation Configuration.
                                   0xBF,   // BSCFG     Bit synchronization Configuration.
                                   0x43,   // AGCCTRL2  AGC control.
                                   0x09,   // AGCCTRL1  AGC control.
                                   0xB5,   // AGCCTRL0  AGC control.
                                   0xEA,   // FSCAL3    Frequency synthesizer calibration.
                                   0x2A,   // FSCAL2    Frequency synthesizer calibration.
                                   0x00,   // FSCAL1    Frequency synthesizer calibration.
                                   0x1F,   // FSCAL0    Frequency synthesizer calibration.
                                   0x59,   // FSTEST    Frequency synthesizer calibration.
                                   0x81,   // TEST2     Various test settings.
                                   0x35,   // TEST1     Various test settings.
                                   0x09,   // TEST0     Various test settings.
                                   0x06,   // IOCFG2    GDO2 output pin configuration.
                                   0x00,   // IOCFG0D   GDO0 output pin configuration. Refer to SmartRF® Studio User Manual for detailed pseudo register explanation.
                                   0x00,   // PKTCTRL1  Packet automation control.
                                   0x00,   // PKTCTRL0  Packet automation control.
                                   0x00,   // ADDR      Device address.
                                   0xFF    // PKTLEN    Packet length.
};

const uint8_t tModePaTable[] = {0xC0};
const uint8_t tModePaTableLen = 1;

Those values are the same of the Ti wmbus stack, i just changed the Fc to 434.475 MHz.

For testing purposes the RTL2832 is connected to a raspberry pi and i am using this software to decode the packets: github.com/xaelsouth/rtl-wmbus

This is the rtl_sdr setup that i used: rtl_sdr -f 434425000 -s 1600000 - 2>/dev/null | build/rtl_wmbus

Is there any additional configuration that i must do in cc1101?

Thanks in advance !

 

  • "First, to make sure the sdr is working i tested it with a 434.475 MHz radio from a 3rd party and with the RC1140-MBUS3 module. Both worked fine. I used the xaelsouth software for demodulating and decoding the T1 mode packets.

    I can also read the wmbus packets coming from my cc1101 with the RC1140-MBUS3 module."

    From the above it sound like the following is the case:
    SDR <-> RC1140-MBUS3 OK

    CC1101 <-> RC1140-MBUS3 OK

    SDR <-> CC1101 NOT OK.

    Which software does RC1140-MBUS3 and CC1101/ MCU run?

    We have never looked into the SDR you are trying to use. What is the end goal with this test?
  • Hello TER,

    The RC1140-MBUS is just a uart module, i use it just to send test packets to the SDR. I have problems when sending the exact same test packets with the CC1101. This is very weird.

    i just made a simple software that sends a test packet each 10 seconds. I have two separate boards, one using the RC1140-MBUS3 and another with the CC1101.

    It seems that the wmbus implementation is not 100% correct in CC1101 besides the fact that the RC1140-MBUS3 is able to read the CC1101 test packets just fine. As i mentioned i have also tested a wmbus smart meter with the SDR and it worked.

    Notice that i am operating in T1 mode so this is a tx only link with the SDR.

    The sdr board is the Rafael 820T2 Tuner Dongle.

    The goal is a proof of concept of a wmbus gateway with better range and flexibility like the SDR based gateways used in glidernet (wiki.glidernet.org/).

  • The RC1140-MBUS has the WMBUS stack implemented. You are referring to the wmbus implementation in the CC1101. First of all the implementation has to be in a MCU controlling the CC1101. What exactly is your CC1101 hardware and software?

    T mode require 3 out of 6 coding etc.
  • We are using the Ti Wmbus Stack for the msp430, it is working because we can read the wmbus packets with the RC1140-MBUS3.

    For this test we are not using the firmware of our product. We are just using the same hardware (msp430 + cc1101).

    The code used for this test is the swra234a. It contains a example of T1 mode in 868 MHz.  We just changed the carrier frequency to 434.475 MHz, because the wmbus in our country must operate in this frequency.

    This is the link of the source code from Ti => www.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=swra234a

    This is the reason i am so confused. 

  • I attached two pictures, the first is the demodulated signal coming from the reference (a wmbus smart meter, which works very well with the sdr) , and the second the demodulated signal from the cc1101 board using the example code of Ti Wmbus stack.

    WMBUS Smart Meter - 434.475 MHz - demodulated signal

    WMBUS CC1101 Board - 434.475 MHz - Ti wmbus stack, example code - demodulated signal

    It look likes a problem related with the preamble, i tried to change the preamble settings but didnt work.

    Update: I increased the preamble lenght to 8 bytes. The stacks configures the sync words to -> SYNC1 = 0x54 and SYNC0 = 0x3D. This should produce this bit stream

    010....0101        01010100  00111101

    (preamble)         SYNC1            SYNC0

    This matches the wmbus standard, but if you see the cc1101 screenshot, you will notice that there is one single bit that is wrong. The sequence is 01010101 00 1010100....

    This bit is the next after the end of the preamble (beggining of sync1). SYNC1 value should be different than 0x54 to make this possible, but it is really 0x54 in the stack....

    I made a little modification in xaelsouth wmbus software to considerer this behavior in the packet decoding and then i could read my cc1101 packets. But in this way the radio is not 100% meeting the wmbus standards.

  • It looks like it send a 0xAA preamble and not a 0x55 preamble. In the standard the preamble is defined as nx(01) and if a 0x(10) pattern is sent this seems to be not according to spec.

    How did you get the wmbus stack you are using?
  • TER, i think you are correct. I downloaded the stack from Texas Instruments website - swra234a . Is there a way to change the cc1101 preamble format (0x55 instead of 0xAA)?
  • CC1101 can only use 0xAA preamble. I'll try to check internally why the stack send a 0xAA preamble.
  • TER

    I believe i found a fix, could you check if this is safe?

    I removed the preamble/sync usage (MDMCFG2 = 0x00). To emulate the preamble and sync, i send this array before sending the wmbus packet -> { 0x55, 0x55, 0x55, 0x55, 0x55 , 0x55, 0x55, 0x55, 0x54, 0x3D}.

    I think the stack is according with the wmbus with this little modification because i can read the cc1101 packets with the SDR without any modifications in the decoding software.
  • I thought about something along those lines. It's safe to place the full packet including preamble and sync as part of the payload or if you mange to send 0x55 before the sync without any time delay.