Imitate signal with CUL433

[Martin Karlgren]

Hello everyone!

I have a CUL433 which I would like to use to send signals to my floor heating central (so that I can control it myself rather than using the RF thermostats). I don't have a proper oscilloscope, so I haven't been able to sniff the 433.7 MHz signal, but I have used a logic analyser to probe the signal directly on the thermostat circuit board. The signal looks like the image below (the pulse length seems to be 0,4 ms).

I have used the following commands to try to send the proper signal, but nothing happens at the receiver:

W0F10
W10AE
W1146
X21

(To set 433.7 MHz frequency)

G00A0F300191900FFFFFFEAAA8C9A5E549A
(To send the actual signal)

One problem is that I don't really see a manchester-type pattern in the signal, so I don't know if the symbol 1 has both a high and a low signal etc. So in the CUL command I have set the 0-bit high time to 0 and 1-bit low time to 0, and the 1-bit high and 0-bit low to 400 us respectively. So I'm trying to send the "raw" signal I probed using the analyser... but this doesn't seem like the right way to do it... any help and insights would be greatly appreciated!

(The RF chip in the thermostat I'm trying to imitate is a U2741BN and I'm assuming it uses simple ASK encoding.)

[Cadu Silvestre]

Hi Martin,

Did you have any luck? I'm trying to do the same with my CUL433, but still without success.

What commands are you using to sniff?

Thanks.

[Martin Karlgren]

Hi Cadu,

Yes, I did have success at last! (I have small children so I only get short moments every now and then to play with this...)

I tried to sniff with the X command without much luck, partly because I looked for the wrong data and partly (probably) because it's not as reliable as the CC1101 internal packet handling. I ended up sniffing with the "fr" command after setting the correct parameters in the FASTRF config. I also made a minor modification in fastrf.c to get hexadecimal output rather than binary to avoid mixing up newline characters with actual data (replace DC(buf[i]); by DH2(buf[i]); near the end of the FastRF_Task function).

As mentioned (see also my other post about the FastRF patch), you need to set the correct FASTRF parameters before entering "fr" mode. I knew my receiver used a 433.7 MHz carrier frequency and a 2.5 kbit/s data rate (thanks to using a logic sniffer on the transmitter circuit board on one of the thermostat transmitters), so I could configure the registers based on that. I didn't know the sync word in use but still wanted to have preamble detection to get rid of all the noise, so I used a setting of 0x32 for MDMCFG2 (address 0x12 + 0x37 (FASTRF_CFG offset)). 0x32 represents ASK modulation and 16/16 sync word bits – and I knew there would be a preamble (alternating 1 and 0), so I simply used 0xAA (10101010) as both the high and low byte sync word. I used infinite packet length. After leaving the sniffer on for an entire night I had enough data to match with the output of my logic sniffer. It turned out the signal I received from the CUL was both bit-inverted (I had probably reversed the probes on the circuit board) and bit-shifted. After that, I could match the rest of the signals from my other 6 thermostats.

Unfortunately I don't have time for all the details right now but I may be able to fill in more later (feel free to ask specific questions if you have any). I really recommend reading cc1101.pdf thoroughly, especially the configuration register documentation on page 68 and forward. Also, SmartRF Studio (available free from Texas Instruments) was helpful to get the correct settings for the carrier frequency and data rate (although it's certainly possible to calculate manually as well).

Regards,

Martin

[Cadu Silvestre]

Hi Martin,

Thanks a lot for finding time to answer me back.

I'm a old time developer, but not very close to hardware and RF and the last time I developed for a microcontroler was on university with a 8051 - it was the first one accepting C 14 years ago.

I started reading CC1101, it cleared out a lot of things to me but not everything yet. Still struggling. Want to do is to receive this signal and replicate it:

https://damn.technology/controlling-british-gas-wr1-receiver-arduino

Those guys use a simple digital antenna to see data through the sound card - I didn't want to go through this direction as I don't have a solder and I thought via CUL it would be simpler ... not true :)

