Reverse Engineering central heating wireless thermostat - help needed!

[LaserSteve]

Why in the heck would you want to try to demod the RF when you have access to the SPI on BOTH ends?
Unless a Demod tool is already coded, that is just asking for a huge development project.  You could spend tens of minutes waiting for a single command burst. 

I'd vote for Sniffing the bus.  Even my low end four channel scope has a sniff mode option for SPI. 

Dear OP, if you want to see the burst rate, I'll link what I was going to suggest if the transmitter was on/off keyed.
One diode detector, one scope channel, and a 81 mm length of wire as a quarter wave antenna..

http://www.techlib.com/electronics/detect.htm

On Chuck Wenzel's detector circuit,  linked above, you may need to lower the value of the 0.1 uF cap or the 100K resisitor to see a full envelope.



Steve

[picitup]

Hi

I wanted to go the RF route for two reasons;  firstly I wanted to know that I can acquire a transmitter (868.3MHz) that would work with the system otherwise it will never work and secondly, going the RF route, I can play until my heart's content rather than start hacking the transmitter around and killing it as the cold weather approaches then we have no heating.  This may cause local tensions 

Another option is to buy another (cheap) wireless stat and receiver, fit that to the central heating then I'm free to hack this one around.

Both reading the SPI bus and the RF side are interesting to me.  I think there's plenty of scope for me to learn a lot.

I've seen an RTL-SDR stick on eBay for £7.81 item number 161897487881.  Is this the kind of stick I would need?

Ps I don't mind spending the time if I'm learning something new.

Thanks again all for your comments.

Cheers

Steve

[picitup]

OK I've done a bit of reading and youtubing and found these 2 videos, that you might find interesting if you're an RF noob like me.  Both show using the RTL2832U stick on Androids using OTG.





So I've put my hand in my pocket and bought a stick which is fleabay item 172017000295 for £7.58.  Despite the main pic, it comes with an aerial and remote control.  It's stocked in the UK supposedly so hopefully it won't take too long to come.

I'll post up when it arrives.

Cheers

Steve

[picitup]

Yes when you start digging into devices, it's amazing how scabby the designs are.  It gives me hope for the future!

Well no SDR stick today, so hopefully Monday.  I decided to buy the cheap transceiver from fleabay mentioned above.  It's item 141804081741 and is £2.40 and is apparently a Silicon Labs SI4463 clone which is another SPI->Radio solution.  I asked the seller for the data sheet and he sent me Silicon Labs AN632 EZRadioPro advice note:

https://www.silabs.com/Support%20Documents/TechnicalDocs/AN632.pdf

The SI4463 datasheet is here:

https://www.silabs.com/Support%20Documents/TechnicalDocs/Si4464-63-61-60.pdf

and I'm pretty gobsmacked.  It's a fully featured programmable spi->radio with I/O and configurable frequency and modulation etc.  It has a config program which allows you to change many settings and I think you can code it in C too.

I thought I was buying a simple on/off point-point device but it's the full works.

I'm hoping I can learn how to use it in less than a year lol, but coupled with the SDR stick I think I'm in for some fun.

Cheers

Steve

[ataradov]

Well, actually Si446x is a subset of Atmel AT86RF215. IEEE 802.15.4g specifies a lot of modes, so it appears that things are infinitely configurable, but they are not.

And Si446x does not support QPSK modes, so if your RF212-based device is using them, then it will be completely useless.

[ataradov]

Or the goal of reverse engineering has changed to learning about modulations?

[picitup]

Hi you may well be right, but for the very low price I thought it was worth a try.

No my main goal is the same, to be able to talk to the wireless receiver next to the boiler, but you're right I'm being seduced into learning some wider RF in the process.

I'll post up when the SDR arrives and I'd had a play with it.

Cheers

Steve

[picitup]

Well, my RTL-SDR dongle hasn't arrived yet, but I've had a chance to do some reading and here's what I found:

Dongles
======
I bought the cheapest one I could find (£7.58) and there are reports of drift at the higher end of the spectrum due to overheating.  There's an improved version here:

http://www.rtl-sdr.com/buy-rtl-sdr-dvb-t-dongles/

