Protocol decoder:Rc encode

2018-06-17T18:40:08Z

SteveR: Created page with "{{Infobox protocol decoder | id = rc_encode | name = RC Encode | description = Remote Control Encode. | status = supported | license..."

{{Infobox protocol decoder
| id = rc_encode
| name = RC Encode
| description = Remote Control Encode.
| status = supported
| license = GPLv2+
| source_code_dir = rc_encode
| image = [[File:rc_encode.png|250px]]
| input = logic
| output = none
| probes = data
| optional_probes = none
| options = remote;
}}

The '''rc_encode''' protocol decoder can decode the remote control protocol which is frequently used within key fobs and power socket remotes.

== Decoder ==

They contain encoding chips like the [http://www.princeton.com.tw Princeton Technology Corp] PT2262 which converts the button pressed and address settings into a series of pulses which is then transmitted over whatever frequency and modulation that the designer chooses. These devices operate at a number of frequencies including 433MHz.

This PD should also decode the HX2262 and SC5262 which are equivalents.

The decoder also contains some optional additional decoding for a Maplin L95AR remote control and will turn the received signal into which button was pressed and what the address code DIP switches are set to.
== Resources ==

* [http://www.princeton.com.tw/Portals/0/Product/PT2260_s.pdf PT2260]

[[Category:Protocol decoder]]
[[Category:Wireless]]

File:Ook vis.png

2018-06-17T18:37:59Z

SteveR:

Protocol decoder:Ook vis

2018-06-17T18:37:40Z

SteveR: Created page with "{{Infobox protocol decoder | id = ook_vis | name = OOK Visualiser | description = On Off Keying Visualiser | status = supported | license..."

{{Infobox protocol decoder
| id = ook_vis
| name = OOK Visualiser
| description = On Off Keying Visualiser
| status = supported
| license = GPLv2+
| source_code_dir = ook_vis
| image = [[File:ook_vis.png|250px]]
| input = ook
| output = ook
| probes = none
| optional_probes = —
| options = unknown
}}

The '''ook_vis''' protocol decoder takes '''ook''' input from the ook decoder and displays it in a variety of formats.

It is provided to help analyse unknown format waveforms. Using the ook decoder with this one allows you to try '''NRZ''', '''Manchester''' and '''Differential Manchester''' and their possible settings to see what produces the lowest errors. Then use ook_vis to format the results in a suitable fashion for what you are decoding, make some structure assumptions and see what that does to the results.

The '''ook_vis''' protocol decoder provides two lines of decode. The first line does a basic decode (with formatting) while the second attempts to work out where the preamble and sync might be and then displays the data with a posible structure. The sync position is worked out from the preamble and detects when it switches from '1111 ...' or '1010 ...' to something else.

== Decoder ==

The '''ook_vis''' decoder has three options

{'id': 'displayas', 'desc': 'Display as', 'default': 'Nibble - Hex', 'values': ('Byte - Hex','Byte - Hex rev', 'Byte - BCD','Byte - BCD rev','Nibble - Hex','Nibble - Hex rev','Nibble - BCD','Nibble - BCD rev',)},
{'id': 'synclen', 'desc': 'Sync length', 'default': '4', 'values': ('0','1','2','3','4','5','6','7','8','9','10')},
{'id': 'syncoffset', 'desc': 'Sync offseth', 'default': '0', 'values': ('-4','-3','-2','-1','0','1','2','3','4')}

The '''displayas''' option allows the user to pick how the data is presented. It supportes two lengths 4 bits (Nibble) and 8 bits (Byte). It also allows numbers to be displayed as Hexadecimal or Binary Coded Decimal (BCD) and also supports bit reversal.

The '''synclen''' option allows the user to set the length of the Sync and vary it to see what that does to the data after it.

The '''syncoffset''' option allows the user to move the start of sync backwards and forwards to see what that does to the data after it.

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

<pre>
$ sigrok-cli -P ook_vis --show
</pre>

== sigrok-cli examples ==

The '''ook_vis''' decoder concentrates on the protocol and not how it is transmitted so it needs the ook decoder to deal with the 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 1111 (default) (Oregon V3 sensor) and then pass the result to the ook_vis decoder and only display the ook_vis output. The trace belongs to a real Oregon v3 rain sensor model PCR800.
<pre>
sigrok-cli -P ook:data=D0,ook_vis -i oregon_pcr800.sr -A ook_vis
</pre>

__FORCETOC__

[[Category:Protocol decoder]]

File:Ook oregon.png

2018-06-17T18:35:29Z

SteveR:

Protocol decoder:Ook oregon

2018-06-17T18:35:03Z

SteveR: Created page with "{{Infobox protocol decoder | id = ook_oregon | name = Oregon Scientific | description = Decodes Oregon Scientific signals for weather sensors | sta..."

{{Infobox protocol decoder
| id = ook_oregon
| name = Oregon Scientific
| description = Decodes Oregon Scientific signals for weather sensors
| status = supported
| license = GPLv2+
| source_code_dir = ook_oregon
| image = [[File:ook_oregon.png|250px]]
| 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 [http://store.oregonscientific.com/us/weather-stations.html 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 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.

== 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:

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

== 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.
<pre>
sigrok-cli -P ook:data=D1:preamble='1010 ...',ook_oregon -i thgr228n.sr -A ook_oregon
</pre>

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

== 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'''
* [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 os_v2_1_temp_hum_sensor library] written by deberman 2016-02-24, derived from Virtual v2.1 sensor by Olivier Lebrun
* [https://wiki.pilight.org/oregon PiLight]

__FORCETOC__

[[Category:Protocol decoder]]

File:Ook.png

2018-06-17T18:29:45Z

SteveR:

Protocol decoder:Ook

2018-06-17T18:26:23Z

SteveR: SteveR moved page Protocol decoder API:Ook to Protocol decoder:Ook: put it under the api by mistake

{{Infobox protocol decoder
| id = ook
| name = On Off Keying
| description = Decodes On Off Keying waveforms which are frequently used for remote control protocols
| status = supported
| license = GPLv2+
| source_code_dir = ook
| image = [[File:ook.png|250px]]
| input = logic
| output = ook
| probes = none
| optional_probes = —
| options = invert, decodeas, preamble, preamlen, diffmanvar
}}

The '''ook''' protocol decoder takes a logic level input and decodes NRZ, Manchester and Differential Manchester encoding.

It decodes based on sample lengths rather than on sampling rate or inter pulse delays, so should be capable of decoding a variety of signals.

== Getting a signal to Analyse ==

There are two main ways of getting a signal to decode. Opening up the device and attaching the probes from a logic analyser directly to the logic level signal (if you can find and safely connect to it) or using a receiver to demodulate the Radio Frequency (RF) signal to recover the logic level signal.

Opening up the device is going to get you the cleanest signal but carries the risk of breaking the device and any warranty.

Using a demodulator is much lower risk but comes with its own challenges which mainly resolve around the extra noise and other signals that the RF receiver picks up that are nothing to do with the signal that you are interested in. If another device transmits at the same time as the wanted signal then the two will interfere with each other and add up to a mangled mess. Similarly if something creates noise at the same time as the wanted signal then there are going to be some holes in it. One coping strategy is to take a decent number of samples and hopefully get one that is clean.

Sigrok has a very useful feature that allows the cursors in PulseView to be used to highlight part of the waveform and "Save Selected Range As" to manually cut out a useful signal from the noise and other signals around it. '''Important''' when using this feature make sure that you leave at least five times the preamble period on the end of the signal or the stacked decoders will not get triggered.

In an ideal world the decoder would be able to do the manual identification for you and chop the garbage out too. There are a couple of extra things that have been built into this decoder that will try and improve your chances of getting a good result from a less than ideal waveform. Good electrical design and layout of the receiver are major factors too.

== How it works ==

The '''ook''' decoder assumes that the signal that it needs to decode will have a square wave preamble which can be analysed to work out the original clock period (in samples) which it needs to recover the sending clock and decode the signal. '''Note''' that it does not look for specific inter pulse times which would limit what it could decode.

It is important to make sure that the preamble is correctly identified and that the decoder doesn't try and use random noise or other garbage as the preamble.

To give the demodulator option a better chance of working from the output of an RF receiver, this decoder contains some garbage removal code. The code requires 7 pulses (adjustable from 3 to 10) in a row that have lengths within a factor of 5 of each other before it will start decoding. This is designed to reject random background noise and noise which is created by the way that RF receivers work.

If garbage removal and Advanced clock recovery (see below) are not needed then these features can be totally disabled by selecting a preamlen of '0'. Don't disable this feature unless you are opening up the device and attaching the probes from a logic analyser directly to the logic level signal.

A genuine preamble will pass intact through the garbage filter.

Only decoding from a genuine preamble does several good things, it reduces the work that the higher levels have to do and it frames the wanted signals.

At the end of receiving a good signal the super regenerative RF receivers go low for a few hundred milliseconds. This is a useful marker to spot when looking at captured waveforms. Find the blanks and go backwards to the signal and its preamble.

The decoder imitates this behaviour to detects the end of each set of pulses by looking for a low for five times the preamble period. Once the decode has timed out the resulting OOK pattern is sent up the stack to the higher level decoders and the decoder is reset ready for the next set of pulses which may be from a completely different device.

== Advanced Clock Recovery ==

The example waveforms in the articles in the Resources section below all use a clock that is a pure square wave (50:50 mark/space) which have equal high and low times. It makes it much easier to understand what is going on and also makes it easier to decode at the other end.

Decoding is based upon spotting long and short pulses, so its essential to recover the clock accurately to work out what is a long and short pulse.

In real life the ideal square wave preamble doesn't always happen and the signal can frequently end up skewed with significantly longer on than off periods or vice versa. This makes some devices much harder to see and decode than others. The RF decoder chosen will have a significant effect too.

This decoder copes with the problem by treating the clock high and low reference lengths independently. It looks at the preamble and if the preamble is skewed then it assumes that the signal will be too and compensates by comparing high pulses with the high reference and low pulses with the low reference.

== Decoder ==

The '''ook''' decoder has the following options and defaults
invert - Yes/No - default No
decodeas - Manchester/Differential Manchester/NRZ - Decode As - default Manchester
preamble - '1010 ...'/'1111 ...' - Preamble pattern - default '1111 ...'
preamlen - 0/3/4/5/6/7/8/9/10 - Preamble filter length - default 7 - 0 turns it off
diffmanver - 1/0 Differential Manchester - transition at start is a - default 1

'''Manchester encoding'''

This can send a 50:50 mark/space square wave to transmit a signal that is '1111 ...' or '1010 ...'. In one case the pulse samples represent the clock period in the other only half. Which one was intended cannot be easily detected by the receiver, so there is an option for the user to make the choice. Making the right choice should remove most of the decoding errors.

There are also two variants, as per G.E Thomas and IEEE 802.3 These are the opposite way up to each other. The default here is IEEE 802.3 but the option is there to '''invert''' the result and comply with G.E Thomas.
The '''diffmanver''' option will be ignored as it only applies to Differential Manchester decoding.

'''Differential Manchester encoding'''

Again there are two options, to treat a transition at the start of the clock cycle as a 1 or 0 and no transition as a 0 or 1. The default is to treat a transition as a 1 and no transition as a 0.
Note. Inverting a Differential Manchester signals does nothing, so although the '''invert''' option does work here, it won't effect the result. The '''preamble''' pattern only applies to Manchester encoding and is ignored inside this decoder.

'''NRZ'''

Or '''Binary Encoding''' as it is called in Computer Networks 2nd Edition - Andrew S. Tannenbaum only has one option which is '''invert'''
The '''decodeas''', '''preamble''' and '''diffmanver''' options are ignored.

== Output ==

The results of decoding each bit can be
'0' zero or low
'1' one or high
'E' Error or invalid. This can be caused by missing transitions or the wrong pulse lengths according to the rules for the particular encoding. In some cases this is intentional (Oregon v1 preamble) and is part of the sync pattern. In other cases the signal could simply be broken.

If you get large numbers of 'E's then you are probably using the wrong decoder, using the wrong options with the right decoder, there is simply too much noise or more rarely the sample rate is too low for the decoder to work properly. The ideal sample rate is 50 to 100 times higher than the preamble clock and becomes more of an issue with badly skewed signals.

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

<pre>
$ sigrok-cli -P ook --show
</pre>

== sigrok-cli examples ==

usage with sigrok-cli is:

To use '''ook''' to decode a Manchester (default) encoded trace with a preamble starting 1010.
<pre>
sigrok-cli -P ook:data=D1:preamble='1010 ...' -i thgr228n.sr
</pre>

To decode a Manchester (default) encoded trace with a preamble starting 1111 (default)
<pre>
sigrok-cli -P ook:data=D0 -i oregon_pcr800.sr
</pre>

The ook output from the ook decoder can also be stacked with another decoder that accepts ook input such as the [http://store.oregonscientific.com/us/weather-stations.html Oregon Scientific] decoder
To decode a Manchester (default) encoded trace with a preamble starting 1010 (Oregon V2.1 sensor) and then pass the result to the oregon decoder and only display the oregon output
<pre>
sigrok-cli -P ook:data=D1:preamble='1010 ...',oregon -i thgr228n.sr -A oregon
</pre>

The ook decoder can optionally display the pulse lengths in micro seconds by using the Binary output switch with an option called "pulse-lengths"
<pre>
sigrok-cli -P ook:data=D0,ook_oregon -B ook=pulse-lengths -i oregon_pcr800.sr
</pre>

== Resources ==
* [https://en.wikipedia.org/wiki/On-off_keying On Off Keying wiki]
* [https://en.wikipedia.org/wiki/Unipolar_encoding Unipolar Encoding includes NRZ]
* Computer Networks 2nd Edition - Andrew S. Tannenbaum P60 Fig 2.3 "Three different encoding techniques" has an excellent picture of logic level waveforms that were used to create the Manchester and Differential Manchester decoders
* [https://en.wikipedia.org/wiki/Manchester_code Wikipedia: Manchester code] Pictures are analog waveforms not logic
* [https://en.wikipedia.org/wiki/Differential_Manchester_encoding Wikipedia: Differential Manchester code] Pictures are analog waveforms not logic

* [https://ipfs.io/ipfs/QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco/wiki/Differential_Manchester_encoding.html Differential Manchester encoding]

Other interesting articles

* [http://www.nesweb.ch/downloads/doc9164.pdf Atmel (Arduino) Manchester coding basics]
* [http://www.pcbheaven.com/wikipages/manchester_coding/ Manchester and Diff Manchester encoding] good unipolar pictures plus some good flow charts for decoding with a microcontroller.

__FORCETOC__

[[Category:Protocol decoder]]

Protocol decoder:Ook

2018-06-17T18:24:17Z

SteveR: Created page with "{{Infobox protocol decoder | id = ook | name = On Off Keying | description = Decodes On Off Keying waveforms which are frequently used for remote c..."