Open rVs21 opened 1 year ago
Everybody else doing this: please compile your data into a BitBench like this. Much easier to work with.
Interesting, there seems to be a shorter f101
and a longer e601
message and sometimers also a f102
.
But if we invert the bits we get 0efe
19fe
and 19ff
-- the bits look "too heavy" when inverted, but 0x0e=14 and 0x19=25 are the length of those messages (minus length and checksum fields).
Last two byte are a CRC-16 with poly 0x8005, but the init varies with length, so something isn't prefect.
I poked at this data a bit and couldn't find a way to get the CRC init values to align between the one used for the short messages and the one for the long messages. Using inverted bits so that the 0x0e
and 0x19
bytes indicate length is probably not a coincidence.
I did discover that the byte just before the CRC in the short messages is a parity byte. (poly=0x01
) but don't see a similar parity byte in the long messages.
$ reveng -w 16 -s 0efec1251df9dddf15853fc6f34f376cf5 0efec3251df9dddf15859fc6f34f95a339 0efec1251df9dddf15858fc6f34f875bd5 0efec3251df9dddf15851fc6f34f159c39
width=16 poly=0x8005 init=0x4ed0 refin=false refout=false xorout=0x0000 check=0x4260 residue=0x0000 name=(none)
$ reveng -c -w 16 -p 8005 -i 4ed0 -b 0efec1251df9dddf15853fc6f34f37
6cf5
$ reveng -w 8 -s 0efec1251df9dddf15853fc6f34f37 0efec3251df9dddf15859fc6f34f95 0efec1251df9dddf15858fc6f34f87 0efec3251df9dddf15851fc6f34f15
width=8 poly=0x01 init=0x10 refin=false refout=false xorout=0x00 check=0x21 residue=0x00 name=(none)
width=8 poly=0x01 init=0x08 refin=true refout=true xorout=0x00 check=0x21 residue=0x00 name=(none)
$ reveng -c -w 8 -p 01 -i 10 -b 0efec1251df9dddf15853fc6f34f
37
FWIW, here's the flex spec I'm using for these samples:
rtl_433 -Y minmax -X n=WMR500,m=FSK_PCM,s=26,l=26,r=312,invert,preamble=552c6e2c6e
These files contained recognized Oregon-THGR810 data (instead of the relevant WMR500 data):
Here's various updated bitbench views (with some manual data corrections):
All CRCs test okay:
$ reveng -w 16 -s 19fec0251df9dddf15857bc6f74fb233e980b387c90dbac3a8997272 19fec2251df9dddf1585abc6f74fb233e980b387c90dbac3a8cb5d9a 19fec0251df9dddf1585ebc6f74fb233e980b387c90dbac3a8091278 19fec2251df9dddf15853bc6f74fb223e980b387c90dbac3a8ab6bb6 19fec0251df9dddf15852bc6f74fb223e980b387c90dbac3a8594511 19fec2251df9dddf15852bc6f74fb203ea80b387c90dbac3a8ba8383 19fec0251df9dddf15859bc6f74fb203ea80b387c90dbac3a868ee2d 19fec2251df9dddf15859bc6f74fb3c3eb80b387c90dbac3a8aa7002 19fec0251df9dddf15859bc6f74fb3c3eb80b387c90dbac3a8a8bce6 19fec2251df9dddf1585fbc6f74fb393ea80b387c90dbac3a8fb54ae 19fec0251df9dddf15851bc6f74fb393ea80b387c90dbac3a8195845 19fec2251df9dddf15851bc6f74fb3939480b387c90dbac3a81d52ce 19fec0251df9dddf15851bc6f74fb3939480b387c90dbac3a81b1e31 19fec2251df9dddf15851bc6f74fb3539480b387c90dbac3a85d236f 19fec0251df9dddf15851bc6f74fb3539480b387c90dbac3a85b6f90
width=16 poly=0x8005 init=0x1a4c refin=false refout=false xorout=0x0000 check=0x6698 residue=0x0000 name=(none)
$ reveng -w 16 -s 0efec1251df9dddf1585abc6f74fa755a5 0efec3251df9dddf1585ebc6f74fe5b529 0efec1251df9dddf15853bc6f74f376d45 0efec3251df9dddf15853bc6f74f359249 0efec1251df9dddf15852bc6f74f276aa5 0efec3251df9dddf15852bc6f74f2595a9 0efec1251df9dddf15859bc6f74f975d85 0efec3251df9dddf15859bc6f74f95a289 0efec1251df9dddf15859bc6f74f975d85 0efec3251df9dddf15851bc6f74f159d89 0efec1251df9dddf15851bc6f74f176285 0efec3251df9dddf15851bc6f74f159d89 0efec1251df9dddf15851bc6f74f176285 0efec3251df9dddf15851bc6f74f159d89 0efec1251df9dddf15851bc6f74f176285
width=16 poly=0x8005 init=0x4ed0 refin=false refout=false xorout=0x0000 check=0x4260 residue=0x0000 name=(none)
Hi all, I have a wmr500 that I would also like to get connected.
Is there any data I can help to submit to aid this issue? If so what is the best method to collect and submit?
more docs/*.md
. Feel free to ask after reading if you still have questions.
This needs work by the people with the devices to move to a PR.
I took another look through all this.
The WMR500 system consists of a base unit (which only receives the RF sensor data and is also a wifi transciever) and an "All-In-One" sensor (which is what transmits the RF data we're interested in). This All-In-One sensor transmits at either 868 MHz (EU) or 915 MHz (US). The captured data provided here is at 868 MHz. Oregon Scientific WMR500 Professional All-In-One Weather Station
In the 37 provided captures, 7 were already recognized at Oregon-THGR810 data (g004, g009, g014, g019, g024, g029, g034). Typical Oregon sensor data is ASK (not the FSK we see in the other sample files) and I suspect these are from the All-In-One sensor. But are the FSK samples from this device as well? I suppose it's possible that there is a FSK transmitter for the wind and pressure data in the All-In-One, but it's strange that Oregon would use a new transmission method and protocol for this data. Oregon Scientific RF Protocol Description
Without more sample captures from other users of this device, I'm not sure how to go any further. @GardenShedDevelopments - would you be able to capture signal data from your sensor and post here?
FWIW, here's flex decoders for the FSK signals. I haven't had much luck in making sense of their data, though.
decoder {
name = Oregon_WMR500_LEN_25,
modulation = FSK_PCM,
short = 26,
long = 26,
reset = 312,
invert,
preamble = {40}552c6e2c6e,
bits >= 287,
bits <= 288,
get = LEN:@0:{8}:%d,
get = TYPE:@16:{8}:%x,
get = CRC-8005:@208:{16}:%x,
}
decoder {
name = Oregon_WMR500_LEN_14,
modulation = FSK_PCM,
short = 26,
long = 26,
reset = 312,
bits >= 199,
bits <= 200,
invert ,
preamble = {40}552c6e2c6e,
get = LEN:@0:{8}:%d,
get = TYPE:@16:{8}:%x,
get = CRC-8005:@120:{16}:%x,
}
Here are examples of using rtl_433 to decode some data posted by @rVs21:
$ rtl_433 -Y minmax -r g001_868.2M_1000k.cu8
$ rtl_433 -Y minmax -r g002_868.2M_1000k.cu8
$ rtl_433 -r g004_868.2M_1000k.cu8
Hello,
The first analysis of Christian :
It's ~25 µs PCM, not something we have seen from OS before. We get the PCM bits: {200} 55 55 55 55 A7 23 A7 23 E2 02 7D B5 C4 0C 44 41 D4 F5 4C 73 81 60 C5 1E 2C Put that in BitBench and shift one bit, now we get aaaaaaa d391 d391 f1013edae2062220ea7aa639c0b0628f16 That's a well know sync word (d391), not sure what the payload is though, too much data and very random looking.
I've uploaded some better cu8 captures and the result of rtl_433 -f 868.2M -X 'n=WMR500,m=FSK_PCM,s=25,l=25,r=3000,preamble=aad391d391' (in log.txt from 7.1°C, 59%hum to 9.9°C, 49%hum)
cu8.zip log.txt
Regards