which is $24.95 and has an OXCO for 1ppm stability, is vented to keep it cooler and they say it has a more sensitive front end.

The sdrPlay device covers from 100KHz to 2GHz and costs £118.80 and is here:

http://www.sdrplay.com/

However, don't expect to pick up much the low end with the piddly antenna supplied with the cheap dongle.  I've read that you can buy a wide band antenna, something like the discone or eBay item 121508352707 if you're really serious.

Software
======
There's a lot of free software out there and there's a list here:

http://www.rtl-sdr.com/big-list-rtl-sdr-supported-software/

I've chosen SDR# (sdrsharp) as it's free and seems to be widely used.  It has a range of plugins (including an oscilloscope!!!) here:

http://www.rtl-sdr.com/sdrsharp-plugins/

Identifying Signals
=============
If you're a noob like me, you might like to look at the Signal Idenfication Wiki which has pictures of waterfalls, audio recordings and modulation types etc:

http://www.sigidwiki.com/wiki/Signal_Identification_Guide

Well that's all for now.  I'm away all weekend so if the dongle doesn't arrive tomorrow then I'll post up again next week.

Cheers

Steve

[picitup]

Hi All

After a short present wrapping break I found some time to look at this.  The SDR dongle arrived and I installed sdr# to play with it.  Just a couple of comments about the dongle; it's quite wide and fouls the USB port next to it, so I bought a 4 inch USB extension cable which seems to work fine.  Secondly the supplied antenna had about 3 feet of cable which made it difficult to get by the window.  The aerial socket on the dongle is mcx so I bought a 4 foot extension lead.  The antenna screws onto the base with an m3 thread and I've got loads of m3 brass pillars so I may experiment with different antenna lengths in the future.

To learn sdr# I just played around, tuning in local stations etc and then calibrated the dongle with a program called imaginatively, Kalibrate which scans for local GSM stations and then gives you a ppm offset you enter into sdr# by clicking on the cog icon.

Onto the main business; I located my thermostat on the 868mHz band and proved it was the right one by removing the batteries.  Unsurprisingly, it was the strongest signal at a distance of 1 foot from the antenna.

I've posted up a picture of SDR (SDR-Raw)and the waterfall shows the transmission.  The 2 wide signals are the thermostat and I'm not sure what the small signal is, but I think it's an outdoor temp sensor that connects to our wireless thermometer.  The thermostats does a couple of bursts of information about every 40 seconds and you can see this in the audacity recording image Audacity-RepeatSignal.jpg.  Audacity sampling rate was set to 384 KHz to get about 17 samples per cycle and get a reasonable representation.

Audacity-FirstSignal.jpg and Audacity-FirstSignal-Zoom are zoomed in views of the first burst of data.

Audacity-Single.wav is a recording of the dual spike signal and is amplified to make it more visible.

Now I'm stuck  .  I don't have enough experience to find out the modulation type and protocol.  Choosing RAW seems to have the best audio output as for example, WFM has a lot of background hiss.  The zoomed in waveforms as show below don't seem to represent simple binary and have cycles that are well above and below the centre line and other cycles dancing around the centre line.

If anyone has the patience for an RF noob then I'd be grateful for any help I can get.

I did also take note of the helpful posts that suggested I sniff the SPI bus and as a backup plan I've ordered an OpenBench logic sniffer which is currently walking it's way from China.  I figured, I could buy a transmitter only, experiment with it and if I didn't kill it, sell it again without too much loss.

Thanks for reading....

Steve

[ataradov]

Sure. First of all, you have a good start knowing what radio it is and what standard it follows. So it will be very helpful to read IEEE 802.15.4-2006 standard to understand what is going on.

The radio is quite flexible, but assuming they went with frequency/modulation from the standard, here are a few quotes from it:

The data rate of the 868/915 MHz band BPSK PHY shall be 20 kb/s when operating in the 868 MHz band and 40 kb/s when operating in the 915 MHz band.

The 868/915 MHz BPSK PHY shall employ direct sequence spread spectrum (DSSS) with BPSK used for
chip modulation and differential encoding used for data symbol encoding.

