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 protocolIt'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 protocol4byte 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.