JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

KM - Save device upgrade in RM format
Goto page 1, 2  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
cdhixson



Joined: 04 Aug 2003
Posts: 48
Location: Charlotte, NC USA

                    
PostPosted: Tue Sep 30, 2003 8:47 am    Post subject: KM - Save device upgrade in RM format Reply with quote

Mark,

You changed the format of the Output worksheet in the newer versions of KM, but you didn't change the UpgradeSAVE_RM code to match these changes. Here are the changes you need to correctly save the code blocks. You could also just drop these code blocks because RM never uses them. Without these changes, the file created by this macro will not load into RM.

Thanks,
Chris

Code:

Dim cell As Range

'device upgrade code
Print #fNum, ""
Print #fNum, "[Device Upgrade Code]"
For Each cell In ThisWorkbook.Worksheets("Output").Range("A6:A10")
    If cell.Value <> "" Then Print #fNum, cell.Value
Next cell

'protocol code
Print #fNum, ""
Print #fNum, "[Protocol Code]"
For Each cell In ThisWorkbook.Worksheets("Output").Range("A12:A14")
    If cell.Value <> "" Then Print #fNum, cell.Value
Next cell

'key move code
Print #fNum, ""
Print #fNum, "[Key Move Code]"
For Each cell In ThisWorkbook.Worksheets("Output").Range("A16:A18")
    If cell.Value <> "" Then Print #fNum, cell.Value
Next cell
Back to top
View user's profile Send private message Send e-mail
Mark Pierson
Expert


Joined: 03 Aug 2003
Posts: 3017
Location: Connecticut, USA

                    
PostPosted: Tue Sep 30, 2003 5:10 pm    Post subject: Reply with quote

Thanks for the heads up, Chris. I'll make the changes and upload a new version.
_________________
Mark
Back to top
View user's profile Send private message Send e-mail Visit poster's website
gfb107
Expert


Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC

                    
PostPosted: Tue Sep 30, 2003 5:15 pm    Post subject: Reply with quote

Is this feature still needed, now that RM has the ability to import a KM upgrade file?
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)
Back to top
View user's profile Send private message Visit poster's website
cdhixson



Joined: 04 Aug 2003
Posts: 48
Location: Charlotte, NC USA

                    
PostPosted: Wed Oct 01, 2003 7:05 am    Post subject: Reply with quote

I found one thing that this feature can do that you can't with just the KM text files. In the latest KM, Mark changed the name of the Tivo Hacked protocol to Tivo (Advanced). The KM text file version only saves the name of the protocol and not the protocol ID. This text file won't read into RM correctly because the protocols.ini file doesn't have an entry for Tivo (Advanced). The Save as RM file feature saves the protocol ID and RM loads it fine.
Back to top
View user's profile Send private message Send e-mail
gfb107
Expert


Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC

                    
PostPosted: Wed Oct 01, 2003 9:22 am    Post subject: Reply with quote

Bummer. I specifically recreated the protocols using the same names that KM uses, and now he's gone and changed one (maybe more?).
Because there are old device upgrade floating around out there, I can't just change the name RM uses.

I guess I'll enhance RM's import feature to be more forgiving when it can't find an exact match for the protocol, similar to what it does when it can't find an exact match for the remote.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)
Back to top
View user's profile Send private message Visit poster's website
cdhixson



Joined: 04 Aug 2003
Posts: 48
Location: Charlotte, NC USA

                    
PostPosted: Wed Oct 01, 2003 9:47 am    Post subject: Reply with quote

gfb107 wrote:
Bummer. I specifically recreated the protocols using the same names that KM uses, and now he's gone and changed one (maybe more?).
Because there are old device upgrade floating around out there, I can't just change the name RM uses.

I guess I'll enhance RM's import feature to be more forgiving when it can't find an exact match for the protocol, similar to what it does when it can't find an exact match for the remote.


I think your idea is a good one. Have you also thought about adding an alternate name section to the protocols.ini entry? Something like this.

[Tivo Hacked]
PID=00 41
AltName="Tivo (Advanced)","Tivo (Yet Another)"

In the future, somebody will probably want to change the name of a protocol, maybe more than once. We need some way to track the name changes. Of course, the protocol ID is the one thing that should never be changed.
Back to top
View user's profile Send private message Send e-mail
gfb107
Expert


Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC

                    
PostPosted: Wed Oct 01, 2003 11:13 am    Post subject: Reply with quote

cdhixson wrote:
Have you also thought about adding an alternate name section to the protocols.ini entry? Something like this.

[Tivo Hacked]
PID=00 41
AltName="Tivo (Advanced)","Tivo (Yet Another)"

