JP1 Remotes

[onewell]

Hi - I've recently begun working with IR in the context of using a networked IR
device (GlobalCache GC100 www.globalcache.com) to control home theatre setups.
The global cache is a 'dumb' device, having no built-in IR codes whatsoever, so
I'm left with the option of building up my own IR database. It seemed like a better
route than grabbing the Pronto CCF files for each device one at a time from the
Premise Home Control site, as recommended by the Global Cache folks (too
painful). Little did I know how many variations on the IR theme existed!

Anyway, I'm building up a Java class library that can generate IR codes for the various
protocols, and am creating device descriptions in an XML format. I have built up
protocol generators for the more common formats (Sony, NEC, Panasonic) from
information on Barry Gordon's site (excellent resource) but am interested in
expanding the device coverage if possible. Ideally additional protocol descriptions
would be available in a simple description file, similar to Barry Gordon's 'IRP' format.

Is there a obvious straighforward path for me to convert some of the protocol algorithm
information from this site into a more 'IRP'-like format? (I don't see a master list
of protocols and their parameters at first glance) Figured I'd ask the experts before
exploring further!

Below is a quick snippet of my (very early) XML device description. I'm sure it
will be changing as things mature...

----------------------------------------------------------------------------------------------

<?xml version="1.0"?>

<!-- XML device description for IR control of generic Sony TV device -->

<IRDevice>

<Manufacturer>Sony</Manufacturer>
<DeviceType>TV</DeviceType>
<Model>Generic</Model>
<Protocol>Sony12</Protocol>

<!-- List of supported device/function codes. Some devices use multiple -->
<!-- device codes, so the device code is supplied for each key -->
<!-- Codes use attributes vs elements for conciseness (1 line per entry) -->

<KeyCodeList>

<KeyCode name="1" dev="1" func="0" />
<KeyCode name="2" dev="1" func="1" />
<KeyCode name="3" dev="1" func="2" />
<KeyCode name="4" dev="1" func="3" />
<KeyCode name="5" dev="1" func="4" />
<KeyCode name="6" dev="1" func="5" />
<KeyCode name="7" dev="1" func="6" />
<KeyCode name="8" dev="1" func="7" />
<KeyCode name="9" dev="1" func="8" />
<KeyCode name="0" dev="1" func="9" />

<KeyCode name="Enter" dev="1" func="11" />

<KeyCode name="Chan Guide" dev="1" func="14" />
<KeyCode name="Clear" dev="1" func="15" />
<KeyCode name="Channel+" dev="1" func="16" />
<KeyCode name="Channel-" dev="1" func="17" />
<KeyCode name="Volume+" dev="1" func="18" />
<KeyCode name="Volume-" dev="1" func="19" />
<KeyCode name="Mute" dev="1" func="20" toggle="true" />
<KeyCode name="Power" dev="1" func="21" toggle="true" />

</KeyCodeList>

</IRDevice>

[johnsfine]

[jon_armstrong]

There is a spreadsheet that I put together in the old irp notation. It actually is in a format that can be used by GenIRDB (in most cases). If you download DecodeIR.dll and read the included documentation you will find that John has added some additional protocols in the new notation plus has many of the same protocols in the new notation.

I have also smashed together the text of a series of discussions between John and me on the new notation. It is a bit rough from an editorial perspective, but John explained ever thing pretty clearly and it may save some time. I also put together a similar Excel spreadsheet of the Protocols in the new irp format, but is also not quite ready for prime time. If either would help you, email me and I'll send them to you.

As John has mentioned, Barry's irp files reflect the thinking of about three years ago. Since then this group has continued to discover and decode many more IR protocols and has a deep understanding of them. This is out of necessity, because OFA remotes have 2 KB of EEPROM and can only learn ~25 commands in the 1KB allocated to learning.

However, if you understand the protocol then you can do an entire device/protocol upgrade in ~100 bytes and with the advanced tools can recover most of the learning space for additional device upgrades
_________________
-Jon

[onewell]

Thanks for the info...sounds like the new 'irp' notation is the way to go.

