 |
JP1 Remotes
|
| View previous topic :: View next topic |
| Author |
Message |
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21238
Location: Chicago, IL
|
 Posted: Fri Jan 08, 2010 12:34 pm Post subject: |
 |
|
This sounds very impressive, so please do post the program so I can try it out. How do you differentiate between the XMP1 and XMP2 styles of signal, so we know which byte is the OBC?
_________________
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 |
|
 |
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
| Posted: Fri Jan 08, 2010 4:40 pm Post subject: |
|
|
I haven't done anything about XMP1/XMP2 yet, so XMP2 still shows up as before, with OBC >= 256. I have been concerned, so far, only with sorting out the corruption arising from the limit of ten bursts. I will post it shortly.
__________________
Graham |
|
| Back to top |
|
|
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
| Posted: Sat Jan 09, 2010 12:12 pm Post subject: |
|
|
I have now refined DecodeIR 2.40 Beta and have posted it here. The changes since yesterday's message are:
* The decoder now shows the protocol as XMP-1 or XMP-2 when one of the two OBC values is zero.
* The "Cal" algorithm is now split into two, since the two variants have different potential errors of reconstruction. When one digit has been calculated and inserted, it still shows as "Cal" and the most likely error is that the two hex digits of the OBC are the wrong way round. When a missing zero OBC, i.e. two consecutive missing zero bursts, have been identified and inserted, it now shows as "Cal2" and the most likely error is that it shows as XMP-1 when it should be XMP-2.
In XMP-1 the value shown in the OBC and Hex columns correspond to OBC1 as OBC2 is zero. In XMP-2 the value shown corresponds to OBC2 as OBC1 is zero. If both OBC values are zero it shows as XMP-1/2. If neither are zero it shows as XMP, the values in the columns correspond to OBC1 and the Misc field gives the corresponding values for OBC2.
Rob has said
| Quote: | | 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. |
I have not changed the meaning of Device and SubDevice for XMP. They are exactly as Rob describes, though Device = device code 1 and SubDevice = device code 2. I have not taken up the suggestion concerning OEM codes. I am requiring the 3rd byte to be 44 for the signal to be recognised as XMP. The danger in relaxing virtually everything - the checksums can't be tested as they are used for corrections - is that other protocols will start being recognised as XMP with errors. I've already needed to process frame lengths (the number of bursts in a frame) of 16, 17, 18, 25 and 26 all as possible corrupted XMP signals when the only valid value is 18, so until there is evidence of 3rd bytes other than 44 I would prefer to keep that as a requirement. I don't require the 4th nibble to be F, since that can get corrupted to E, so other values for the 4th nibble will get shown as undecoded XMP signals.
I have not changed the way in which signals recognised as XMP but which cannot be fully decoded are reported. They show with a protocol name such as XMP:136.218-0F0F441A0A800F00. See DecodeIR.html for the meaning of the two digits after the colon. The digits after the hyphen give the 16 data nibbles (or possibly 14 or 15 if some are missing) after any reconstruction algorithms have been applied. This particular example, taken from John Fine's text in DecodeIR.html contains two "coalescences": E and F both show as F, 9 and A both show as A. One F should be an E, one A should be a 9.
What would my reconstruction algorithms have done with this? The 11th nibble of 8 indicates that this is a repeat frame. It is likely that the first frame would have been received as 0F0F441A01000F00, in which the second half frame is correct. This is likely because all the digits in that second half frame occur elsewhere in the signal. As this has a valid second half checksum, the reconstruction would work with this and not with the repeat frame. The coalescence of 9 and A has therefore been avoided. The most likely remaining error is that E and F have been coalesced since only digits larger than 8 seem subject to this. But there is no way to determine which of the two F's in the first half frame should be an E. (It won't be the F in the second half frame as that now has a valid checksum.) So the Correction algorithm fails and it would be reported as an undecodable XMP signal. Hand decoding, however, would not be able to do any better. The repeat frame would not be shown separately in the IR.exe learned signals display.
I an sure that the reconstruction algorithms can be improved still further, but I need more examples to work from. This decodes correctly everything in Rob's six sample files (files 5 and 6, I have realised, are different learns of signals already present in the first four files so the correct values are in the spreadsheet) and the above example shows that not everything can be corrected. But if I have samples where the present reconstruction fails, I will look into whether it can be further improved.
________________
Graham |
|
| Back to top |
|
|
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
| Posted: Sat Jan 09, 2010 12:17 pm Post subject: |
|
|
Oops! John's example CAN be fully reconstructed. In the frame 0F0F441A01000F00 it HAS to be the first F in the first half frame that is really an E, as the second F is part of the fixed data. So I am right - the reconstruction algorithms CAN be improved!
_______________
Graham |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21238
Location: Chicago, IL
|
| Posted: Sat Jan 09, 2010 12:27 pm Post subject: |
|
|
I've got to say that it sounds like you have done an absolutely AWESOME job with this Graham, so I can't wait to test it out.
Regarding whether you should test for F in the 4th nibble, maybe you should require that it be either F or E, as I don't think an F would learn with a value less than E.
_________________
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: Sun Jan 10, 2010 1:12 pm Post subject: |
|
|
Here's an initial attempt at a reduced size 1-byte XMP-1/2 executor.
| Code: | Upgrade protocol 0 = 01 6C (S3C8+) XMP-1/XMP-2 (152 bytes)
43 8B 61 8B 05 00 00 69 01 67 08 09 F0 C0 04 09
C0 60 C0 0E 04 07 C0 88 C0 B6 C8 08 B0 0A 18 04
37 11 05 E4 09 0A B0 09 46 04 01 56 C0 0F 56 07
F0 44 C0 07 6C 03 F6 FF 6C C6 F8 19 64 F6 01 58
6C 07 F6 FF 6C C6 F8 17 70 F6 01 58 6C 07 58 0D
F6 01 0A 6A 02 58 0D 6E 59 0D FB 3B C6 F8 13 88
F6 01 58 6A E9 46 08 80 08 C8 8B BF B0 C5 C7 26
F0 C2 F6 FF 84 C7 26 F6 FF 84 6E 5E 37 54 EF 1C
12 8D 01 64 1C 12 F6 01 4C 56 C2 0F 6B 09 C6 F8
00 3E F6 01 58 2A F7 AF
End
Upgrade protocol 0 = 01 6C (HCS08) XMP-1/XMP-2 (145 bytes)
20 08 22 47 61 00 00 68 01 7B B6 66 62 BB 66 40
BB 64 A4 0F B7 52 A8 08 B7 58 3F 67 00 61 05 4E
66 67 3F 66 10 61 B6 64 A4 F0 BA 52 B7 64 6E 60
54 AD 34 45 19 64 CD FF 74 AD 2C 45 17 70 CD FF
74 6E 07 52 4E B2 53 CD FF 92 3B 52 03 4E B2 53
3C 52 4E 53 B2 24 39 45 13 88 CD FF 74 3B 52 E4
1E 65 4E 58 52 20 BF 3F 52 AD 0E AD 0C 3C 54 3C
52 05 52 F5 AE 6A CC FF 68 AE 6A CD FF 65 8C BE
54 F6 62 F7 A4 0F 27 08 45 00 43 CD FF 74 4B F8
81
End |
These executors retain all the functionality of the latest official versions, including handling repeats properly, but omit the optional second "key-up" toggle on the final frame. I've done some minimal testing of the S3C8+ version, but I have not tested the HCS08 version yet.
They use 6 fixed bytes and one variable byte (the OBC). The first four bytes are constructed in the same way as for the official XMP executor, as Rob describes here, except that the 4th nibble is $F for XMP-1 and $E for XMP-2. The checksum in the 2nd nibble must be precalculated (the executor does not do it), and should always treat the 4th nibble as if it were $F even when it is $E.
The fifth & sixth fixed bytes are the first two bytes of Part 2:
The 1st nibble is a copy of the 1st nibble from part 1.
The 2nd nibble is a partial checksum (see below).
The 3rd nibble is always 0.
The 4th nibble is a copy of the 3rd nibble from part 1.
The partial checksum in the 2nd nibble is calculated in the same way as the checksum in part 1, but only includes nibbles 1, 3 & 4 of part 2. The executor will add in the checksum for the OBC before transmitting the frames.
_________________
Mike England |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21238
Location: Chicago, IL
|
| Posted: Sun Jan 10, 2010 1:29 pm Post subject: |
|
|
I just got Excel and the rest of the JP1 software installed on this new laptop and I tried out the DecodeIR and I'm totally amazed that you were able to build in all those correction routines, it's much better than I could possibly have hoped for, so thank you very much, I really appreciate it.
_________________
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: 3367
|
| Posted: Sun Jan 10, 2010 2:07 pm Post subject: |
|
|
| Quote: | | so until there is evidence of 3rd bytes other than 44 |
According to devices.xls and the Lookup Tool, Cable 1061 (Slingbox JU) and Video 0707 (URC-8203) both have the 3rd byte as 00. Both setup codes have fixed data listed as 04 0F 00 0D. The checksum nibble 4 is correct for a 3rd byte of 00. Do we think those are in error or are they examples of "other than 44"
Similarly, the 4th nibble is usually F, but there are three examples of 7 (Cable 1730, 1961, and 2060). However, I don't think the checksums for these agree with the fixed data, so presumably some aspect of the fixed data has been recorded incorrectly. |
|
| Back to top |
|
|
mr_d_p_gumby
Expert
Joined: 03 Aug 2003
Posts: 1370
Location: Newbury Park, CA
|
| Posted: Sun Jan 10, 2010 7:07 pm Post subject: |
|
|
| 3FG wrote: | | Similarly, the 4th nibble is usually F, but there are three examples of 7 (Cable 1730, 1961, and 2060). However, I don't think the checksums for these agree with the fixed data, so presumably some aspect of the fixed data has been recorded incorrectly. |
The official UEI executor uses one or more bits of the 4th nibble for options, but always forces the nibble to $F before transmitting. For example, the latest versions use bit 3 = 0 to transmit a final frame with bit 4 of the toggle byte set to 1.
_________________
Mike England |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21238
Location: Chicago, IL
|
| Posted: Sun Jan 10, 2010 10:07 pm Post subject: |
|
|
I have just updated the devices.xls spreadsheet to use the new format device codes for XMP. When the 3rd byte isn't 0x44 I have put the decimal value into the 3rd column.
I can't tell the difference between XMP1 and XMP2 just from the fixed data, so I have listed them all simply as XMP.
_________________
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 |
|
|
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
| Posted: Mon Jan 11, 2010 3:54 am Post subject: |
|
|
I will investigate whether I can relax the requirement in DecodeIR for the 3rd byte to be 0x44 without causing other protocols to be considered as corrupted XMP. The way things seem to be developing, we do need this to be relaxed but the 4th nibble, it seems, is safe to stay as 0xF. So as Rob suggested, perhaps the way to try to go is to require the 4th nibble to be 0xF or 0xE (the latter being a corrupted F) and reporting the 3rd byte as OEM when it is other than the default 0x44.
Does that seem OK?
_____________
Graham |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21238
Location: Chicago, IL
|
| Posted: Mon Jan 11, 2010 8:44 am Post subject: |
|
|
| mathdon wrote: | I will investigate whether I can relax the requirement in DecodeIR for the 3rd byte to be 0x44 without causing other protocols to be considered as corrupted XMP. The way things seem to be developing, we do need this to be relaxed but the 4th nibble, it seems, is safe to stay as 0xF. So as Rob suggested, perhaps the way to try to go is to require the 4th nibble to be 0xF or 0xE (the latter being a corrupted F) and reporting the 3rd byte as OEM when it is other than the default 0x44.
Does that seem OK? |
Absolutely.
_________________
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 |
|
|
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
| Posted: Tue Jan 12, 2010 6:49 am Post subject: |
|
|
Mike, I'm getting confused by what seems contradictory info in two of your posts. Early in this thread you wrote
| mr_d_p_gumby wrote: | | In the case of the XMP executors, so far I have not been able to detect any difference in the fixed or variable data used by any of the variations, so there is presently no need to identify variants. There are some subtle differences. For example, the latest S3C8 & HCS08 versions add a forced repeat of 14x if it is executing within a macro. The other differences just seem to be attempts to re-code this rather huge executor more efficiently. |
More recently you have written
| mr_d_p_gumby wrote: | | The official UEI executor uses one or more bits of the 4th nibble for options, but always forces the nibble to $F before transmitting. For example, the latest versions use bit 3 = 0 to transmit a final frame with bit 4 of the toggle byte set to 1. |
That looks to me like a difference in the fixed data that should count as a variation. My concern at present is in getting DecodeIR right. If there are versions of XMP that send a distinctive final frame, or flags in the fixed data that cause other variations from the normal pattern of an initial frame with a toggle nibble of 0 and all subsequent frames having a toggle nibble of 8, it would be helpful to me to know about them. My ideal would be to have DecodeIR detect and report on which variation was used.
__________________
Graham |
|
| Back to top |
|
|
mr_d_p_gumby
Expert
Joined: 03 Aug 2003
Posts: 1370
Location: Newbury Park, CA
|
| Posted: Tue Jan 12, 2010 11:43 am Post subject: |
|
|
| mathdon wrote: | | That looks to me like a difference in the fixed data that should count as a variation. |
The very latest versions added the option for the extra toggle bit on the final frame. Technically, this does require variant identification, but I didn't suggest it yet as I didn't want to introduce even more confusion here until we got the basics worked out. Until 3FG mentioned the discrepancy above, I had not seen this feature used.
| mathdon wrote: | My concern at present is in getting DecodeIR right. If there are versions of XMP that send a distinctive final frame, or flags in the fixed data that cause other variations from the normal pattern of an initial frame with a toggle nibble of 0 and all subsequent frames having a toggle nibble of 8, it would be helpful to me to know about them. My ideal would be to have DecodeIR detect and report on which variation was used.
|
So far, this is the only option provided by the executor. It is found in the 15-100, 15-133/4/5, Arcam CR100, Atlas3033, Comcast 1067BX3, Cox 7820B, Cricket, Dreambox V5, RCA RCRP05B, URC-7525, URC-7950, URC-7781, URC-8305/8, URC-8350 and URC-10820N.
Here's how it works. When the option is enabled (bit 3 of the 4th nibble = 0), the only difference is in the final frame transmitted after all repeats are done and the button is no longer pressed. The toggle nibble is set to $9 and the checksum is updated.
_________________
Mike England |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21238
Location: Chicago, IL
|
| Posted: Wed Jan 13, 2010 3:53 pm Post subject: |
|
|
Here are two working upgrades that I've created for the Slingbox (one for the PL box and one for the RV box). They're currently formatted as "Manual Settings" upgrades because they include custom protocol upgrades, each designed especially for the specific PL or RV Slingbox.
Is there a way that we could set up the "XMP" protocols.ini entry so that if the user selects a Slingbox, RM will present them with the custom protocol code?
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=7837
_________________
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 |
|
|
|
|
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
