Protocol decoder:ook_oregon
 | |
| Name | Oregon Scientific |
|---|---|
| Description | Oregon Scientific weather sensor protocol |
| Status | supported |
| License | GPLv2+ |
| Source code | decoders/ook_oregon |
| Input | ook |
| Output | — |
| Probes | — |
| Optional probes | — |
| Options | unknown |
The ook_oregon protocol decoder takes 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 '1111'. 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. Field 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 annotation rows, 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 row 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 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:
- unknown, possible values: Unknown, Temp, Temp_Hum, Temp_Hum1, Temp_Hum_Baro, Temp_Hum_Baro1, UV, UV1, Wind, Rain, Rain1
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 ook_oregon/lists.py can be edited to include the sensorID, model number and decoding type. Please provide a patch for inclusion in the upstream sigrok decoder, thanks! Please make sure that you are extremely confident that the trace belongs to the right sensor.
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 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 and Humidity sensor model BTHR968.
$ sigrok-cli -P ook:data=D0,ook_oregon -i oregon_bthr968.sr -A ook_oregon
To decode a Manchester (default) encoded trace 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
To continuously sample what is coming in on channel D0 at 50kHz from a USBee AX PRO clone (fx2lafw) and display just the oregon decode:
$ sigrok-cli --driver fx2lafw --config samplerate=50k -C D0 -P ook:data=D0,ook_oregon --continuous -A ook_oregon
The ook_oregon decoder can optionally display the data part of the signal in hex by using the binary output switch (-B) 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.
$ sigrok-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
- Oregon weerstations met compatibele sensoren 2017 (Oregon weather stations with compatible sensors 2017). Also look at bottom of the page for "Lijst met oude modellen stations en sensoren" (List of old models stations and sensors) which lists Oregon protocol versions and what sensors use them
- Oregon Scientific Sensor Compatibility Chart with base stations
- Virtual Sensors
- Virtual v2.1 sensor using an Arduino (by Olivier Lebrun)
- Arduino os_v2_1_temp_hum_sensor library (written by deberman 2016-02-24, derived from Virtual v2.1 sensor by Olivier Lebrun)
- BTHR918N_ArduinoSender (written by Jonathan Martin, derived from Virtual v2.1 sensor by Olivier Lebrun)
- PiLight