Add Support for TFA 30.3307.02 Windsensor

[aZa1905]

Hi there!
I have to preface this with the following:
I have almost none experience when it comes to using Radios / Wireless-stuff. So I'm sorry in advance for not being very helpful.

I recently bought a TFA 30.3307.02 Windsensor in the hopes to have a compatibility with rtl_433. It does not, but I thought maybe someone here is so nice and would help me add support or show me how.
I have recorded some samples from that device, I'll attach them below.

To let the device start transmitting, you have to uncover the solar panel and press a small button at the bottom which triggers some kind of initialization sequence. I don't know if it has been received by rtl_433 though. After that it sent some data twice.
I don't know if that is important or not.

I'd appreciate any kind of help. And since there is already support for a lot of TFA devices I assume it shouldn't be too hard to add support? But again, I have almost zero experience with this stuff.
If any additional Info is required I will try to supply as much as possible!

TFA 30330702 windsensor.zip

[ProfBoc75]

Hi @aZa1905 ,

Do you have the WeatherHub and the weather sensor information related each capture like wind speed , wind direction ?
Without these information it's very difficult or impossible to decode the frame.

Your samples sound to be ook pwm signal , try with rtl_433 -f 868M -X "n=TFA,m=OOK_PWM,s=150,l=650,r=10000", should have something starting with lot fffff then the data related to your weather station.

[ProfBoc75]

From the Specifications
Wind speed and gust:
Measuring range: 0.3 … 50 m/s
Resolution: 0.1 m/s
Measuring range: ± 1m/s < 8m/s | ± 10% > 8m/s (wind speed only)
Wind directions: 16 (resolution 22.5°)
Transmission to gateway: every 7 minutes

Extract from the user guide, this can give some details about the expected data units and multiples.

Try to move manually the weather vane , while your licensing for data, and very slowly , you should have one data that will change from 0 to 15 , 0x0 to 0xf , they are multiples of 22.5 degrees. Usually 0 = North and value clockwise increase.

[aZa1905]

Hi @aZa1905 ,

Do you have the WeatherHub and the weather sensor information related each capture like wind speed , wind direction ? Without these information it's very difficult or impossible to decode the frame.

Your samples sound to be ook pwm signal , try with rtl_433 -f 868M -X "n=TFA,m=OOK_PWM,s=150,l=650,r=10000", should have something starting with lot fffff then the data related to your weather station.

First of all, thank you very much for answering me! :)

I unfortunately do not have the Weather hub that this thing is supposed to connect to. BUT with the command you gave me, i was able to capture some data from the windsensor:

sensor_data.txt

I titled the sections with the wind direction thingy pointed to different sides and two time me blowing at the wind-speed thing.

I'll try to find the values that changed. But I thought at least four eyes see more than just two! :)

[ProfBoc75]

Well, sounds like the signal is OOK_NRZS , source here https://github.com/baycom/tfrec , this is another SDR project, and your device 30.3307.02 sounds to be already decoded/supported.

FYI , into rtl_433, an existing device 150 Klimalogg is already using this coding, and disabled by default, you must add -R 150.

rtl_433 -f 868M -R 150

I already tried with your samples, but not decoding them. --> which is normal, based on the information I found into the tfrec project, baudrate and the sensor information are not the same.

Unfortunately, the OOK_NRZS is not supported into the flex decoding (-X ... ) , but supported by rtl_433 into a device decoder.

Since the other github project is under license GPLv2, I'm not sure if we can add it into rtl_433 ?
@merbanan @zuckschwerdt should know that.

[zuckschwerdt]

I don't see why we should not look at tfrec.

This is an interesting signal. @ProfBoc75 already did some good analysis.
It looks different than the KlimaLogg-Pro samples we have. But NRZS could be read as just PCM, then decoded later.

Use this to look into the signal: rtl_433 -w g003_868M_1000k.ook g003_868M_1000k.cu8 and live use -Y classic
Then drop the ook on https://triq.org/pdv/
The preamble is repeated 141 µs pulse + 26 µs gap, the data then is multiples of that 167 µs length. We have two symbols: 167µs pulse and 141 µs pulse + 26 µs gap. This does not feel like NRZ(S).
The pulse length encodes the number of 1's and each gap is a 0:

