-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TFA 30.3233.01 support #1240
Comments
Capturing the signal is indeed the first step.
Post your findings and upload a zip with some samples known to be from the device. |
I did as you suggested, placed the device very close to the pi, removed antenna of the dongle. |
It is always good to add some length of USB cable between the Raspi and the dongle. Plugged directly into the ports it will get noticable noise. |
Ok, I used an extension USB cable and tried again. |
Hi @Fietspomp86, I am also looking into this device! I have many samples and some idea how to decode. I will keep you posted. |
Hi all, I gathered some samples and loaded one into sigrok. It seems that the signal has a period of 750us. At the beginning of a period, a pulse is sent at either 250us or 500us length. The sensor sends the same message 6 times. At the beginning of each message, two sync pulses are sent: 750us high, 750us low, 750us high, 750us low. Note that the screenshot shows the beginning of the very first message, where only one sync pulse (750us hgh, 750us low) is sent. @zuckschwerdt Does this analysis make sense to you? The modulation seems to be PWM. Given this data, the following flex decoder:
produces output:
Note that the first row of len 1 is an artifact of the first sync pulse. I have already gathered many samples, including a nice rain simulation by putting the sensor under a running sink for an hour or so. I find it most intuitive to look at the data at the crumble level (two crumbles are one nibble). Here is a histogram: This shows the relative freqencies of each crumble value at a given index in the data. Note that I am adding a padding of a 0 nibble on the right. What is immediately obvious here is that the first three bytes (crumbles 0 to 11) are always identical. This is the device ID - it changes after a battery reset. The histogram above was generated from just one run, so the ID is the same. From looking at the data itself, I know that crumbles 16-19 form the LSB of the rain counter. The data is not entirely clean. I assume some sort of transformation has to be applied - but looking at the bits as they change, it is clear that lower bits roll over and higher bits increase. Interestingly, after 8 tips of the rocker, crumbles 16, 17 and 24-27 flip from 00 to 11. So 24-27 also seem to be related to the rain counter, which would give us 8 crumbles or 2 bytes to encode the rain data. I will investigate a bit more. It seems that I need to XOR crumbles 18 and 19 with |
The analysis on crumbles and the histogram is great. I have an old half-finished tool to detect change frequency, roll-over and similar. But it was a rabbit hole. It seemed I always needed to add too many assumptions. Better to just show a picture and squint your eyes ;) The unexpected double bit flip might be a parity bit. Some protocols have 7-to-8 encoding. |
@zuckschwerdt Well, I have a script which dumps only the changed crumbles. High-entropy columns are bold, low-entropy columns are light. Sadly, the output does not transport very well except as a screenshot. The leftmost column here is the number of tips of the rocker which 0000 being the initial state and 0001 the first tip. Note that some values are duplicated. It is easy to see that crumble 19 changes often, then crumble 18. It also seems obvious that I am still confued by what's happening after I was also looking at BCD, but that does not seem to be case. Perhaps some gray code or hamming code. I will check later. I also have some more data for 50, 75 and 100: |
If I read that right and |
I think I got it. You were right about flipping the bits. The missing transformation is the addition of Basically, zero is at 65526 - 9 is at 65535, and thus The following python code implement this transformation: def simple_decoder(input_data) -> int:
rain_a = input_data.get_byte_at_index(4)
lower = (rain_a.as_int() ^ 0xff)
rain_b = input_data.get_byte_at_index(6)
higher = rain_b.as_int() ^ 0xff
value = (higher << 8) + lower
value = value + 10
value = value & 0xffff
return value I will make a PR with this. Now I need to figure out two more things: the bit for low battery and the parity/checksum. Basically, I have 5 bytes out of 8.5 figured out by now. @zuckschwerdt Given that I have to invert bytes 4 and 6, it is reasonable to assume that I have to invert the entire stream? edit: Looks like the "low battery" bit is bit 24, i.e. first bit after the ID: bitbench |
@Fietspomp86 Can you try this code? #1255 |
Hmm, it seems my rainmeter has died on me. |
@Fietspomp86 Maybe you can also try to reset the batteries - maybe the devices lost sync. |
I did some work on the checksum today I noticed some interesting behavior: the sensor will repeatedly submit identical data with increasing transmission counter bits. Once the transmission counter rolls over, byte 7 is identical to previous transmissions with identical rain counter and transmission counter bits. I assume now that byte 7 is indeed the checksum. I already tried several approaches: reveng, xor of values, sum of values, two's complement etc. Nothing worked. I also tried leaving out the first nibble, as it is a fixed for all device IDs - no luck. I should note that the checksum is different for identical rain and transmission counter values across different device IDs (e.g. after battery reset). One interesting thing: the last bit of byte 7 determines the value of the first bit of byte 8: they will be identical. I have prepared several bitbenches with different device ids: @zuckschwerdt Any idea how I can proceed with the checksum? |
Looks very thorough, so nothing obvious to recommend. Not sure if revdgst (see https://triq.org/) can help. But it could be useful to quickly try some checksum ideas. Putting all of your BitBench data into a txt file and using revsum (or revdgst) shows somethings like nibble-wide parity. But that really needs some poking around to make sense of. |
One thing that might be visible in your sorted examples is too little true randomness in the checksum. It feels more like a sum (plain add with carry or xor without carry, or even some Fletcher-style sums). |
I do have to double check, but could indeed be a LFSR digest: reverse Galois with byte reflection, generator 31, key f4, final XOR c0). |
Sounds very specific already, I will be happy to do the double checking for you tomorrow :)
Am 11. Januar 2020 20:03:00 MEZ schrieb "Christian W. Zuckschwerdt" <notifications@github.com>:
…I do have to double check, but could indeed be a LFSR digest: reverse
Galois with byte reflection, generator 31, key f4, final XOR c0).
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#1240 (comment)
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
|
Interesting thing to note: LFSR digests are somewhat weaker checksums than CRC, so no reason to bother really. But a Galois digest might very well be a native feature of the used chips. So maybe the designers just went with that because it's easy. It might look like a nice security feature to novice designers but 8 bit keystreams are toys from a serious security standpoint. Even 16 bit LFSR are not too hard to crack -- revdgst was made for that and the 8 bit brute-force came with that because it takes no computational power whatsoever ;) Harder to make sense of are the botched CRC implementations in some protocols -- though when you finally see where the designers went wrong it's a great laugh :) |
You can get the keystream with |
@zuckschwerdt Now you have me a bit confused. My goal was to understand the computation of the checksum so that I can re-implement it. With my own implementation, I can compute a checksum from the message and compare with the transmitted checksum. Messages where the checksum does not match are discarded. Above, you provided the output of your
With this information, I was able to re-implement (or rather, copy&paste from your code :)) the checksum algorithm and it seems to work: https://github.com/merbanan/rtl_433/pull/1255/files#diff-0391fbab6a3dbb6c0ddbc0e5a1e7d82aR226 The code is rather heavily commented as I was trying to understand what was happening there :) Is there anything else I am missing here? What could I get from I have two more questions related to
This is now the second time where you just produced a tool that really solves my problem. Next time, I will ask directly :) The PR in #1255 should now be ready for a review! |
Oh, sorry, just rambling there. That algorithm is just one example which works in producing a stream of keys to use for each bit. The final XOR (c0) should be the fixed point that all valid codes result in. Usually we'd want a zero there but that's arbitrary. Perhaps there is a bug in revdgst and indeed it's zero here, like your code shows. The runner just tries a number of methods how the checksum could be composited and stored. E.g. each step of the checksum could be xored/added/subtracted/... and the result stored as the directly the final value/addition/substraction/... remainder. In this case it's xor, xor. |
@mhaas @zuckschwerdt can this issue be closed now? |
I bought this sensor because of the support here, but despite the update I dont get any data. |
Can you get sample data as described above?
|
Of course, here are my samples: kwenk_raindrop.zip |
Not ok? Anything else I could do? |
Looks like your samples are "too loud", the center frequency (DC) might be too close to your signal. It might help to offset e.g. 50kHz: |
Nice hint with 433.97M - I used 433.92M - worked with my different kind of temperature sensors but not with this rain sensor. With
I'm picking up my other sensors as well. Sorry for the inconvenience. |
Hi guys,
I have a new rain-sensor, the TFA 30.3233.01.
Website:
Could I please get some guidance how-to add this?
I tried capturing the raw packages but I didn't succeed.
Running a Pi3 with an RTL dongle.
I see plenty of sensors from the neighbours to it's working.
Just need some help with this new sensor.
The text was updated successfully, but these errors were encountered: