Reverse engineering protocol of the TFA Spring weather station sensor
Not so long ago, TFA released a pretty cute weather station TFA Spring with a temperature-humidity sensor of 30.3206.02. If you want to use the sensor in your own development, for example, in a homemade clock / weather station, this article can help.
Since the weather station is relatively new, and Google does not give results on finding the protocol of this sensor, we connect the 433 MHz receiver to the oscilloscope, the oscilloscope to a computer and start exploring the protocol.
')
The oscilloscope shows that the sensor transmits 12 identical packets every 50 seconds separated by wider sync pulses, clearly visible on the oscillogram:
The period of the clock pulses is ~ 1700 uSec, the period of the sequence of data pulses is ~ 700 uSec.
Information is transmitted by the duty cycle - a short pulse means 0, a long 1.
In different packets, the duty cycle varies (but the data pulse period is constant ~ 700 uSec), so for stable decoding it is useful to take the 8 first bits of the packet, take the average pulse duration, and assume that if within one packet the pulse is shorter, it is 0, longer than 1 .
Data packets are separated by 4 wider clock pulses. The parcel is closed by 2 sync pulses, followed by a long period of silence. It is difficult to say about the beginning, because the first pulses are smeared by the receiver's AGC.
Armed with a utility for analyzing waveforms written in C #, data from the sensor are displayed at the original weather station, and we are looking for patterns for different temperature / humidity measurements.
The result is the following data arrangement in identical packets of 40 bit each:
At the end of the packet, it seems, a checksum is transmitted, but to guess the algorithm for calculating it is problematic. Therefore, if 3 or more identical packets of 12 are received, we assume that the received information is correct. By the number of identical packets, you can also assess the quality of signal reception - the more identical packets in the package, the better.
After you have more or less dealt with the decoding algorithm, we implement it on the STM32F429I Discovery debug card. This is followed by a debugging period in the fight for signal quality.
If you compare the last photo with the first one, then you can see that everything turned out, we really got the correct temperature / humidity from the sensor. The exchange protocol of an honestly purchased sensor is no longer a mystery, and the sensor may find additional use in homemade weather stations or logging systems of a smart home.
The decoding sources of the protocol of the sensor are laid out here , in fact, everything is a little more complicated than described in the publication.
The result of this work may be useful to the owners of this sensor / weather station, who want to expand the standard features, for example, by installing a localized meteorological station in the next room, while not duplicating external sensors. It should be noted that the sensor is the most time-consuming part to repeat, mainly because of the hermetic case — it is easier to buy ready-made than to do it yourself.
PS The temperature / humidity sensor is developed by TFA Dostmann, therefore the study of the protocol is limited by the hobby and completely eliminates any commercial use.
Since the weather station is relatively new, and Google does not give results on finding the protocol of this sensor, we connect the 433 MHz receiver to the oscilloscope, the oscilloscope to a computer and start exploring the protocol.
')
The oscilloscope shows that the sensor transmits 12 identical packets every 50 seconds separated by wider sync pulses, clearly visible on the oscillogram:
The period of the clock pulses is ~ 1700 uSec, the period of the sequence of data pulses is ~ 700 uSec.
Information is transmitted by the duty cycle - a short pulse means 0, a long 1.
In different packets, the duty cycle varies (but the data pulse period is constant ~ 700 uSec), so for stable decoding it is useful to take the 8 first bits of the packet, take the average pulse duration, and assume that if within one packet the pulse is shorter, it is 0, longer than 1 .
Data packets are separated by 4 wider clock pulses. The parcel is closed by 2 sync pulses, followed by a long period of silence. It is difficult to say about the beginning, because the first pulses are smeared by the receiver's AGC.
Armed with a utility for analyzing waveforms written in C #, data from the sensor are displayed at the original weather station, and we are looking for patterns for different temperature / humidity measurements.
The result is the following data arrangement in identical packets of 40 bit each:
At the end of the packet, it seems, a checksum is transmitted, but to guess the algorithm for calculating it is problematic. Therefore, if 3 or more identical packets of 12 are received, we assume that the received information is correct. By the number of identical packets, you can also assess the quality of signal reception - the more identical packets in the package, the better.
After you have more or less dealt with the decoding algorithm, we implement it on the STM32F429I Discovery debug card. This is followed by a debugging period in the fight for signal quality.
If you compare the last photo with the first one, then you can see that everything turned out, we really got the correct temperature / humidity from the sensor. The exchange protocol of an honestly purchased sensor is no longer a mystery, and the sensor may find additional use in homemade weather stations or logging systems of a smart home.
The decoding sources of the protocol of the sensor are laid out here , in fact, everything is a little more complicated than described in the publication.
The result of this work may be useful to the owners of this sensor / weather station, who want to expand the standard features, for example, by installing a localized meteorological station in the next room, while not duplicating external sensors. It should be noted that the sensor is the most time-consuming part to repeat, mainly because of the hermetic case — it is easier to buy ready-made than to do it yourself.
PS The temperature / humidity sensor is developed by TFA Dostmann, therefore the study of the protocol is limited by the hobby and completely eliminates any commercial use.
Source: https://habr.com/ru/post/275659/
All Articles