• 141 -> 0
• 308 (167*1+141) -> 10
• 475 (167*2+141) -> 110
• 641 (167*3+141) -> 1110
• 821 (167*4+141) -> 11110
• 1308 (167*7+141) -> 11111110
• 1641 (167*9+141) -> 1111111110

Not sure how to slice this as 167 is not an integer multiple of 26.
PCM 28 might work. Then we get a symbol as 6 raw bits, either 111111 or 111110.

rtl_433 -R 0 -Y classic -X 'n=name,m=OOK_PCM,s=28,l=28,r=50' g003_868M_1000k.cu8for the raw bits, then for the parsed symbols rtl_433 -R 0 -Y classic -X 'n=name,m=OOK_PCM,s=28,l=28,r=50,symbol_zero={6}3e,symbol_one={6}3f' -- but that does not work because the 111111 symbols can't be aligned.

Worst case we might need a new slicer for this. But we should first try PCM 28 and a custom decoder with the above bit extraction.

[ProfBoc75]

Hi @zuckschwerdt , you lost me, I don't have same pulse duration.

From my side, I saw that the signal is always high level, with "negative" pulse to ground.
For example, during the preamble, this negative pulse are all 104 µs , then high level for 560 µs, then negative pulse for 104 µs, and so on. And for me negative pulse = 1, if no negative pulse after 560 µs and stay at high level, this means 0, so every 664 µs we should have 1 or 0 value , depends on the negative pulse is present or not. Later we can invert the values to decode if necessary.

Extract of the signal end of preamble, beginning of data :

[zuckschwerdt]

You need to account for the 1000k sample rate (4x the 250k default). So 104 µs -> 26 µs, 560 -> 141 µs, …
Everything else you say is correct!

[ProfBoc75]

Now I better understand the baudrate to 6000 bps, with my mistake it was 1.5 K , so x 4 = 6K bps. more aligned...

[zuckschwerdt]

Yes, we get a symbol each 167 µs = 6000 baud. But we need to sample much faster because most of every symbol is always pulse. This is a terrible code, they could have used PWM or PPM :/

[merbanan]

-Y classic should not be a property of OOK decoding. Am I missing something ?

[zuckschwerdt]

:) classic/minmax is the level discriminator, that's part of the OOK decision.

[merbanan]

I think the positive symbol is 166us of high and the negative symbol is 26us of low and then 140 us of high.

If we assume it actually is 168us and 24+144us we get even pcm slicing bits for a symbol. A symbol would then be 7 bits long. A pos-symbol would then be 1111111 and a negative symbol would then be 0111111. The bit recovery will have handle long runs of positive symbols but as long as we are lax with the amount of 1's before a starting negative symbol we will be able to keep sync and recover the bits properly.

Example follows:

0111111 1111111 1111111 111111X 0111111
      0       1       1       1       0

In this example we are missing the last 1 bit at the X-position. But we know that it has been lost because we dont sample at an optimal rate. We can afford to loose up to 6 bits before we loose sync and miss a bit.

When checking g003_868M_1000k.cu8 I found a run of 10 symbols with length 1667us.

1667 / 26 = 64,11 -> 64 / 7 = 9 and 1 residual
1667 / 25 = 66,68 -> 66 / 7 = 9 and 3 residual
1667 / 24 = 69,41 -> 69 / 7 = 9 and 6 residual

So if we slice with 24us it looks like we loose less then 1 pcm slice every 10 symbols. There are some other details regarding transitions from the low level to high level that might impact but 24us looks like a promising value.

[zuckschwerdt]

Yes, 24 µs and 28 µs have low deviation for a width of 7 or 6: 167/28 = 5.964 and 167/24 = 6.958 -- I had preferred 28 µs because four symbols of 6 align to three bytes :)

[merbanan]

We still need to implement a bit reader as parser to be able to handle long runs of symbols that causes bit drops. Or can we find a better value that could be used?

After some tests I think that 24 and 28 are the best candidates. One of the values are better then the other...