Rec80 Protocol

[RemoteGuy]

I would like to create an upgrade for a remote that uses REC80 protocol.

RMIR does not seem to have this protocol. There are RECS80(45), RECS80(68) and RECS80(90) protocols but not REC80. None of these seem to make the correct IR signals (as observed on an oscilloscope).

I received the following from the manufacture:

REC80 format
The definition of REC80 format used in this document is as follows:
The data stream consists of a start bit, 22 data bits and a stop bit.
The Start Bit is made up of 4 elements of ‘0’ followed by 4 elements of ‘1’
The Stop bit is a single element of ‘0’
Data Bits:
A logical ‘0’ is defined as one element of ‘0’ followed by one element of ‘1’
A logical ‘1’ is defined as one element of ‘0’ followed by three elements of ‘1’
The resulting 22 bits are defined as AAAAADDDDDDaaaaadddddd where:
AAAAA is a 5 bit address which defines the handset
DDDDDD is a 6 bit data (or command) code which defines the button pressed
aaaaa is the inverse of AAAAA
dddddd is the inverse of DDDDDD

The code does not change between key presses
If a key is held down the same code is repeated at approximately 110mS intervals


Is there some other technique that I should be using to get the right protocol?

Thanks

Ron

[vickyg2003]

Hi Ron,

Sometimes we don't always call the protocols by its official name, because we don't know what it is, so we make up a name that only has meaning in the JP1 world.

Have you captured the signals and used the JP1 tools to recognize it? If the protocol is recognized that will help. If not post the IR files containing the learns in the diganoses area and start a thread in the protocol decode area with a link to the learns.

Then we can create a custom executor for the protocol or we can help you create it with PB.

[RemoteGuy]

Hi,

I don't have the original remote. All I have is a description from the manufacture (in my original post) and picture of a waveform for the "Mute" key. Would that be helpful to post?

[3FG]

We will be able to get this working. I'll have time to look at this tonight.

I have a general interest in IR protocols, and so I'm curious about the details here. REC80 was originally developed by Philips, but I believe that it doesn't correspond to exactly the description you've quoted.

One manufacturer that uses a protocol similar to REC80 is Velleman, who sell various switches, etc.

Which company is providing the IR protocol that you want ot make the upgrade for?

And what model remote is the target for the upgrade?

[RemoteGuy]

The manufacturer is Scion Technology. The target is RCA RCRP05B remote.

Thanks

[vickyg2003]

What you have posted is helpful, it gives the signal structure, but it doesn't give the timing data.

We need a frequency
We need the timing for the "element of 1".
You should be able to get that from an oscilliscope.

I have a feeling this is going to turn out to be what we call Panasonic (OLD). That is a common 22 bit protocol.
IRP notation: {57.6k,833}<1,-1|1,-3>(4,-4,D:5,F:6,~D:5,~F:6,1,-???)+
EFC translation: 6-bit LSB comp with 2-bit mini-combo


We don't know the timing and frequency but we do know that what you are describing is
<1,-1|1,-3>(4,-4,D:5,F:6,~D:5,~F:6,1,-???)+

Personally I like working from the pictures.

[RemoteGuy]

I tried using Panasonic (OLD) and that appears to work. There does seem to be big vs little endian issue between the doc and what comes out but I was able to fix that.

Thanks all for your help.

Ron

[vickyg2003]

I'm glad this turned out to be so easy.

We'll look forward to seeing your upgrade in the file section.

[3FG]

Nice job Vicky!

BTW, RemoteGuy, the Panasonic (old) protocol is nothing like REC80. I don't know why Scion would call it REC80, although they certainly wouldn't need to call it Panasonic (old) either.

[vickyg2003]

Apparently there are two very different protocols that are getting confused here. The REC-80 and the RECS-80

REC-80 is Panasonic
RECS-80 is Philips

But yeah, nobody outside of the JP1 group is going to call this Panasonic (old).

[Barf]

Well, as 3FG said, the protocol usually referred to as RECS80 is something else, DecodeIR.html says

Code: Select all

{38k,158,msb}<1,-31|1,-47>(1:1,T:1,D:3,F:6,1,-45m)+. 

http://www.sbprojects.com/knowledge/ir/recs80.php also describes the protocol. It is known to be "difficult to learn" with very short flashes separated by long gaps.

I was fooling around with such a device some years ago, written down here. Most notably, it was the pickiest toggle-device I have ever used: After sending a signal with toggle=0 it steadfastly refused all signals with toggle=0, until it had received a signal with toggle=1. NO timeout, like we know it from e.g. RC5-devices.

The protocol is implemented in a chip called SAA3008 (or a competitor), Google for "SAA3008" for a datasheet.

[cauer29]

Well, as 3FG said, the protocol usually referred to as RECS80 is something else, DecodeIR.html says

Code: Select all

{38k,158,msb}<1,-31|1,-47>(1:1,T:1,D:3,F:6,1,-45m)+. 

http://www.sbprojects.com/knowledge/ir/recs80.php also describes the protocol. It is known to be "difficult to learn" with very short flashes separated by long gaps.

I was fooling around with such a device some years ago, written down here. Most notably, it was the pickiest toggle-device I have ever used: After sending a signal with toggle=0 it steadfastly refused all signals with toggle=0, until it had received a signal with toggle=1. NO timeout, like we know it from e.g. RC5-devices.

The protocol is implemented in a chip called SAA3008 (or a competitor), Google for "SAA3008" for a datasheet.

There is no shortage of RC5 and RC6 devices without any timeout on the expected toggle state. They don't usually apply this across different keys, but just to successive receptions of the same key.

A.A.