JP1 Remotes

I'm working on it, but I don't know what I'm doing, and don't even know if it is possible to get a working RDF. I'm sure that we don' t have enough information to determine it completely. I assume that will have to have some inspired guesses.
I too had put the WAV file into IR, and tried to make a test RDF from the URC 8206; without that IR couldn't even read in the data, and I still get an access violation, but that comes after the data is read. The remote signature is 11421142, and I can see each of the three upgrades. We also have a raw IR file from a 8305, which I hoped would help, but it looks like it uses a different processor (or IR isn't getting that part right).

I've read the WAV file directly into an Excel spreadsheet, which makes it easier to search on bytes, and to copy the individual upgrades into RM. But that just proves that my guess at button maps was wrong!

We can make a pretty good guess at the EFCs and key assignments for the 1531 and 823 upgrades, so I hope that I can figure out most of the button maps. By the way, I don't see 1531 in the list of known setup codes. Any chance it is really 1571?

Hi,

Binky123 is also looking at it. I hope you both get any result. Today the new remote arrived and i tried the ext. codes again. Same result. So it seems a bug or something else is wrong in this type of remote.
Gonna e-mail all for one to get it figured out.

3FG wrote: ... it looks like it uses a different processor (or IR isn't getting that part right)...

I'm staying out of most of this thread and just lurking, but as a long time user, I'd caution you to keep in mind what info IR actually READS from the remote, and what info it GETS FROM THE RDF. I'm pretty sure that IR doesn't "figure out" what the processor is when you download from the remote. If there is an RDF, IR gets the processor info from that. If there is no RDF, that display is meaningless. (I believe that IR simply displays the last processor type that was used in IR). So don't get sidetracked by IR's "Processor" disply on the last tab. It is not a diagnostic tool.

3FG wrote:I'm working on it, but I don't know what I'm doing, and don't even know if it is possible to get a working RDF. I'm sure that we don' t have enough information to determine it completely. I assume that will have to have some inspired guesses.
I too had put the WAV file into IR, and tried to make a test RDF from the URC 8206; without that IR couldn't even read in the data, and I still get an access violation, but that comes after the data is read.

3FG,

Not sure how much experience you have with IR.exe, but you CAN ABSOLUTELY read a download without an existing RDF.

Go to the Advanced Menu and check "Enable Raw Download". This enables IR to read the file and display it using only 2 tabs "General and Raw Data". IR can then determine the signature for you, but not the processor (if I understand correctly).

Hi,

Just got an e-mail back from OneForAll.
It's a bug in the revision i have.
3 revisions exist.
URC 8308Chip version
1115 = R00
1142 = R01
1158 = R02

1142 has this bug. 1115 does't have this (but they don't have that one anymore)
So i cant set Ext. Codes. Only option is to use the "learn" function. But as i don't have a remote that has the function for discrete input select i am stuck..................sux bigtime.

Well, I'll try it again, but using Raw Download didn't work for me. Maybe I didn't do it right. I don't know enough about the upgrade format to know whether processor type is embedded in it or not. Obviously the signature is--it's the first 8 bytes-- and I assume that UEI wants that info to avoid loading an incorrect upgrade. I had thought that perhaps a processor byte might also be in the upgrade.

The reaon I thought the processor type may be embedded is when loading the 8305 IR file, the indicated processor type changes from the S3F8 that is usually there when I'm playing with my own remotes.

I'll check it more carefully. In any case, unless there is something in IR that I'm missing, having the upgrade in Excel is more useful to me. It is easier to find setup codes in the string of data for example, or 2 byte hex data.

I did post a RDF here.

I believe the keymover(direct efc or hex cmd) has bugs in it as it seems to use an extra byte. For example, a direct keymove is 2-byte setup code + keycode. It seems to want 2-byte setup + keycode + real-keycode. For the hex cmds, it wants 2-byte setup + hexcmd1 + hexcmd2 + hexcmd3 where it uses hexcmd2 + hexcmd3 as the bytes to send the EFC.

You might be able to test this out by using the RAW tab and modifying the data.

Also, creating a device upgrade with the input select codes may work as well but I'm not certain.

Also, someone else can learn the Sony input code, post their IR file and you can cut-n-paste the learn code into your URC-8308 Learn section.

