|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
gfb107 Expert
Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC |
Posted: Mon Jan 26, 2004 8:19 pm Post subject: Adding Zenith Protocol to RM |
|
|
Here I go again....
Most everything about the device and cmd parms is pretty straight forward.
The Signal Length is a 4-bit value that is stored in bits 4-7 of the fixed data. The only interesting thing is that the value is one more than the value entered by the user. When the default value is used (no value entered), the adjustment is not performed.
The "Long Record" is a single bit that is mapped into bit 0 of the fixed data. I'll implement that as a check-box.
The only one that has me a bit confused is the "Style (0 or 1)".
It appears that this flag changes the OBC from an 8bit unsigned value to an 8bit signed value. Other than that I see no difference in the fixed data or hex cmd . Since the only valid values are 0 or 1, this is a good candite for a check-box, or drop-down box, but the name isn't very informative.
What does this really do? _________________ -- 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 |
|
|
johnsfine Site Admin
Joined: 10 Aug 2003 Posts: 4766 Location: Bedford, MA |
Posted: Mon Jan 26, 2004 9:27 pm Post subject: Re: Adding Zenith Protocol to RM |
|
|
gfb107 wrote: |
The only one that has me a bit confused is the "Style (0 or 1)".
It appears that this flag changes the OBC from an 8bit unsigned value to an 8bit signed value. |
I haven't checked anything to refresh my memory, but I assume you mean it gets stored as the top bit of every hex command. Calling that "unsigned" vs. "signed" is rather strange, so maybe one of us is confused.
gfb107 wrote: |
Other than that I see no difference in the fixed data or hex cmd . Since the only valid values are 0 or 1, this is a good candite for a check-box, or drop-down box, but the name isn't very informative.
What does this really do? |
Maybe later I'll check some decodes to be sure. I think the decoder presents that bit as a "subdevice" (because I couldn't think of anything better to do with it, so I'm not suggesting you copy that.). I'm not sure what you mean by "really do":
That bit is sent as part of each signal. It is encoded in the IR signal differently than the OBC bits (because they are each encoded as double bits and it isn't).
So far as I have noticed, a given device has that bit the same in all of its commands, so it is logically part of the device level info, even though IIRC it is implemented as part of the hex cmd rather than part of the fixed data.
I can't think of any advantage to changing the name or UI of "Style" from the way KM does it. Making it a check box rather than 0/1 type in would require thinking of a different/better name for it and I don't think that is a good idea.
(Making "Long Record" into a check box would be a clear improvement.) |
|
Back to top |
|
|
gfb107 Expert
Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC |
Posted: Mon Jan 26, 2004 9:30 pm Post subject: |
|
|
Upon further examination, I see that having the Style set to 1 sets the OBC Adjust value to 128, which causes 128 to be added to the OBC when calculating the hex cmd.
Seems like I could accomplish the same thing by XORing the value of the Style bit with bit 0 (msb) of the OBC. Either way, I need to create a new Translator subclass for this.
I'd still like to know if there is a better name than "Style" for this field, and if I should make it a check box. Until I hear otherwise I'll make it a drop-down _________________ -- 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 |
|
|
johnsfine Site Admin
Joined: 10 Aug 2003 Posts: 4766 Location: Bedford, MA |
Posted: Mon Jan 26, 2004 9:41 pm Post subject: |
|
|
gfb107 wrote: |
Seems like I could accomplish the same thing by XORing the value of the Style bit with bit 0 (msb) of the OBC. Either way, I need to create a new Translator subclass for this.
|
We have a translator specifically for taking values from the setup sheet (device level data) and storing it in the hex command.
I think I see what is confusing you. The number of bits in the actual OBC is the number in the Signal length field (I guess THAT needs a new translator to do correctly). The largest size is 7 bits. The top bit of the OBC goes in the second to top bit of the hex cmd.
KM lets you put in an OBC that is too big, and it lets the OBC overflow into the style bit. I think that is a defect, not a feature. Check with Jon or Rob, but I think you are better off not duplicating that behavior, especially if it would need a new translator. |
|
Back to top |
|
|
gfb107 Expert
Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC |
Posted: Mon Jan 26, 2004 10:29 pm Post subject: |
|
|
johnsfine wrote: |
The number of bits in the actual OBC is the number in the Signal length field (I guess THAT needs a new translator to do correctly).
|
Not only do I need a new translator, I also need a new input validator to restrict the maximum value for the OBC field. There's nothing in the current design to accomodate that. In fact, the current design will simply mask off the high order bits if the value is too large (although it will not allow values larger than 255 .
Rather than changing the name of the Style dev parm, maybe we could give the values meaningful names instead of just 0 and 1. _________________ -- 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 |
|
|
|
|
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
|