JP1 Remotes

This topic has been split off from this original topic:
http://www.hifi-remote.com/forums/viewtopic.php?t=7474

The Robman wrote:I've updated the KM file, so give it another try. The official code for this set is TV/1755 which uses the "Emerson Combo (4 dev)" protocol (and I've loaded the official version here).

The official protocol has code in it that you don't need, so I scalled it down somewhat for the version I want you to test.

OK -- here's the results: The UEI official upgrade works almost perfectly (more about that shortly). Your version works except for all the functions which have byte2 = 2. Both versions have a minor flaw -- the closed caption selection (ccd) function has the same coding as the mute function. It's the mute function which is correct. I have verified that the two definitely have two distinct functions on the original remote.

I also went back and verified that your first pass works neither in my 8811 nor in my 9910. Finally, I have isolated the cause of my problems with getting the TV upgrade to work with the 9910 to my use of RemoteMaster. With Keymap-Master I have no problems at all but if I convert the upgrade for RemoteMaster the upgrade code it outputs is different and has significant problems -- it would seem that there's something in this protocol that RemoteMaster simply can't handle.

So, do you still want me to create an IR file with some learned buttons from the original remote? I was thinking of learning the CCD command at least, to see if I can find a code for it.

Again, thank you for all of your help. I really appreciate it.

- Les

I tried loading the linked upgrades in RM v1.72, and the upgrade code is the same as what I see in KM (other than the embedded comments).

The upgrades I tried:
Sampo-PME42S6-plasma (ver3)
TV-1755

The Robman wrote:

gfb107 wrote:I tried loading the linked upgrades in RM v1.72, and the upgrade code is the same as what I see in KM (other than the embedded comments).

The upgrades I tried:
Sampo-PME42S6-plasma (ver3)
TV-1755

Greg,
The upgrades should be the same, but the protocol code should be different. My protocol code is smaller.

Yes, there are differences between the two files. But for each file, I see no difference in the output generated by RM and KM (other than embedded comments).

Here's the protocol code generated by my upgrade...

Upgrade Protocol 0 = 00 65 (S3C8+) Custom Protocol for TV/1755 TV/1755 (KM v9.06)
43 8B 41 8B 12 C3 45 06 06 01 A3 01 90 01 A3 04
D3 C4 36 06 8E 06 78 18 07 19 04 19 06 60 06 56
C1 03 87 21 03 29 03 37 20 05 B6 C2 E4 8B 02 60
C2 29 05 8D 01 46
End

and here's the protocol generated by the UEI upgrade...

Upgrade Protocol 0 = 00 65 (S3C8+) Custom Protocol for TV/1755 TV/1755 (KM v9.06)
45 91 41 8B 14 C3 45 06 06 01 A3 01 90 01 A3 04
D3 CC 6A 06 8E 06 78 C4 36 18 07 56 C1 03 87 21
03 29 03 E4 07 04 E4 07 06 60 06 37 22 0F E6 0E
43 E6 0F 8B F6 01 55 E4 22 1C E4 23 1D 37 20 05
B6 C2 E4 8B 02 60 C2 29 05 8D 01 46
End

The first one is 54 bytes long, the 2nd one is 76 bytes long, so even with the naked eye you should be able to see that they're not identical.

I think Gregs answer was based more on what this seems to be saying.

I have isolated the cause of my problems with getting the TV upgrade to work with the 9910 to my use of RemoteMaster. With Keymap-Master I have no problems at all but if I convert the upgrade for RemoteMaster the upgrade code it outputs is different and has significant problems -- it would seem that there's something in this protocol that RemoteMaster simply can't handle.

The upgrade doesn't change for me either if I use rm or km.

whompus wrote:I think Gregs answer was based more on what this seems to be saying.

If you're trying to replicate Les's problems, keep in mind that he's not opening the upgrade using RM, he's using the Raw Import function to copy the upgrade from his URC-8811 IR image over to RM...

lnoland1 wrote:I used the raw code from the 8811 upgrade as seen by IR and imported it into RemoteMaster, creating a new upgrade.

Ah...

Importing a raw upgrade can easily be done incorrectly, which could explain the above problems.

It is always better to import the original KM file (if you have one) than to import the raw upgrade.

The common mistakes are:

• Setting the remote to the target remote rather than the source remote
• Setting the device type incorrectly
• Leaving out the protocol code when there is an associated protocol upgrade, especially when it reuses a built-in pid.

Unless someone can convince me otherwise, I'm going to chalk this up to user error.

