Page 1 of 2
RM from KM import - fixed bytes shift etc. - Dish Combo
Posted: Sat Jan 20, 2007 11:59 am
by ElizabethD
I imported KM upgrade file for Dish combo. RM 1.69.
https://www.hifi-remote.com/forums/dload ... le_id=4115
1. It has 5 fixed bytes which rollover by one position when the file is imported into RM. I guess because Unit is last here.
2. The protocol notes say it's coded for 5 repeats. I think not (byte left of $43 is 02)
3. In KM it was coded for 6131, extended. Should RM pick the extended remote for me? It doesn't. Trivial.
4. On the Output sheet, the upgrade matches completely, other than the rollover of fixed bytes, but the protocol section says it's required. KM didn't say so. Is it because of the anticipated repeats change? The protocols are the same.
I really like the Notes section listing all the codes. Cool.
Re: RM from KM import - fixed bytes shift etc. - Dish Combo
Posted: Sat Jan 20, 2007 1:56 pm
by Mark Pierson
I keep getting a 0-byte file...
In KM it was coded for 6131, extended. Should RM pick the extended remote for me? It doesn't.
That might be connected to the change Mike made in KM where the extender is now indicated by a setting on the Setup sheet instead of by remote selection (name). Perhaps Greg needs to modify RM to accomodate this, though I'm not familiar with the exact details of what Mike did.
Posted: Sat Jan 20, 2007 2:10 pm
by ElizabethD
Sorry. Try now. I don't know why it was 0 bytes. Blame the computer
I think I also need to update my RM. If anything changes, I'll post.
Edited: v1.74 behaves the same.
Posted: Sat Jan 20, 2007 3:02 pm
by Mark Pierson
ElizabethD wrote:Try now. I don't know why it was 0 bytes.
Is all better now.
Blame the computer
So blamed...
I'm pretty sure the change Mike made is causing RM to not recognize the extender version. Whether that's also causing the shifting, I don't know.
Posted: Sat Jan 20, 2007 10:36 pm
by ElizabethD
I took a quick look at the RMIR section (work in progress, right?). It behaves slightly differently. Should this go to RMIR thread??
I opened IR file containing the same upgrade and few more.
OOPS, Notes from the loaded IR file vanish in this mode.
When I cliked on device for that upgrade, the protocol (0002) got identified as Dish Network, rather than combo. That's ok, we discussed that once before regarding some other hard to distinguish protocols.
All protocol parameters were there, though I doubt they really belong in a non-combo. However it retains the data, so I'm not complaining.
We discussed hard to distinguish protocols, and I'm sure this is one of them, but perhaps the presence of 4 device entries could be the distinguishing point?
I then switched to the Combo from the dropddown above, got new pid. If KM called 0002 by the same number as RM that might help? maybe?
All the parameters got changed, but differently than before, and I lost Device4 (the byte 2 thing).
Fixed data sequence remained correct. As did the codes on the Setup sheet.
No big deal, it's some sort of additional indexing issue that's inconsistent between the RM and RM-IR at this point.
Posted: Sun Jan 21, 2007 12:24 am
by mr_d_p_gumby
Mark Pierson wrote:I'm pretty sure the change Mike made is causing RM to not recognize the extender version. Whether that's also causing the shifting, I don't know.
Yeah, that's right, let's blame Mikey! It's all his fault!
Probably RM is not picking up the yes/no field in the saved KM file that indicates if the extender is in use. Not a big deal, since it only affects the 6131 & the Atlas DVR. The only thing this will affect is keymoves.
It is definately not causing the shifting of the fixed data. Protocols.ini seems to be coded to always provide the Dish Network Combo as an upgrade. Not sure why it is that way; it has been some time since we did anything to this protocol in KM. (My notes are dated in 2004.)
Posted: Thu Mar 22, 2007 11:02 am
by ElizabethD
Bump
Posted: Fri Mar 23, 2007 3:29 pm
by gfb107
The shifting is simply a result of having the device parameters in a different order in protocols.ini than they are in KM.
Changing the order of the parameters in protocols.ini would cause problems loading existing .rmdu files that use the "Dish Network Combo" protocol.
Fortunately, we have a simple way to get RM to reorder protocol parameters when importing a KM upgrade. Add the line
Code: Select all
DeviceImporter=ReorderImporter(4,0,1,2,3)
to the protocol's entry in protocols.ini.
RM definitely isn't picking up the new way of dealing with extended remotes in KM. I had no idea this change was coming. I'll have to find time to add support for that.
Now some discussion about how the Dish Network protocols are/should be handled.
I see that for the 6131, the "Dish Network" protocol (pid 0002, 5 fixed bytes) is the same as the "Dish Network Combo".
In protocols.ini, these are different protocols. It may be possible to use RM's existing support for alternate PIDs to get RM to behave like KM, but I'll have to go back and review how all that works. I'll follow up after I've done some more investigation.
Posted: Fri Mar 23, 2007 5:14 pm
by gfb107
OK, looks like Dish Network is one of the protocols for which the alternate PID support was created.
So, in protocols.ini change
[Dish Network Combo]
PID=01 E2
DevParms=Device 1:5=0,Device 2:5=1,Device 3:5=0,Device4:5=0,Remote Address (1 to 32) :5=0
DeviceTranslator=Translator(lsb,0,5,8) Translator(lsb,1,5,16) Translator(lsb,2,5,24) Translator(lsb,3,5,32) Translator(lsb,4,5,0,0,-1)
to
[Dish Network Combo]
PID=00 02
VariantName=5
AlternatePID=01 E2
DevParms=Device 1:5=0,Device 2:5=1,Device 3:5=0,Device4:5=0,Remote Address (1 to 32) :5=0
DeviceTranslator=Translator(lsb,0,5,8) Translator(lsb,1,5,16) Translator(lsb,2,5,24) Translator(lsb,3,5,32) Translator(lsb,4,5,0,0,-1)
DeviceImporter=ReorderImporter(4,0,1,2,3)
The
Code: Select all
DeviceImporter=ReorderImporter(4,0,1,2,3)
should also be added to the entry for "Dish Network" with VariantName=5
Liz, if you could try out these changes and verify you get the desired behavior, that would be a big help.
Posted: Fri Mar 23, 2007 8:34 pm
by ElizabethD
I can confirm the Dish Combo changes work great. Nothing rolled over. Thanks a bunch for highlighting in red, it made it a snap. Everything on the functions sheet looks good, as does the device upgrade. KM uses the 1E2 version as you just did here.
I don't know how to do DishNetwork. I went to KM, changed combo to just Network. it retained 4 devices (0,1,2,3) and the 5 fixed bytes. Then I did the same thing in RM, where 4th device got dropped and the 4th device fixed byte got changed to 00 from C0. But that;s the only comparison I can make, since I don't know what's to come out nor if concept of devices even holds in DishNetwork, though KM nor RM objected.
Greg, I still needed to change 6131 to 6131ext, and the protocol notes say it repeats 5 times. Perhaps it does, but I wonder, because I modified it and came up with repeats in the byte just left of 43 8C, the one that now says 02.
Code.S3C80=2B 5C 51 8B 16 B6 59 05 06 00 C5 03 32 00 C5 05 73 0B F2 00 C5 0B F2 05 02 43 8C 18 08 56 C1 03 87 21 04 29 04 8D 01 46
I did all this on 1.74, I just noticed. I forgot to download the latest. I doubt it'll make any difference.
Posted: Sat Mar 24, 2007 9:28 am
by gfb107
A more recent version of RM would not help with this.
The loss of the Device 4 value when switching from "Dish Network Combo" to "Dish Network" is caused by a single missing space in the definition of "Dish Network Combo" in protocols.ini
Incorrect wrote:DevParms=Device 1:5=0,Device 2:5=1,Device 3:5=0,Device4:5=0,Remote Address (1 to 32) :5=0
Corrected wrote:DevParms=Device 1:5=0,Device 2:5=1,Device 3:5=0,Device 4:5=0,Remote Address (1 to 32) :5=0
As I said before, I'll have to add code to RM to handle the new way that KM deals with extenders (which is not only inconsistent and incompatible with RM, but also inconsistent with IR).
I can't comment on the repeat issue. That's outside my scope of knowledge.
Posted: Sat Mar 24, 2007 10:45 am
by mr_d_p_gumby
gfb107 wrote:As I said before, I'll have to add code to RM to handle the new way that KM deals with extenders (which is not only inconsistent and incompatible with RM, but also inconsistent with IR).
Greg, bear in mind that this only affects two remotes (URC-6131 and Atlas DVR). It absolutely does
not affect the generation of the device or protocol upgrades. Currently, the only significant difference between the extender/non-extender choices in KM is the generation of keymoves, which have not been directly discussed in this thread. Whether RM recognizes the extender choice or not won't have any impact on the Dish Network problem under discussion here.
As to why I made that change to KM, remember that KM has to have all the RDF information embedded within itself. With the extended remotes listed separately there was a large amount of information that was redundant, and that made it difficult to even think about adding support for other extended remotes. As things are at this point, I would suggest that modifying RM to support this is not an emergency; it is more of a convenience for the user.
(Just between you and me, if correcting inconsistencies between IR, RM & KM has become a major focus, we all have a lot of work to do. For example, can I select a remote in RM by signature?)
Posted: Sat Mar 24, 2007 11:18 am
by gfb107
I understand all that.
I just didn't expect that at this stage we'd be introducing new inconsistencies.
Posted: Sat Mar 24, 2007 2:48 pm
by ElizabethD
gfb107 wrote:The loss of the Device 4 value when switching from "Dish Network Combo" to "Dish Network" is caused by a single missing space in the definition of "Dish Network Combo" in protocols.ini.
Space fixed it all. Thank you Greg. I tried in RM and RMIR.
gfb107 wrote:I can't comment on the repeat issue. That's outside my scope of knowledge.
Well, it's outside my even more. it's just that where I changed the repeats it works.
Sorry about the totally trivial nag about 6131ext. Doing one click is no big deal.
Posted: Sat Mar 21, 2009 12:27 pm
by gfb107
ElizabethD wrote:The protocol notes say it repeats 5 times. Perhaps it does, but I wonder, because I modified it and came up with repeats in the byte just left of 43 8C, the one that now says 02.
Code.S3C80=2B 5C 51 8B 16 B6 59 05 06 00 C5 03 32 00 C5 05 73 0B F2 00 C5 0B F2 05 02 43 8C 18 08 56 C1 03 87 21 04 29 04 8D 01 46
Can anyone tell me which byte in the code for the other processors controls durations? RM has support for creating a device parameter that is tied to bytes in the protocol code, so I can make tweaking this duration byte much more user friendly. I just need to know the offset of the byte for each protocol code. For reference, here's the code for each processor supported by this executor:
Code: Select all
Code.S3C80=2B 5C 51 8B 16 B6 59 05 06 00 C5 03 32 00 C5 05 73 0B F2 00 C5 0B F2 05 02 43 8C 18 08 56 C1 03 87 21 04 29 04 8D 01 46
Code.740=06 0D 51 80 10 B8 70 17 05 06 03 18 04 97 06 9C 17 08 F0 01 05 E6 5C 44 5D A5 62 29 03 AA B5 5E 85 5E 20 00 FF 3C 62 7F 4C 00 FF
Code.6805-C9=06 0E 51 20 11 B8 F0 00 17 05 06 03 19 04 9A 07 01 17 08 F4 01 05 3C 59 33 5A B6 5F A4 03 97 E6 5B B7 5B AD 04 A6 E2 B7 7C CC 01 83
Code.6805-RC16/18=0B 18 51 20 12 B6 59 05 06 01 62 A4 02 62 C4 06 03 00 06 62 04 05 02 B6 5F A4 03 97 E6 5B B7 5B CC 01 AF
Also, is there code for the newer processors in the JP1.2/3 remotes?