Open floe opened 6 months ago
Well researched and the conclusions are sound.
A 55
is nearly the same as aa
, just shifted by one bit.
With FSK it's likely to get some garbage bits at end.
You want to include the syncword at the end of the preamble to "anchor" it.
There are bit errors in the preamble, it is longer than it seems. And by shifting the code a few bits we can spot the common syncword of d391 d391
. Try preamble=aad391d391
, you get something like in this BitBench.
I'm seeing rtl_433's decode dropping a bit every now and again, 4 bits total over the signal, when comparing to a URH decode. I'm not sure why or how to prevent it with the flex decoder. I think the 26µ symbol width is correct.
rtl_433 -r g011_868.25M_2000k.cu8 -X n=WattsVision,m=FSK_PCM,s=26,l=26,r=500 -Y minmax
{243}55556aab4e474e445342826c4e3681ba3540301df00110200760192182c0e
URH decode, I get:
{248}aaaaaaaad391d39114d0904d89c6d03746540301df001101003b00c90c1607
(or shifted a bit to align with the start of rtl_433's decode:
{247}55555555a723a72229a1209b138da06e8ca80603be00220200760192182c0f
)
Try preamble=aad391d391, you get something like in this BitBench.
Brilliant, thank you! That would probably have taken me a while to spot the repeated sync word 😅
This works, I'll put a bunch of captures into BitBench and fiddle with them a bit to see if I can figure out the relevant fields and CRC.
I'm seeing rtl_433's decode dropping a bit every now and again, 4 bits total over the signal, when comparing to a URH decode. I'm not sure why or how to prevent it with the flex decoder. I think the 26µ symbol width is correct.
Good to know about the symbol width. Can you recommend a starting point for writing a "full" decoder? How would you work around the dropped bits?
Regarding dropped bits, I think this is a weaker signal and the gain on the recording is high. I'd try maybe using -s 1024k to collect the signal to see if that helps. I might also try positioning the transmitting device a few cm from the SDR with its antenna disconnected to see if that helps improve the signal quality.
Maybe a coincidence since I've only seen 1 sample, but, removing the prefix, the last byte might be "CRC-8/DVB-S2":
$ reveng -w 8 -s 14d0904d89c6d03746540301df001101003b00c90c1607
reveng: warning: you have only given 1 sample
reveng: warning: to reduce false positives, give 4 or more samples
width=8 poly=0xd5 init=0x00 refin=false refout=false xorout=0x00 check=0xbc residue=0x00 name="CRC-8/DVB-S2"
According to the CC110L datasheet, it does CRC-16 in hardware... but I haven't found a match with reveng
yet (awesome tool BTW).
Lower sample rate was a good idea, thanks, here's a few samples I collected with rtl_433 -g 8 -f 868.25M -s 1M -X "name=WattsVision,m=FSK_PCM,s=26,l=26,r=500,preamble=aad391d391" -Y minmax
:
14d0904d89e6d03715c10304df001100003b0010e73b58
14d0904d89c6d03745900302df001100003b00c34852fc
22d0374654c6d0904d898d0011008a02f0034b02c4cc00000
22d0374654c6d0904d898d0011018a0285034b02c6cc00000
But still no CRC matches AFAICT.
Great. It would still be useful to look at .cu8 files to verify decodings if you're able to post those as well.
Sure, here's a few captures and what I currently know about them:
[Bathroom]
14d0904d89c6d03715c10304df001101003b00111b4750 [current 22.0, target 20.0 (heating off) g001_868.25M_1000k.cu8]
14d0904d89c6d03746550307df001108003b001b7fc3280 [current 22.1, target 22.0 (heating off) g002_868.25M_1000k.cu8]
14d0904d89c6d03715c10304df001100003b0010e73b58 [current 22.2, target 22.0 g003_868.25M_1000k.cu8]
It's been trickier than expected to only capture a single sensor, because everyone in the house has the same ones and they're hardwired to a floor sensor, so you can't remove them. I'll try moving the SDR antenna around and putting it close to a sensor next.
Oh, so I just noticed that some of the messages occasionally also get decoded as Marlec-Solar!
That explains quite a bit. Now I know that the CRC is "CRC-16/CMS" according to reveng
, and also that a lot of the samples I've been capturing apparently still have bit errors, because there was no CRC match across them. Also, the first byte is a length byte, which apparently is always 0x14 for the Watts devices AFAICT.
./reveng-3.0.5/reveng -w 16 -s 14d0904d89c6d03746540301df001101003b00c90c1607 14d0904d89c6d03715c10304df001100003b0010e73b58 14d0904d89c6d03715c10304df001101003b00111b4750 14d0904d89c6d03746550307df001108003b001b7fc328
width=16 poly=0x8005 init=0xffff refin=false refout=false xorout=0x0000 check=0xaee7 residue=0x0000 name="CRC-16/CMS"
I think this should perhaps even work with a decoder { ... }
definition, is that documented anywhere in more detail?
Great work! I think the next step is to collect more labeled samples and play around with identifying the data in BitBench. Here's a start: BitBench
Since you've uncovered the CRC and are now familiar with reveng, you can make sure data points are good before adding them to the BitBench.
Here's an interesting find - the 16 bits before the CRC-16/CMS are CRC-16/MODBUS on the bits after the initial length byte.
$ reveng -w 16 -s d0904d89c6d03746540301df001101003b00c90c d0904d89c6d03715c10304df001101003b00111b d0904d89c6d03746550307df001108003b001b7f d0904d89c6d03715c10304df001100003b0010e7
width=16 poly=0x8005 init=0xffff refin=true refout=true xorout=0x0000 check=0x4b37 residue=0x0000 name="CRC-16/MODBUS"
Here's an interesting find - the 16 bits before the CRC-16/CMS are CRC-16/MODBUS on the bits after the initial length byte.
Trust issues, anyone? Seems like the CRC-CMS is done by the transceiver directly, and the CRC-MODBUS is done by the controller.
Here's a couple more captures with verified CRCs: BitBench
BTW, if I want to try and write a decoder { ... }
definition, what would I need to pick for the CRC type(s)? I've only seen one example in https://github.com/merbanan/rtl_433/issues/2582#issuecomment-1882413647 which uses CRC-16_1021_XMODEM
, so is there also something like CRC-16_8005_CMS
?
That field is just a plain output, there is no processing. Some day we might add checksum validation options to the flex decoder, but there is nothing right now.
Oh, new discovery: there's actually two message lengths, r=500
was too low. With r=1000
, I get a bunch of 0x22 length messages as well (this is from setting the target temperature to 24˚C and thereby turning on the heating):
14 d0904d89 c6 d0374654 03 01df001101003b00 c90c 1607 [good]
22 d0374654 c6 d0904d89 8d 0011018a0284034b02bfcc000000008e0a24934c0000 310d 98a4 [good]
14 d0904d89 c6 d0374654 03 01df001100003b00 c8f0 6a0f [good]
22 d0374655 c6 d0904d89 8d 0010088a02cc004b02cfcc000000008e0a24934c0000 7492 faf3 [good]
14 d0904d89 c6 d0374655 03 07df001008003b00 26bf 4eb8 [good]
I'm pretty certain that the shorter messages are sent by the thermostat, and the longer ones are from the base station. That would also correspond to the first 12 bytes being source and destination address, respectively.
AFAICT Bitbench doesn't support different format strings for different lengths, though? That makes it a bit harder to see what's going on...
P.S. I can't seem to spot anything in the data that corresponds to a sensible representation of the temperature value. 😕 The closest I've found is somewhere around offset 18 in the longer messages, but no matter what conversion factor I try, this doesn't really match the measured temperature nor the target temperature. Are there any experiences with other thermostat-type devices that also have odd value representation?
What we usually recommend is to capture data over a longer period, say a day, while the value is slowly changing and observe that -- it should be easier to spot the lowest bit then. But that is obviously only workable for outdoor-ish sensors and not for something that should mostly be fixed like your thermostat :/
@floe What's the status and plan here?
I'd agree with @zuckschwerdt that we'd need captures over a long period labeled with the temperature readings to better attempt to decode the values in the signal.
FWIW, here's a rough flex decoder I put together which may help capture what we know so far. The one for the longer messages is a guess since I don't have any samples to test it on.
decoder {
name = WattsVision_20,
modulation = FSK_PCM,
short = 26,
long = 26,
reset = 1000,
bits >= 200,
bits <= 299,
preamble = aad391d391,
get = length:@0:{8}:%d,
get = id:@8:{32}:%08x,
get = dest:@44:{32}:%08x,
get = CRC-MDB:@152:{16}:%04x,
get = CRC-CMS:@168:{16}:%04x,
}
decoder {
name = WattsVision_34,
modulation = FSK_PCM,
short = 26,
long = 26,
reset = 1000,
bits >= 309,
bits <= 600,
preamble = aad391d391,
get = length:@0:{8}:%d,
get = id:@8:{32}:%08x,
get = dest:@44:{32}:%08x,
get = CRC-MDB:@264:{16}:%04x,
get = CRC-CMS:@280:{16}:%04x,
}
$ rtl_433 -Y minmax -r g011_868.25M_2000k.cu8
@floe What's the status and plan here?
Not much at the moment TBH... completely swamped with work. Hopefully will be able to look into this again around July. Any hints/extra captures very welcome!
Hi everyone,
I'm trying to build a decoder for the Watts Vision thermostats (see bottom of post for a picture to avoid confusion with other Watts models).
I'm writing this issue both as a kind of memory aid for myself, and also to illustrate where I got stuck.
Here's what I know:
So I recorded a couple of samples with an RTL2832 SDR (Elonics E4000 tuner) and a random old DVB antenna using:
I had initially used autogain, but that apparently clipped the signal pretty badly, so I arrived at that gain setting using some trial and error.
When I upload the files to triq.org, I get (e.g.) the following signal: g011_868.25M_2000k.cu8.gz
To my untrained eye, this looks pretty much like GFSK.
After some more fiddling, I came up with a general-purpose decoder for testing (I had read in another issue that GFSK may be a bit tricky to decode and should use the minmax detector - neither auto nor classic worked).
And this is the point where I'm currently stuck on some issues (which may well be due my limited RF background knowledge):
So, am I actually going in the right direction with my approach, or am I rather barking up the entirely wrong tree?
P.S. Picture of thermostat in question: