Teardown of the "Beckett Rocket" fuel level sensor receiver.
To make the experience fit your profile, pick a username and tell us what interests you.
We found and based on your interests.
I've put together some scripting for Domoticz which converts depth and temperature readings into virtual sensors for tank full percentage and volume — compensating for fuel expansion and reporting the volume at a canonical temperature so you don't get lower readings overnight.
What I need to do next is automatically feed the data from rtl_433 into Domoticz. Some people have scripts for that, but I think Domoticz should spawn rtl_433 in its mode which outputs JSON, then just read data from its stdout.
I also need to fix the volume sensor. Currently I'm abusing a water meter sensor type, since that was the only one with the correct units (albeit misspelled). But the graphs don't do the right thing there because they plot usage as the volume increases, and we want the opposite. And we also want to plot the absolute volume over time and project when it'll hit zero — not something we have to do with a water meter.
This is probably the final short-term experiment to aid with temperature calibration. The transmitter was placed in the oven again until it reported a temperature reading of '4'. It was then placed in the same location as the previous freezer experiment, at about the same ambient temperature. Again the measurements were recorded as the unit reached room temperature, and the depth reading corresponding to each temperature reading was adjusted according to the speed of sound at the temperature we believe the unit to be reporting.
These data strongly support the hypothesis that the temperature at a given reading t is intended to be interpreted as and that the observed discrepancy between that and the measured temperatures at the high end of the range is due to experimental error or miscalibration of the temperature sensor in the unit under test. The realisation that this even makes a little bit of sense in legacy units (3°F per value) contributes to the confidence in this conclusion.
At this point we might perhaps do one more experiment, leaving it in the oven at a constant temperature for a long period of time and verifying a single set point — and comparing with other transmitter units. But since we have little use for the temperature reading anyway except to perhaps account for the expansion of fuel at high temperatures, perhaps this is good enough for now.
More calibration at higher temperatures shows a distinct non-linearity in the results. Arguably, if the temperature of the oil tank is 60°C then we probably have bigger things to worry about than precisely how much oil is in it (unless it's on fire?). But it would be good to be reasonably calibrated at least up to 30°C.
The new data were obtained by heating the transmitter (and the 1wire temperature sensor) in an electric fan oven to 65°C and then letting them cool. The oven door was kept closed so that cooling rate was relatively slow — so the fact that the unit itself has higher thermal inertia than the temperature sensor should not have too much of an effect. The unit was also disassembled, to have its circuit board exposed to the air in the oven. So although part of the resulting curve might have been due to this effect, hopefully it's not too pronounced.
The spreadsheet at http://david.woodhou.se/watchman.ods has been updated with the new data. The result of the speed-of-sound compensation is also included in the graph.
At this point, the best fit line for the temperature reading is at odds with the best fit for the speed-of-sound adjustments that the unit was observed to be making. The best fit for the latter, keeping the adjusted depth reading as consistent as possible, remains close to the calculation inferred yesterday — with a reading of 25 indicating -10°C and a reading of 17 indicating 20°C, as shown by the green line above.
A best fit for the newer temperature readings, however, makes the speed-of-sound adjustments make a lot less sense:
It's probably worth repeating the experiment to monitor how it compensates for the temperature that it perceives, as it cools down from a higher temperature.
Alternatively, we could just put an independent temperature sensor next to its installed location, and compare temperature values over a longer period of time.
The temperature reading is non-obvious, and appears to be inversely proportional to the temperature. Also, when the temperature is on the borderline between two values and is fluctuating, the depth reading appears to fluctuate with it — there is some adjustment being done according to the measured temperature. Two experiments were performed to help understand this.
Firstly, the unit was placed in the freezer at -20°C until the temperature reading became stable (at 35). It was then removed and placed in a stable location at about 18°C and roughly 250cm from a wall. The readings were monitored as it warmed up to ambient temperature.
Secondly, the unit was placed in a warm room and then the heating was turned off and the window opened. Readings were monitored overnight as the temperature dropped to 5.7°C and then rose again. The maximum and minimum ambient temperature at which each value from the sensor was seen, was charted.
Using the results of the second experiment, a chart was plotted to illustrate an estimate of the meanings of the temperature values. A good fit is achieved by assuming that 35 indicates -10°C, which is the lowest rated temperature of the system, and 17 indicates 20°C.
These assumptions are further validated by the results of the depth calibration in the first experiment. For each temperature reading, an assumed actual temperature is now available, and the speed of sound at that temperature can be calculated.
Remember, in the first experiment the ambient temperature was actually about 18°C, with the speed of sound being ~342m/s. But the unit had just been taken out of the freezer and was still warming up, so its reading of the temperature was inaccurate. To start with, it was assuming that the temperature was -8.3°C and thus the speed of sound was only 326m/s, and thus it was under-reading the distance by 5%. If we adjust for the temperature misreading, a distance of 251.46cm is obtained.
Similar calculations are seen in the table above, for each temperature value. It can be seen that the assumptions (35==-10°C, 17==20°C) give a reasonable fit for these data too, with a minimal variance between the minimum and maximum "adjusted" depth readings as the unit warmed up.
Conclusion
Given the above, it seems reasonable to conclude that the transmitter is giving a pre-adjusted depth value which already takes into account the temperature and the resulting speed of sound, and that the temperature indicated by a given temperature reading t is calculated by:
Having solved the RF part of the puzzle, we now have 8-byte data packets. As noted, byte 0 seems to be a constant 0x28 and byte 7 is a 1Wire CRC.
Bytes 1-3 are a unit ID, which changes each time you rebind the device.
Byte 4 is flags — bit 2 (0x04) seems to be the leak/theft alarm, which surprisingly is sent from the transmitter rather than inferred by the receiver. Bit 0 (0x01) is set when a magnet is held to the transmitter. We're still working out the others — it would be useful to be able to send packets and see how the receiver responds.
The top 6 bits of byte 5 indicate a temperature. We haven't fully calibrated this, but a value of 35 (decimal) seems to be -10°C while 17 is around 20°C.
The actual distance reading is 10 bits, from the low 2 bits of byte 5 along with byte 6. The value is roughly given in centimetres. The transmitter unit compensates for the fact that the speed of sound varies with temperature, to give a reading which should be relatively stable as temperature varies. A depth value of zero indicates a failed reading. The reading is quite unreliable under about 10cm.
When a magnet is held to the transmitter, bit 0 of the flags byte is set. The depth reading also switches to a countdown — which counts from 0x51 to 0x5a before the unit ID changes to a new value. The new IDs seem to be time-based, increasing every time. If the receiver receives these countdown messages with a high RSSI, within two minutes of poiwering up, it will bind to the new unit ID. The PIC in the receiver has a few bytes of EEPROM, so presumably the currently-bound unit ID is stored in there.
Support for decoding this has also been added to rtl_433, giving output as follows:
2015-12-08 20:43:29 Oil Watchman c7724c 80 17 0 137
2015-12-08 20:51:24 Oil Watchman 4ecc8c 80 23 0 57
2015-12-08 20:59:58 Oil Watchman c7724c 80 17 0 136
2015-12-08 21:23:38 Oil Watchman c7724c 80 17 0 137
2015-12-08 21:26:21 Oil Watchman 4ecc8c 80 23 0 57
2015-12-08 21:41:17 Oil Watchman c7724c 80 17 0 0
2015-12-08 21:57:17 Oil Watchman c7724c 80 17 0 136
2015-12-08 22:01:17 Oil Watchman 4ecc8c 80 23 0 57
2015-12-08 22:19:52 Oil Watchman c7724c 80 17 0 137
2015-12-08 22:22:24 Oil Watchman c7724c 81 17 80 0
The fields are unit ID (hex), flags byte (hex), temperature (decimal, raw uncalibrated value), binding countdown, depth (raw value). The latter two are of course taken from the same byte of the packet, depending on whether bit 0 of the flags byte is set. Using RTL-SDR, we've managed to listen to the transmissions of the device and decode them in software. This is the FM-demodulated waveform of one of its transmissions:
This is a Manchester encoding where high->low indicates a 0 and low->high indicates a 1, with a frame preamble of three high half-bit periods followed by three low half-bit periods, and a frame postamble which just maintains the level of the last half-bit (low for a 0, high for a 1) for a further two half-bit periods to make three. The "half-bit" period is about 1ms. The data in this particular packet are as follows:
Or 0x28 0xc6 0xd6 0x1d 0x81 0x40 0x51 0x83. The first byte is always 0x28 and might be part of the framing or packet identification. The final byte is a 1Wire CRC. We'll get to the rest later.
At this point it should be possible to configure the RFM01 or similar modules to receive the signal. Support for decoding this framing has also been added to rtl_433 which is probably easier to experiment with.
If I did my math right the SI4320 can be configured in billions of ways. So I made a big mistake here. When I removed the PIC processor from the board I damaged it, and having the arduino cycle through all possible configurations is going to take an absurd amount of time. What I think I need to do from here is buy two more of the receivers. One to use like it is supposed to so when I begin to doubt the transmitter I can verify, and the other to listen to the PIC processor (I will try soldering straight to the legs and see if I get valid data, but if this connection corrupts the communication I will cut the traces to the SI4320 and not remove the PIC) and hook it up to the arduino through SPI and capture what comes out.
I think that this will work because all of the setting commands have a defined header and are of the same length. To get this far I wrote a python script that generated the hex for all possible bit combinations for each setting. I am hoping that I can read the data from the PIC processor to the arduino, pass it to the python script, look up the value in the appropriate dictionary and finally make a working program.
As with all of the best laid plans of mice and men I have to keep my fingers crossed that I didn't make other blunders along the way and don't get receivers with different chip combinations. In the mean time I will let this board combo plug away and see if I get lucky.
So far I have communication with the SI4320 through SPI, still haven't managed to listen in on the transmitter.
Pin Out is as follows:
SI4320-------------------------------------------Arduino
1 (SDI) ---------------------------------------------- D11
2 (SCK) -------------------------------------------- D13
3 (nSEL) ------------------------------------------- D10
4 (SDO) ------------------------------------------- D12
6 (floating input when using FIFO)-------- D8 (used to tie it down)
11 (VSS) ------------------------------------------- Ground
14 (VDD) ----------------------------------------- +5vdc (2.2-5.4VDC)
Create an account to leave a comment. Already have an account? Log In.
This is a great hack. Thank you.
I have a question.
Looking at the binary interpretation of the manchester encoding
on the hack, We have
0010 1000 1100 0110 1101 0110 0001 1101 1000 0001 0100 0000 0101 0001 1000 0011
Numbering the above as bytes,
1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8
or the manchester encoding in hex
28 C6 D6 1D 81 40 51 83
The hack describes the bytes as being as follows
>>>>>> Byte 1, 2 & 3 watchman sonic Unit ID <<<<<<<
This is the unique unit ID which is reassigned each time you pair the device
>>>>>> Byte 4, flags <<<<<<<<
0001 when magnet is held to transmitter, and 0110 when leak alarm occurs.
>>>>> Byte 5 (6 bits of the 8 bits only) <<<<<<<
top 6 bits are temperature in deg C using the equation
[ -(reading x 5) + 145] / 3 = temp in degC
>>>>> Byte 5 (remaining 2 bits only & Byte 6 (all 8 bits) <<<<<<<
Depth approximately in centimetres. Temperature compensation incorporated.
Depth = 0 is a failed reading. Readings under 10cm unreliable.
QUESTION:
Using rtl_433 and linux and command
rtl_433 -d 0 -R 42 -q
I have the following output
2017-01-04 18:17:58 : Oil watchman : 28DCE63B : 80 : 26 : 5.000 : 0 : 107
1 2 3 4 5 6 7 8
I have numberred the above for convenience. This numbering does not relate to the byte acount above.
1 is obvious, 2 is obvious.
Does 28DCE63B use up 3 bytes as stated or 4, or does it incorporate the flag as described?
What is 80?
Is 26 the temperature before arithmetical conversion?
What is 5.000?
107 is the depth. I know that from moving the receiver around.
(I did a repair to the receiver and lots of watchman sonic receiver and transmitter detailed internal photos here https://1111zz.wordpress.com/2014/10/09/watchman-sonic-oil-tank-meter-failure)
I've had some similar issues and I think it is down to a different protocol. I've got something currently working using a temporary fork of rtl_433 at https://github.com/nrandell/rtl_433 (look at the proteus branch)
If you download and build it, then run the following from the build directory
src/rtl_433 -R 70 -F json
At the moment it detects the preamble, dumps the decoded buffer and parses using the standard watchman algorithm.
Try it and see!
I now think, perhaps wrongly, that the assumption that all
models of the watchman type oil sensor have the same innards, may not be
accurate.
In my case, the board is marked TEK574, and is manufactured by Tekelek Group Ltd.
Unit 118, Shannon Free Zone, Shannon, Co. Clare, Ireland, and I think this uses
a different protocol to the “normal” Watchman i.e. –R 42.
I think you are on the right track,
but
sadly, I am not a “linux” man, I am a “windows” man, and certainly not any sort
of expert user, and so I cannot act on your suggestion to compile and run your “fork”.
But, if you are placed to turn it into a Windows application, I would be more
than willing to have a go!
Hello,
I have an Apollo oil monitor sender unit. No receiver unit.
I have deployed RTL-433 exe – i.e. Windows.
I have a batch file as follows to start RTL_433.exe
____________
@echo off
cd C:\ADSB\RTL 433\Daily
rtl_433.exe -f 433900000 -g 40.2 -m 3 -p -39 -G -F json
1>fullscan.txt
pause
____________
I have also run the batch file without the –m 3 parameter.
The gain is set at 40.2, which receives a radio thermometer
in my house, as follows:
{"time" : "2016-11-01 17:17:33",
"model" : "TFA pool temperature sensor", "id" :
228, "channel" : 1, "temperature_C" : 4.100}(I put the
thermometer in the fridge to ensure that it was my thermometer & watched the
Rtl_433 output as the temperature dropped)
So, it seems to me that my dongle receiver works ok.
I have touched the Apollo with a magnet to get quick data
transmissions – the led pulses – the lcd display shows lines - But, nothing
received.
I have also deployed the magnet for a longer period, in
efforts to change the transmitter id.
Assuming that the transmitter is not faulty, can anyone give
me some pointers on how to proceed. I am also assuming that the transmitter
does not need to
I should mention that at max gain i.e. 49.6 I can pick up
the “Watchmans” below, with a constant i.e unchanged id
I am reasonably certain that they are from neighbouring
installations.
{"time" : "2016-10-30 17:00:23",
"model" : "Oil Watchman", "id" : 672018617,
"flags" : 128, "maybetemp" : 20, "temperature_C"
: 15.000, "binding_countdown" : 0, "depth" : 66}
{"time" : "2016-10-30 17:10:15",
"model" : "Oil Watchman", "id" : 138674681,
"flags" : 128, "maybetemp" : 21, "temperature_C"
: 13.333, "binding_countdown" : 0, "depth" : 29}
{"time" : "2016-10-30 17:26:19",
"model" : "Oil Watchman", "id" : 138674681,
"flags" : 128, "maybetemp" : 21, "temperature_C"
: 13.333, "binding_countdown" : 0, "depth" : 29}
{"time" : "2016-10-30 18:15:50",
"model" : "Oil Watchman", "id" : 672018617,
"flags" : 128, "maybetemp" : 20, "temperature_C"
: 15.000, "binding_countdown" : 0, "depth" : 66}
{"time" : "2016-10-30 18:30:32",
"model" : "Oil Watchman", "id" : 138674681,
"flags" : 128, "maybetemp" : 21, "temperature_C"
: 13.333, "binding_countdown" : 0, "depth" : 29}
I would keep logging with the gain turned up, to see that it is logging at regular intervals, and then run the magnet past your sending unit and see if one of the units increases the number of logs generated.
Thank you for your reply. I did as you suggested. I also removed the battery. But all was in vain. I now believe, wrongly perhaps, that in order for the sender unit to "come to life" and start transmitting, it must first be "paired" with a (manufacturer's) receiver unit. Thereafter, I assume that the transmitter will continue to broadcast independently i.e whether the receiver unit subsequently exists or not. Hopefully, I'm wrong and someone will correct me & give me some clues. Meantime, hope is fading!
I've been following this project too - recently moved into a house with oil central heating, and a Watchman Sonic oil level gauge. Although better than peering into the top of the tank every so often, I wanted something with more than 10 'blobs' of resolution!
I'm also pulling together a smarter heating controller with a RasPi, Arduino and a few DHT sensors, and perhaps some FHT8v radiator valves. Although the RTL-SDR is a great project, the computing power required looks like it will outstrip what the Pi can provide, so I hoped to use the provided receiver directly.
I started in a similar fashion to Mr Woodhouse, but managed to solder directly to the SPI pins. Reading these with the Arduino supplied what appeared to be the configuration for the Si4320 (comparing from the datasheet) but I wasn't confident enough to remove the PIC and try 'properly'. I also noticed that there was no actual data coming back from the SI4320. Tracing the connections, there was another pin connected to the PIC - pin 6. This is labeled on the Si4320 datasheet as a 'data' pin. Pin 7 is the data clock, so I soldered connections to those and listened with the 'duino. There appeared to be something on pin 6, but it took a while to catch an actual transmission from the receiver, but the data is there! It appears that the PIC sends SPI commands to configure the Si4320, but doesn't receive data over SPI. It just uses pin 6?
The data from pin 6 is quite noisy - it looks like the voltage from the aerial fed through the amplifier/schmidt trigger, but when the actual transmission comes through, it is clear, and matches the output traces from the RTL-SDR.
Thanks to your work decoding the transmitted data, it was then straight-forward to throw together some code on the 'duino to decode the data and spit it out on the serial port (although I admit my code is crappy, and only takes notice of temperature and distance - I even throw away the CRC8 byte). Despite that, it is working well, and has not yet missed a transmission (through three solid stone walls).
Arduino code is here, should anyone want it: https://github.com/mjc-506/Watchman-Arduino
Hello,
I have been following with interest your results with the watchman products.
I have bought something that looks very very similar but comes under the brand of Proteus (https://proteus-meter.com). The rtl_433 and watchman-demod do not seem to be able to decode the received signals.
rtl_433 -A returns the following output :
Detected FSK package
Analyzing pulses...
Total count: 62, width: 20066 (80.3 ms)
Pulse width distribution:
[ 0] count: 1, width: 0 [ 0; 0] ( 0 us)
[ 1] count: 45, width: 126 [124;134] ( 504 us)
[ 2] count: 15, width: 254 [253;258] (1016 us)
[ 3] count: 1, width: 527 [527;527] (2108 us)
Gap width distribution:
[ 0] count: 45, width: 127 [124;134] ( 508 us)
[ 1] count: 2, width: 384 [382;387] (1536 us)
[ 2] count: 14, width: 252 [249;257] (1008 us)
Pulse period distribution:
[ 0] count: 1, width: 124 [124;124] ( 496 us)
[ 1] count: 38, width: 253 [252;258] (1012 us)
[ 2] count: 2, width: 639 [638;640] (2556 us)
[ 3] count: 13, width: 380 [378;387] (1520 us)
[ 4] count: 7, width: 507 [506;511] (2028 us)
Level estimates [high, low]: 15969, 410
Frequency offsets [F1, F2]: 4512, -14865 (+17.2 kHz, -56.7 kHz)
Guessing modulation: No clue...
Would it be possible for someone to look if it is an easy task to decode the received signals?
If yes i can send you the gfile.data i have captured with "rtl_433 -a -t".
Let me know what you think!
The top three bits of flags don't seem to be humidity. It was believable that it was moist when it was in the freezer, and dry when it was in the oven, and just appeared to correlate with temperature. After I got bored of letting it cool down in the oven, though, I held it over a boiling kettle and then captured steam in a bowl which I placed upside-down over the transmitter. The 'flags' byte remained resolutely at 0x80.
I'm content to ignore them for now; I think we have everything we need to perform the actual function of the unit to a reasonable accuracy.
Once I've got it hooked up to something like Domoticz and working 'in anger', I can stick a real temperature sensor next to it and continue to calibrate that just by comparing logs. Eventually I suspect I'll also work out the 'low battery' indication too :)
The main thing to do is provide a way for users to configure the dimensions of their tank, so that it can give either a percentage figure (which only requires height, as is set on the DIP switches on the existing receiver), or an actual volume of oil. The current "centimetres of air" report isn't ideal from a user point of view :)
no, there is no humidity sensor in the unit (at least not the one I have), and I am guessing that the temp sensor is in the rf chip. I it would make sense that they are humidity and that it covers a wide range, because it is meant to be operated in a closed environment, and kerosene would make a 'humid' environment at relatively low temp., and the ranges can be fairly wide because humidity only has a small effect on velocity.
On the other hand, if it's humidity then it would seem to be measured in the wrong place. You want to measure it *inside* the tank not outside. And you'd want to measure the amount of fuel vapour in the air; not water.
I would also guess that te only reason it is spitting this out is for troubleshooting and to add complexity to the string, otherwise it would be fairly easy to corrupt the string and crc by the same amount, and the receiver would accept bad data as if it were good.
Not sure about that really. The CRC8 is fairly good at what it does; adding extra bits to the payload doesn't really make much difference.
It's not a problem with the crc, but if it is a noisy environment, or the receiver is at the edge of the operating distance then the data will start to get corrupted through the process of transmission. So the receiver may not be able to make sense of what it is receiving. I have had situations in a noisy environment where it was beneficial to add random numbers to the string and then calculate the crc so that if the message was corrupted then it would be less likely that the message and crc were corrupted in a way such that it looked like good data. However, you have to find a happy medium. If the environment is too noisy and you make the message too complex then you will end up having every packet fail.
Ah, OK. That makes sense. I still suspect it doesn't help much in this case — with the 8 halfbits of framing, Manchester encoding which requires a H→L or L→H transition at the right times, *and* the CRC on the decoded data, I doubt that having those three extra bits be redundant data is really any better than requiring them to be zero.
But perhaps it could explain why when they *had* three unused bits, their instinct was to put something redundant in there instead of just leaving them zero. I wouldn't give up on looking for meaning in them just yet though :)
Can you put it over a heating vent to see what the values go to when they go high?
Not heating vent, as it reaches ambient temperature much slower than the DS18B20 I'm using to compare temperatures. It needs to be in an environment with reasonably high thermal inertia so that the two are are the same temperature. Hence putting it in the oven and then letting it cool down, which seems to have worked OK.
I closed the door to the study and opened the window, and captured data overnight. Here's the rtl_433 log and the corresponding temperatures.
It was pointing at the ceiling and occasionally getting a double reading. Perhaps we can work something out about the low nybble of the flags? Maybe 0x08 means it thinks it has a stable reading, and 0x04 means leak/theft? Or 0x08 is for when the oil level *rises* fast or just when it's unstable? I'm not sure these ones work when it's in streaming mode; might need a slow test for that.
I am pretty sure that the alarm is set at -10C because that is the temperature that kerosene will gel up. So the temp measurement will probably still be correct, just a freeze alarm flag will be set. That would make sense for them to make that their rated operating range because it is effectively a solid at that point.
I stuck it in the fridge for a while at 5°C:
2015-12-08 11:32:44 Oil Watchman c7724c 88 20 0 105
Then I put it in the freezer at -20°C:
2015-12-08 11:50:03 Oil Watchman c7724c 64 29 0 99
2015-12-08 11:51:42 Oil Watchman c7724c 64 30 0 92
2015-12-08 11:58:13 Oil Watchman c7724c 68 32 0 93
2015-12-08 12:03:17 Oil Watchman c7724c 64 33 0 13
2015-12-08 12:16:00 Oil Watchman c7724c 60 35 0 52
2015-12-08 12:16:21 Oil Watchman c7724c 40 35 0 20
The speed of sound at -20°C is 319m/s, while at +20°C it's 343m/s. That's a difference of 8% on depth readings, so probably worth compensating for. Note that kerosene will expand too, by about 4% over the same temperature range — but the *transmitter* can't account for that as it only knows the depth of air, and not the full tank height.
It settled at 35, so I then got it out of the freezer and set it up about 250cm from a wall (didn't want to spend too long making it precisely located, because it warms up fast). I got these readings (averaged roughly where the reading was fluctuating e.g. between 241 and 242).
"temperature", "depth"
34, 239
33, 241.5
32, 241.5
31, 241.5
30, 241.5
29, 244
28, 244
27, 246
26, 246
25, 246
24, 246
23, 248.25
22, 248,25
21, 248.25
20, 248,25
19, 251
Now, since the unit is only rated down to -10°C, let's assume that's what a value of 35 represents. The temperature scale doesn't make much sense if that really was -20°C. Let's say for the sake of argument that 17 represents 18°C, given last night's results. I'll do some more calibration with oven and fridge (leaving it in for longer) later, but this is reasonable.
So... throw together a spreadsheet which gives resulting temperatures in °C based on those assumptions, and the speed of sound at that temperature. Multiply each depth reading from the device, by the speed of sound at 18°C (341.97 m/s) which was *actually* the temperature of the room, and divide by the speed of sound at the temperature that we think the device is sending.
For the first '34, 239' reading, that's -8.4°C, 326.07 m/s. 239*341.97/326.07 = 250.65 cm
For the last (so far) '19, 251' reading, that's 14.9°C, 340.14 m/s. 251*341.97/340.14 = 252.35 cm
The adjustment that it makes is quantised — it's returning the *same* depth values for quite a wide range of temperatures. But it *does* definitely seem to be adjusting its depth output according to the speed of sound at the temperature it measures. The 'adjusted depth' figure is fairly constant, ranging from 250.26 cm to 252.84.cm. And remember, these adjustments are only compensating for the fact that the unit has been in the freezer and it hasn't returned to ambient temperature yet. So what it *thinks* is the speed of sound, is not. In normal operation it *will* be at ambient temperature, and we don't need to screw with its readings at all. But when we do a depth calibration (rather than lazily just calling it centimetres), we should probably do it in the *middle* of one of the adjustment bands (e.g. at temperature reading 17 which should be about 17°C).
If I mess with the temperature ranges (my estimates of what the 17 and 35 readings actually mean), the results stay looking relatively sane and it still looks like it's compensating for the speed of sound. So I'm relatively happy with that conclusion even though I haven't done a *proper* temperature calibration yet.
On the receive side, I'm not sure if we should be compensating for the expansion of the fuel or not. I suppose so, if we want a consistent reading. Although you genuinely *do* have more litres of fuel in your tank at 20°C than you do at -20°C. So strictly speaking if we're going to give a volumetric output, we *shouldn't* adjust. It'd be interesting to fake some transmissions and see what the receiver unit does.
[this comment has been deleted]
Apologies, I've made the data readout from rtl_433 slightly confusing.
Byte 0 of the packet is always 0x28, and the ID is in bytes 1-3. Byte 4 is flags, and printed in hex. The top 6 bits of byte 5 are the "temperature" value, which is printed in decimal. The low two bits, along with all of byte 6, are the "depth" reading which is also printed in decimal. Byte 7 is the CRC. See https://github.com/merbanan/rtl_433/blob/master/src/devices/oil_watchman.c#L17 for the full details.
So this reading in my output above:
2015-12-08 11:50:03 Oil Watchman c7724c 64 29 0 99
... will correspond to the bytes:
28 c7 72 4c 64 74 63 xx
The low bit of the 'flags' byte is the binding flag. It's set when there's a magnet held next to the transmitted. And then byte 6 is actually the binding countdown. The flags seem to change from 0x80 to 0x60 and then 0x40 as it cooled down in the freezer, then back up to 0x80 as it warmed up. I wonder if that's actually the battery level? When it reached 0x40 the /!\ on the receiver came on. ISTR from the other day that 0x08 was the leak/theft alarm.
My full log is at http://david.woodhou.se/warmup.txt so you can see how it varied over time.
IN: 28 C7 72 4C 64 74 63 XX
0010 1000 | 1100 0111 0111 0010 0100 1100 | 0110 0100 | 0111 0100 0110 0011 |
Begin TX | Unique Identifier | FLAGS | DATA* |
(omitted) | (hex: c7724c) | (hex: 64) |
XX is the crc8
* DATA
0111 01 | 00 0110 00 11
TEMP | DEPTH
(dec:29) | (dec:99)
OUT: c7724c 64 29 0 99
Depth is at least 9 bits. Your two bits of 'BNDG' is actually the top two bits of 'DEPTH'. I've seen it go from 0xff to 0x100 and back again as I move the sensor. I've been treating it as 10 bits, although in fact I've never seen that second bit in byte 5 be set and perhaps it doesn't make sense.
OK, I misread what you wrote previously about where the binding count down was.
Also, there is this:
2015-12-08 13:54:18 Oil Watchman c7724c 61 27 80 0
2015-12-08 13:54:19 Oil Watchman c7724c 61 27 81 0
but I don't know if this is just an error.
That's the rebinding countdown. Bit 0 of the flags is set to indicate there's a magnet present, and it starts counting up from 0x50 to 0x5a. If I hold the magnet there for long enough it'll change its unit ID. I actually just wanted it to start streaming readings, instead of sending one every 35 minutes or so. You hold the magnet to it briefly and it starts streaming, then hold it again and it goes back to normal mode.
ok. I had seen several times where the flag was set, to start streaming, but this was the only place that I had seen it start counting.
Also, it looks like the ranges are
WARMING UP
40h: 28 - 35
60h: 19 - 27
80h: 11? - 19 (I don't know the upper bound)
COOLING DOWN
80h: ? - ?
60h: ? - 32
40h: 32 - 35
It looks like a fairly simple relationship, but I think it would take a controlled environment to figure out were it is switching from 40h to 60h and 60h to 80h.
I wonder if it goes to 100h for the depth reading, if that is an overflow, and flags a bad reading.
No, 0x100 isn't a bad depth reading. Remember, it can read up to 3m (300cm or 0x12c). I've seen it count not only from 0xff to 0x100, but also to 0x101 and all the way up to 0x121 at least.
Zero is a bad reading, when it can't get an echo.
No idea. I'm assuming it's something to do with the temperature?
I've just added support for the protocol to rtl_433: https://github.com/merbanan/rtl_433
It looks like there's a temperature sensor too, and the readings from that affect the depth readings. Some more investigation required. Here's a log from when I bring it in from the cold and leave it reading the *same* distance across the room as it warms up. The 19/20 figure is the temperature (at least, it *seems* to be inversely proportional to temperature), and the depth is the final number...
2015-12-07 15:04:08 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:08 Oil Watchman c7724c 80 20 0 252
2015-12-07 15:04:09 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:09 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:10 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:10 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:11 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:11 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:11 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:12 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:12 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:13 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:13 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:14 Oil Watchman c7724c 80 20 0 252
2015-12-07 15:04:14 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:15 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:15 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:15 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:16 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:16 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:17 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:17 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:18 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:19 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:19 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:19 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:20 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:20 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:21 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:21 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:22 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:22 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:23 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:23 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:23 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:24 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:24 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:25 Oil Watchman c7724c 80 20 0 252
2015-12-07 15:04:25 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:26 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:26 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:27 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:27 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:27 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:28 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:29 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:29 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:30 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:30 Oil Watchman c7724c 80 20 0 252
2015-12-07 15:04:31 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:31 Oil Watchman c7724c 80 20 0 252
2015-12-07 15:04:31 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:32 Oil Watchman c7724c 80 20 0 252
2015-12-07 15:04:32 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:33 Oil Watchman c7724c 80 20 0 252
2015-12-07 15:04:33 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:34 Oil Watchman c7724c 80 20 0 252
2015-12-07 15:04:34 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:35 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:35 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:35 Oil Watchman c7724c 80 20 0 252
2015-12-07 15:04:36 Oil Watchman c7724c 80 20 0 252
2015-12-07 15:04:36 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:37 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:37 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:38 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:38 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:39 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:39 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:40 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:40 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:41 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:41 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:42 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:42 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:43 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:43 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:43 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:44 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:44 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:45 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:45 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:46 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:46 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:47 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:47 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:47 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:48 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:48 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:49 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:49 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:50 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:51 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:51 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:51 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:52 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:52 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:53 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:53 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:54 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:54 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:55 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:55 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:55 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:56 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:56 Oil Watchman c7724c 80 20 0 251
2015-12-07 15:04:57 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:57 Oil Watchman c7724c 80 19 0 254
2015-12-07 15:04:58 Oil Watchman c7724c 80 20 0 252
2015-12-07 15:40:03 Oil Watchman c7724c 80 17 0 256
2015-12-07 16:15:47 Oil Watchman c7724c 80 17 0 257
Did you measure the distance from the ultrasonic sensor to the wall to compare the values to? And do you know what the temp was from the readings below where it read 40/41?
No, I've calibrated neither of those things yet. Here are the next few readings as I left it alone this evening:
2015-12-07 16:51:31 Oil Watchman c7724c 80 17 0 256
2015-12-07 17:27:16 Oil Watchman c7724c 80 17 0 257
2015-12-07 18:03:01 Oil Watchman c7724c 80 17 0 257
2015-12-07 18:38:46 Oil Watchman c7724c 80 17 0 257
2015-12-07 19:14:30 Oil Watchman c7724c 80 17 0 257
2015-12-07 19:50:14 Oil Watchman c7724c 80 17 0 257
2015-12-07 20:25:58 Oil Watchman c7724c 80 17 0 257
2015-12-07 21:01:42 Oil Watchman c7724c 80 17 0 257
2015-12-07 21:37:25 Oil Watchman c7724c 80 17 0 257
2015-12-07 22:13:09 Oil Watchman c7724c 80 17 0 257
2015-12-07 22:48:52 Oil Watchman c7724c 80 18 0 255
2015-12-07 23:24:35 Oil Watchman c7724c 80 18 0 255
It *definitely* seems like the transmitter is doing some adjustment of its own based on the temperature reading, but *also* sending the temperature to the receiver unit; perhaps to be used again?
At 15:04 I'd had it *on* the radiator, and it was slowly cooling down. So I can't estimate those temperatures. By 15:40 it had reached a stable reading of 17, which should be the ambient temperature of the room. The heating system says the room temperature was 20.7°C at that point. The temperature continued to be reported as 17 until 22:13, at which point the room temperature was 17.8°C. My logs say the room temperature dropped to 17.7°C at 22:55, just after the Watchman started sending a temperature value of 18.
I've put a 1wire temperature sensor right next to it on the shelf; I'll be able to get a better log as the room cools down overnight and then warms up again in the morning.
Then again, maybe it's not temperature at all — maybe it's humidity or air pressure that it's monitoring? But temperature is the biggest factor affecting the speed of sound, isn't it?
Tried to receive data with rtl_433 but without success, in debug mode I can see the signal but there's no data processing, even specifing -R 42. No issues with watchman-demod. Any suggestion?
Try a lower detection limit (-l2000). Also try hacking pulse_detect.c and reducing FSK_DEFAULT_FM_DELTA to 4000. See https://github.com/merbanan/rtl_433/issues/223 and the discussion in https://github.com/merbanan/rtl_433_tests/pull/57
And if you still can't get it working, capture the transmission with 'rtl_433 -a -t' and submit a pull request to add it to the rtl_433_tests repository.
No success by hacking pulse_detect and by lowering detection limit. Pulled request to rtl_433_tests. However thats my fork with data from two different watchman sonic unit (folder 02 and 03): https://github.com/fraschizzato/rtl_433_tests/tree/master/tests/oil_watchman
Thanks fixed now by the pull request at https://github.com/merbanan/rtl_433/pull/232— would be interesting to see if that first byte of the packet really is part of the ID, or has some other meaning.
I've updated http://david.woodhou.se/watchman-demod.c and posted replacement data to http://david.woodhou.se/watchman.txt
Turns out I had the Manchester encoding the wrong way round — zero is indicated by a transition from high to low, not the other way round. And once I fix that, I can work out the CRC, which is the 1Wire CRC8. So now my output looks like this...
28 c7 11 7b 80 40 00 (crc ok 70)
28 c7 11 7b 80 40 f2 (crc ok b8)
28 c7 11 7b 80 40 00 (crc ok 70)
28 c7 11 7b 80 40 00 (crc ok 70)
28 c7 11 7b 80 41 04 (crc ok d5)
28 c7 11 7b 80 41 03 (crc ok 56)
28 c7 11 7b 80 41 04 (crc ok d5)
That's when I was playing with getting it to read the largest distance I could. So it seems the depth reading is more than just the last (non-CRC) byte. It's at least 9 bits. Possibly 10, but in the bigger log in watchman.txt you can see at some point that a flag in bit 2 appears is changing while the I'm holding it fairly still:
28 c7 11 7b 80 44 fc (crc ok 9c)
28 c7 11 7b 80 44 fc (crc ok 9c)
28 c7 11 7b 80 44 fc (crc ok 9c)
28 c7 11 7b 80 40 fc (crc ok a7)
28 c7 11 7b 80 44 fc (crc ok 9c)
28 c7 11 7b 80 40 fc (crc ok a7)
28 c7 11 7b 80 40 fb (crc ok 24)
28 c7 11 7b 80 40 fb (crc ok 24)
So the depth reading isn't going to be more than 10 bits.
That was all done with a spare unit I'd bought from eBay for playing with (anticipating that I'd take the receiver apart again). I then switched to the real one that's installed in my tank. I found I had to do the rtl_power bit again, and found peaks at 433872,433940kHz instead of 433867,422925kHz. To make it work I had to retune:
# rtl_fm -f 433906000 | ./watchman-demod
I should fix my hack so it actually learns the high and low levels and doesn't just compare with zero — or, as was my original intention, I should use an existing decoder which can automatically adapt to both timing *and* bias variations, instead of hacking up my own. Or at this point maybe I should start playing with the RFM01 modules, which will also do all that for us.
FWIW here's some output from my other unit:
28 4e 84 b4 80 4c 37 (crc ok ba)
28 4e 84 b4 80 4c b3 (crc ok 57)
28 4e 84 b4 90 4c 00 (crc ok cd)
28 4e 84 b4 91 4c 52 (crc ok 01)
28 4e 84 b4 91 4c 52 (crc ok 01)
28 4e 84 b4 91 4c 52 (crc ok 01)
28 4e 84 b4 90 4c 00 (crc ok cd)
28 4e 84 b4 90 4c 00 (crc ok cd)
28 4e 84 b4 80 4c 64 (crc ok 83)
28 4e 84 b4 90 4c 00 (crc ok cd)
I've actually suspended the project (due to time), but my next step would be to follow the step used on decoding the Efergy Wireless Meter ( https://github.com/jdesbonnet/rtl-sdr-efergy ) and use an rpi for grab and decode data.
Probably the data transmitted is only a simple number, or a number plus a multiplier (the ping time of the ultrasonic sensor) because all the calculations are made by the receiver (using the dipswitch settings as depth reference).
Assuming that the frequency and timing is tuned by the receiver during pairing and a sensor ID is sended to the receiver (probably the first bytes that are not moving), one of the bytes can be a battery level indicator (maybe trying to under-power the sensor is a good way to check that). for the moving bytes can be usefull to have an output with a distance reference. The max measurable depth is 3 meters (from brochure) and if data is the ping time (as i assume) at a double heigth we must have the double output. Starting from about 10cm and growing 10 by 10 we can see if there's one or more multiplier bytes or not...
About the RFM01 i suggest to don't start with it because it will be another variable to tune... By working with that for other arduino based project i've found that any library needs deep changes to work on project like this (libraries are made for who wants to make both receiver and transmitter )
Another idea is to use gnuradio on linux (an rpi is perfect for this) for getting and decoding data (it has many tools for grab and decode data and any project can be exported as full working program) , actually i've made a small script for finding another device transmission (a gas meter - Urmet Easy Read) but after months I have not even found the frequency :-( , but daemon is still running.... (is a single transmission once a month, all the electronics is pretty glued and I can't broke it)...
Using rtl-sdr I'm now able to receive data using the hack at http://david.woodhou.se/watchman-demod.c
We get 8 bytes of data. The first 4 bytes seem to be a unit ID. It changes when you hold a magnet to the unit for long enough to rebind it.
The final byte is a checksum of some kind. The penultimate byte, usually, is the depth reading. Bytes 4 and 5 are flags of some kind, and will include the battery level. The low bit of byte 4 changes from 1 to 0 when you hold a magnet to it. And when you do, the penultimate byte stops being a depth reading and starts counting down from 0xaf to 0xa4, at which point the unit ID changes again.
I've posted some captured data at http://david.woodhou.se/watchman.txt
http://www.zlib.net/crc_v3.txt
I don't know if this would be useful or not, I haven't had a chance to return to this project, but I hope to take a look at your snapshots this weekend.
Doesn't seem to be a CRC8 with any possible polynomial, unless we also need to screw with bit ordering or something like that.
When byte 4 becomes 0x77 (it's normally 0x7f) the alarm goes off. Looks like the leak/theft logic is actually handled on the *transmitter* side.
Some more pictures of a Watchman Sonic receiver at https://1111zz.wordpress.com/2014/10/09/watchman-sonic-oil-tank-meter-failure/
I've just ordered a spare receiver from eBay and I'm going to try to sniff the SPI traffic passively with a Bus Pirate while it's actually working. That way, we should be able to work out the Si4320 configuration and configure our own FSK receiver to match.
fraschizzato, can you elucidate on the pairing? Am I right in thinking that it does nothing on the receiver side (there's just a static magnet behind the pairing dot), and that holding a magnet to the *sensor* causes it to start streaming data?
That implies that the sensors all have a unique(ish) ID which they include in their transmissions, and the receiver selects on it. The PIC16F630 in the receiver does have 128 bytes of EEPROM, so it can remember its pairing over a power loss. Not sure how it decides to re-pair though. Perhaps it accepts a new sensor ID only if it sees the 'pairing' transmissions before ever seeing any valid transmissions from its existing paired sensor after a power-up? Which implies that you could screw over your neighbours by sticking a magnet on your own sensor just as the power comes back after a power cut... :)
Any news about that? I'm trying to do a similiar stuff, receiving the rocket sensor rf signal with an rfm01 and arduino. Actually i've found the following information that can be usefull:
- The same electronics (sender, receiver) are used in 'Apollo Ultrasonic Sensor' and "Whatchman Sonic " (i'm using the second one), but i cannot retrieve other information
- Modulation used in transmission is FSK (my RFM01 receiver has the same SI4320 rf)
- "pairing" the sensor with the receiver starts a continous data transfer, maybe for sync, and offers a good way for testing communication (i'm using a magnet to put the sensor in "pairing mode)
- each transmission has a duration of 0.140 sec and has 140bit of data (maybe 1000-1200kbps), the first 16 bit (but i'm not shure) are the same in each transmission, so i think is a sort of header, that reduces the "data" bit to 124, probably 31 nibbles.
- transmission frequency I supposed is 433.9Mhz (in my case I have two peak at 433.87 and 433.93)
- watching radio scheme i've seen 18 peak/oscilation for bit value 0 and 86 peak for bit value 1 (probably is not a precise measurements, i've used rtl-sdr + audacity for signal view)
I hope that can help us to find a way to get sensor data
Sorry it has taken me so long to reply. I haven't looked at this again in a while, but I will hopefully pick it up again soon. I will definitely let you know if I get anything.
Become a member to follow this project and never miss any updates
This is really interesting. I have an Apollo Ultrasonic from around 2006 before Silicon Labs bought Integration associates in 2008, so the receiver chip is the IA4320. This appears to be identical to the sl4320.
However the preamble is the default for the chip (0xAA) and the bytes sent is half of the size described here. So oil_watchman.c cannot decode it.
Pics attached.
Any advice about where to start from here to get this working in rtl_433 appreciated!