Is there a version of a 'irp form compiler' that is suitable for adaptation to Java
(adding support for the new notation along the way) ? ( I looked for the MakeHex
source but couldn't find it anywhere on this site or remote central)

If not, I'll cook my own...(I'll share it when it's presentable). If you
have any thoughts on inputs/outputs to the black box, let me know.
I'll post my initial design ideas before I go too far, just to make sure
I'm not missing the point.

Is the thinking that, if properly coded, this Java parser would eventually find a home
in RM? (In that case maybe I'd better comment it!). l looked briefly at the RM code,
and it looked like a base 'Translator' class was extended by subclasses to provide
support for the various protocols. Presumably that would be unnecessary if the protocol notation was flexible enough to handle all the known protocols? Am I getting that right?

Jon - I'll take whatever you have on the new notation. I found the threads on Yahoo
and it looked like it was pretty well spec'd out, except I don't remember seeing
support for Barry's DEFINE capability. I'll send you my email momentarily...

Thanks again -

-Oliver

[johnsfine]

[onewell]

[johnsfine]

I have a few comments on the data structures that I think IRP should parse into.

When I designed IRP notation, I intended that the parser be able to distinguish ordinary numbers from durations by context and thus I said all the processing of time unit quantities into microsecond quantities would happen at parse time, rather than execution time.

When I added a more general "define" ability to makehex, I discovered that it became arbitrarily complicated to distinguish durations from numbers inside subexpressions. I decided it was simpler to leave that (and multiplying by the unit size) to execution time. I think the same decision may be best for the new IRP parser.

That means we need a scalarValue class for the result of evaluating a scalar object. The scalarValue would contain the value itself, plus a flag for whether it is explicily in microseconds (vs. just being a number).

A scalar object has two important methods:
1) It can be evaluated (returning a scalarValue object)
2) You can pass it an inputContext object and an outputContext object and it will generate an IR signal.

An outputContext object accumulates an IR signal as it's generated. The parser doesn't create any outputContext objects. It just creates objects which know the interface of an outputContex. You can tell an output context to emit a duration (a positive or negative duration in microseconds) and you can tell it where a repeat begins (with minimum and max repeat count) and where it ends. A prontoHex outputContext may have extreme limits on repeating: The must be only one true repeat in the whole IR signal, it must have an unlimited max and it must end at the absolute end. Some other outputContext object may be more flexible. The caller's of the outputContext should try whatever the IRP notation tells them to try and let the outputContext abort if it can't handle it.

An inputContext holds the unit, the current bitSpec, the msb flag, the values of defines, and the interface to external inputs (such as device, subdevice and function in RM).

There are two fundamental kinds of scalar. A bitField and a scalarNumber. They do two totally different things when asked to generate IR. A scalarNumber evaluates itself and converts the result to microseconds (if it wasn't already) and passes that to the outputContext. A bitField evaluates itself and then sequences through the bits of that value (as specified by the msb flag) and passes each bit (and the ouput context) to the current bitSpec for processing.

There are many kinds of scalarNumber object. Those include simple numbers, simple duration numbers (in microseconds), symbol references, and various subexpression operations (such as a plus operation). All share the same method for generating IR but have different eval methods.

Many scalar objects include references to other scalar objects: a bitField contains references to three scalars; a plus operation contains references to two scalars; etc. The types can be mixed. In theory you could add a bitField to a duration etc.

The key data type would be a sequence. It contains:
1) Optionally a reference to a bitSpec
2) A min and Max repeat count (by default both are 1). Max needs some encoding for unlimited.
3) A sequence of refrences to objects that are able to generate IR. The two kinds of such objects are sequences and scalars.

When you generate IR for a sequence, first it checks whether it has a bitSpec. If so it makes a clone of the inputContex it was given and binds the original input context into the bitSpec and binds the bitSpec into the clone, then uses the clone. Otherwise it just uses the inputContext it was given. Then it just calls every item in the sequence to generate IR.

A bitSpec contains refrences to some power of two number of sequences. It also can have an inputContext temporarily bound to it, and it can buffer bits until it has enough to select a sequence. When called with a bit and an outputContext, it either just buffers the bit, or uses the accumulated bits to select a sequence them passes the input and output contexts to that sequence to generate IR.

A parser should be able to go through the IRP, delaying the decisions about whether each '(' represents a start of sequence or a start of subexpression, and other than that having an easy time converting the text to a big tree of sequence, bisSpec and scalar objects, plus some info for the inputContext object.

[johnsfine]

I finally posted those MakeHex sources at
http://john.fine.home.comcast.net/ir/source/MakeHexCpp.zip

[onewell]

