Watchman Sonic Advanced - CRC check

[steve-burke]

After experimenting with different gains I have finally managed (in a test environment) to get regular half-hour outputs from my Watchman Sonic Advanced. However, although the message is supposed to be 192 bits long, I always get more than 192 bits (usually 194, occasionally 193). If any additional bit is a 1 (which it always is when I get 194 bits) the CRC check fails. 193 bit messages generally have a 0 bit at the end, and pass the CRC check. (I use -R234:vvv to see these results.)

Although most messages fail the CRC check, the actual contents seem fine (depth and temperature don't vary by more than expected and other values stay consistent).

Does anyone know: shouldn't the messages be truncated to 192 bits, and is it possible the additional bits are messing up the CRC checks?

Here's a typical output for one reading:

oil_watchman_advanced_decode: failed CRC check
pulse_slicer_pcm: Watchman Sonic Advanced / Plus, Tekelek codes [{194}aaaaaaaaaa2dd40e040153b5cb9066a3906a010703008c954] bits [1010 1010 1010 1010 1010 1010 1010 1010 1010 1010 0010 1101 1101 0100 0000 1110 0000 0100 0000 0001 0101 0011 1011 0101 1100 1011 1001 0000 0110 0110 1010 0011 1001 0000 0110 1010 0000 0001 0000 0111 0000 0011 0000 0000 1000 1100 1001 0101 01]

Incidentally, the status code I am getting is 0x90, and the 'version no.' is 1.7.3.0.

[ProfBoc75]

@steve-burke if you get more bits than expected is probably due to wrong timing / wrong pulse, too short , here must be around 500 us. If you are able to increase by 10 us the value (at the end of decoder, you will need to rebuild) and test ? Could be also a battery issue, no more able to respect the exact timing/ bit rate.

Can you share a sample file to let us analyze this timing with -S known option , can be confirm by -A option to see pulse values.

Another advice from the decoder documentation : use -Y minmax option could help as the modulation is GFSK, not well decoded by rtl_433.

I got more success with smaller preamble (ThermoPro sensor using also GFSK modulation), remove the 3 first byte 0xaa, keep only the 3 last byte, change PREAMBLE_SYNC_LENGTH_BITS to 16 (instead of 40).

EDIT: I confirm a bug into the decoder, the CRC is not properly calculated. When testing manually the CRC 16 for your sample, it's ok, but not from the decoder. The length is taken into account and should not.

{194}aaaaaaaaaa2dd40e040153b5cb9066a3906a010703008c954 => payload = 0x0e040153b5cb9066a3906a010703008c95
The CRC is 0x8c95, so matching.

If you test with rtl_433 -y aaaaaaaaaa2dd40e040153b5cb9066a3906a010703008c95 it works

[ProfBoc75]

@steve-burke I found the error, it's about this value, error for the "body" length:

-    static uint8_t const BODY_LENGTH_BITS          = 144;
+    static uint8_t const BODY_LENGTH_BITS          = 128;

Data Layout:

Byte position                      0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18
Sample       aa aa aa aa aa 2d d4[0e 04 01 00 25 9e 80 4f aa 60 28 01 05 03 00]25 3d
             PP PP PP PP PP SS SS[LL MM MM II II II FF TT RR rD DD VV VV VV VV]CC CC
                                    [BODY                                           ]

• PP: 40 bits of preamble, i.e. 10101010 etc.
• SS: 2 byte of 0x2dd4 - 'standard' sync word
• LL: 1 byte - message length, fixed 0x0e (14)
• MM: 2 byte - fixed 0x0401 or 0x0106 - presumably a model identifier, common at least to the devices we have tested
• II: 3 byte integer serial number - as printed on a label attached to the device itself
• FF: 1 byte status:
  • 0xC0 - during the first 20ish minutes after sync with the receiver when the device is transmitting once per second
  • 0x80 - the first one or two transmissions after the sync period when the device seems to be calibrating itself
  • 0x98 - normal, live value that you'll see on every transmission when the device is up and running
• TT: 1 byte temperature, in intervals of 0.5 degrees, offset by 0x48
• RR: 1 byte - varying bytes which could be the raw sensor reading
• r: 4 bits - varying bytes which could be the raw sensor reading
• DD: 12 bits - integer depth (i.e. the distance between the sensor and the oil in the tank)
• VV: 4 byte of 0x01050300 - constant values which could be a version number? (1.5.3.0)
• CC: 2 byte CRC-16 poly 0x8005 init 0

So BODY = Payload 14 byte + CRC 2 byte = 16 Byte = 128 bit not 144.

[ProfBoc75]

@steve-burke : I pushed the correction, I tested successfully on Watchman Sonic Advanced samples from rtl_433_test.

Update your rtl_433 with last version should correct your issue. Or wait for next nightly version.

[steve-burke]

That’s fantastic. Many thanks - I’ll give it a try.

[steve-burke]

Unfortunately this has not fixed my problem. BUT there have been more issues that could be affecting the situation.

First, I found that the Watchman receiver in the test environment had started showing the "No Echo" symbol, and indeed the regular 30 mins signals had stopped.

I got them to restart (just by slightly moving the sensor). However, the signals now seem more corrupt than I was getting yesterday. So the CRC failures could now be genuine.

Here's a signal that I'd hoped the new correction would have fixed (because it gives reasonable temperature/depth measurements):
oil_watchman_advanced_decode: failed CRC check
pulse_slicer_pcm: Watchman Sonic Advanced / Plus, Tekelek codes [{194}aaaaaaaaaa2dd40e040153b5cb9063898067010703003b308] bits [1010 1010 1010 1010 1010 1010 1010 1010 1010 1010 0010 1101 1101 0100 0000 1110 0000 0100 0000 0001 0101 0011 1011 0101 1100 1011 1001 0000 0110 0011 1000 1001 1000 0000 0110 0111 0000 0001 0000 0111 0000 0011 0000 0000 0011 1011 0011 0000 10]

There are a number of other signals that are definitely bad (with 194, 195 or 196 bits).

So I guess its back to the start: testing different gains/timings to try to improve the response. I'll also try the -S and -A options.

Incidentally, my command line is:
rtl_433 -M time:unix:usec:utc -M bits -M level -M protocol -M stats:3:300 -F mqtt://<mqtthost>:1883,user=<user>,pass=<password> -R 234:vvv -Y minmax -Y autolevel -t digital_agc=1 -g 15 -F log:rtl433.log

[ProfBoc75]

@steve-burke Back to my first remark about the bit rate and pulse. Here you have too many bit. At least 1 extra bit. Therefore the crc value is shifted by 1 bit and validation failed. So pulse width value is too small and should increased, I need samples to say how many:

{194}aaaaaaaaaa2dd40e040153b5cb906389806701070300 3b308
If you shift by 1 bit left 0x3b308 << 1 = 0x7661 = expected crc 16 value ( poly 0x8005, init 0x0000, final XOR 0x0000)

Notice that before my correction, the messages were not really valid and yet could pass the crc 16 which could explain now why less success but it's due to pulse length.

So, please share samples cu8 files to confirm my assumptions with -R 234 -S known
Drag and drop zip file with cu8 files into message here, do not rename cu8 files, the name contains metadata used to decode/replay them. I will check also the pulse on samples into rtl_433_test.

About your command line, these 2 options -Y autolevel -g 15 should not be used at the same, enter in conflict, -Y autolevel only for autogain and autolevel should work better (autogain is by default so -g 0 is not required at all). Or only -g 27 , higher gain without autolevel.

[steve-burke]

Here are 3 sample sets: g002.... with -Y autolevel (and no -g setting), g003.... with -g 15 (no autoloevel) and g006 with -g 30 (and no autolevel).

In all cases I'm guessing that the waveform is clipped. I tried analyzing with -A, and although I haven't used this before the pulse stats look a mess.

I don't know how to increase pulse width value unless I use the -X option - but doesn't this override the -R 234 decoder?

book.zip

[ProfBoc75]

@steve-burke All your 3 samples are working and are valid.

The pulse .short_width and .long_width ( short = long because of PCM) can be modified at the end of the oil_watchman_advanced.c file. But I tried to increase the pulse width without any impact, still 194 bit, as rtl_433 is robust enough to extract value at the good frequency / bit rate.

I found a workaround at the CRC validation level by adding a second control with a left shift of the CRC value.
I tested successfully on your last failing code.

I will update tomorrow the decoder with this improvement.

[ProfBoc75]

@steve-burke , if you are able to test my PR , let me know ?

[ProfBoc75]

@steve-burke , in the meantime, you may have a look at the issue #2306 , there is some useful information there, around the GFSK and pulse width. Notice from these other issue, rtl_433 decodes better when the sensor is far enough to avoid clipping signal.