One of my big problems is that I don't have any info on the signal I want to listen as it's a close protocol (and I don't have the know how to do as you did - "(thanks to using a logic sniffer on the transmitter circuit board on one of the thermostat transmitters)". Now I'm trying to config the CC1101 to the very general 433MHZ config:

RF_SETTINGS rfSettings =        // 433Mhz, 9600Bauds
{
    0x06,  // FSCTRL1       Frequency Synthesizer Control - IF:152.343Khz
    0x07,  // IOCFG0        GDO0 Output Pin Configuration - Packet received and CRC OK
    0x00,  // FSCTRL0       Frequency Synthesizer Control - Freq offset
    0x10,  // FREQ2         Frequency Control Word, High Byte - 433.999 Mhz
    0xB1,  // FREQ1         Frequency Control Word, Middle Byte
    0x3B,  // FREQ0         Frequency Control Word, Low Byte
    0xF8,  // MDMCFG4       Modem Configuration - BW: 58.035Khz
    0x83,  // MDMCFG3       Modem Configuration - 9595 Baud
    0x13,  // MDMCFG2       Modem Configuration - 30/32 sync word bits - Manchester disable - GFSK - Digital DC filter enable
    0x22,  // MDMCFG1       Modem Configuration - num of preamble bytes:4 - FEC disable
    0xF8,  // MDMCFG0       Modem Configuration - Channel spacing: 199.951Khz
    0x00,  // CHANNR        Channel Number
    0x15,  // DEVIATN       Modem Deviation Setting - 5.157Khz
    0x56,  // FREND1        Front End RX Configuration 
    0x10,  // FREND0        Front End TX Configuration
    0x18,  // MCSM0         Main Radio Control State Machine Configuration - PO timeout: 64(149-155us) - Auto calibrate from idle to rx/tx
    0x16,  // FOCCFG        Frequency Offset Compensation Configuration
    0x6C,  // BSCFG         Bit Synchronization Configuration
    0x03,  // AGCCTRL2      AGC Control - target amplitude: 33dB - Maximum possible LNA + LNA 2 gain - All gain settings can be used
    0x40,  // AGCCTRL1      AGC Control - LNA gain decreased first
    0x91,  // AGCCTRL0      AGC Control - Medium hysterisis - Filter Samples: 16 - Normal AGC operation 
    0xE9,  // FSCAL3        Frequency Synthesizer Calibration
    0x2A,  // FSCAL2        Frequency Synthesizer Calibration
    0x00,  // FSCAL1        Frequency Synthesizer Calibration
    0x1F,  // FSCAL0        Frequency Synthesizer Calibration
    0x59,  // FSTEST        Frequency Synthesizer Calibration Control
    0x88,  // TEST2         Various Test Settings
    0x31,  // TEST1         Various Test Settings
    0x09,  // TEST0         Various Test Settings
    0x07,  // FIFOTHR       RX FIFO and TX FIFO Thresholds - Bytes in TX FIFO:33 - Bytes in RX FIFO:32
    0x06,  // IOCFG2        GDO2 Output Pin Configuration - Sync word received/sent - end of packet
    0x04,  // PKTCTRL1      Packet Automation Control - No address check - Automatic flush of RX FIFO is disable - sync word is always accepted
    0x05,  // PKTCTRL0      Packet Automation Control - whitening is off - RX/TX data normal mode - CRC calculation in TX and CRC check in RX - Variable packet length
    0x00,  // ADDR          Device Address 
    0xFF,  // PKTLEN        Packet Length
    0x3F,  // MCSM1         Main Radio Control State Machine Configuration
};

And with that I hope to listen the on/off of my worcester.

Initially I thought about changing the code, but I'm starting to think on write my own - you said you use the FastRF command, I never imagined it as the command reference is not very clear:

f<type>[<data>]
"fast" (250kBaud) rf txmit via CC1101 packet handling.
First switch both devices to fastrf mode with "fr", then send data: fs<data>, e.g. fsHallo
Reset to "SlowRF": fx, followed by X21
It can be used to "sniff" RFR packets

I'll have a look to see if I can sniff after applying your patch - do you have the command sequence you used here? It would be very helpful.

Thanks a lot, again.

Cheers.

--
--
To unsubscribe from this group, send email to
cul-fans+u...@googlegroups.com

---
Sie erhalten diese Nachricht, weil Sie in Google Groups ein Thema der Gruppe "CUL fans" abonniert haben.
Wenn Sie sich von diesem Thema abmelden möchten, rufen Sie https://groups.google.com/d/topic/cul-fans/B3nXuV_4xKY/unsubscribe auf.
Wenn Sie sich von dieser Gruppe und allen Themen dieser Gruppe abmelden möchten, senden Sie eine E-Mail an cul-fans+u...@googlegroups.com.
Weitere Optionen finden Sie unter https://groups.google.com/d/optout.

[Martin Karlgren]

Cadu,

After a quick glance at the pulse captures it almost looked like manchester coding, but after I had a look at his example code snippet (rf.cpp) it seems the pulse lengths are rather inconsistent. Maybe the easiest way is to skip fastrf mode and port his code snippet instead, i.e. use the timing arrays from rf.cpp and set the output high/low accordingly. Have a look at the send_bit function in clib/rf_send.c where you can see how to set the output high/low on the CUL. pgm_read_word_near should be available on the CUL as well thanks to avr-libc, if I'm not mistaken, so you should be able to use PROGMEM (just like in Stevens code snippet) to store your timing arrays in flash memory.

A generic CUL function to simply alternate output with raw timings provided via tty would be cool if someone finds the time at some point...

Regards,

Martin

[Cadu Silvestre]

Martin,

Thanks again for your support.

You gave me great tips to the send function and that's what I'm gonna do. I'm working now in a way of reading it, as the second phase (worcester id) is different from Steven's one (different boilers hehe). I'm trying to configure the cc1101 correctly (according to the manual and SmartRf, trying different configs as I don't have the rf info) and reusing the rf_receive.c basis.

I'll post here my results.

Cheers.