Thanks for the data structure comments and the MakeHex post...

I was just experimenting with 'javaCC' for parsing the IRP notation. Cool utility,
but it may be overkill for the limited IRP grammar - I'd rather have more readable
parser code than javaCC generates, and less of it. That bias may be just 'cause I'm
not very familiar with the tool though. Time to read up on tokenizer/parser lingo!

-Oliver

[johnsfine]

I never heard of the javaCC tool, but I've worked with many tools for generating parsers. Generally I don't like them. Anyone who knows how to write a parser can write a smaller, faster, more readable, more maintainable parser directly without the tool.

In some sort of class on compiler writing, where you design the language syntax AFTER you select the parser writing tool, such tools can have a major advantage. They let someone who doesn't know how to write a parser write one.

More importantly they make certain syntax design decisions very hard to implement. That forces the student to adjust the syntax to be more easily parsed. Usually that means correcting syntax design mistakes that the student has made and results in a better final syntax than you'd get if the tool hadn't made the bad syntax hard to implement.

In the real world, a parser writer is usually handed a syntax spec with no choices to fix the syntax to fit the tool. In kludging the use of the tool to fit the syntax, you get an unmaintainable mess (believe me, I've been through that MANY times).

In the case of IRP, it may be too simple to be worth the tool. But it also has the intentional ambiguity between sequences and expressions, which I decided makes it cleaner for the user, but a little trickier for the coder of a direct parser. I'm not sure about javaCC, but most parser generation tools are totally blocked by that sort of ambiguity. ANTLR can handle it as a three level parsing process (insert a paren matching tree generation level above the lexer and below the real parser) but that really overkill for just IRP. Traditional automatic two level (lex and parse) designs can't do it.

[onewell]

Hi John -

A couple of basic questions on the protocol format:

1. The Sony12 format is listed (in the protocol spreadsheed and DecodeIR
README) as:

{ 40k, 600 } <1,-1 | 2, -1>(4,-1,F:7,D:5,^45m)+

My experience with Sony devices is that the signal needs to be transmitted a
minimum of 2 times. Is that not true for all Sony devices? If so, should the
protcol description read:

{ 40k, 600 } <1,-1 | 2, -1>(4,-1,F:7,D:5,^45m)2+

2. (newbie question) I understand that D = device code, F = function code. A
number of the protocols have an 'S' field. Is that like an extended device
code? Is it always used when device codes are more than 8 bits?


BTW - Picked up a Pronto off Ebay to help solve any Pronto Hex mysteries I
might encounter. I also got a cheap OFA remote (URC-4330B03) from CVS
just so I can beam it's codes over to the pronto and examine the HEX if I
want.

-Oliver

[Mark Pierson]

[johnsfine]

[onewell]

Hi John -

FYI - I got diverted with other things for a while, but I now have a mostly functioning Java IRP parser. One thing I did do to make my life easier was to use '[' ']' instead of '(' ')'
for expressions (remove the ambiguity between expressions and IRStreams).
I wasn't too clear on why you intentionally designed it this way - feel free to clarify...


Right now the code can generate 'generic' IRBursts in units of clock frequency. I'm
planning on coding up a Pronto hex converter 'plug-in', and tidying up this week.
Hope to post the result at the end of the week for feedback.

-Oliver

[onewell]

Hi -

I just posted a zip file with my first cut at a Java-based IR signal generator package. It's at:

www.mediarush.com/download.html

There is a README in the top directory of the unzipped archive. In a nutshell, the package has:

- An (intially tiny) set of device descriptions in XML format,
and a separate set of protocols using John Fine's IRP
notation (the latest version). The XML file format
allows the IR protocol parameters (device/function codes)
to be specified on a device-wide, function group-wide,
or indivual keyCode basis. Also the format is set up to
allow device files to be nested - more 'generic' versions
of devices can be used as 'Base Devices' for more
advanced versions of the device.

- Java IR device and protocol classes that work with the
above. The protocol parser class builds up an in-memory
represention of the protocol (a syntax tree, basically),
which can be used to generate IR signals on the fly.

- A couple of simple sample programs to interactively
generate Pronto Hex for a device, or alternatively
control it using a GlobalCache IR controller.

This package is probably not bug-free enough yet for general use, but I'm interested in feedback, general impressions, and ideas for efficiently populating the database with device files in the XML format (the
real trick!)

Cheers,

-Oliver