In the future, somebody will probably want to change the name of a protocol, maybe more than once. We need some way to track the name changes. Of course, the protocol ID is the one thing that should never be changed.


I have though about it. It's probably what I'll have to do.

As far as I can tell, the KM .txt files don't have the PID in them, so I can't use that if there is no matching name. Hopefully I've just missed it and its actually there somewhere.

I don't know how KM manages to find the correct protocol in cases like these.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)
Back to top
View user's profile Send private message Visit poster's website
cdhixson



Joined: 04 Aug 2003
Posts: 48
Location: Charlotte, NC USA

                    
PostPosted: Wed Oct 01, 2003 12:17 pm    Post subject: Reply with quote

gfb107 wrote:
I have though about it. It's probably what I'll have to do.

As far as I can tell, the KM .txt files don't have the PID in them, so I can't use that if there is no matching name. Hopefully I've just missed it and its actually there somewhere.

I don't know how KM manages to find the correct protocol in cases like these.


The .txt files definitely do not have the PID in them. KM has a hidden worksheet called Old2New that contains the old protocol names and their new names. Here are the ones listed in KM 7.53. The old names are on the left with the new names on the right.

Code:

ReplayTV Hacked             ReplayTV (Advanced)
ReplayTV 1994               ReplayTV (Advanced)
ReplayTV Official           ReplayTV (Official)
NEC Generic                 NEC1
RCA Combo                   RCA Combo (Official)
Panasonic JVC               JVC-48
Tivo Hacked                 Tivo (Advanced)
Tivo Official               Tivo (Official)
Panasonic Combo (Official)  Panasonic Combo
Back to top
View user's profile Send private message Send e-mail
Mark Pierson
Expert


Joined: 03 Aug 2003
Posts: 3017
Location: Connecticut, USA

                    
PostPosted: Wed Oct 01, 2003 1:25 pm    Post subject: Reply with quote

gfb107 wrote:
Bummer. I specifically recreated the protocols using the same names that KM uses, and now he's gone and changed one (maybe more?).

Blame Rob for all that! Wink

As things have evolved, there's several protocols (and remotes) that have had their "labels" changed. As Chris mentioned, KM can handle it all because of the Old2New sheet. If KM reads an "old" file, it looks for a normal match. If one's not found, it turns to Old2New.
_________________
Mark
Back to top
View user's profile Send private message Send e-mail Visit poster's website
johnsfine
Site Admin


Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA

                    
PostPosted: Wed Oct 01, 2003 1:46 pm    Post subject: Reply with quote

cdhixson wrote:

In the future, somebody will probably want to change the name of a protocol, maybe more than once. We need some way to track the name changes. Of course, the protocol ID is the one thing that should never be changed.


I've alread changed protocol ID's and I think we'll need to again on rare occasion.

I haven't looked at what KM stores when exporting to RM format, but a little more info is generally nice and maybe RM itself should be storing more info (from the selected protocols.ini entry) in the upgrade so things won't be as confused later when an old upgrade is used with a new protocols.ini.