The raw data is passed to a spectrum spreader, which maps each bit (symbol) to 15-bit long M-sequence, distinct for 1 and 0.

Then the resulting stream is passed on to the BPSK modulator.

Here is what we know about that modulator:

The chip sequences are modulated onto the carrier using BPSK with raised cosine pulse shaping (roll-off
factor = 1) where a chip value of one corresponds to a positive pulse and a chip value of zero corresponds to a negative pulse. The chip rate is 300 kchip/s for the 868 MHz band and 600 kchip/s in the 915 MHz band.

With chip rate of 300 kchip/s you need to digitize your signal with sampling frequency of at least 600 ksps, but for first experiments, it is better to go as fast as hardware will allow.

Right now your signal looks way undersampled, it is not recoverable.

[ataradov]

After you sample the signal at a right frequency, you should see a level signal with distinct states for 0 and 1. It may be multiplied by a relatively slow sine wave, which can be removed either by more accurate frequency tuning, or later in signal recovery.

[Harvey17]

This is literally what I did for the Worcester-Bosch MT10RF, but I did it with an Agilent mixed-signal scope, a Python script, and a couple of wires and a broken Worcester-Bosch MT10RF I found on Ebay. Then I found a TI USB FET (MSP430 Flash programmer) and hooked it up to the JTAG pins on the main micro... which helpfully wasn't JTAG-locked! 

Ten minutes later, I had a complete flash ROM dump, and about an hour after that, I'd single-stepped their code and knew what the I/O pins did, why the temperature sensing was so shockingly bad (they're using a digital pin to sense a thermistor using an R/C, and the capacitor drifts like a mother with both time and temperature...) and what the RF protocol was "as they envisioned it". Curiously it can signal low-battery status back to the boiler, but the boiler doesn't have any way of saying "uh, the battery's low, fix pls?" -- nor does the thermostat. First you find out about that is when your heating doesn't come on...

So it's not impossible. In fact, on an SPI chip it's probably easier than the WoBo -- I was dealing with TX_EN and FSK_DATA on some Infineon chip.

Cheers,
Phil.

Necro-posting here, but wondering if you still have any info on the RF protocol these MT10RF's use? I can see [in the one I have] it uses a TDA 5100 as the ASK/FSK Transmitter, and a MSP430F2121 processor, so I'm hoping its not going to be too hard to work out what's going on. I'd like to make a "better" thermostat as these MT10RF's are just damn annoying in so many ways.

[Harvey17]

So I managed to tap into the transmitters FSK drive test point, found out my scope's storage space isn't quite big enough to capture an entire packet ( ) so resorted to using the sound card capture and have managed to get a few examples captured. I've got a feeling this thermostat is more than just a basic ON/OFF signal as we have a modulating combi boiler and its noticeable that the boiler reduces its output as the temperature of the room gets close to the set temperature, so ideally I'd like to work out some sort of decoding of the transmitted data so as to figure out if this is the case.

I first thought the data stream was Manchester coded, but it doesn't seem to follow the rules for Manchester, so would anyone like to guess the transmission protocol used in the attached capture? (The selected part is the preamble. and this is just the start of the data stream)

[ataradov]

The frequency in the preamble is two times the frequency of the bits. So the preamble is used to lock the bit clock. Just decode it as individual bits. At least count how many bots there. Hoe do they change from transmission to transmission? Any parts are static?

To tell for sure you will have to do many more captures. And you can probably take Arduino or similar board and write a simple decoder that will synchronize the same way as a real receiver. This will make it easier to dump the data continuously.

[philpem]

So I managed to tap into the transmitters FSK drive test point, found out my scope's storage space isn't quite big enough to capture an entire packet ( ) so resorted to using the sound card capture and have managed to get a few examples captured. I've got a feeling this thermostat is more than just a basic ON/OFF signal as we have a modulating combi boiler and its noticeable that the boiler reduces its output as the temperature of the room gets close to the set temperature, so ideally I'd like to work out some sort of decoding of the transmitted data so as to figure out if this is the case.

I first thought the data stream was Manchester coded, but it doesn't seem to follow the rules for Manchester, so would anyone like to guess the transmission protocol used in the attached capture? (The selected part is the preamble. and this is just the start of the data stream)

