My ventilation system needs an upgrade. The old one is noisy and it is 40 years old. Some research lead me to the Itho CVE ECO RFT SP. This has a DC driven motor which should consume a lot less power as well. The new unit has a remote receiver and you can buy a remote control. The RF communication works on the 868 MHz band.

itho-rft-for-cve

Now I spent some time to reverse-engineer the schematic. All pin 1 pads are coulored blue.

ComponentList:
ANT: PCB Antenna
BAT: Battery holder CR2032 3V Lithium
C1: ?
C2: 100nF
C3: ?
C4: 100nF
C5: 600pF
C6: 100nF
C7: 600pF ?
C8: 100nF
C9: ?
C10: ?
C11: ?
C12: ?
C13: ?
C14: ?
C15: 10nF
C16: 10nF
C17: 10nF
C18: 10nF
C19: 100nF
C20: 100nF
C21: 100nF
C22: 100nF
C23: 100nF
K1: Programming connector
L1: ?
L2: ?
L3: ?
L4: ?
Q1: FDPUC (did not find it yet, probably a transistor)
Q2: SRARBF (also did not find this part yet, probably a voltage regulator)
Q3: AT MEGA169PV
Q4: CC1150
R1: 56K
R2: 1K
R3: 1K
R4: 1K
R5: 1K
R6: 100K
R7: 100M
R8: 10E
SW1..SW4: Switches
TP1..TP27: Testpoints
X1: ASN26.00A1

As you see they use a standard ATMega controller and an RF chip (TI 1150) for sending information to the other unit. On the print I also noticed a lot of TestPoints. It turns out that every netlist has been exposed by a TestPoint (except for the oscilator, antenna and bias pins). From the contoller the power of the RF chip is enabled by Q1. This is done to save power when there is no transmission needed.

Next steps is to look at the SPI signals. For that I need to connect to the following TestPoints:
TP2 or TP26: NET_GND
TP11: NET_1150_SCLK (Clock input)
TP12: NET_1150_SI (Data input)
TP13: NET_1150_GDO0
TP14: NET_1150_PWR_ENABLE
TP23: NET_1150_CSn (Chip select)
TP24: NET_1150_SO (Data output)

On the receiver side we have the following:
ATMEGA329V
TI CC1101
WTL 26.000
In the beginning I found it strange that there is a transciever on the fan unit because the remote control I have does not have the possibility to send info back. Later I received information that the new remote control units are able to send as well. That way the new generation remote controls are able to implement a stronger security regime ;-(

I already have a set of nrf905 modules from dx.com. With these I will try to decode the RF traffic generated by the remote control. I can also a sniffer to dissect the I2C protocol.

The transmitter has an Atmel mega controller and a TI CC1150. Maybe the NRF905 module isn’t the best one to start with, but I will give it a try.

3 thoughts on “Itho RF protocol dissection

  • 2017/01/25 at 21:27
    Permalink

    [quote]
    It is strange that there is a transceiver, because the remote control is not able to receive anything. Maybe the transmit functionality just is not used at all.
    [/quote]

    Maybe it is used to connect the two. I have the same remote for my Itho. Before you can use them they have to ‘learn’ each other (there is a timespan after turning on if memory serves me). I suspect that the receiver knows which remote controls it can respond to. On the other hand it just might not need it.

    Reply
    • 2017/01/26 at 09:12
      Permalink

      Hi Wrecker,

      I have changed the article from:
      “It is strange that there is a transceiver, because the remote control is not able to receive anything. Maybe the transmit functionality just is not used at all.”

      into:
      “In the beginning I found it strange that there is a transciever on the fan unit because the remote control I have does not have the possibility to send info back. Later I received information that the new remote control units are able to send as well. That way the new generation remote controls are able to implement a stronger security regime ;-(”

      Thanks for your comment !

      Reply

Leave a Reply