JP1 Remotes

Ereth · Joined: 07 Dec 2003 Posts: 10

Aha! The light bulb begins to go off.

I had wondered for years how it was that all these remotes didn't interfere with each other, assuming that each manufacturer was sending some sort of encoded signal that was unique to it (in a similar fashion to morse-code, really, ie, 1 was this set of pulses and 2 was a different set of pulses, etc). I figured it was only a matter of time until someone used a code for their device that someone else had used for a different device and remote chaos would take over.

Obviously that didn't happen and now I begin to understand why. Is there a standards group that assigns these codes/protocols, or is it pure chance that the manufacturers came up with a system that allows them to interoperate this way? (I warned you I was a geek)

[Edit: re: decodeccf.. I looked in Tools and never looked in programs. D'oh! Thanks for the pointer. Some days I'm a total idiot. Sorry about that].

The Robman · Posted: Mon Dec 08, 2003 3:35 pm Post subject:

gfb107 · Expert Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC

Also some Zenith TVs and TiVos
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

The Robman · Posted: Mon Dec 08, 2003 4:07 pm Post subject:

johnsfine · Posted: Mon Dec 08, 2003 4:10 pm Post subject:

I've been surprised that we (the various remote control forums) see so few reports of conflicts. But we certainly do see some reports.

There are a lot of different protocols and in the common protocols there are a lot of different device numbers. A typical end user has very few devices together, so even with no attempts at control conflicts would be rather rare.

Most of what we know about IR signals is from reverse engineering the signals themselves, not from official documentation, so we can only guess at topics like this one.

Surprisingly few IR signals have any inherent confusion across protocols. I expect anyone inventing a new protocol would make some attempt to avoid such conflicts with previous protocols. But most protocols seem to have been kept secret until the recent internet sharing of IR data seems to have convinced many companies either that the secret can't be kept anyway or that the benefits of sharing the information outweighs the harm. Before that I don't know how a designer of a new protocol would get data on old protocols. I'd be amazed if there were a governing body across multiple protocols.

Where we have seen reports of IR confusion across protocols it almost always is across protocols with no structural similarity and no understandable reason for the confusion. I don't know what to make of those case, but they're rare.

Some IR protocols are clearly the intellectual property of specific companies. The RC-5 and RC-6 (Philips if I remember correctly) are clearly documented as such. That gives the company the power to manage the device numbers when licensing the protocol. RC-5 numbers used by companies other than Philips seem particulary badly managed and that is the place I'd most expect strange conflicts (though I don't remember reading about too many). So having the ability to manage it doesn't mean that they do.

There is considerable reverse engineering evidence that someone is managing the device numbers in the NEC protocols to avoid these problems. But I haven't read anything that says who is doing it (some governing body, some standards group, the owner of the intellectual property, ??). There is also a fair amount of evidence that their enforcement has gaps, because a few companies use NEC protocols in a way that looks like a violation of what we infer as the rules coming from wherever. Remembering all this is just inferred from reverse engineering the signals not from real knowledge, Rob's example of Goldstar would have been number one on my list of companies that look like they're using NEC protocol without listening to any governing body.

There is also a Kaseikyo governing body with a family of protocols and clearly defined rules for companies to use those protocols with no overlap across companies (overlap within a company is clearly up to the company to decide about). But all of the Kaseikyo we see in the USA and Europe doesn't add up to much fraction of the total code sets, so their being well managed doesn't skew the total. (The main Kaseikyo protocol we see is "Panasonic").

There are also a few companies with robustly different protocols that they use themselves and others don't use, so they can manage any overlap issues on a single company basis. The extreme example is Sony. They sell virtually nothing that uses IR remote control that doesn't use one of their own protocols and virtually nothing that does use their IR protocols is sold under other brand names.

gfb107 · Expert Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC

usblipitor · Joined: 10 Oct 2003 Posts: 516 Location: Greenbelt, MD

Ereth · Joined: 07 Dec 2003 Posts: 10

Ok, I tried CD/0028 and while it's promising, it doesn't actually suceed. After trying the codes listed here, I built a simple spreadsheet and went through all the EFC codes one at a time, to see what I could find. There are clearly codes here to do things on the front panel that I cannot do from the remote, but not all the codes I need are here. I'm hoping that this is because CD/0028 has no subdevices? In any case, some of this is similar to 0313, but not all of it. There's a paucity of actual results, maybe this will mean something to one of you. Here's the actual results I get from trying P-xxx with CD/0028 in the remote:

000 - Power on/off toggle
003 - Volume up
040 - Speaker Delay
066 - Switched to Tuner
102 - Test Tones on/off
106 - Left Speaker adjust
114 - Stereo
190 - 198 - Presets on the tuner, selectable from buttons on the front panel
242 - Surround sound
248 - On Screen INFO (what radio frequencies were set in the presets, how each speaker was adjusted)
252 - Mute
254 - Direct Tune to a frequency (this let me type in numerals to pick a radio station directly, rather than scanning, or going to presets)
255 - Volume down

I have ordered the JP1 cable from filebug, and he says it'll ship tomorrow. I'm thinking that these codes are promising enough that there likely IS discrete codes for what I want, but not in the CD/0028 set.

Does this make sense or am I missing the boat?

usblipitor · Joined: 10 Oct 2003 Posts: 516 Location: Greenbelt, MD

A lot of your codes match those found in devices4. Have you tried the codes for the numbers 0-9 with the device in a mode that is expecting to see numbers?

Ereth · Joined: 07 Dec 2003 Posts: 10

Yeah, once I was in Tuner mode, when I did those codes 0-7, it selected the various tuner presets (ie, different radio stations). I didn't have it in Tuner until 066, so the 061 and 065 might have been presets too, but I wouldn't have seen it.

The fact that I got a menu item for Left Speaker Delay, and no other speaker makes me wonder if there's other codes for the other speakers, or if that's a toggle and goes through them. I should've tried it again (it was late, didn't think of it).

Regardless, the codes I did find seem incomplete, and I'm hoping there's more codes in a subdevice or something.

If 1027 is device 71 instead of 184, is there a device 71 with subdevices code that I could use to see if other EFCs work, while I wait on my cable to arrive?

jamesgammel · Posted: Tue Dec 09, 2003 11:18 am Post subject:

Devices.xls doesn't list "device 71" in any position for a Nec1 protocol. If there is one, it's newer than a 1994. You could probably create one with KM or RM, but without a cable I don't know of a way to get it into your remote. Maybe someone knows of a newer standard one that has it for your newer remote.

Jim

Ereth · Joined: 07 Dec 2003 Posts: 10

Oops, I misread what John said. It's subdevice 1 and 71 that is in the 1027 setup code.