Having bought a Wireless Rain Gauge from Pearl Diffusion, and since they looked alike, I was hoping that even if the model number was different, its protocol would be similar to the TFA DROP 47.3005 which is implemented/documented by rtl_433.
It turns out that they are similarities (they might come from the same factory) and also quite a few differences.
- For reference, here is the inFactory FWS-275 (aka NX-6331-675):
- And here the TFA 47.3005 (aka TFA 30.3233.01):
Looking for the data
Signal
I decoded several protocols in the past, mainly using dumps of timing on Arduino serial port. Here, the author of the TFA device's code (helped by one of the maintainers of rtl_433) gives a few clues in how to proceed rapidly in the issue associated.
rtl_433 -A
manages to collect the format of the signal and a way to display some formated information:
rtl_433 -X 'n=rain,m=OOK_PWM,s=996,l=2700,r=2684,g=0,t=0,y=7352'
The signal seems to be composed of 2700µS and 970µS pulses with 7340µS synchronisation pulses. One suprising thing is that it doesn't seem to be regular (for example long HIGH + short LOW or the opposite). It is a mix of long HIGH + short/long LOW or short HIGH + short/long LOW). But it we take into account only the HIGH side, it doesn't matter much.
Data
When decoded (PWM slicer), the first chunk is always different (values divided by 2), probably due to a shifted bit. The second and the third are almost identical, except the last byte. Best is to ignore it and see.
bitbench is another handy tool to carry on with the decoding.
Protocol
One (obvious) difference between the two gauges mentionned above is that the one I own also a outdoors temperature display, so the protocol has to transmit the value.
The 2 first bytes never change except after a change of batteries on the outdoor unit, so it is certainly a random ID.
The third byte follows the pattern 00, 02, 04, 06, 08, 0a, 0c, 0e already found in the TFA unit. Like on the TFA, bit 7 is the battery indicator (tested using a variable power supply to lower the voltage) and bit 6 a reset indicator.
The fourth and fifth bytes seem to be the counter of the bucket tips, using the same weird initial value (-10). More about it later
The sixth and seventh values are the temperature. Since, they didn't really match the Celcius display, I switched the display to Farenheit and in this case a change of value is also a change of display. This mean the transmission is in Farenheit (like in the F007TH protocol) but the encoding is diffent. After toying a bit, it appeared that the format is 16 bits Little Endian and that the value is in tenth of degrees Farenheit with an offset of 900.
Last but not least, the checksum... I was expecting something like on the TFA unit (it took me a while to understand zuckschwerdt's answers to be honnest) but after trying the referenced tools it turns out that the checksum is just that... a sum of the first 7 bytes!
All was fine... except that the main reason of this apparatus is to mesure the amount of rain, and there was not an obvious link between the counter values and the display!
Knowing that the base is 25.4mm (top of the tube on the display), it is almost certain that the mesurement is with imperial units too.
After tiping the bucket (by hand) a few hundred times, it seems that the value is 1 tip = 0.0425 in of rain. Converted in metric, this gives 1 tip = 0.108 mm.
How on earth did they managed to select this kind of value??? Well never mind...