Oregon Scientific WMR500

[rVs21]

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

[zuckschwerdt]

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.

[klohner]

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

[klohner]

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):

• g004_868.2M_1000k.cu8
• g009_868.2M_1000k.cu8
• g014_868.2M_1000k.cu8
• g019_868.2M_1000k.cu8
• g024_868.2M_1000k.cu8
• g029_868.2M_1000k.cu8
• g034_868.2M_1000k.cu8

Here's various updated bitbench views (with some manual data corrections):

• All data bitbench
• Short codes bitbench
• Long codes bitbench

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)

[GardenShedDevelopments]

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?

[gdt]

more docs/*.md. Feel free to ask after reading if you still have questions.

[gdt]

This needs work by the people with the devices to move to a PR.

[klohner]

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