Difference between revisions of "Protocol decoder:Ook oregon"
Uwe Hermann (talk | contribs) |
|||
(5 intermediate revisions by one other user not shown) | |||
Line 2: | Line 2: | ||
| id = ook_oregon | | id = ook_oregon | ||
| name = Oregon Scientific | | name = Oregon Scientific | ||
| description = | | description = Oregon Scientific weather sensor protocol | ||
| status = | | status = supported | ||
| license = GPLv2+ | | license = GPLv2+ | ||
| source_code_dir = ook_oregon | | source_code_dir = ook_oregon | ||
| image = [[File:ook_oregon.png|250px]] | | image = [[File:ook_oregon.png|250px]] | ||
| input = ook | | input = ook | ||
| output = | | output = — | ||
| probes = | | probes = — | ||
| optional_probes = — | | optional_probes = — | ||
| options = unknown | | options = unknown | ||
}} | }} | ||
The '''ook_oregon''' protocol decoder takes | The '''ook_oregon''' protocol decoder takes input from the [[Protocol decoder:ook|ook]] decoder and turns that into what the [http://store.oregonscientific.com/us/weather-stations.html Oregon Scientific] sensor is reporting. | ||
== Introduction == | == Introduction == | ||
The Oregon weather sensors use Manchester encoding to transmit their data. The v2.1 sensors use a '1010 | 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 (>= | 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 [http://www.osengr.org/WxShield/Downloads/Weather-Sensor-RF-Protocols.pdf 434MHz RF Protocol Descriptions for Wireless Weather Sensors - October 2015] | The vast majority of the information that allowed this decoders creation came from [http://www.osengr.org/WxShield/Downloads/Weather-Sensor-RF-Protocols.pdf 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 == | == Output == | ||
The '''ook_oregon''' protocol decoder provides two | 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 | 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 | 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. | Unknown sensors will be identified as '''Unknown''' and as such cannot be level2 decoded without human help. | ||
Line 36: | Line 36: | ||
== Decoder == | == Decoder == | ||
The '''ook_oregon''' decoder has one option | 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 | 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 | 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: | You can show the available options with the --show command: | ||
$ '''sigrok-cli -P ook_oregon --show''' | |||
$ sigrok-cli -P ook_oregon --show | |||
== sigrok-cli examples == | == sigrok-cli examples == | ||
Line 58: | Line 52: | ||
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. | 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 | 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= | $ '''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 == | == Resources == | ||
'''Virtual Sensors''' | * '''Protocol Information''' | ||
* [http://www.connectingstuff.net/blog/encodage-protocoles-oregon-scientific-sur-arduino/ Virtual v2.1 sensor using an Arduino] | ** [http://store.oregonscientific.com/us/weather-stations.html Oregon Scientific] | ||
* [https://github.com/deberman/OS_V2.1_temp-hum_sensor os_v2_1_temp_hum_sensor library] written by deberman 2016-02-24, derived from Virtual v2.1 sensor by Olivier Lebrun | ** [http://www.osengr.org/WxShield/Downloads/Weather-Sensor-RF-Protocols.pdf 434MHz RF Protocol Descriptions for Wireless Weather Sensors - October 2015] | ||
* [https://wiki.pilight.org/oregon PiLight] | ** [http://wmrx00.sourceforge.net/Arduino/OregonScientific-RF-Protocols.pdf Oregon Scientific RF Protocol Descriptions -June 2011] (older version) | ||
** [http://www.osengr.org/WxShield/Downloads/OregonScientific-RF-Protocols-II.pdf Oregon Scientific RF Protocol Description] (versions 1.0, 2.1, 3.0) | |||
* '''Base Station Compatability with sensors + Oregon protocol versions and what sensors use them''' | |||
** [https://weerhuisje.nl/en/e/oregon_sensoren 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 | |||
** [https://www.weathershack.com/static/osi-sensor-compatibility-chart.html Oregon Scientific Sensor Compatibility Chart] with base stations | |||
* '''Virtual Sensors''' | |||
** [http://www.connectingstuff.net/blog/encodage-protocoles-oregon-scientific-sur-arduino/ Virtual v2.1 sensor using an Arduino] (by Olivier Lebrun) | |||
** [https://github.com/deberman/OS_V2.1_temp-hum_sensor Arduino os_v2_1_temp_hum_sensor library] (written by deberman 2016-02-24, derived from Virtual v2.1 sensor by Olivier Lebrun) | |||
** [https://gist.github.com/RouquinBlanc/5cb6ff88cd02e68d48ea BTHR918N_ArduinoSender] (written by Jonathan Martin, derived from Virtual v2.1 sensor by Olivier Lebrun) | |||
** [https://wiki.pilight.org/oregon PiLight] | |||
__FORCETOC__ | __FORCETOC__ | ||
[[Category:Protocol decoder]] | [[Category:Protocol decoder]] |
Latest revision as of 13:39, 13 October 2018
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