Electronics > Projects, Designs, and Technical Stuff

Reverse Engineering central heating wireless thermostat - help needed!

<< < (8/9) > >>

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:

--- Quote from: philpem on December 02, 2015, 06:52:55 pm ---
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!  >:D

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.

--- End quote ---

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 ( |O) 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:

--- Quote from: Harvey17 on November 21, 2018, 01:13:19 am ---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 ( |O) 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)

--- End quote ---


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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod