KM .txt files to RM

silron1 · Post by **silron1** » Mon Dec 08, 2003 5:31 am

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 · Post by **Mark Pierson** » Mon Dec 08, 2003 6:18 am

silron1 wrote: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.

One of the primary differences between KM and RM is the handling of byte2 details. Your only option is to manually correct the byte2 entries. As for the protocol code, is RM set to the correct remote?

johnsfine · Post by **johnsfine** » Mon Dec 08, 2003 6:47 am

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 · Post by **silron1** » Mon Dec 08, 2003 6:56 am

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 · Post by **gfb107** » Mon Dec 08, 2003 6:58 am

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.

silron1 · Post by **silron1** » Mon Dec 08, 2003 7:17 am

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

gfb107 · Post by **gfb107** » Mon Dec 08, 2003 9:10 am

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".

silron1 · Post by **silron1** » Mon Dec 08, 2003 9:23 am

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 · Post by **gfb107** » Mon Dec 08, 2003 10:14 am

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:

Code: Select all

Upgrade code 0 = 30 e7 (DVD/0231)
 cd 00 fe fe bc 3d bf fb fa
 c7 67 c7 f7 c7 77 c7 b7 c7 37 c7 d7 c7 57 c7 97
 c7 17 c7 e7 ff fb ff 7b ff b3 c7 ad c7 6d c7 43
 bb fc bb d3 bb 53 bb 13 bb 93 bb af b7 30 bb bf
 bb 3f bb ff ff 22 f7 3e ff 54 b7 1a bb 9c ff c6
 ff 86 df da ff 3a
KeyMoves
 9f f4 30 e7 bb fe
 95 f4 30 e7 c7 16
 96 f4 30 e7 bb 52
 97 f4 30 e7 bb 2a
 99 f4 30 e7 bb 22
 9a f4 30 e7 bb 33
 9b f4 30 e7 bb ec
 9c f4 30 e7 bb 1d
 9d f4 30 e7 bb 15
 9e f4 30 e7 bb dc
 52 f4 30 e7 bb 15
 18 f4 30 e7 ff d2
 67 f4 30 e7 ff 22
END

silron1 · Post by **silron1** » Mon Dec 08, 2003 10:40 am

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 · Post by **Nils_Ekberg** » Mon Dec 08, 2003 10:52 am

We are kind of hitting you from both sides today with tests on this and the RDFs/maps. Hope you are having fun..

gfb107 · Post by **gfb107** » Mon Dec 08, 2003 11:02 am

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?

johnsfine · Post by **johnsfine** » Mon Dec 08, 2003 12:15 pm

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 · Post by **gfb107** » Mon Dec 08, 2003 12:38 pm

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

It worked after my fix for byte2 (which isn't really influenced by the other differences in the protocols).

After reading your response and looking at protocols.ini, it looks like RM might have been able to use the same variant as KM if it searched for protocols using both the name and the PID. Right now it uses only the name, and because of that will always match the builtin protocol when there is one.

Another thing to add to the to-do list!

silron1 · Post by **silron1** » Mon Dec 08, 2003 12:40 pm

[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

JP1 Remotes

KM .txt files to RM

KM .txt files to RM

Re: KM .txt files to RM