 |
JP1 Remotes
|
| View previous topic :: View next topic |
| Author |
Message |
3FG
Expert
Joined: 19 May 2009
Posts: 3370
|
 Posted: Sat Jan 16, 2010 5:58 pm Post subject: |
 |
|
| The Robman wrote: |
1) XMP - this option would use the built-in executor when it's available, and use Mike's code when it isn't. |
I think this will work for XMP-1 and XMP-2 protocols, but I don't see how to permit choosing the case where both bytes are non-zero. To enter both bytes, the UI needs to be different, but I don't think the UI can be altered according to the existence of a built-in executor-- then again I don't know much about RM. Maybe we'll see both bytes with non-zero data when the 4th nibble changes from F. |
|
| Back to top |
|
 |
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21258
Location: Chicago, IL
|
| Posted: Sat Jan 16, 2010 6:59 pm Post subject: |
|
|
Keep in mind that we haven't seen a situation where both bytes are non-zero, so this is still a "what if" situation.
But regardless, if we keep the UEI version as an option, like I suggested, the user would be able to use the official UEI version.
_________________
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 |
|
|
3FG
Expert
Joined: 19 May 2009
Posts: 3370
|
| Posted: Sun Jan 17, 2010 12:37 am Post subject: |
|
|
I think I misunderstood your proposal. Is this how it would work?
The RM user interface for XMP would look the same as XMP (Hacked), with a checkbox for for XMP-2 (default is XMP-1) and a checkbox for Final Frame (default is none).
The UI for XMP (UEI) would be similar to the existing XMP add-in, with 2 OBC columns, and the user would select XMP-1, XMP-2 or XMPfull, by filling in an OBC value in one or both of the OBC columns. This would be the only entry that can generate a 16 bit command. |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21258
Location: Chicago, IL
|
| Posted: Sun Jan 17, 2010 11:18 am Post subject: |
|
|
That's pretty much what I was thinking, though I don't think it's necessary to make the XMP (UEI) version as complicated as you suggest. I think having it set up similar to the current Dreambox option would suffice. Keep in mind that regular users would not need to use this option, this is primarily there for experts to test with, etc. Regular users should only need to use the basic XMP selection, which will provide Mike's code when the executor is not pre-installed, and the UEI format when it is.
_________________
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 |
|
|
3FG
Expert
Joined: 19 May 2009
Posts: 3370
|
| Posted: Sun Jan 17, 2010 3:49 pm Post subject: |
|
|
Well, I guess we're working from different assumptions. I think:
1) RM should be capable to generate XMP with two non-zero command bytes.
2) the UI must provide two columns for OBCs so the user can specify both bytes.
3) With RM, as currently written, the choice of 1 or 2 colums is defined in protocols.ini, with no mechanism for the user to change that choice.
Perhaps I'm wrong about 3), and perhaps you disagree about 1).
As you say, XMP (UEI) would be primarily used by experts. Why would we want to decrease flexibilty? |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21258
Location: Chicago, IL
|
| Posted: Sun Jan 17, 2010 4:20 pm Post subject: |
|
|
| 3FG wrote: | | 3) With RM, as currently written, the choice of 1 or 2 colums is defined in protocols.ini, with no mechanism for the user to change that choice. |
That's not true. XMP is currently supported in RM as "Dreambox" and it has two columns for the OBCs, with one column entitled OBC and the other entitled Sub-Device.
Let me see if I can clarify what I'm trying to say a bit.
The primary option would be called "XMP", this is the protocol that most users would select when they try to build a new XMP upgrade. It would have an option that lets you select the XMP1 format or the XMP2 format. It would also have an option that lets you select the final frame that has been discussed earlier. If your remote has the official XMP executor installed, it would use it and format a device upgrade that uses 4 bytes of fixed data and 2 variable bytes. If your remote does not have the UEI executor installed, it would use Mike's code instead with it's 7 fixed bytes and 1 variable byte. Also, if the version of the UEI executor that is pre-installed in your remote doesn't support the final frame, and you select that you need the final frame, we would also switch to using Mike's code.
The secondary option would be "XMP (hacked)". This option would look exactly the same as the primary option, the only difference being that it would use Mike's code regardless of whether your remote has the UEI executor installed. I see the need for this because, if you need to install more than 1 XMP upgrade, you may end up using less memory by reducing the upgrades to 1 variable byte and including a protocol upgrade.
The final option would be "XMP (UEI)" which would use the official code regardless of whether it's pre-installed in the remote. Apart from experts wanting to perform tests, the only time I can envision a regular user needing this is if they have a device that uses the XMP protocol with both OBC bytes populated (ie, non-zero). Therefore, I don't see the need to have an XMP1/XMP2 selection option, I think we should just provide two OBC columns labeled OBC1 and OBC2. I don't see how giving the full flexibility of providing both OBC columns reduces flexibility, but maybe I'm missing something.
_________________
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 |
|
|
3FG
Expert
Joined: 19 May 2009
Posts: 3370
|
| Posted: Sun Jan 17, 2010 4:58 pm Post subject: |
|
|
| Good. I think we are in complete agreement. |
|
| Back to top |
|
|
mr_d_p_gumby
Expert
Joined: 03 Aug 2003
Posts: 1370
Location: Newbury Park, CA
|
| Posted: Tue Jan 19, 2010 3:57 pm Post subject: |
|
|
| The Robman wrote: | | "XMP (hacked)" |
Any chance we can call this one "XMP (JP1)"? I think some users are afraid to use anything that is "hacked" these days. 
I think RM will need a fourth entry for "XMP (Slingbox)". The UI would be identical to "XMP (JP1)", but the executor would be a smaller one without the leadout processing (coming soon).
I'm still working on my versions with the final frame toggle & leadout processing. Right now the S3C8 version is at 137 bytes and the HCS08 is at 132 bytes. I'll post them after I've had a chance to test them.
Rob: I notice in some of your Silingbox versions that you set the repeat count to 2 in the executor. Should this be a standard thing for the Slingbox version?
_________________
Mike England |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21258
Location: Chicago, IL
|
| Posted: Tue Jan 19, 2010 4:20 pm Post subject: |
|
|
| mr_d_p_gumby wrote: | | Any chance we can call this one "XMP (JP1)"? I think some users are afraid to use anything that is "hacked" these days. |
Absolutely.
| mr_d_p_gumby wrote: | | I think RM will need a fourth entry for "XMP (Slingbox)". The UI would be identical to "XMP (JP1)", but the executor would be a smaller one without the leadout processing (coming soon). |
Would it be possible to take care of that behind the scenes, so when someone selects XMP and a Slingbox we just provide them the smaller code?
| mr_d_p_gumby wrote: | | Rob: I notice in some of your Silingbox versions that you set the repeat count to 2 in the executor. Should this be a standard thing for the Slingbox version? |
Yes, anything larger and they see multiple presses of the button, which is a pain when you're trying to enter channel numbers! 
_________________
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 |
|
|
3FG
Expert
Joined: 19 May 2009
Posts: 3370
|
| Posted: Tue Jan 19, 2010 4:36 pm Post subject: |
|
|
If I understand the way RM works, we need to define variant names for the XMP executors that take different data formats. If the fixed or variable data varies in the number of bytes or in the meaning assigned to a given bit, it requires a different PID or variant name.
RM presents a list of executors, which are coupled with instructions of how to format parameters and command data into the hex data that are to be sent to the executor. RM can determine which executor code is necessary to match a processor type, but it allows only one format of the data to be sent to the executor per entry in the list.
So it seems that the very convenient XMP protocol, as Rob outlined it above, which switches between a) 4 byte fixed data, 2 byte variable data and b) 7 byte fixed, 1 byte variable, depending on the target remote, is not possible with RM as it is written today. I think we have to have separate entries for Mike's one byte executor and the traditional XMP executor.
I think we'll have to re-visit the organization of XMP executors, and decide on a name for the variant protocol(s). To avoid potential conflict with UEI variant names, perhaps we can prefix a variant number with a J. |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21258
Location: Chicago, IL
|
| Posted: Tue Jan 19, 2010 5:44 pm Post subject: |
|
|
Just FYI, the Slingbox executor will have exactly the same fixed data as the regular executor, it will just have less code in it.
I'll have to re-visit how we've handled the numerous variations of the Pioneer protocol where the number of variable bytes changes and the number of fixed bytes changes.
_________________
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 |
|
|
mr_d_p_gumby
Expert
Joined: 03 Aug 2003
Posts: 1370
Location: Newbury Park, CA
|
| Posted: Tue Jan 19, 2010 9:20 pm Post subject: |
|
|
| The Robman wrote: | | The primary option would be called "XMP", this is the protocol that most users would select when they try to build a new XMP upgrade. It would have an option that lets you select the XMP1 format or the XMP2 format. It would also have an option that lets you select the final frame that has been discussed earlier. If your remote has the official XMP executor installed, it would use it and format a device upgrade that uses 4 bytes of fixed data and 2 variable bytes. If your remote does not have the UEI executor installed, it would use Mike's code instead with it's 7 fixed bytes and 1 variable byte. Also, if the version of the UEI executor that is pre-installed in your remote doesn't support the final frame, and you select that you need the final frame, we would also switch to using Mike's code. |
To accomplish switching executors & fixed data based on the final frame toggle option will at least require that the RDFs be updated with variant info for the 016C protocols.
We haven't established variant number/names yet, but I would suggest the following:
016C (equivalent to 016C:1) -- Any version without the final frame toggle fucntion.
016C:2 -- Any version with the final frame toggle function.
016C:bad -- Any version which has incorrect timing and should always trigger a protocol update.
| The Robman wrote: | | I'll have to re-visit how we've handled the numerous variations of the Pioneer protocol where the number of variable bytes changes and the number of fixed bytes changes. |
Just to make this prospect even more pleasant, don't forget that there are two new variants of the Pioneer MIX protocol now that still need to be added to RM. 
_________________
Mike England |
|
| Back to top |
|
|
mr_d_p_gumby
Expert
Joined: 03 Aug 2003
Posts: 1370
Location: Newbury Park, CA
|
| Posted: Sat Jan 23, 2010 1:02 am Post subject: |
|
|
Here is the XMP (JP1) protocol code that includes both the final frame toggle and the leadout processing. I've tested these and compared captures to the official version in the 15-135.
The fixed data is the same as I described before, except that now setting bit 7 of the 7th fixed byte activates the final frame.
| Code: | Upgrade protocol 0 = 01 6C (S3C8+) PID 016C XMP (JP1) (137 bytes)
43 8B 71 8B 05 00 00 69 01 67 08 0A F0 C0 04 0A
C0 60 C0 0E 04 07 C0 88 C0 B6 C8 08 CF 10 09 6B
05 E4 0A 09 B0 0A C0 C5 F6 FF 4E 6C 08 48 0D C6
F8 13 D7 F6 01 58 49 0D F6 01 0A FB 02 6A F0 46
08 80 08 C8 7B E2 37 5E 3F 46 08 10 00 C0 56 C0
0F 56 07 F0 44 C0 07 6C 03 F6 FF 63 C6 F8 17 F1
F6 01 58 3C 04 F6 FF 73 F6 FF 73 6E 3A F7 1C 12
8D 01 4C F6 FF 6E F1 C6 C7 26 56 C2 0F 6B 09 C6
F8 00 3E F6 01 58 2A F7 AF
End
Upgrade protocol 0 = 01 6C (HCS08) PID 016C XMP (JP1) (132 bytes)
20 08 22 47 71 00 00 68 01 7B B6 67 62 BB 67 40
BB 64 97 A8 08 B7 71 38 66 27 05 4E 67 66 3F 67
36 70 9F AD 22 16 6E 4E B2 72 45 13 CD CD FF 74
4E 72 B2 CD FF 92 24 03 3B 6E EF 1E 65 B6 71 25
E2 0F 70 3F 18 65 4A A4 0F B7 6E B6 64 A4 F0 BA
6E B7 64 6E 60 69 AD 06 45 17 E4 CD FF 74 6E 04
6E AD 0C AD 0A 3C 69 3B 6E F7 AE 6A CC FF 65 AD
F9 8C BE 69 F6 62 F7 A4 0F 27 08 45 00 43 CD FF
74 4B F8 81
End
Upgrade protocol 0 = 01 6C (P8/740) PID 016C XMP (JP1) (156 bytes)
0B 1A 71 A5 64 85 6B 82 6B 18 65 6B 49 FF 3A 18
65 61 A8 49 08 85 6E 06 63 F0 07 A5 64 85 63 3C
00 64 66 6D 98 20 7E 01 44 6A A5 83 85 6C A2 98
A0 0A 22 44 A5 6C 85 83 22 06 B0 04 06 6A B0 EE
EF 62 A5 6E 90 DF F7 6D 52 8F 62 1A 29 0F 85 6A
A5 61 29 F0 05 6A 85 61 3C 00 6F 20 90 01 3C 04
6A 20 AB 01 20 AB 01 E6 6F C6 6A D0 F4 A9 08 20
DB 00 A2 E7 A0 11 22 44 60 A9 08 20 DB 00 A2 BF
A0 01 22 44 A6 6F B5 5D 85 6B 82 6B A5 6B 95 5D
29 0F A2 2B A0 01 22 44 1A 10 F7 60
End |
Here is a shortened version for the Slingboxes where the leadout process has been removed and the repeat count set to 2.
| Code: | Upgrade protocol 0 = 01 6C (S3C8+) PID 016C XMP (JP1) for Slingbox (130 bytes)
43 8B 71 8B 05 00 00 69 01 67 08 0A F0 C0 04 0A
C0 60 C0 0E 04 07 C0 88 C0 B6 C8 08 CF 10 09 6B
05 E4 0A 09 B0 0A C0 C5 E6 0D 02 F6 FF 47 C6 F8
9E E5 F6 01 58 F6 01 0A 46 08 80 08 C8 7B EC 37
5E 3F 46 08 10 00 C0 56 C0 0F 56 07 F0 44 C0 07
6C 03 F6 FF 5C C6 F8 17 F1 F6 01 58 4C 04 F6 FF
6C F6 FF 6C 6E 4A F7 1C 12 8D 01 4C F6 FF 67 F1
C6 C7 26 56 C2 0F 6B 09 C6 F8 00 3E F6 01 58 2A
F7 AF
End |
I couldn't make a version small enough to fit in the older 6805-RC16/18 and 6805-C9, but this 6805-RC16/18 version with no final frame toggle & no leadout processing works and has been tested. It still is too big to fit in some of these remotes, but should work OK in the JP1.1 SST remotes and a few others, like the DTV remotes.
| Code: | Upgrade protocol 0 = 01 6C (M6805-RC16/18) PID 016C XMP (JP1) w/o ff-toggle or leadout abort (125 bytes)
11 24 71 20 05 00 00 33 BD 61 AD 64 FB 40 BB 5E
A4 0F B7 62 A8 08 B7 63 38 60 27 04 F6 B7 60 7F
B6 5E A4 F0 BA 62 B7 5E AE 5A BF 6A AD 13 AD 11
A6 59 5F AD 22 CD 01 89 1E 5F B6 63 B7 62 24 E0
81 3F 62 AD 15 AD 13 3C 6A 3C 62 05 62 F5 4F AD
0E 11 14 AE 01 A6 12 CC 01 96 AD 14 F7 A4 0F 4C
AE 23 42 AB 9C 24 01 5C B7 69 BF 67 5F CC 01 CA
BE 6A F6 AE 10 42 BF 6B BA 6B BE 6A 81
End |
I do have a full version which I believe will work on a JP1.1 remote, but I do not have one of them to test with. If anyone is interested in testing it, let me know.
One possible problem I see is that when the final frame toggle is enabled, there is no leadout after the final frame. If the command is in an extender macro where another command follows, it might be necessary to add a short pause after the XMP command. This applies to both the official version and my version.
_________________
Mike England |
|
| Back to top |
|
|
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4530
Location: Cambridge, UK
|
| Posted: Sat Jan 23, 2010 9:51 am Post subject: |
|
|
I have now posted DecodeIR 2.40 Beta 2, which reports "With Final Frame" when that is present. I've also followed Rob's suggestion and put the correction algorithms used as a list in brackets after the XMP data, rather than before it as in the first Beta.
_________________
Graham |
|
| Back to top |
|
|
mr_d_p_gumby
Expert
Joined: 03 Aug 2003
Posts: 1370
Location: Newbury Park, CA
|
| Posted: Sun Jan 31, 2010 1:26 pm Post subject: |
|
|
I've posted XMP(JP1)RM.zip, which partially implements the XMP protocols as Rob had requested here. It uses 3FG's XMPsumCheck translator, and provides:
XMP (JP1)
XMP (Slingbox)
XMP (UEI)
The RDF files will need to be updated for those remotes that have the 016C:2 variant to prevent RM from requiring a protocol upgrade for those remotes when using the XMP (UEI) protocol.
| The Robman wrote: | | mr_d_p_gumby wrote: | | I think RM will need a fourth entry for "XMP (Slingbox)". The UI would be identical to "XMP (JP1)", but the executor would be a smaller one without the leadout processing (coming soon). |
Would it be possible to take care of that behind the scenes, so when someone selects XMP and a Slingbox we just provide them the smaller code? |
This is as close as I could come to your request here. The RDF does not have any way to make RM choose between two different executors and force a protocol upgrade at the same time.
While I was able to do it KM v9.19, as 3FG mentioned above, I don't think there is any way to implement the 'XMP' protocol in RM in the manner you requested. That would require RM to select a different protocols.ini entry based on what entries the user made in the device parameters in addition to RDF contents.
The problem is similar for XMP (UEI), which presently only attempts to work with variant 016C:2. I don't know of any way to make RM choose between variant 1 and variant 2 based on the users entry for the Final Frame devparm option.
I've also posted my XMP (JP1) PB files.
_________________
Mike England |
|
| 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
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
File Section
Wiki
