I've been wondering for a while about just how the Cinema 7 (and family) remotes deal with both device and advanced code spaces. By "space" I mean the domain of all possible codes.

It would seem that the consumer electronics industry has standardized IR signals, at least as far as the 0-255 code space is conserned. In other words, a remote will send a binary number in timed pulses. The timing seems to be the same for (almost) all systems, only the number it sends changes.

If there were no standardization -- that is, each device pulled its IR blink patterns out of thin air (shave-and-a-haircut to mute?) -- then every single signal would have to be programed into a universal, or every new signal would have to be learned. Not good.

But my question is about the device codes, and in particular, how the Cinema 7 handles them. Are the device codes just additional bits prefaced to the advanced code number? Is there also a 2-bit device type preface. Or is it back to shave-and-a-haircut to wake up my Acme TV/Toaster followed by a 0-255 command -- in which case, if my universal doesn't know the preface, you can't program that code, only "learn" it.

The upshot of all this... If there is no device code for my Acme Tv/Toaster, can I "search" for one? Can I punch in a thousand or two device codes, and test all 256 advanced codes for each? Or will my Cinema 7 just give me a long blink for any device code it doesn't have in it's ROMs? Can you enter a device code for which there is no default key layout?

Oh, and are OFA's device codes in a standard format, so that I can go to Acme and ask THEM what the device code would be?

"Why is the sky brown, Daddy?"
Non

> But my question is about the device codes, and in
> particular, how the Cinema 7 handles them. Are the
> device codes just additional bits prefaced to the
> advanced code number? Is there also a 2-bit device type
> preface. Or is it back to shave-and-a-haircut to wake
> up my Acme TV/Toaster followed by a 0-255 command -- in
> which case, if my universal doesn't know the preface,
> you can't program that code, only "learn" it. The
> upshot of all this... If there is no device code for my
> Acme Tv/Toaster, can I "search" for one? Can I punch in
> a thousand or two device codes, and test all 256
> advanced codes for each? Or will my Cinema 7 just give
> me a long blink for any device code it doesn't have in
> it's ROMs? Can you enter a device code for which there
> is no default key layout?

> Oh, and are OFA's device codes in a standard format, so
> that I can go to Acme and ask THEM what the device code
> would be? "Why is the sky brown, Daddy?" Non

"You know you're a Cinema7ophile when.....".

Hmmm.... I guess I'll take a shot at this... I don't
work for OFA so this is just my opinion, anyone can
feel free to advance another theory if my information
is incomplete or clearly erroneous. From the way I look
at it, "device codes" are just codes that represent IR
code "tables". These tables are pre-determined by OFA
after having done research on a particular remote
(OFA's are said to have the biggest database of code
tables in the industry). The device codes just call up
these predetermined tables in the available code
database, hard-coded into the remote's firmware, and
they set them in active memory. There is no special
"standardization" for these device codes (although
there may be for the IR codes themselves, but not
necessarily for the protocol a URC uses to access these
codes). Every manufacturer has their own database of
code tables in their remote's firmware, and use
different device codes to represent these IR code
"tables". So the manufacturer of the equipment you use
the IR codes with has nothing to do with any other
company's URC's "device codes", and I predict they will
just look at you with a blank stare if you ask them
about "device codes".

The number of IR code tables in any given OFA remote is
limited from the onset (and may only be enhanced if the
remote has built-in "upgradability"). So you can't just
punch in any old number and expect to bring up a piece
of equipment not listed in the manual. The "device
codes" are just like page numbers (for IR code table
data), and OFA has no incentive in "hiding" extra page
numbers from their customers. The EFC's (otherwise
known as the infamous "advanced codes") are a different
matter. They do not represent tables of IR codes, they
*are* the IR codes represented in the device code
tables. They (the EFC's) represent direct "frequencies"
which your remote uses to talk to your equipment (the
parameters for these "frequencies" being defined by the
particular device code in operation). This is the only
area where you have room to play around, to find codes
not listed in the manual, or indeed, not listed by
OFA's "generous" donation of EFC code tables to those
lucky enough to receive a response from them when they
are requested. My guess is that OFA's method of
identifying the function of these EFC codes is less
than "meticulous", meaning it is done manually. Because
some functions only demonstrate an action during
certain modes, perhaps this is why some EFC codes never
make it to their EFC tables, or perhaps they are missed
for other reasons. In any case, it's usually not a lot
of codes that would be missed from their EFC tables,
but I think it's worth the 15 min. to find out if any
are.

It is entirely possible that an EFC code in a family of
device codes similar to the equipment you have (that is
not already supported by OFA device code tables) will
control a function or other on your unsupported
equipment. For example, I have a friend who has a Sony
VCR and a Zenith tv. Every time he operates a certain
function on the VCR, a certain function on the TV
responds. Both, apparently, utilize the same IR
'frequency' (so much for the notion of industry
standardization....). Whether you will be able to
control ALL functions by stabs in the dark to find
frequencies that will control the functions on your
unsupported equipment is another matter. I wouldn't
think there are no limitations to OFA's EFC code
capability. Even if we're just talking about all the
advanced functions on a *supported* component.
(However, I must say that I do not yet have any piece
of equipment that I am not able to get the Cinema 7 to
yield every single original function on the component's
remote via EFC codes, and often MORE than the number of
original functions). If you have found a piece of a/v
equipment not supported by the OFA and there are
similar components that are supported by the C7, you
might want to spend some time checking out all the EFC
codes for similar components to see if your
equipment will respond to those frequencies.

A device code selects three things:

1. An IR protocol for sending some number of bits
(usually 32) to the device.

2. The contents of the bits that never change
from button to button. (the device ID bits --
These are to minimize the likelyhood that a
remote will accidentally activate a function on a
different remote controlled device, like your TV
remote's power button making your VCR rewind, or
some such thing.) There are often 24 such bits,
and they are often the first 24.

3. A set of default key mappings. This might
say, for instance, that EFC 123 is on the play
button by default, and that EFC 083 is on the
stop button, etc. This is partially to save
programming memory by doing the obvious stuff for
you, but mainly to make the remote easier to use
for those not technically inclined.

There is not enough room in the digits of a
device code to hold all of this information.
Therefore, the device code is simply an index
into a table inside the remote's ROM. When you
enter a device code, it looks up in this table
which protocol to use, what device ID bits to
use, and which EFC's are assigned to which keys
by default.

Now, it is possible that you may find a device
code that activates the correct IR protocol AND
device ID bits for you device, but a completely
wrong default key map. I know, as it happened to
me. I have an unsupported stereo system/surround
sound decoder, but I found more than one device
code which would work exclusively via EFCs, and
which could thereby COMPLETELY control the
device.

Ironically, after documenting all the EFC's
(advanced codes) for all the functions of that
device, I found that I would be better off using
learning memory, because I wanted some main
memory left over for macros and such. :)

-=Ingenious=-