I think a protocols.ini entry should have a way to suggest a replacement protocol (to be used in various cases where that entry isn't appropriate). I also think a protocols.ini entry should have a way to indicate that it is obsolete, which is ONE of the reasons RM would look at its suggested replacement field.

Then we just add some dummy entries for "old" protocol names which suggest the new ones. But the feature is more general and will cover other situations as well.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21234
Location: Chicago, IL

                    
PostPosted: Wed Oct 01, 2003 1:52 pm    Post subject: Reply with quote

While the protocol id isn't stored in a nice clean stand alone field, it can be derived from the data. The first byte of the "Upgrade Code" data is the second byte of the protocol id. To get the first byte, you would have to take the setup code hex (eg, the "21 2c" in "Upgrade Code 0 = 21 2C (DVD/0300)" and convert it to binary, the MSB (ie, rightmost bit) is the first byte of the protocol id.

As for why protocol names change, let's stick with the Tivo example. When UEI created the original Tivo protocol they made it use 2-byte variable data, which in turn meant that it didn't support advanced code. So we called this protocol "Tivo Official", we then created our own version that uses 1-byte variable data and called it "Tivo Hacked".

Then, after constant nagging from me, UEI changed the official protocol to use 1-byte variable data. At this point, the old names no longer made sense. So, I wrote to Mark and suggested the he change "Tivo Hacked" to just "Tivo" and "Tivo Official" to "Tivo 2-byte". Both versions would use the "01 11" protocol id rather than the redundant "00 43" id.

The idea being that people with newer remotes that already have the 1-byte protocol installed would not need to install a protocol upgrade each time. People with remotes that have the 2-byte version installed, would have the choice of whether to use a protocol upgrade or not.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21234
Location: Chicago, IL

                    
PostPosted: Wed Oct 01, 2003 1:58 pm    Post subject: Reply with quote

OK, here's a follow up on how I think the Tivo protocol is currently implemented in KM.

There doesn't appear to be any support for the 2-byte version anymore (which is no big loss).

If you select "Tivo (Official)" for a remote that has the 2-byte version of the protocol installed, KM will offer up the 1-byte protocol upgrade. If you select this with a remote that does have the 1-byte protocol installed, no protocol upgrade is offered.

The "Tivo (Advanced)" protocol is the old hacked protocol. The only reason you would want to use this is if you have a remote with a FAV/SCAN button and you want to assign a function to that button.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
Mark Pierson
Expert


Joined: 03 Aug 2003
Posts: 3017
Location: Connecticut, USA

                    
PostPosted: Wed Oct 01, 2003 6:13 pm    Post subject: Reply with quote

cdhixson wrote:
The .txt files definitely do not have the PID in them.


The Robman wrote:
While the protocol id isn't stored in a nice clean stand alone field, it can be derived from the data. The first byte of the "Upgrade Code" data is the second byte of the protocol id. To get the first byte, you would have to take the setup code hex (eg, the "21 2c" in "Upgrade Code 0 = 21 2C (DVD/0300)" and convert it to binary, the MSB (ie, rightmost bit) is the first byte of the protocol id.

While I could (and maybe should) add the PID to the saved KM txt file, I haven't simply because it wouldn't help any of the existing files out there. That's an important consideration I make anytime I change something in the file format.

My foremost concern with saved KM files is not their ability to feed data to RM, but to maintain backward compatability with prior versions. IMHO, RM needs to overcome these limitations/omitions on it's own, because there's no way all those existing files are going to get updated (what would be the point?). Therefore, Rob's suggestion about decoding the PID from the Upgrade/Protocol data makes a lot of sense.

johnsfine wrote:
I think a protocols.ini entry should have a way to suggest a replacement protocol (to be used in various cases where that entry isn't appropriate). I also think a protocols.ini entry should have a way to indicate that it is obsolete, which is ONE of the reasons RM would look at its suggested replacement field.

As for the protocol name changes, I'll try to post them as they occur. That way, John's suggestion about including obsolete ones in the protocol.ini file and/or the above PID issue should do the trick.
_________________
Mark
Back to top
View user's profile Send private message Send e-mail Visit poster's website
gfb107
Expert


Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC

                    
PostPosted: Wed Oct 01, 2003 6:31 pm    Post subject: Reply with quote

I'll definitely add support for an ObsoleteNames attribute to a protocol, and will search through the ObsoloteNames for a match if there is no match using the name from the saved KM file. This would also apply to loading older save RM files.

Storing the protocol definition in the RM saved file is possible, but will come later. I'll have to think about some of the issues it would introduce.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)
Back to top
View user's profile Send private message Visit poster's website
gfb107
Expert


Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC

                    
PostPosted: Thu Oct 02, 2003 9:40 am    Post subject: Reply with quote

The Robman wrote:
OK, here's a follow up on how I think the Tivo protocol is currently implemented in KM.

There doesn't appear to be any support for the 2-byte version anymore (which is no big loss).

If you select "Tivo (Official)" for a remote that has the 2-byte version of the protocol installed, KM will offer up the 1-byte protocol upgrade. If you select this with a remote that does have the 1-byte protocol installed, no protocol upgrade is offered.

The "Tivo (Advanced)" protocol is the old hacked protocol. The only reason you would want to use this is if you have a remote with a FAV/SCAN button and you want to assign a function to that button.


I'm going to try to recreate this behavior in RM. I've already coded up the changes for parsing the oldnames from protocols.ini, and searching those if a normal match isn't found.

Now I'm going to update protocols.ini, and I'm not quite clear on what to do. Here's what I'm thinking:

1. Copy the protocol behavior (device parms, cmd parms, protocol code, etc.) from "TiVo Hacked" to "TiVo Official", leaving the PID as 0111.

2. Rename the "TiVo Hacked" protocol to "TiVo (Advanced)", leaving the PID as 0041. Add the line
OldNames=TiVo Hacked
So that old KM and RM upgrade files can still be read.

3. Remove the 0111 PID from the [Protocols] section of the RDFs for remotes that have the 2-byte TiVo protocol. Where can I look in RM to see which remotes have the 2-byte 0111 protocol and which have the 1-byte 0111 protocol? I assume there are no remotes that have the 0041 protocol built in.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Software All times are GMT - 5 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control