Yeah.. Thats what I was thinking. I am always looking to learn more from you guys. So what I did was load it into my 8811 to see if maybe the remote was changing something on upload. Then imported raw from it.

gfb107 wrote:Ah...

Importing a raw upgrade can easily be done incorrectly, which could explain the above problems.

Actually, I tried several approaches without success. One thing to note, howver, is that the upgrade I was having the RemoteMaster troubles with was the original upgrade based on the protocol that Jon Armstrong had prepared for me, not the ones which Rob had created (the problems I had with those were, so far as I know, unrelated to the problem I spoke of.)

To demonstrate the problems I was having I have provided some pictures. In this case the actual upgrade file is not the one which is available in the files section here but one based on that, after I had assigned the keys the way I wanted them but I have little doubt that the upgrade in the files section will have similar results.

Here is an image of Keymap-Master after loading my upgrade and changing the remote:

http://www.wideopenwest.com/~lnoland/im ... pgrade.jpg

Now here is an image from RemoteMaster after loading the same .txt file, changing the remote, and nothing more:
http://www.wideopenwest.com/~lnoland/im ... pgrade.jpg

As you can see, the protocol code is the same, but the upgrade code is quite different.

Now compare these two IR files for which I simply took blank IR files and then imported the protocol and upgrade -- in the first case from KeyMap-Master and in the second case from RemoteMaster:

http://www.wideopenwest.com/~lnoland/im ... pgrade.jpg

http://www.wideopenwest.com/~lnoland/im ... pgrade.jpg

See how different the various keycodes are? Something about this protocol or upgrade is not being handled properly within RemoteMaster. None of my other upgrades had such problems -- I used RemoteMaster for just about everything up until that point.

- Les

Ahh... This may or may not be the difference. RemoteMaster has been updated 3 times from the version you are running. Get Rm 172 here In the software section. I found the reverse of you with these files. My km was older version. Km did give me a pop up letting me know it was.

whompus wrote:Ahh... This may or may not be the difference. RemoteMaster has been updated 3 times from the version you are running. Get Rm 172 here In the software section. I found the reverse of you with these files. My km was older version. Km did give me a pop up letting me know it was.

Well, I downloaded version 1.72 and tried it again but it still had problems. It appears that a byte may have been inserted (or deleted -- I don't recall which way the shift went) in the process as the commands appear to be shifted by a byte down the line.

- Les

Yeah, now that I found the original upgrade file, I see something a bit unusual. Not in the protocol itself, but in how the commands were entered.

The protocol uses 3-byte commands, which is fine. For Manual Settings, 3-byte commands are normally entered as hex directly in the EFC (or OBC) column. In this case, the first byte is in the EFC column, and the next 2 bytes are in the byte2 column. RM doesn't handle this unusual situation correctly.

Looks like someone else thought it was unusual too, because there's a version with the 3-byte command entered as hex: Sampo-PME42S6-plasma HEX. RM handles this one well (not perfectly, though: the 3-byte hex is imported correctly, but RM only creates a "Byte 2" column, when a "Byte 3" column is also needed, so the third byte can only be changed in the "Hex" column)

I'll have a fix out shortly.

RM v1.73 handles this unusual situation correctly.

As the original thread had basically divided into three seperate discussions, I have split the thread accordingly as follows:

1) Upgrade memory full - need help
http://www.hifi-remote.com/forums/viewtopic.php?t=7474

2) Sampo PME42S6 plasma TV
http://www.hifi-remote.com/forums/viewtopic.php?t=7503

3) RM problems with 3-byte protocol
http://www.hifi-remote.com/forums/viewtopic.php?t=7502

gfb107 wrote:Yeah, now that I found the original upgrade file, I see something a bit unusual. Not in the protocol itself, but in how the commands were entered.

The protocol uses 3-byte commands, which is fine. For Manual Settings, 3-byte commands are normally entered as hex directly in the EFC (or OBC) column. In this case, the first byte is in the EFC column, and the next 2 bytes are in the byte2 column. RM doesn't handle this unusual situation correctly.

Looks like someone else thought it was unusual too, because there's a version with the 3-byte command entered as hex: Sampo-PME42S6-plasma HEX. RM handles this one well (not perfectly, though: the 3-byte hex is imported correctly, but RM only creates a "Byte 2" column, when a "Byte 3" column is also needed, so the third byte can only be changed in the "Hex" column)

I'll have a fix out shortly.

Yeah, the upgrade always seemed like an odd duck -- it looked strange when loaded (particularly in some of the early tools) and Jon cautioned that I'd be limited in what modifications could be done to it, etc. And, of course, it was kind of big. Rob's version is much nicer.

- Les