JP1 Remotes

Hello JohnsFine,
Clarity needed re terminology ..Panasonic ir protocol
Device = address. cool I get that.
OBC stands for?.. and is it the sub-device address or the function/command number/data?
EFC stands for?.. or is it that the sub-device address or the function/command number, and does pronto ignore the EFC anyway?
Does RTI ignore EFC also?

Also I've been looking for days .. I need a document that details correctly the PANASONIC protocol specification. (ie the "Panasonic" implementation of this protocol)
I'm programming a spreadsheet to generate all possible hex codes for each device address. I've made sheets for Sony SIRCxx and NEC but need to the Panasonic spec sheet or similar.
This will be made freely available once finished.
So.. I'll need a clear description as to which hex numbers are reversed, complimented, and the order the bits are sent out.

Help greatly appreciated....

the Panasonic version of the Kaseikyo is formatted as follows:

IRP notation: {37k,432}<1,-1,1,-3>(8,-4,2:8,32:8,D:8,S:8,F:8,(D^S^F):8,1,-173)+

each of the following are 8-bits in length:

oem device code 1 (value 2)
oem device code 2 (value 32)
device code
sub-device code
command code (aka "OBC")
checksum

the checksum is calculated by XOR-ing the device code, sub-device code and OBC.

Here's the timing data for Panasonic (all in uS):
0 = +440 -440
1 = +440 -1310
leadin: +3500 -1750
leadout: +440 - 74000

here's some sample binary data (you need to read the binary backwards to convert it to decimal because the signal is an LSB signal):

dev=144, sub=1, obc=10
01000000 00000100 00001001 10000000 01010000 11011001

dev=144, sub=1, obc=2
01000000 00000100 00001001 10000000 01000000 11001001

dev=144, sub=1, obc=3
01000000 00000100 00001001 10000000 11000000 01001001

dev=144, sub=0, obc=253
01000000 00000100 00001001 00000000 10111111 10110110

As for the terminology, OBC stands for "Original Button Code", this is the decimal "command code" or "function code" value you get when you read the variable portion of the binary.

EFC stands for "Extended Function Code", and unless you are programming a "One For All" brand remote (made by UEI) you don't need to worry about this one. EFCs are irrelevant to RTI, Pronto and any other brand of remote. The only time you will care about an EFC code is if you see one posted (eg, for a discrete code) and you want to convert it into an OBC so you can format a Pronto signal. In this case, tell us the EFC and we'll tell you the OBC.

If you want to generate Pronto hex for signal formats like this, you should really make yourself familiar with John's MakeHex program. You can also read up on Panasonic and lots of other protocols on John's web page here:

http://www.hifi-remote.com/johnsfine/DecodeIr.html

Thanks for the info.
I never did decipher the makehex method representing the protocol.
My understanding is basically as follows, reading bits from rhs to lhs using your first example, all hex numbers are msb -lsb reversed as usual.

First 2 bytes (2x 8 bit bytes) are the oem device code, always the same for panasonic protocol.,
01000000 00000100 00001001 10000000 01010000 11011001
20 02 hex,

Second byte is the MSByte of the Address or Device Code
01000000 00000100 00001001 10000000 01010000 11011001
90h (read right to left)

Third Byte , is the LSByte of the Address or "sub device" code, really just part of the full 16bit address, with the Sub-dev code being 00h if omitted from makehex.
01000000 0000010000001001 10000000 01010000 11011001
01h (right to left)

So Device code= (device : subdev) = 144dec:1dec = 9001h

Fourth byte is the Function or Command code (OBC)
01000000 00000100 00001001 10000000 01010000 11011001
your example obc=10dec or 0Ah (right to left)

The last byte is the Checksum, using MOD 10 maybe?
01000000 00000100 00001001 10000000 01010000 11011001


Please correct my understanding if in error.
Just a couple of other things,
Q.1. How is the EFC represented in the code?
Q.2a. The Lead-out is always the same "0ACE" from Makehex, but this is not a "complimentary" protocol (the "1":"0" ratio is not always the same). Should not the lead-out "low" time be determined based on the period expected for each IR sequence prior to a repeat (as for NEC protocol.)?
Q.2b Or does makehex simply put a nice long low at the end to ensure the next code is read reliably?
Q.3. It looks like this protocol has no "repeat" command, and a repeat is achived simply by sending the full seqence again. ?
This would explain Q2 above
Q.4. What is the Checksum "MOD" process?

Happy Trails.

The last byte is the Checksum, using MOD 10 maybe?
01000000 00000100 00001001 10000000 01010000 11011001

(D^S^F):8

Q.1. How is the EFC represented in the code?

