 |
JP1 Remotes
|
| View previous topic :: View next topic |
| Author |
Message |
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21238
Location: Chicago, IL
|
 Posted: Sun Jan 31, 2010 3:39 pm Post subject: |
 |
|
Thanks Mike.
_________________
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 |
|
 |
alanrichey
Expert
Joined: 24 Mar 2008
Posts: 3529
Location: UK/USA
|
| Posted: Tue Feb 02, 2010 10:48 am Post subject: |
|
|
| mr_d_p_gumby wrote: | 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)
|
Any chance we can have an edit to the EXE version of Remotemaster ? Just adding the XMP(Slingbox) to Protocols.ini causes the program to crash and refuse to shut down when you select it.
Cheers
Al |
|
| Back to top |
|
|
3FG
Expert
Joined: 19 May 2009
Posts: 3367
|
| Posted: Tue Feb 02, 2010 11:43 am Post subject: |
|
|
You need change RemoteMaster.jar (it's in the instructions) so that the class XMPsumCheck is available. Otherwise, RM fails with a message to the error log, but with no obvious message to the user.
Been there, done that.....
I realize this won't help the .EXE file. But what's wrong with using the Java version? |
|
| Back to top |
|
|
alanrichey
Expert
Joined: 24 Mar 2008
Posts: 3529
Location: UK/USA
|
| Posted: Tue Feb 02, 2010 12:32 pm Post subject: |
|
|
Pure laziness  I'll give it a try |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21238
Location: Chicago, IL
|
|
| Back to top |
|
|
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
| Posted: Sat Feb 06, 2010 7:26 am Post subject: |
|
|
| alanrichey wrote: | | Any chance we can have an edit to the EXE version of Remotemaster ? Just adding the XMP(Slingbox) to Protocols.ini causes the program to crash and refuse to shut down when you select it. |
I have discovered that new translators can be added on to the EXE version of RemoteMaster as easily as they can be added in to the Java JAR version. This will enable the new XMP protocols to be used with the EXE version without any need for a new EXE file to be compiled.
I've posted full instructions in this thread.
_______________
Graham |
|
| Back to top |
|
|
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
| Posted: Sat Feb 06, 2010 8:26 am Post subject: |
|
|
| mr_d_p_gumby wrote: | 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) |
Mike, there appears to be a bug in the protocols.ini entries for all except XMP (UEI). All your entries have
which forces a 2-byte hex command. Except for XMP (UEI) it should be
although I think this is the default, so the line could be omitted.
______________
Graham |
|
| Back to top |
|
|
mr_d_p_gumby
Expert
Joined: 03 Aug 2003
Posts: 1370
Location: Newbury Park, CA
|
| Posted: Sat Feb 06, 2010 11:12 am Post subject: |
|
|
Thanks Graham. It appears that I had already fixed this, but I neglected to update it to the zip file I actually uploaded. I have done so now.
_________________
Mike England |
|
| Back to top |
|
|
vickyg2003
Site Admin
Joined: 20 Mar 2004
Posts: 7073
Location: Florida
|
| Posted: Wed Mar 17, 2010 9:05 am Post subject: |
|
|
Alan is asking for help on the Thomson STB. I was interested enough to take a look even though I don't know how to help. I tried to open the RDMU, but got the message
Protocol Name not found
XMP (Slingbox) ID=01 6C, variant name JP1 Slingbox.
I know this is the thread where this was discussed.
When I couldn't open it, I tried downloading RM 1.98Beta7.
When that wouldn't open it, I found Mikes XMP Class Zip file and dumped that into my RemoteMaster folder.
I assume that somewhere in this thread there are instructions on what to do next,(probably and protocol.ini entry) but for the life of me, I can't find the instruction.
How to I get RM to open a XMP (slingbox) file?
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
|
|
| Back to top |
|
|
3FG
Expert
Joined: 19 May 2009
Posts: 3367
|
| Posted: Wed Mar 17, 2010 10:52 am Post subject: |
|
|
Use Mike's XMP add-in . Follow the instructions in ReadMe.txt.
You need to modify protocols.ini and change the contents of RemoteMaster.jar |
|
| Back to top |
|
|
vickyg2003
Site Admin
Joined: 20 Mar 2004
Posts: 7073
Location: Florida
|
| Posted: Wed Mar 17, 2010 3:00 pm Post subject: |
|
|
Apparently I've done something very, very wrong, Most probably in the adding the files to the Jar. Remotemaster is slow to start, and locks up and quits.
How exactly does one zip these things up so that they still have thier path?
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
|
|
| Back to top |
|
|
3FG
Expert
Joined: 19 May 2009
Posts: 3367
|
| Posted: Wed Mar 17, 2010 3:43 pm Post subject: |
|
|
You should only be adding XMPsumCheck.class to the .jar file. The XMPsumCheck.java file is just for information and should not be included.
Insert the contents of the Addin.txt (I don't remember the exact name) file into protocols.ini.
I like to copy the RemoteMaster.jar file to a temporary directory, rename it to RemoteMaster.zip, unzip it, add the .class file to the directory, zip up all the files, rename to RemoteMaster.jar, and copy it back to my operating directory. |
|
| Back to top |
|
|
vickyg2003
Site Admin
Joined: 20 Mar 2004
Posts: 7073
Location: Florida
|
| Posted: Wed Mar 17, 2010 6:02 pm Post subject: |
|
|
Thanks 3FG. I finally got it to work with your help. I had a LOT of trouble with this procedure, so hopefully I've learned a lot as well.
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
|
|
| Back to top |
|
|
vickyg2003
Site Admin
Joined: 20 Mar 2004
Posts: 7073
Location: Florida
|
| Posted: Fri Mar 19, 2010 11:25 am Post subject: XMP catchup |
|
|
I'm trying to play a bit of xmp catch up. I played around with XMP last night trying to figure out what I've read.
I learned AndyRoss's signals and then switched them to XMP1. I did a learn of the XMP1 and and XMP2, and then played with all the tools. I exported them to IR and found that they came up as XMP-1(Rec) and XMP-2 (Cor) and when I learned them back to IRScope they said Rec and Cor again.
What do REC and COR mean?
Is that something to do with the post where Rob said that there was a 10pair limit to different timings for learns?
my ICT files and learns are zipped here.
Also, I'm trying to find the Subdevice in all of this, and for the life of me I can't it. I'd also like to know how the checksum was calculated.
I see that Part 1 and Part2 of a signal are seperated with a midframe burst that has a time off of 13000us
I see how each timing pair represents 4 bits of data, where a the timeoff gets longer by ~135us for each possible hex value from 0
Using Robs example
I see that each frame begins with fixed data 170f44
170F443E - 1A003200 - sent once
170F443E - 12803200 - repeating signal
I see the device in this case would be 62 or 3eh
170F443E - 1A003200 - sent once
170F443E - 12803200 - repeating signal
I see that this is XMP-1 because this is 32 00 instead of 00 32
170F443E - 1A003200 - sent once
170F443E - 12803200 - repeating signal
I see the toggle for the repeating frame where it goes from 0 to 8
170F443E - 1A003200 - sent once
170F443E - 12803200 - repeating signal
I see from Robs xls sheet that the second nibble from part 2 reflected in column x always changes but I don't understand the significance.
5 to D
A to 2
C to 4
D to 5
8 to 0
So where is the subdevice?
What is the significance of nibble2 of part 2?
| The Robman wrote: | I've been meaning to write something up for the XMP protocol to get decodeIR and RM in sync. I've just gotta say that I really hate this protocol, it's one of the most time consuming protocols to try and decode by hand. Plus, UEI learning remotes have a problem getting the learns just right and sometimes the burst pair that is saved is exactly half way between two valid pairs, so you don't know which to chose. They also manage to completely drop some of the pairs.
Furthermore, the Slingbox chips have a problem with it too. If it's not already in the Slingbox, it's too big to load as an upgrade. If it is in the Slingbox, the timings don't work properly, so I always have to create special protocols that adjust the timings. I think the Slingbox processor is faster than those in remote controls, therefore the timings need to be reduced, but this is just a guess.
This executor uses two variable bytes, but none of the devices that use it really need two variable bytes. They all either use var-byte1 or var-byte2 as the OBC byte, and the other byte is always zeroes. So, I think we should refer to this executor as XMP-1 and XMP-2, where XMP-1 uses the first variable byte and XMP-2 uses the second. (Of course, DecodeIR won't know which to pick when OBC zero is used).
There's a toggle in the signal and a couple of checksums.
Let's take a sample of the signal:
**part1* - **part2* - description
170F443E - 1A003200 - sent once
170F443E - 12803200 - repeating signal
The first 4 bytes are the fixed data that is fed into the executor. The 2nd nibble of each 4-byte set is a SUM of all the other seven nibbles in the set.
The toggle is the rightmost bit of the 3rd nibble of the 2nd part of the signal (ie, 0 changes to 8 in this example, which in turn causes the checksum to change from A to 2).
Nibbles 4-6 of part1 are always "F44", at least in every example that I've seen, so the only fixed data that varies is the 1st nibble, 3rd nibble and the 4th byte.
Part1:
The 1st nibble is variable (but it's usually 1).
The 2nd nibble is the checksum.
The 3rd nibble is variable (but it's usually 0).
The 4th nibble is always "F"
The 3rd byte is always "44"
The 4th byte is the main device code.
Part2:
The 1st nibble is a repeat of the 1st nibble from part1.
The 2nd nibble is the checksum.
The 3rd nibble is the toggle.
The 4th nibble is a repeat of the 3rd nibble from part1.
XMP-1
The 3rd byte is the OBC.
The 4th byte is zeroes.
XMP-2
The 3rd byte is zeroes.
The 4th byte is the OBC.
We could assign "device code 1" to the 4th fixed byte. We could combine the 1st and 3rd nibbles as "device code 2". The 4th nibble and 3rd byte could be OEM codes, that way we can change them if needed.
As very few remotes have the $016C executor built in, I would recommend that we provide a reduced version that uses 1 variable byte if it's requested for a remote that doesn't have it.
For remotes that do have it (like the 15-135), if the user selects XMP-1, the OBC data should get dropped into the 1st variable byte, and if the user selects XMP-2, it should get dropped into the 2nd variable byte.
For DecodeIR, as long as the middle portion of the fixed data is "F44", it could provide the data as described above. If the data is different, it could append the new data to the protocol name. For example, if the fixed data was "170D433E", it could display the protocol as XMP-170D433E-1 or XMP-170D433E-2 (depending on whether the 1st or 2nd OBC byte was used).
Given how hard it can be to differentiate between some pairs, expecially the $E and $F pairs, I think it would be a good idea for DecodeIR to use the checksum nibble as a way of validating the data. If the OBC byte is half way between 0E and 0F, for example, check which value would generate the value found in the checksum nibble and go with that one. Be aware, of course, that the checksum pair could also be between two values, so you would need to decide which pair you have the greater confidence in.
Here's how you can calculate the checksum:
1) convert each nibble (except for the checksum nibble) to decimal
2) ADD all the decimal values
3) subtract the result from 256
4) MOD it with 16 (ie, divide by 16 and keep the remainder)
5) convert the result back to 1 nibble of hex.
For anyone else who's interested, here are the 16 pairs used by this protocol:
0 = +210 -750
1 = +210 -890
2 = +210 -1030
3 = +210 -1170
4 = +210 -1310
5 = +210 -1450
6 = +210 -1590
7 = +210 -1730
8 = +210 -1870
9 = +210 -2010
A = +210 -2150
B = +210 -2290
C = +210 -2430
D = +210 -2570
E = +210 -2710
F = +210 -2850 |
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
|
|
| Back to top |
|
|
3FG
Expert
Joined: 19 May 2009
Posts: 3367
|
| Posted: Fri Mar 19, 2010 11:37 am Post subject: |
|
|
| Quote: | So where is the subdevice?
What is the significance of nibble2 of part 2? |
The subdevice is the combination of the 1st and 3rd nibbles of the first part ($10 in the above example = 16 decimal)
Nibble 2 in both parts is the checksum of the other 7 nibbles.
You've quoted Rob's post where he lists a 5 step algo to calculate the checksum near the end. |
|
| 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
