Difference between revisions of "Protocol decoder:Ook oregon"

From sigrok
Jump to navigation Jump to search
 
Line 2: Line 2:
| id              = ook_oregon
| id              = ook_oregon
| name            = Oregon Scientific
| name            = Oregon Scientific
| description    = Decodes Oregon Scientific signals for weather sensors
| description    = Oregon Scientific weather sensor protocol
| status          = possible candidate
| 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          = none
| output          = —
| probes          = none
| probes          = —
| optional_probes = —
| optional_probes = —
| options        = unknown
| options        = unknown
}}
}}


The '''ook_oregon''' protocol decoder takes '''ook''' input from the ook decoder and turns that into what the [http://store.oregonscientific.com/us/weather-stations.html Oregon Scientific] sensor is reporting.
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 ==
Line 20: Line 20:
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 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 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] 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.
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 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 '''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 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 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 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.
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:


    'id': 'unknown', 'desc': 'Unknown type is', 'default': 'Unknown', 'values': ('Unknown','Temp_Hum','Temp_Hum1','Temp','Temp_Baro','UV','UV1','Wind','Rain','Baro')
* '''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.
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.
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.
 
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:
You can show the available options with the --show command:


<pre>
$ '''sigrok-cli -P ook_oregon --show'''
$ sigrok-cli -P ook_oregon --show
</pre>


== sigrok-cli examples ==
== sigrok-cli examples ==
Line 59: Line 53:


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.
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.
<pre>
 
sigrok-cli -P ook:data=D0,ook_oregon -i oregon_bthr968.sr -A ook_oregon
$ '''sigrok-cli -P ook:data=D0,ook_oregon -i oregon_bthr968.sr -A ook_oregon'''
</pre>


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.
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.
<pre>
sigrok-cli -P ook:data=D0,ook_oregon -i oregon_pcr800.sr -A ook_oregon
</pre>


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 -P ook:data=D0,ook_oregon -i oregon_pcr800.sr -A ook_oregon'''
<pre>sigrok-cli --driver fx2lafw --config samplerate=50k -C D0 -P ook:data=D0,ook_oregon --continuous -A ook_oregon
</pre>


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.
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:
<pre>
 
sigrok-cli -P ook:data=D0,ook_oregon -B ook_oregon=data-hex -i oregon_pcr800.sr
$ '''sigrok-cli --driver fx2lafw --config samplerate=50k -C D0 -P ook:data=D0,ook_oregon --continuous -A ook_oregon'''
</pre>
 
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 ==
'''Protocol Information'''
* [http://store.oregonscientific.com/us/weather-stations.html Oregon Scientific]
* [http://www.osengr.org/WxShield/Downloads/Weather-Sensor-RF-Protocols.pdf 434MHz RF Protocol Descriptions for Wireless Weather Sensors - October 2015]
* [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'''
* '''Protocol Information'''
* [http://www.connectingstuff.net/blog/encodage-protocoles-oregon-scientific-sur-arduino/ Virtual v2.1 sensor using an Arduino] by Olivier Lebrun
** [http://store.oregonscientific.com/us/weather-stations.html Oregon Scientific]
* [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
** [http://www.osengr.org/WxShield/Downloads/Weather-Sensor-RF-Protocols.pdf 434MHz RF Protocol Descriptions for Wireless Weather Sensors - October 2015]
* [https://gist.github.com/RouquinBlanc/5cb6ff88cd02e68d48ea BTHR918N_ArduinoSender] written by Jonathan Martin, derived from Virtual v2.1 sensor by Olivier Lebrun
** [http://wmrx00.sourceforge.net/Arduino/OregonScientific-RF-Protocols.pdf Oregon Scientific RF Protocol Descriptions -June 2011] (older version)
* [https://wiki.pilight.org/oregon PiLight]
** [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 14:39, 13 October 2018

ook_oregon
Ook oregon.png
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