EFC stands for "Extended Function Code", and unless you are programming a "One For All" brand remote (made by UEI) you don't need to worry about this one. EFCs are irrelevant to RTI, Pronto and any other brand of remote. The only time you will care about an EFC code is if you see one posted (eg, for a discrete code) and you want to convert it into an OBC so you can format a Pronto signal. In this case, tell us the EFC and we'll tell you the OBC.

The EFC is not represented in the code at all. The EFC is for UEI remotes only. An EFC is just what we need to feed UEI's engine to get the signal to appear.

remoteone wrote:I never did decipher the makehex method representing the protocol.

There are a lot of different protocols that can be represented concisely and unambiguously in IRP notation. You should take the time to learn it. It really isn't that hard.
The IRP notation used in MakeHex is somewhat kludgy. The related IRP notation Rob used above
{37k,432}<1,-1,1,-3>(8,-4,2:8,32:8,D:8,S:8,F:8,(D^S^F):8,1,-173)+
is more useful in discussing IR protocols.

all hex numbers are msb -lsb reversed as usual.

Since most IR protocols are LSB, IRP notation assumes LSB and explicitly states "MSB" for the exceptions. Panasonic is LSB.

First 2 bytes (2x 8 bit bytes) are the oem device code, always the same for panasonic protocol.,

Correct.

Second byte is the MSByte of the Address or Device Code

You lost count there, so we understand you mean the third byte.

All of my software interprets that byte of Panasonic as an 8 bit device code. But that is just retaining compatibility with a minor error in reverse engineering we made long ago.

In fact the first (low) four bits of the third byte are a check nibble for the first two bytes and like those first two bytes will be constant for all Panasonic signals.

At the moment, I forget the official layout of the next 12 bits (high half of third byte and all of fourth byte). There are online documents somewhere describing it. But it is convenient to treat the fourth byte as "subdevice" in software that tries to use consistent names for the parts of IR signals across multiple inconsistent protocols.

with the Sub-dev code being 00h if omitted from makehex.

Another artifact of earlier incorrect reverse engineering. We saw a lot of signals with zero there before we saw any with non zero.

Function or Command code (OBC)

Yes OBC = Function = Command = Data, depending on the terminology used by the manufacturer.

The last byte is the Checksum, using MOD 10 maybe?

No, using xor.

Q.1. How is the EFC represented in the code?

It isn't. The EFC is a lame encryption of a data byte used internally by OFA remotes, usually to generate the OBC. I think OFA created that in order to be able to tell advanced code values to their customers in a form that wouldn't be helpful to users of other remotes.

Q.2a. The Lead-out is always the same "0ACE" from Makehex, but this is not a "complimentary" protocol (the "1":"0" ratio is not always the same). Should not the lead-out "low" time be determined based on the period expected for each IR sequence prior to a repeat (as for NEC protocol.)?

I don't know. Devices rarely care about this detail in any protocol and it doesn't seem to be consistent across even original remotes generating Panasonic protocol. So I just picked a value that seems to get the job done.

Q.2b Or does makehex simply put a nice long low at the end to ensure the next code is read reliably?

That value is for repeats of the same code while the button is held. Neither IRP notation nor Pronto Hex nor UEI executors even try to spec the time needed between different commands. That varies too much by device and function.

The lead out value is supposed to be in the range that the device will understand multiple frames as a single button being held.

Q.3. It looks like this protocol has no "repeat" command, and a repeat is achived simply by sending the full seqence again. ?

Right.

Q.4. What is the Checksum "MOD" process?

Bitwise Exclusive OR.

Thanks all for the time consuming replies,
Yes I did lose count there with the byte numbering.
Think I have enough info to finish the job.
My question re lead-out time comes about since once having problems with NEC codes I made for a customer. The NEC protocol uses both seq1 and seq2 of thepronto hex format. The lead-out time of seq1 prior to the repeat code of Seq2 , and the period of the seq2 repeat code are very critical. Hence my concerns re the panasonic leadout time.
Thanks Again

The UEI executor for the Panasonic protocol has a fixed leadout time, whereas their executor for NEC has a variable leadout time (what we call "off as total"), so while your concerns are valid for NEC, I don't think you need to worry about a variable leadout for Panasonic.

remoteone wrote:The lead-out time of seq1 prior to the repeat code of Seq2 , and the period of the seq2 repeat code are very critical.

"Critical" as in picky about the exact duration? That's possible, but I doubt it.

Those two lead-out times (initial and repeat) for the form of NEC that we call NEC1 are very different, so even if the receiver isn't "picky" about the exact duration, you couldn't get away with using the same duration for both.

When the perfect lead-out depends on the bit pattern ("off as total" as Rob said) it still doesn't vary from the average lead-out enough to bother typical devices. If you rebuilt the NEC executor with an average Lead-Out and without the "off as total", I think you would only need to fix the extreme case of the NEC1 repeat frame. NEC2 and the variation among NEC1 first frames probably never gets far enough from average to break anything.