OSV protocol3

[deennoo]

Hello,

i'm working on vairous project to add OSV protocol 3 sensor

on devices/oregon_scientific.c

line 243 you decode a thgr810 sensor and that works great !

i want to add pcr800 (rain gauge) and wgr800 (wind gauge)

actually working on PCR800 i'm facing a bad chacksum calculation.

i'm sure my problem is line 244

if (validate_os_checksum(msg, 15) == 0) {

how get 15 ?

my PCR 800 sensor message is like this :

/* PCR800 Rain Gauge Sample Data: // 0 1 2 3 4 5 6 7 8 9 A // A2 91 40 50 93 39 33 31 10 08 02 // 0 1 2 3 4 5 6 7 8 9 A B C D E F 0 1 2 3 4 5
// 10100010 10010001 01000000 01010000 10010011 00111001 00110011 00110001 00010000 00001000 00000010 // -------- ------- bbbb--- RRRRRRRR 88889999 AAAABBBB CCCCDDDD EEEEFFFF 00001111 2222CCCC cccc

// byte(0)_byte(1) = Sensor ID // bbbb = Battery indicator(7) My investigations on the anemometer would disagree here.
// After exhaustive low battery tests these bbbb bits did not change // RRRRRRRR = Rolling Code Byte // 222211110000.FFFFEEEEDDDD = Total Rain Fall (inches) // CCCCBBBB.AAAA99998888 = Current Rain Rate (inches per hour) // ccccCCCC = 1 byte Checksum cf. sum of nybbles // Message length is 20 nybbles so working in inches

Information from lostbit arduino osv3 logger

did some one can help me ?

[magellannh]

In the call to validate_os_checksum(msg, 15), the 15 is the "nibble index" where the thgr810 checksum byte starts. This index will be sensor specific, so you'll need to figure out the correct index for each sensor type. This is why that code block starts with a check of the sensor ID.

However, the bigger problem is that the framing on the message you posted seems to be off by 4 bits (one nibble). From some googling, I believe the sensor ID for the PCR800 is 0x2914 not 0xA291. I think the A in the front of the message is part of the preamble data and shouldn't have been part of the msg[] data. So msg[0] should be 0x29.

It's been a while since I wrote this code and I barely remember how it works, but there could be a bug in that framing/decode logic. This is what determines where the preamble ends and the payload starts. I only had one sensor for testing when I wrote the code and perhaps it isn't robust enough yet!

It'd be helpful to see the full output from oregon_scientific_v3_parser() with all the fprintf statements active. If you can uncomment them all and post a dump of the output, maybe we can figure out what's going wrong.

[magellannh]

This issue could also be due to the frequency or level (-l) settings not being tuned correctly.

Even if I mentally adjust the framing in the message you posted so msg[0]=0x29 and msg[1]=0x14, I can't get the checksum to validate. I think the correct checksum_nibble_idx parameter to use for this sensor type is 18, but I'm not positive. Even so, I tried manually running the checksum calculation with different values for this and I couldn't get a match with any of them.

That makes me wonder if the framing is off due to bit-errors in the message from poor reception.

It could be worth trying slightly different levels and frequencies to see if the message data changes when you do that.

[deennoo]

Your right for sensor ID, this 29 14

I got it !

message checksum is : 18

now working on wgr800 !

thank you very much for you help,

xhen all were ok, i'll publish it, i'm agree with you for the plug in system !

(but i'm a real newbie and for now my only experiance is just to copie modify and past, source from one to each other and try to get good result)

[deennoo]

facing a big probleme!

depending on web site osv3 got 2 differents name

PCR800 : 2914 or 2a19 WGR800 : 1984 or 1a89

All the exemple i got are for 2A19 & 1A89 (arduino, rfxcom)

It looks you design your code to work with 2914 or 1984

https://github.com/robwlakes/Weather-Station-OS-Sensors

this arduino sketch "DebugVersion_16_NextStep" perfectly works.

it's look like i miss the first nibble number 0 who is A

try to make nibble slide be follow the checksum advice but i got no valide result, can you help ?

[magellannh]

I don't understand what you're saying exactly. Depending on what web site?

The code isn't designed to work with 0x2914 or 0x2a19. It just tries to decode the data that's received. If a sensor sends a message with a sensor ID of 0x2914, that's what should be received if everything is working correctly. If the sensor transmits an ID of 0x2a19, the code should receive that.

It would help if you could uncomment the debug printf statements in the v3 parser routine and post the output that's produced.

Also, it could be that your RTL device isn't tuned to the exact right frequency. Each RTL-SDR device is slightly different and often you have to adjust the frequency (-f) or the level setting (-l) if you're not receiving messages correctly.

[deennoo]

just trying to help main source for 2914 or 1984

one of my favorite : http://wmrx00.sourceforge.net/Arduino/OregonScientific-RF-Protocols.pdf

My source for 2A19 or 1A89 : my best one (rfxcom decoder source) : http://cpansearch.perl.org/src/BEANZ/Device-RFXCOM-1.110800/lib/Device/RFXCOM/Decoder/Oregon.pm http://connectingstuff.net/blog/decodage-des-protocoles-oregon-scientific-sur-arduino-2/ (sorry this in french) http://domolinx10.free.fr/wiki/tiki-view_blog.php?blogId=2&offset=10 http://iut-tice.ujf-grenoble.fr/tice-espaces/GEII/jpg/wupload/File/LPRO-BAT/TP/TP2_Ethernet_lecture_donnees_meteo.pdf (sorry french again)

[magellannh]

Do you have a working setup where you can run the code and post the debug output? We should be able to see what data is received and that should help.

I don't know if the documentation conflicts are due to differences in how messages are decoded in different setups or if these are cases of oregon shipping devices that have the same model number but use different sensor IDs. I believe THGR810 devices use at least 2 different sensor IDs depending on whether they were sold standalone or as part of a kit. Maybe there are other cases of this.

I have a THGR810 and can verify that it sends 0xF824 as the device ID and that the checksum validates correctly and the temperature and humidity readings are good. So I know the code works, at least in that one case.

That doesn't mean there can't still be bugs in the code of course...

[deennoo]

I'll provid you what you need.

I know your working is good, my thgn800 is reconize, my fake thgr810 too, i can see all of my sensor with batilan And pm-cz works, and all of this without any device adjustement.

The différence is for me on the way of how the message is décoded, as i'm a beginner, i follow exemple and documentation.

[Batilan]

Another resource regarding OS sensor compatibility can be found on the site of Oregon Scientific themselves: http://www.oregonscientific.com/wcsstore/IDTStorefrontAssetStore/File/sensorchart.pdf Although I'm not sure if "compatible sensor" means that the packet structure is the same, it might also mean that the weather station is capable of receiving different packet formats. If the latter is the case then this overview is of limited use (it also doesn't contain the sensor-ID's).

Maybe it also helps to send samples using the "-m 0" or "-m 1" options so that @magellannh has more or less "raw data" (at least for "-m 1" if I'm right so the effects of level can be determined?

[deennoo]

@magellannh

please found here : what i can provid you :

https://www.dropbox.com/sh/57w87bq1ic4dc8i/AAA-yxZGHYJf3yZY8mM4flNQa?dl=0

Please explain my how to give you result with -m0 and -m 1

does ./rtl_433 -a -m 0 have to give a special result ?

[magellannh]

Still looking at this, but right away I can see a problem. The msg[] array is an array of bytes not nibbles. In your code, msg[15] is past the end of the message, which is only 10 bytes long. I believe the checksum is at msg[9].

[magellannh]

Nice work on figuring out the correct nibble index to use to get the checksum to work. So now it looks like that message has a good sensor ID and a good checksum. It's looking promising.

I don't think we need the output with -m0 and -m 1. The main OS v3 parsing seems to be ok since the message looks good and the checksum verifies.

Next, we have to find the nibbles with the windspeed info.

                   msg:  19  84  03  b0  50   c0     00      00      05    38
              byte Idx:   0  1   2   3   4    5      6       7       8     9
            In nibbles: 1 9 8 4 0 3 b 0 5 0  c 0    0  0    0  0    0  5   3
             nibbleIdx: 0 1 2 3 4 5 6 7 8 9 10 11  12  13  14  15  16  17  18

According to the OS decode doc, current wind speed is in nibbles 11..13 and average speed is in nibbles 14..16. Unfortunately, all of these nibbles are 0 in the message you posted.

The wind direction is in nibble 8, which is 5, and apparently you multiply 5*22.5 to get the wind direction in degrees (112.5 degrees?)

To extract the nibbles and assemble them into correct values, maybe something like this would work:

      float CurWindspeed = (((msg[6]>>4)*100)+((msg[5]&0x0f)*10) + ((msg[5]>>4)&0x0f)) /10.0F;
      float AvWindspeed = (((msg[8]>>4)*100)+((msg[7]&0x0f)*10) + ((msg[7]>>4)&0x0f)) /10.0F;

[deennoo]

You got it !

thank you for your help it's working.

And know with your structure information i just understand that your call msg the byte idx and not the nibble idx (like the arduino sketch)...

quadrant is 360° and divid by 16 on the weather station (wmr86), following other tips

i'll working on the pcr800

[nathanashton]

I'm using a WGR800 also and not sure that the CurWindspeed and AvWindspeed posted above are accurate. Even when the sensor is not moving I'm showing 1.2 and the average seems to go up and down quite often.

Values with the Wind sensor resting on the couch Message: 1 9 84 0e 90 00 c0 00 00 09 33 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Raw Data: 00 00 00 58 91 20 79 00 03 00 00 00 9c c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

[MartinSwanepoel]

Using a WGR800 and the direction is off by 90 % although the message string value is correct. Any ideas?

root@Oregon:~/rtl_433/build/src# ./rtl_433 Registering protocol "Silvercrest Remote Control" Registering protocol "Rubicson Temperature Sensor" Registering protocol "Prologue Temperature Sensor" Registering protocol "Waveman Switch Transmitter" Registering protocol "Steffen Switch Transmitter" Registering protocol "ELV EM 1000" Registering protocol "ELV WS 2000" Registering protocol "LaCrosse TX Temperature / Humidity Sensor" Registering protocol "Acurite 5n1 Weather Station" Registering protocol "Acurite 896 Rain Gauge" Registering protocol "Acurite Temperature and Humidity Sensor" Registering protocol "Oregon Scientific Weather Sensor" Registering protocol "Mebus 433" Registering protocol "Intertechno 433" Registering protocol "KlikAanKlikUit Wireless Switch" Registering protocol "AlectoV1 Weather Sensor" Registering protocol "Cardin S466-TX2" Registering protocol "Fine Offset Electronics, WH-2 Sensor" Registering protocol "Nexus Temperature & Humidity Sensor" Registering protocol "Ambient Weather Temperature Sensor" Found 1 device(s): 0: Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: Generic RTL2832U OEM Found Rafael Micro R820T tuner Exact sample rate is: 250000.000414 Hz [R82XX] PLL not locked! Sample rate set to 250000. Sample rate decimation set to 0. 250000->250000 Bit detection level set to 10000. Tuner gain set to Auto. Reading samples in async mode... Tuned to 433920000 Hz. Oregon Scientific v3 Sync test val ffafff00 ok, starting decode at byte index 3 bit 4 Message received from unrecognized Oregon Scientific v3 sensor. Message: ff ff ff f3 7c ff ff f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Raw: 3f ff ff af ff ff ff ce 3f ff ff c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Oregon Scientific v3 Sync test val 00589100 ok, starting decode at byte index 3 bit 4 F0 25 F1 132 F2 15 F3 48 F4 0 F5 192 F6 4 F7 0 F8 4 --------- Where is this coming from nibble 8 is 0 Message: 19 84 0f 30 00 c0 00 00 04 30 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Raw: 00 00 00 58 91 20 fc 00 03 00 00 00 2c 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Weather Sensor WGR800 Wind Gauge Gust Wind Speed : 1 m/s Wind direction 90 dgrs Oregon Scientific v3 Sync test val 00589100 ok, starting decode at byte index 3 bit 4 F0 25 F1 132 F2 15 F3 48 F4 0 F5 192 F6 4 F7 0 F8 4 Message: 19 84 0f 30 00 c0 00 00 04 30 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Raw: 00 00 00 58 91 20 fc 00 03 00 00 00 2c 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Weather Sensor WGR800 Wind Gauge Gust Wind Speed : 1 m/s Wind direction 90 dgrs Oregon Scientific v3 Sync test val 00589100 ok, starting decode at byte index 3 bit 4 F0 25 F1 132 F2 15 F3 48 F4 64 F5 192 F6 8 F7 0 F8 8 -------------- same here nibble 8 is 4 Message: 19 84 0f 30 40 c0 00 00 08 3f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Raw: 00 00 00 58 91 20 fc 02 03 00 00 00 1c f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Weather Sensor WGR800 Wind Gauge Gust Wind Speed : 0 m/s Wind direction 180 dgrs Oregon Scientific v3 Sync test val 00549800 ok, starting decode at byte index 3 bit 4 Message received from unrecognized Oregon Scientific v3 sensor. Message: 29 14 0d 50 00 00 77 88 00 04 90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Raw: 00 00 00 54 98 20 ba 00 00 0e e1 10 00 29 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Oregon Scientific v3 Sync test val 00589100 ok, starting decode at byte index 3 bit 4 F0 25 F1 132 F2 15 F3 48 F4 64 F5 192 F6 8 F7 0 F8 8 ----------------- Same here nibble is 4 Message: 19 84 0f 30 40 c0 00 00 08 3f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Raw: 00 00 00 58 91 20 fc 02 03 00 00 00 1c f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Weather Sensor WGR800 Wind Gauge Gust Wind Speed : 0 m/s Wind direction 180 dgrs Oregon Scientific v3 Sync test val 00589100 ok, starting decode at byte index 3 bit 4 F0 25 F1 132 F2 15 F3 48 F4 112 F5 192 F6 11 F7 0 F8 11 -------------- Nibble 8 = 7 Message: 19 84 0f 30 70 c0 00 00 0b 39 a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Raw: 00 00 00 58 91 20 fc 0e 03 00 00 00 dc 95 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Weather Sensor WGR800 Wind Gauge Gust Wind Speed : 1 m/s Wind direction 248 dgrs

Thanks

[magellannh]

I don't see the code that's producing the F0..F8 values in the repository. Is that extra debug code? Is it referencing nibbles or bytes? Note that F0=25 which is 0x19 (hex) and F1=132 which is 0x84 (hex). That said, the rest of the F values don't always coincide with the message data.

Also, it seems like the message data you're receiving is changing a lot. I wonder if you're having reception issues. Finally, I notice that you're getting a startup error about the PLL not being locked. I'm not sure what to make of that but it doesn't seem good.

[MartinSwanepoel]

Found the problem. Fix below:

float quadrant = ((msg[4] >> 4)&0x0f)*22.5;

Must be message 4 and not 8 and do the bitshift to get only nibbleIdx 8.

[magellannh]

Nice find and good job with the fix.

Still, based on comments by others I'm not 100% confident in the rest of the decode for this sensor type. If possible, it'd be great if you could methodically test the fixed code with varying directions and speeds and then update the code in the repository with corrections.

There seems to be a lot of confusion between byte indexing and nibble indexing. All the Oregon docs and some other Internet references refer to message formats using nibble indexing. However C code only supports byte indexing and you have to manually convert nibble references into byte references as you did correctly above. The original 8 in the code you fixed was probably an incorrectly applied nibble index.

[magellannh]

As I look at the code in the repository, the wind speed definitely isn't right with "float gustWindspeed = (msg[11]+msg[10])/100". It also seems to be confusing nibble and byte indexing.

The code I suggested several comments above might be ok, but someone with a device needs to test it and push it back into the repository if it works. Here's the suggested fix:

      float CurWindspeed = (((msg[6]>>4)*100)+((msg[5]&0x0f)*10) + ((msg[5]>>4)&0x0f)) /10.0F;
      float AvWindspeed = (((msg[8]>>4)*100)+((msg[7]&0x0f)*10) + ((msg[7]>>4)&0x0f)) /10.0F;

[MartinSwanepoel]

Tested and verified formula for wind direction in degrees on WGR800: float quadrant = ((msg[4] >> 4)&0x0f)*22.5; Use table below to change it to Cardinal direction.

N 348.75 - 11.25 NNE 11.25 - 33.75 NE 33.75 - 56.25 ENE 56.25 - 78.75 E 78.75 - 101.25 ESE 101.25 - 123.75 SE 123.75 - 146.25 SSE 146.25 - 168.75 S 68.75 - 191.25 SSW 191.25 - 213.75 SW 213.75 - 236.25 WSW 236.25 - 258.75 W 258.75 - 281.25 WNW 281.25 - 303.75 NW 303.75 - 326.25 NNW 326.25 - 348.75

Wind speed, ave speed and gust might be problematic to simulate.

[magellannh]

That's great that you did all that testing. I understand that wind speed would be tougher to verify but does it appear to basically work? In other words, when the wind is still does it report 0 and when it's blowing does it report reasonable values?

If so, perhaps you could do a pull request and contribute your fixes. It'll be great to get this into the code base so no one else has to debug it again.

[merbanan]

No sample files so nothing more can be done. The support might be there as the ticket is old. Closing issue.