Hello,

I have been playing with a number of the IR utilities found in the files forum, and I have a few questions. Mostly, I've been trying to generate "clean" remote control codes to load into my system ccf; I've also been looking for hidden discretes.

First, I was trying to generate the full IR code list for my Panasonic DVD-RP91. Both ProntoUtil and MakeHex support Panasonic products, however I don't know what device number it is. IRTool does not support Panasonic. Is there any straightforward way for me to figure out what device this is?

Second, I was trying to generate the full IR code list for my Kenwood VR-507 A/V receiver and CD-425m CD Jukebox. Neither seems to be straightforward. Kenwood is supported by ProntoUtil and IRTool. IRTool Identified the VR-507 as device #184. The codes produced by ProntoUtil mostly worked, but there were 10+ codes on the remote that weren't included in device #184. This includes discrete codes for tuning Video 3 and DVD. When I try to decode these buttons with IRTool, I either get Raw/Unknown or a couple of device numbers in the 600+ range. IRTool identifies the CD-425m as device number 182, however none of the codes in #182 does anything when broadcast at the CD-425m. Does anyone have any idea what might be going on here?


Thanks,

Joe

You should use the JP1 version of IrTool, not the one available at RC.

You need to join the Yahoo JP1 forum to get that file from
[Link: groups.yahoo.com]

Hopefully it will be moved soon to the new JP1 file archive at
[Link: hifi-remote.com]
so people will be able to get it without joining Yahoo.

To use that IrTool, you also need my DecodeIR.dll
[Link: john.fine.home.comcast.net]


The JP1 IrTool does support Panasonic.
The RP91 (and every other Panasonic DVD with data in the RC CCF file collection) uses Panasonic protocol, device 176.0


In MakeHex and in the JP1 version of IrTool, the Kenwood protocol is called NEC1. The old IrTool gets confused between NEC1 with a subdevice of 0 and NEC1 with no subdevice (the subdevice field then holds a check byte equal to 255 minus the device number).

Kenwood receivers typically use device 184, but with a mixture of subdevices, definitely including subdevice 0, and maybe including no subdevice. To search the full set of codes you'd need to search 256 codes for each subdevice at least from subdevice 0 through 4.


For subdevices that are neither 0 nor null, IrTool reports a device number of 256*subdevice+device, so for subdevice 2 you'd get
2*256+184 = 696


Kenwood CD's are typically device 182 with NO subdevice. That is 182 as a device number in MakeHex. Were you using 182.0 instead? Subdevice 0 is NOT the same as no subdevice. The old IrTool is just confused. It reports device 184 for the reciever where most commands are really 184.0 and reports 182 for the CD where it really is 182, not 182.0

This message was edited by johnsfine on 10/19/04 09:45 ET.

Thanks, John.

I'll try playing with these new tools tonight.

Boy, there is a lot of stuff out there!

I consider myself fairly "fluent" in home theater/technical stuff -- and I wasn't aware of half this stuff (I remember when the JP1 interface came out -- I thought it interesting because I used UEI remotes which had to be reprogrammed for Kenwood and ReplayTV devices, but I never thought it would get so well developed!).

take care,

Joe

John,

Thanks for your tips -- the "missing" IR functions for the receiver were indeed found in 184.1, 184.2, and 184.3, and the IR codes produced for the CD jukebox device 182 using MakeHex worked without any problems.

I found something new -- I have a Chinese DVD player imported/labeled by Curtis International of Canada, model DVD-1030. It is identified by IRTool/DecodeIR as NEC1 Device 1. Sure enough, the codes produced for this device via MakeHex control the player. Is there anything significant about NEC1 Device 1? Do Chinese players (i.e. Apex and clones) typically use this device? Do you know if it might include any discrete power commands?


Thanks,

Joe

I have a lot of DVD upgrades from the JP1 group in a folder on my computer. That includes 11 upgrades using NEC1 protocol, device 1. I don't know if the brands are made in China (though it seems likely). These upgrades include:
1 Jaton
1 KLH
1 Koss
1 Magnavox
1 Poloroid
1 Tevion
5 Malata