Capn Trips.
Apparently I'm doing something wrong. Running IR 8.01, if I don't have a RDF file available, then simply opening this Wav file (linked earlier by Gup in this thread) gives me a dialog, and switches to just two tabs. Same behavior if I import a Wav file. If I click on Enable Raw Download, or Unsafe Upload (!), and then open the file, there's no complaint about the missing RDF. But for each of these ways of opening the file, the raw page is filled with FFs, except for 4 bytes, which are 4 digits of the signature. With a cobbled RDF, I can get the raw data, although there is also an access violation.

If I start with IR showing 30393039, S3F8, and JP1.3 on the raw page, then using the cobbled RDF, info changes to 30393039, HCS08, JP1.2. The indicated remote processor type changes, but the indicated signature does not, even though I can see it in the raw data.

3FG wrote:Capn Trips.
Apparently I'm doing something wrong. Running IR 8.01, if I don't have a RDF file available, then simply opening this Wav file (linked earlier by Gup in this thread) gives me a dialog, and switches to just two tabs. Same behavior if I import a Wav file.

That is what you are supposed to get. The RDF defines all of the other stuff, so if there is no RDF, no memory allocations can be determined, there is no way for IR to figure out if there is a Volume lock, or any other such thing. All you see is the Raw data from the memory on the Raw Data page. It usually contains the signature at the beginning, and then you can ususally sort out the various memory allocation boundaries

If I click on Enable Raw Download, or Unsafe Upload (!), and then open the file, there's no complaint about the missing RDF. But for each of these ways of opening the file, the raw page is filled with FFs, except for 4 bytes, which are 4 digits of the signature.

From the file you posted, one can concluded that the upgrade memory area starts at 0400, since taht's where the upgrades begin.

With a cobbled RDF, I can get the raw data, although there is also an access violation.

I don't know about access violations, as the file you uploaded earlier opens fine for me in IR, it just has no RDF, so it opens with only the two tabs, with data that is unadulterated by any rdf.

If I start with IR showing 30393039, S3F8, and JP1.3 on the raw page, then using the cobbled RDF, info changes to 30393039, HCS08, JP1.2. The indicated remote processor type changes, but the indicated signature does not, even though I can see it in the raw data.

If you use ANY RDF - cobbled or final, it will have an procesor type entry somewhere in it (I haven't seen this RDF you're using), so that is where IR gets that info from. If you have NO RDF that matches the signature, then IR will simply "keep" the last used processor type (from my experience).

Capn Trips,
Thanks. I'll try re-downloading IR 8.01 and also the released version to see if that will fix the access violation.

I think my last post wasn't very clear. Here's what I was trying to say: I read your second post in this thread as implying that Enable Raw download had to be checked in order to read raw data. I was pointing out that it isn't apparently necessary. And yes, I can see that IR gets the processor info from the RDF. What's interesting to me is that IR didn't change the displayed signature (in the case of this one wav file) even though it clearly read the signature. Perhaps that is a consequence of the access violation I am seeing.

3FG wrote:I read your second post in this thread as implying that Enable Raw download had to be checked in order to read raw data. I was pointing out that it isn't apparently necessary.

If you're referring to importing a .wav file you are correct. Enable Raw Download only affects downloading from a remote AFAIK.

Gup reports that the following works.
23109 AV1 02 80 Learn data:
1F 24 1B 00 C8 04 01 2C 34 A4 04 B0 01 34 02 58
01 32 01 2C 01 32 8D 13 33 33 32 23 33 00

22085 AV2 82 80:
15 24 1B 00 C8 04 01 2C 33 78 04 B0 01 34 02 58
01 32 01 2C 01 32 8D 12 33 33 32 23 33 00

22597 AV3 42 80:
16 24 1B 00 C8 04 01 2C 33 78 04 B0 01 34 02 58
01 32 01 2C 01 32 8D 13 23 33 32 23 33 00

21829 HDMI1 e2 80:
17 24 1B 00 C8 04 01 2C 31 1E 04 B0 01 34 02 58
01 32 01 2C 01 32 8D 12 22 33 32 23 33 00

55877 HDMI2 12 80:
19 24 1B 00 C8 04 01 2C 33 78 04 B0 01 34 02 58
01 32 01 2C 01 32 8D 13 33 23 32 23 33 00

54853 HDMI3 92 80:
1A 24 1B 00 C8 04 01 2C 32 4D 04 B0 01 34 02 58
01 32 01 2C 01 32 8D 12 33 23 32 23 33 00

Also, by using the following upgrade and device setup, he was able to fix the buggy keymove code in his remote. The device upgrade and protocol upgrade can be removed after using TV/1107 CH+ or CH-.