While scouring the internet for information on the Oresgon Scientific RF protocols I came accross some information gathered by others so I woul like to share it here. Much of the information here has been gathered from various postings on the internet. Several people have successfully decoded OS protocols. This document summarizes what has been already made public and adds a little more to the pile of knowledge.
The RF transmissions use on-off-keying (OOK) with Manchester coding on a
carrier frequency of 433.92MHz. See the Wikipedia entry on Manchester coding
for more information or consult a basic text on digital RF communications.
All OS protocol versions use the “normal” polarity definition of Manchester coding. This convention requires that a zero bit be represented by an off-to-on transition of the RF signal at the middle of a clock period. Another way to describe this is that the bit value is equal to the RF signal state before the transition.
By definition, RF transitions must occur in the middle of each clock period. In this document, that point will be designated by an integer number. The boundary between two clock periods will therefore be equal to an integer plus one half.
OS version 1.0 sensors transmit bits with a clock rate of approximately 342Hz, while version 2.1 and 3.0 sensors use a bit rate of 1024Hz. In all version 2.1 and 3.0 sensors measured to date, this rate does not vary by more than a few tenths of a Hertz.
Lets start with Version 1.0 message formatting, These sensors also repeat each message once, but do not repeat each bit.
RF Pulse Widths
The duration of Manchester-coded RF pulses is exactly either ½ or 1 data clock
period. As a result, RF transitions do not occur on exactly regular time boundaries and may be displaced in time from data clock edges.
Version 1.0 sensors have the RF pulses lengthened instead of shortened.
Version 1.0 sensors have a simpler format as shown in the figure below.
- The preamble contains twelve “1” bits.
- The sync section consists of a long off period (4.2msec), a long RF pulse(5.7msec) and another long off period (around 5msec).
- The first data sample point (clock edge) is not always marked by an RF transition and must be measured from the end of the long sync pulse.
- The data payload is fixed length since all version 1.0 sensors can only measure temperature.
- These sensors do not transmit a post-amble.
The table below summarizes the information
Protocol Version 1.0
Bit Rate (Hz) 342
Manchester Polarity Reverse
Preamble Bit Count 12
Bits Doubled No
Message Repeated Yes
RF Pulse LengthOffset +255 usec
Reception and decoding is possible using an Arduino board combined with one of the inexpensive 434MHz receiver modules which are readily available.
Hardware available for decoding on the Atmel processor includes a hardware timer with an edge-triggered sampling input. Edges on the trigger input will cause the timer value to be latched and a processor interrupt is then generated. One easy way to handle decoding then is not to attempt clock recovery, but to examine the time difference between transitions on the OOK RF signal.
Classifying Time Intervals
The decoding algorithm works by classifying time intervals between RF transitions (on-to-off and off-to-on) as either short or long.
Because the RF pulses are shortened, separate time thresholds are used for classifying the time period (short or long) depending on the RF state (on or off). Based on the data rate (1024Hz) and the two amounts by which pulses are shortened (96us and 138us), the table below shows the expected values of time intervals (in microseconds) based on the protocol version and RF state.
Protocol Version RF On RF off Short
|Protocol Version||RF On||RF Off|
|1.0 (preamble/data)Version 1.0 leading sync offVersion 1.0 sync pulseVersion 1.0 trailing sync off||1720||31805700||1219||268042005200|
A small improvement in performance might be possible by using different threshold values for each protocol version – which would be possible after the preamble is identified and the protocol version is known.
A reasonable set of thresholds for version 1.0 sensors (in micro-seconds) is shown in the table below:
RF State Short Min Short Max Long Min Long Max
Off 970 1950 1950 2900
On 1500 2400 3400 1100
Sync Begin (Off) 4000 4400
Sync (On) 5585 5985
Sync End (Off) 5000 5400
Sync End (Off) 6480 6880
Note: The two “Sync End” intervals correspond to the two cases where the first data bit is a “1” or “0” respectively.
Decoding Using Time Intervals
The decoding algorithm works by capturing a timer value when RF transitions (on-to-off or off-to-on) occur, and calculating the time interval between successive transitions. These intervals are classified as either short (one-half clock period) or long (one full clock period).
An integer counter keeps track of time in units of one-half clock tick; this counter’s value will be called “half-time”. After being properly initialized, half-time is incremented by one when a short interval occurs and by two for long intervals. Half time is a very useful quantity for decoding RF messages:
• When half-time is even, we are at the middle of a clock period. The transition occurring at this point determines the bit being transmitted.
• When half-time is odd we are at the boundary between two clock periods.
Transitions occurring here are of no interest in determining transmitted
• When half time is even, dividing it by two yields the current message bit
Using half-time, some very simple logic can be used to decode the RF signal.
When a transition falls on a boundary between two clock periods (i.e. half-time is odd), there is no message bit to be decoded. There may still be some useful information here however; if the current time period is long it means that the last transition also occurred at a clock period boundary. This means that there was no transition in the middle of the currently ending clock period, and signifies a violation of Manchester-coding format. This should be detected as an error condition.
When a transition falls in the middle of a clock period (half-time is even), a message bit can be detected and its value is simply equal to the RF state (on=”1” and off=”0”) just prior to the transition.
The decoding algorithm described above is simple and correctly determines the polarity of each bit based on the current RF signal state (on/off). Another algorithm has been developed by others which also works but does not consider the RF state when detecting bits (except for the first bit). This algorithm is described later.
The half-time value is also useful for verifying that bit-doubling is correct in version 2.1 messages. Since a long transition period is required to change from a 1 to a 0 bit (or vice-versa), every bit pair in these messages is required to end with a long transition period. Furthermore, when time is aligned with the end of a double-bit period, half-time taken modulo-4 will be zero.
When decoding a message from a version 2.1 sensor, and half-time modulo-4 is non-zero, no bit is detected. When half-time modulo-4 is zero, a bit is detected and a check is made that the current transition period is a long one (otherwise an error exists).
These algorithms have been published on the internet previously by various
As will be shown below, if the value of the first message bit is known then the
message can be decoded by considering only the time intervals between RF
state transitions, and ignoring the actual RF state value at each transition.
In a Manchester coded signal, each source data bit generates either a pair of
short transition intervals or a single long transition interval. A source bit will
generate a pair of short transition intervals when it is the same value as the
preceding source bit. When a source bit has the opposite value as the
preceding source bit, a single long transition interval is generated.
This description of Manchester coding lends itself to decoding based solely on
transition timing. A pair of short transitions represents a bit identical to the
previous bit. A long transition means the current bit is the opposite of the
previous bit. This works as long as the value of the first bit can be correctly
determined – otherwise the resulting decoded bit stream will be inverted.
Version 1.0 Message Format
At this point, there is only a single known format for version 1.0 messages. All version 1.0 sensors are temperature-only units.
Nibble(s) Contents Details
0 Rolling Code This 8-bit value changes randomly when the sensor is reset or batteries changed.
1 Channel Channels 1,2,3 are coded as 0,4,8
5..2 Temperature BCD temperature in degrees Centigrade
7..6 Cheksum Byte-oriented checksum
Version 1.0 messages are 8 nibbles in length. The channel setting occupies only
two bits in nibble 1 and it is possible that the other two bits may be part of the
rolling code. They have occasionally been seen to be non-zero.
The rolling code does not change every time the reset button is pressed.
Several reset operations are usually required to get this code to change.
According to internet sources, the first temperature nibble (nibble 5) is
actually a bit status field containing the following bits:
• 0 – Not used
• 1 – A “1” value indicates negative temperature
• 2 – Unknown (may be a malfunction flag)
• 3 – Battery low when “1”
The checksum is computed by organizing the 8 nibbles into four bytes in little endian order. Any overflow is summed back into the total sum.
For example, a message received as (in the order of transmission) “8487101C” would contain the following bytes: 0×48, 0×78, 0×01, 0xC1. The first three bytes are summed and compared to the checksum (0xC1 in this example). This message contains a rolling code of “8” and the sensor is set to channel 2, reading 17.8 ºC.
For another example take the message “88190AAB”. The bytes 0×88, 0×91 and
0xA0 sum to a value of 0x1B9. The overflow (0×1) is summed back in giving a
final checksum of 0xBA. This sensor has a rolling code of “8”, is set to channel
3, reads -9.1 ºC and has a low battery.