I also have lots of Apex upgrades, using NEC1 protocol with a few different code sets, but none of those are device 1 (many are device 4).

I don't know how NEC handles reserving device numbers. I expect most of these DVDs using device numbers 0, 1 and 4 haven't reserved the numbers and are just using them. I think someone explained to me that device 0 is supposed to be used that way (unreserved and at the manufacturer's onw risk for and conflicts with other brands).


Discrete power commands are pretty rare in DVD players.

You could download the JP1 upgrades and the RemoteMaster program and check for yourself. I have automation set up for a number of different search types in my library of IR signals, but NOT for anything like a search JP1 upgrades by function name.

John,

I've pretty much rebuilt the entire set of IR codes I'm using in my pronto ccf from the "clean" MakeHex generated codes. Things seem much more "responsive" (commands are missed less frequently).

The one device I have left that I don't know how to generate IR codes from is my ReplayTV PVR (an older 3000 series unit).

Can you explain how one would build an irp file for the Replay? My understanding is it uses its own protocol (or is that an incorrect understanding)? I know there are JP1 upgrade files for it.

Also, I've noticed some references "condensed" hex codes -- codes which look VERY short. What are these and how are they used? I run into memory problems integrating my 200 disc jukebox into my system CCF with Supernudelist -- might I be able to save memory by "condensing" some of the IR codes?

Thanks,

Joe

This message was edited by DrJoe on 10/24/04 15:07 ET.

I wasn't at the right computer to provide an answer today (because I forget what IR signals Replay uses). I thought one of the other experts would jump in by now. I'll be at the right computer to answer this tomorrow.

I don't recall how these signals may vary by model, so I'm not certain I'll find the right data for an unambiguous answer. If you post any sample of Pronto Hex I can decode it to give a definite answer (that wouldn't need the data from that other computer).

One of the experts did jump in, Rob of HiFi-Remote. com informed me that the ReaplyTV uses the RC6a protocol, and that Pronto Edit could generate it exactly. He also emailed me the device #'s for the supported functions.

Thanks,

Joe

John,

Could you answer the second portion of my question?

There seem to be two kinds of codes -- some which are longer than others. The long codes begin with 0000 while the others begin with 5000, 6000, 900A and only consist of 6 groups of 4-digit numbers.

Are these equivalent? Is there a way to translate from the long form of the code to the short form? Would it be possible to save CCF memory by utilizing the "condensed" codes?

Thanks,

Joe

Those others are for three specific IR protocols. Only signals of those specific protocols can be translated into that form. In some models of Pronto, under some conditions, that translation is automatic when the learn is clean enough for the software to recognise it.

5000 is for RC5 protocol.
6000 is for RC6 protocol.
900A is for NEC1 protocol.

RC5 and RC6 have a special feature intended to accurately read long presses vs. multiple short presses of the same key, even when the remote is badly aimed and some frames are lost. The 0000 form of those protocols breaks that feature, so multiple sequential presses of the same key will be misinterpreted as one long press (usually making it seem like all but the first is being ignored). Thus 5000 and 6000 formats not only save space, but also make it work better.

In some models of Pronto (for NEC1 protocol only, of course) you can save a little CCF space by using 900A form instead of 0000.

I don't know of any tool other than some versions of ProntoEdit for translating. If that's not the version of ProntoEdit you'd use normally, using a second version for that translation may be quite impractical.

The 0000 form can be translated to protocol name and Device and OBC numbers by DecodeIR with IrTool or DecodeCCF. The experts can translate from protocol name, device and OBC to 5000, 6000, or 900A (and a few less common forms) in their heads. It isn't much more than remembering which pattern is which and converting from decimal to hex. But instructions are scattered around various threads, not written anywhere clearly.

I have seen some discussion of a condensed form for RC6a. But I think that is used only internal to some version of ProntoEdit and never loaded into the Pronto condensed.