I've actually been reverse engineering the MT10RF protocol myself!

As it happens, the MSP430 in the transmitter isn't code protected and can be read out or debugged with a GoodFET or MSP430 debug probe. The PIC16F628 in the receiver has its code space protected but not its data EEPROM. (the data EEPROM contains the three-byte ID of the transmitter it was paired with)

Line protocol

It's 868MHz FSK (specifically 868.29MHz), 4kHz deviation. With that said, the receiver module's IF filter is considerably wider. A '1' sent to the modulator makes it transmit on the lower frequency (868.29MHz minus 2kHz). The transmitter chip is a TDA5100.

Encoding is Manchester biphase, 800us per bit. "01" is a zero, "10" is a one.

There's a 40-cycle preamble (400ns period, 50% duty) followed by a 1.6ms gap, then the Manchester coded data.

Every byte is packed into a 12-bit block:  Start - 8 bits - Parity - Stop - Stop

Start bit is a '0', then 8 data bits (sent LSB to MSB), odd parity, then two '1's for stop bits.


Packet protocol

4byte Preamble (68 07 07 68 hex) -- ID0,ID1,ID2 -- Pa,Pb,Pc,Pd -- checksum -- terminator.

ID0,1,2: transmitter ID -- unless this is a pairing block, when the ID is set to zero.
Pa: 0x80 for a pairing block, otherwise 0x01 for normal operation or 0x02 for low battery indication.
Pb: ID0 in a pairing block, otherwise 0x00 for no heating demand of 0xFF for heating demand.
Pc: ID1 in a pairing block, otherwise a sequence number: 0x0A, 0x14, 0x28, 0x32 (then wraps round to 0x0A)
Pd: ID2 in a pairing block, otherwise 0x14
Checksum: The additive checksum of ID0 through Pd inclusive
Terminator: 16 hex in a pairing block, otherwise 68 hex

When the thermostat is first powered up, it sends Pairing packets every five seconds for a couple of minutes.  (IIRC the actual pattern is slightly more complex, but the exact timing isn't in my notes)

After the pairing sequence finishes, it waits 180 seconds, then transmits a Status packet every 180 seconds if the heating demand state hasn't changed.
When heating demand changes (off->on or on->off), it sends three Status packets at 5-second intervals, then reverts to sending them every 180 seconds.


I don't think there's any modulation capability, because the receiver module's output is a switch driver. Possibly the boiler is modulating because the TRVs are starting to switch off or the thermostat is oscillating around the setpoint.

[QuitButton]

I've been pointed to the pose by philpem as I was helping a friend a while back to get some of the MT10RF protocol worked out - we didn't get too far and then unfortunately life got in the way...

However,  I've just spent a few hours over the last couple of days coming up with a bit of rough STM32 arduino code that creates a bitstream array that matches the protocol you've posted and it matches a few sample captures I've compared it against. I'll tidy it up a bit and post it somewhere as it could be useful for someone.

The plan was to use a RFM22B to transmit the code (I can't see as it can be transmitted using the RFM22b's internal packet handler, so I coded it to use a timer)...but I'll admit I'm totally baffled by the RFM22B's datasheet and so far I've have little luck making head nor tail of any example code to get something as simple as the right frequency and offset.   

Does anyone know of a simple to use Arduino friendly TX module for 868MHz?

[QuitButton]

...

Pc: ID1 in a pairing block, otherwise a sequence number: 0x0A, 0x14, 0x28, 0x32 (then wraps round to 0x0A)

I'm seeing something more than just a basic sequence number. The one I'm playing with now for an "on" command sends 3 x "on" with 0x28, a pause, one "on" with 0x32, then back to 0x28 while heating needs to be on. For the off sequence it sends 3 x "off" with 0x14, a pause, "off" with "0x0A", then "off" with 0x14 etc.

It's 868MHz FSK (specifically 868.29MHz), 4kHz deviation.

I don't know much about RF but looking at the signal using SDRsharp and a RTLSDR I'm seeing near 100k between upper and lower peaks. Surely that can't be right can it?