Protocol decoder:ook_oregon

From sigrok
Revision as of 19:56, 17 June 2018 by SteveR (talk | contribs)
Jump to navigation Jump to search
ook_oregon
Ook oregon.png
Name Oregon Scientific
Description Decodes Oregon Scientific signals for weather sensors
Status possible candidate
License GPLv2+
Source code decoders/ook_oregon
Input ook
Output none
Probes none
Optional probes
Options unknown

The ook_oregon protocol decoder takes ook input from the ook decoder and turns that into what the Oregon Scientific sensor is reporting.

Introduction

The Oregon weather sensors use Manchester encoding to transmit their data. The v2.1 sensors use a '1010 ...' preamble while the v3 sensors use a '1111 ...' preamble. The v2.1 sensors send two copies of all the bits which means the packets are longer.

The decoder should decode Oregon v1, v2.1 and v3 sensors but has only been tested on virtual v2.1 and real v3. v1 and v2.1 traces from real hardware would be welcomed by the author and/or the sigrok developers (on IRC or mailing list) to allow some additional testing (>= 50Khz sample rate please).

The vast majority of the information that allowed this decoders creation came from 434MHz RF Protocol Descriptions for Wireless Weather Sensors - October 2015 Fields names follow its naming conventions and the list of model numbers and SensorID codes has been used to allow model number lookup. The additional information on what fields are used for what provides the information to carry out the rest of the level2 decode.

Output

The ook_oregon protocol decoder provides two lines of decode, the first one does a basic decode and identification of the version while the second looks at the decoded SensorID and then picks out particular nibbles and turns them into a human readable results.

The first line identifies which version is being received by looking for a particular sync pattern. Once the Sync pattern is found the Preamble and Sync bits are marked and stripped off. All the remaining data is then interpreted as sets of 4 bit Nibbles with all bits reversed (except SensorID). There are then some common fields for v2.1 and v3 sensors which are RollingCode, Channel, RollingCode and Flags1. Finally it prints out the remaining nibbles which are the sensor payload as hex digits without interpreting them.

The level2 decode takes things a bit further by using the SensorID and a lookup table in ook_oregon/lists.py to display the model numbers that use that SensorID. It then looks up the type of sensor from the same list and then adds in fields for Temperature, Humidity, UV level, Rainfall, Wind speed and Barometric pressure. Results depends on what the sensor produces and whether it is recognised.

Unknown sensors will be identified as Unknown and as such cannot be level2 decoded without human help.

Decoder

The ook_oregon decoder has one option

   'id': 'unknown', 'desc': 'Unknown type is', 'default': 'Unknown', 'values': ('Unknown','Temp_Hum','Temp_Hum1','Temp','Temp_Baro','UV','UV1','Wind','Rain','Baro')

This option allows the user to pick what type of sensor that they think the Unknown one is and see the level2 decode for that choice. This is designed to allow them to try the options and see if they can get a meaningful decode out.

If it does work then the ook_oregon/lists.py can be edited to include the sensorID, model number and decoding type. Please make sure that you are extremely confident that the trace belongs to the right sensor. The format is documented in the file. Please be very careful with the syntax and take a backup before editing it. Restarting Sigrok after this should convert the sensorID into a model number and do the decoding.

Sending the author a copy of the extra or edited line in ook_oregon/lists.py might allow the list to grow over time, email address is at the top of the file. Response time will vary dramatically, no guarantees of inclusion. Alternatively a patch to the ook_oregon decoder could also get your device more universally recognised.

New decoding types can be added if needed, example trace + model info plus reading at the time (from a weather base station) required. Or submit a code patch + trace for the sigrok dumps, model info plus reading at the time in the readme.

You can show the available options with the --show command:

$ sigrok-cli -P ook_oregon --show

sigrok-cli examples

The ook_oregon decoder concentrates on the protocol and not how it is transmitted so it needs the ook decoder to deal with the Manchester encoding before it can do its work. It stacks on top of the ook decoder.

To decode a Manchester (default) encoded trace with a preamble starting 1010 (Oregon V2.1 sensor) and then pass the result to the ook_oregon decoder and only display the ook_oregon output. The trace belongs to a virtual Oregon v2.1 Temperature sensor model THGR228N.

sigrok-cli -P ook:data=D1:preamble='1010 ...',ook_oregon -i thgr228n.sr -A ook_oregon

To decode a Manchester (default) encoded trace with a preamble starting 1111 (default) (Oregon V3 sensor) and then pass the result to the ook_oregon decoder and only display the ook_oregon output. The trace belongs to a real Oregon v3 rain sensor model PCR800.

sigrok-cli -P ook:data=D0,ook_oregon -i oregon_pcr800.sr -A ook_oregon

The ook_oregon decoder can optionally display the data part of the signal in hex by using the Binary output switch with an option called "data-hex". The hex can then be compared to other information on the web or saved in the lists.py file from ook_gen.

igrok-cli -P ook:data=D0,ook_oregon -B ook_oregon=data-hex -i oregon_pcr800.sr

Resources

Protocol Information

Base Station Compatability with sensors + Oregon protocol versions and what sensors use them

Virtual Sensors