Add support request for Proteus Meter Ultrasound Oil device

[anabasos]

Hello,

I would like to ask for support within the rtl_433 project for Proteus Meter Ultrasound Oil device.

The product details can be found at the following link : https://proteus-meter.com/produkte/proteus-ecometer/. The setup and output is identical to the Tekelek Group Eco monitor : http://www.tekelekgroup.com/datasheets/9-5605-01%20TEK603%20EcoOil%20Tekelek%20Installation%20Guide.pdf

I have a Rafael Micro R820T tuner and rtl_433 can detect the probe signals but cannot decode them.

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...

Detected FSK package Analyzing pulses... Total count: 62, width: 20065 (80.3 ms) Pulse width distribution: [ 0] count: 1, width: 0 [ 0; 0](0 us) [ 1] count: 45, width: 126 [124;133](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: 126 [123;133](504 us) [ 1] count: 2, width: 384 [382;387](1536 us) [ 2] count: 14, width: 253 [253;255](1012 us) Pulse period distribution: [ 0] count: 1, width: 123 [123;123](492 us) [ 1] count: 38, width: 253 [252;258](1012 us) [ 2] count: 2, width: 639 [638;640](2556 us) [ 3] count: 13, width: 380 [377;386](1520 us) [ 4] count: 7, width: 507 [506;511](2028 us) Level estimates [high, low]: 15945, 433 Frequency offsets [F1, F2]: 2939, -15720 (+11.2 kHz, -60.0 kHz) Guessing modulation: No clue...

Detected FSK package Analyzing pulses... Total count: 62, width: 20059 (80.2 ms) Pulse width distribution: [ 0] count: 1, width: 0 [ 0; 0](0 us) [ 1] count: 45, width: 126 [124;133](504 us) [ 2] count: 15, width: 253 [253;258](1012 us) [ 3] count: 1, width: 521 [521;521](2084 us) Gap width distribution: [ 0] count: 45, width: 126 [124;133](504 us) [ 1] count: 2, width: 385 [384;387](1540 us) [ 2] count: 14, width: 253 [250;257](1012 us) Pulse period distribution: [ 0] count: 1, width: 124 [124;124](496 us) [ 1] count: 38, width: 253 [252;259](1012 us) [ 2] count: 2, width: 638 [637;640](2552 us) [ 3] count: 13, width: 380 [377;387](1520 us) [ 4] count: 7, width: 507 [506;511](2028 us) Level estimates [high, low]: 15920, 439 Frequency offsets [F1, F2]: 5367, -15270 (+20.5 kHz, -58.3 kHz) Guessing modulation: No clue...

rtl_433 -a returns the following output :

p_limit: 20056 bitbuffer:: Number of rows: 0 *\ signal_start = 659679, signal_end = 699736 signal_len = 40057, pulses = 1 Distance coding: Pulse length 20056

Short distance: 1000000, long distance: 0, packet distance: 0

p_limit: 20056 bitbuffer:: Number of rows: 0 *\ signal_start = 758084, signal_end = 798141 signal_len = 40057, pulses = 1 Distance coding: Pulse length 20056

Short distance: 1000000, long distance: 0, packet distance: 0

p_limit: 20056 bitbuffer:: Number of rows: 0 *\ signal_start = 853944, signal_end = 893999 signal_len = 40055, pulses = 1 Distance coding: Pulse length 20054

Short distance: 1000000, long distance: 0, packet distance: 0

p_limit: 20054 bitbuffer:: Number of rows: 0 *\ signal_start = 952352, signal_end = 992409 signal_len = 40057, pulses = 1 Distance coding: Pulse length 20056

Short distance: 1000000, long distance: 0, packet distance: 0

I am adding some more outputs and also signal packet captures collected with 'rtl_433 -a -t'

Thank you!

Proteus.zip

[dwmw2]

So... rtl_433 -r gfile440.data -m 2 gfile440.fm and load the resulting gfile440.fm in Audacity as 16-bit signed mono PCM:

So... looks like a Manchester encoding, except that it starts with a preamble and then a three-halfbit low period? Assume that, decode the subsequent bits (hence bytes) of data. Look at the end for a CRC of some known kind. Mess with it by holding it at different distances from a solid object until you can work out the depth reading. And if it has a temperature sensor (well, it must have the sensor but doesn't necessarily need to report what it's saying) then play with it at different temperatures, etc.

[anabasos]

Thank you for this.

I have one more question : how i can easily extract the bits / bytes decoding assuming the above preamble?

I know you have done a watchman-demod C code for this but i am not sure if i can easily tweak it for the above signal?

Any other suggestions i can use? Once i get the bits equivalent of the decoding i can start playing with distances.

Thank you!

[itretail]

This device is almost certainly the same as the Apollo/Watchman sonic see this link

http://www.amazon.co.uk/Apollo-Smart-Heating-Monitor-Watchman/dp/B0087FDCZU/ref=sr_1_1?s=diy&ie=UTF8&qid=1457882370&sr=1-1&keywords=Dunraven+Systems+Ltd

So I would not be at all surprised if the Watchman Sonic settings work straight out of the box.

[anabasos]

Indeed, this is what i thought as well. However when looking at the recorded signal this does look different form the one expected by the rtl_433 Watchman Sonic module. (for example the preamble looks different) This is why the rtl_433 does not seem to be able to decode this out-of-the-box.

[itretail]

How long did you leave it with Watchman setting to get a reading, mine only transmits every 20-25 minutes, but I remember reading somewhere that you may need to wait up to 45 minutes before any output is decoded.

[anabasos]

I have left the rtl_433 running for a couple of days without success. Then in order to speed up the detection process i have triggered the 'fast transmit' mode on the sensor where it sends 3 readings per second for a period of 10 minutes. This is how i have recorded the captures attached to this ticket.

[dwmw2]

I have one more question : how i can easily extract the bits / bytes decoding assuming the above preamble?

I know you have done a watchman-demod C code for this but i am not sure if i can easily tweak it for the above signal?

Use the code in rtl433. Copy the watchman driver and create your own new one (or in the short term, just hack up the watchman one and use that)_. Tweak the bit lengths —I think you want to halve short_limit and long_limit to 500µs, and just turn reset_limit up so it doesn't trigger.

You should end up in the decode "callback" function with a bitbuffer containing the raw bits — including all the 0101010101010101011000 which we assume is the preamble, followed by the sets of 01 indicating a one data bit, or 10 indicating a zero (or vice versa).

You can start with just reducing the callback function to do nothing but call bitbuffer_print(bitbuffer). And then you can copy what we already have, searching for the preamble (0x555560 for 22 bits) and then manchester-decoding what comes next in the stream...

[itretail]

sorry ignore my comment, I jumped in without reading the whole thread.

[anabasos]

Thank you David for your advice.

After decoding the raw bitbuffer it seems the preamble pattern is 24 bit 55 55 58 [00] {158} 55 55 58 a9 6a 59 59 6a 99 5a 65 a9 96 99 6a a5 a5 55 96 3c

doing Mancester decode after bit 24 gives me a very similar output with the Watchman module where the depth measurement is stored in the penultimate 2 bytes (33 in the example below) :

[00] {64} 18 dd 85 cb 16 58 33 f6

Looks like Proteus can be easily added as a supported Oil Ultrasound Meter device.

Best regards,

[nrandell]

Has there been any progress on this? I've got a recent version of the oilpal from Dunraven. In theory it's the same as the Apollo Watchman, but looks like it uses the proteus protocol.

The raw bitbuffer looks like this [00] {158} 55 55 58 a9 55 aa 55 9a a6 95 55 a9 96 a9 a6 a9 55 55 55 fc

Decoded looks like this [00] {64} 1f 0f 42 7f 16 12 1f ff

(My device is 0x1f0f427f)

So the data is 16 12 1f

Decoding gives this: {"time" : "@0.000000s", "model" : "Oil Watchman", "id" : 521093759, "flags" : 22, "maybetemp" : 4, "temperature_C" : 41.667, "binding_countdown" : 0, "depth" : 543}

I know this is wrong as the temperature is currently close to freezing!

[dwmw2]

So hold it at different distances from a wall and see the 'depth' part of the reading change. Stick it in freezer and oven (only to 50°C or so) and see the temperature change....

[merbanan]

@nrandell "maybetemp" = 4 sounds alot like close to freezing

[merbanan]

rtl_433 -X 'n=name,m=FSK_PWM,s=508,l=1016,r=3000,g=0,t=0,y=0' can decode the provided samples.

[merbanan]

All samples decode to this: [{57}ffbddaed4576e30] with last 0 as a redundant bit.

[merbanan]

The initial issue that contained the sample file has been added to the tests repository but nothing more can be done without anyone collecting more signal samples and corresponding values from the official receiver. Closing issue.

[petercoxphoto]

I have what looks like the identical sensor to the OP - mine is branded 'Apollo Smart Meter', but the product image is the same except for the logo: https://dunravensystems.com/apollo-smart-heating-oil-energy-monitor/

I'm keen to get this working but this SDR stuff is very new to me. I'm happy to gather whatever data is needed to make this work - but I'm not sure how to go about it.

rtl_433 -S unknown does generate .cu8 files but not with any consistency. I have the meter on the desk close to the receiver and even though rtl_433 -a 4 sees a bunch of packets, -S doesn't end up writing many.

How can I set up a testing methodology to get the required samples so this can be added? I've attached some captures made with the meter sitting on the desk (so simulating tank full to overflowing!).

oil_meter_caps.zip

Thanks, Peter

[zuckschwerdt]

Looks like the sample rate is not sufficient, add -s 1000k

[petercoxphoto]

Looks like the sample rate is not sufficient, add -s 1000k

Thanks, that's very helpful. Attached is a series - I started with the monitor sitting on the desk and gradually raised it to about 1m. As I did so the LCD gauge on the meter itself showed the 'oil level' dropping to minimum.

oil_tank_new_sample_rate.zip

Thanks, Peter

[zuckschwerdt]

Yes, that now works. Use e.g. rtl_433 -X 'n=name,m=FSK_PCM,s=500,l=500,r=2000,preamble=5558' to get the MC data after what seems the preamble of 555558. Drop the codes in a BitBench, enable MC and watch the values. Looks like the depth is in byte seven, followed by a checksum.

[zuckschwerdt]

Inverted and byte reflected a CRC-8 poly 0x31, init 0x00 seems the most plausible, e.g. crc8(b, 8, 0x31, 0x00) == 0

[zuckschwerdt]

Try to find out what part of the first bytes (5a e8 5d ea 56 62) has the ID, perhaps by resetting the battery.

[zuckschwerdt]

Ok, looks like the Oil-Watchman protocol, but twice as fast and with a different preamble. Go to https://github.com/merbanan/rtl_433/blob/master/src/devices/oil_watchman.c and change:

• preamble_pattern to 0x58
• the 6 in 40 and 44 to 8
• both 1000 at the end to 500

Recompile, and it should work.

[petercoxphoto]

Fantastic! That works now. Much appreciate the quick and thorough help.

time : 2022-01-20 16:59:27 model : Oil-SonicSmart id : 5ae85dea flags : 56 maybetemp : 24 temperature_C: 8.333 binding_countdown: 0 depth_cm : 516

FYI, the 'maybetemp' variable is likely correct - it's about that temperature in my office. Not sure what 'temperature_C' refers to, but it's definitely not a current measurement.

The depth reading changes as I raise and lower the sensor, but it shows 516cm when flush with the desk. It does appear relatively accurate though, as it reads 529cm when raised 15cm.

Thanks again, Peter

[dwmw2]

FYI, the 'maybetemp' variable is likely correct - it's about that temperature in my office. Not sure what 'temperature_C' refers to, but it's definitely not a current measurement.

The 'maybetemp' is the actual bytes on the wire, which once upon a time in my decoding of this I figured was maybe the temperature in some form. The 'temperature_C' is that value converted through the formula which I empirically determined by sticking the thing in the freezer and then the oven, and also keeping it in a room at constant temperature while it warmed up and slowly adjusted its idea of the speed of sound. See the hackaday logs for the gory details. https://hackaday.io/project/1548-rocket-receiver-teardown

[zuckschwerdt]

Yes, the values seem to be different in this version of the protocol. Best to stick a bitrow_printf(b, 64, "%s: ", __func__); before the data_make and then try a few things (temperature, distance, weak battery, battery reset, sudden movement up aka leak) and note the changes.

What's the rated depth range? For 1m it went to 63, one byte will be good to 4m then.

[petercoxphoto]

Thanks David and Christian. The display that comes with the meter shows tank capacity as calculated from the dimensions of the tank. I plan to correlate the data from the radio feed to what the display shows as well. I'll post once I have something sensible to report.

Thanks again for your help getting this far.

[petercoxphoto]

Hi guys - So I installed the meter back on the tank and realized that the old meter Apollo meter which was still installed (the receiver for which had stopped working some time ago) is still reporting. So the two meters are installed side-by-side (the new one is a larger diameter, so I needed to drill a new hole for it, left the old one in rather than take it out and seal its hole).

This means we get side-by-side reporting of the same data. I added the suggested bitrow_printf() line to the code and here's what we get from both the old meter (oil_standard.c) and new (modified oil_watchman.c):

{"time" : "2022-01-22 06:31:07", "model" : "Oil-SonicStd", "id" : 62521, "flags" : 96, "alarm" : 1, "binding_countdown" : 0, "depth_cm" : 83}

oil_watchman_callback: {64} 5a e8 5d ea 17 22 4e 2d
{"time" : "2022-01-22 06:55:10", "model" : "Oil-SonicSmart", "id" : 1525177834, "flags" : 23, "maybetemp" : 8, "temperature_C" : 35.000, "binding_countdown" : 78, "depth_cm" : 0}

The tank is about 30% full at the moment and is a horizontal cylinder - the Oil-SonicStd meter is fitted slightly off-center so is pointing down slighly off vertical, and the new one is centered and vertical, but the difference is only a degree or two.

From the data, it looks like the 'binding_countdown' variable is actually the depth - the greater value the older meter is showing may be attributable to the slight diagonal it's measuring on.

[petercoxphoto]

What's the rated depth range? For 1m it went to 63, one byte will be good to 4m then.

Published spec is tanks up to 3m tall.

[petercoxphoto]

I also just measured the distance to the oil level from the top of the tank manually and it's just about 80cm.