JP1 Remotes

[silron1]

First, thanks for all the help - wonderful group

My latest prob.

I have a KM upgrade using Panasonic Combo2 protocol - In IR, upgrade code goes into add device tab and upgrade protocol code goes into add protocols tab. Remote works fine!.

Opening RM and using the correct import procedure offered, I convert the KM .txt to RM. No upgrade protocol code appears in the RM output tab and all my sub devices in byte2:sub dev that I entered in KM are shown at 0. As expected this RM output will not work in the remote.


Ron

[Mark Pierson]

[johnsfine]

IIRC, there are a few different Panasonic combo2 protocols floating around. When I set up protocols.ini for those I tried to select the built-in version where possible. KM also uses the built-in version in most cases where it can, but I remember at least one case in Panasonic combo2 where it didn't.

I'm sure Mark is right about the byte2 entries. RM tries to express those in ways that are a better fit for the protocol being generated, but that often means it can't translate from KM's version, especially if KM selected a different variant of the protocol.

[silron1]

OK - I will put in the byte2 sub devices manually into KM on an import from KM
Regarding the correct remote - this is what I mentioned in my previousl post the URC 8060 at present is not correct . I have been in contact with Nils who is working on it just now so hopefully this issue should resolve itself when he finishes the new .rdf.
I will let you know the outcome.

Ron

[gfb107]

If you can post the KM .txt file either as a Devices Upgrade or in the Diagnosis folder, I can take a look and see if there is something wrong in the import code. It may well be that you are the first one to try importing a 2-byte upgrade.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

[silron1]

Have just uploade file to Diagnosis folder under SC-HT500_DVD
NB. no conversion from km to rm

[gfb107]

OK, I've found the bug in RM with importing byte2. I have that part fixed, and can release a new version as soon as we deal with the following:

Now comes the discussion in the differences between RM and KM when it comes to the "Panasonic Combo2" protocol for the URC-8060, which are significant.

RM uses the built-in protocol, KM does not.
RM has 3 device parameters: Main Device (default=160), OEM Dev1(=2), and OEM Dev2(=32)
KM has 4 device parms: Main Device(=160), Sub Device(=0), OEM Code1(=2),OEM Code2(=32)
RM has 2 fixed data bytes, KM has 4, reflecting the difference in dev parms.
RM and KM disagree about the order of the bytes in the hex cmd:
RM puts the EFC/OBC in the 2nd byte, with the Sub Device in the first byte. KM does the reverse.

For example for number 0, where EFC=249, byte2=28, OBC=25, RM computes the hex to be "c7 67", but KM computes "67 C7".
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

[silron1]

Fine - please remember I am just a beginner at this (JP1).

Reading your post, at this point, I must opt out leaving it to the experts.

Will be more than pleased to try your final effort


Ron

[gfb107]

Have you tried the upgrades generated by KM and RM? Do they both work? In this case there may be more than one way to generate a valid upgrade.

Here's the code RM generated with my fix. Note that I didn't do anything about the function-to-button assignments that weren't handled automatically:

[silron1]

Wonderful - your piece of code worked

Look forward to downloading the new RM so that I can try another conversion from KM


Ron

[Nils_Ekberg]

We are kind of hitting you from both sides today with tests on this and the RDFs/maps. Hope you are having fun..
_________________
Nils
Files Section
Diagnosis File Section

[gfb107]

OK, so we're just going to chalk this up to a VALID difference in behavior for RM and KM, and leave it at that. The cool part here is that even though the protocol variant aren't the same, the import still worked. This won't always be the case, but isn't it nice when thing work the way you want?
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

[johnsfine]

Unless we made serious errors you would expect both variants to work. They are both valid ways of generating the same signal.

One relies an a protocol built into the remote and uses that correctly. The other correctly uses a protocol that isn't built in and correctly provides that protocol as an upgrade.

In importing old and/or KM files, it would be nice if RM figured out which specific protocol was in use and performed the import for that protocol followed by a translation to the acceptable one. Protocols.ini does contain two variants of this combo2 protocol. But I'm not sure that the "other" one is the one KM used (if not then I should have put a third one in protocols.ini) and I'm not sure how RM should know (on import from KM) which variant was used.

Maybe I misunderstood this thread. You said "the import still worked". But I thought the point of earlier messages was that the import hadn't worked.

[gfb107]

[silron1]

[You said "the import still worked". But I thought the point of earlier messages was that the import hadn't worked.]

It only worked after it was debugged