PID $016C: XMP Protocol

[mr_d_p_gumby]

Here's my next attempt:

Code: Select all

Upgrade protocol 0 = 01 6C (S3C8+) XMP-1/XMP-2 (122 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 56 C0 0F 56 07 F0 44 C0 07 6C 
 03 F6 FF 52 C6 F8 19 64 F6 01 58 6C 07 F6 FF 52 
 C6 F8 9B 47 F6 01 58 F6 01 0A 46 08 80 08 C8 7B 
 D5 AF 5C 04 F6 FF 62 F6 FF 62 6E 5A F7 1C 12 8D 
 01 64 1C 12 F6 01 4C 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) XMP-1/XMP-2 (114 bytes)
 20 08 22 47 71 00 00 68 01 7B B6 67 62 BB 67 40 
 BB 64 A4 0F B7 52 A8 08 B7 58 38 66 27 05 4E 67 
 66 3F 67 B6 64 A4 F0 BA 52 B7 64 6E 60 54 AD 19 
 45 19 64 CD FF 74 AD 11 45 9B 47 CD FF 74 CD FF 
 92 1E 65 4E 58 52 25 DB 81 6E 04 52 AD 0C AD 0A 
 3C 54 3B 52 F7 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

It might be interesting to try this on your Slingbox PL file, as it is smaller than the PL-specific code in your upgrade. (You'd have to add the repeats.)

What I did here was to throw out UEI's elaborate leadout logic and go back to a straight leadout. I also changed to 7 fixed bytes. The first 6 fixed bytes are as I detailed in the other post above. except that the 4th nibble is always $F. The 7th byte is $40 for XMP-1 and $00 for XMP-2, and is not included in the partial checksum.

[3FG]

I've made a revised XMPsumCheck class for RM which handles both XMP and XMP-1/XMP-2, using the protocol upgrades and fixed data format provided by mr_d_p_gumby just above. I think we decided to avoid a possible naming conflict with UEI official protocols, so I have called the shorter protocol XMPsmall. Obviously that can be changed to a better name.

XMPsmall uses the same parameters as XMP, with OBC-1 (command sent in the 3rd byte of the second part) as the default. The user can click on a check box labeled OBC-2 to cause the data to be written to the 4th byte.

HCS08 remotes which don't have 016C protocol built in will only show XMPsmall in the protocol drop down.
https://www.hifi-remote.com/forums/dload ... le_id=7772

[The Robman]

I think we decided to avoid a possible naming conflict with UEI official protocols, so I have called the shorter protocol XMPsmall. Obviously that can be changed to a better name.

Having read the descriptions of the other XMP variants, I don't think it's likely that we'll ever see them in a remote control, so I'm not as worried about naming overlaps now. Plus, I really can't come up with anything better than XMP-1 and XMP-2, so my vote would be to just stay with those names.

[The Robman]

The 7th byte is $40 for XMP-1 and $00 for XMP-2, and is not included in the partial checksum.

I've just started reading your code to see how you did this and it looks like the 7th byte should really be $80 or $00 (not $40 or $00) because you're grabbing the MSB from it to use as the control bit. Do you agree?

Also, regarding using this for the Slingbox, that's a good idea but we'll still need to maintain a separate version because the Slingbox needs different burst times as it has a different processor speed than the remotes. However, using a version of your executor means that we wouldn't need to maintain a separate version for each Slingbox, which means we could have an "XMP-1 (Slingbox)" protocol option.

[The Robman]

Just finished reviewing Mike's XMP code (the S3C8 version, that is) and it's pretty damn good. Here's my disassembly of his code.

Mike, what is the difference between the $014C routine and the $0164 routine? I noticed that you used $0164 to start the leadout pairs, but you used the more standard $014C to start the regular pairs.

[mr_d_p_gumby]

I've just started reading your code to see how you did this and it looks like the 7th byte should really be $80 or $00 (not $40 or $00) because you're grabbing the MSB from it to use as the control bit. Do you agree?

Ah, my devious plan is revealed! I was reserving bit 7 for possible use in controlling the final-frame toggle, should it be necessary to add it. Using bits 6 & 7 like this, I can test both bits and zero the 7th byte with one shift instruction.

Also, regarding using this for the Slingbox, that's a good idea but we'll still need to maintain a separate version because the Slingbox needs different burst times as it has a different processor speed than the remotes. However, using a version of your executor means that we wouldn't need to maintain a separate version for each Slingbox, which means we could have an "XMP-1 (Slingbox)" protocol option.

I haven't digested the timing differences yet, but I see no reason why we couldn't do this.

Mike, what is the difference between the $014C routine and the $0164 routine? I noticed that you used $0164 to start the leadout pairs, but you used the more standard $014C to start the regular pairs.

$0164 only generates the burst on (mark) period, whereas $014C generates both the burst on and off (mark and space) periods. I guess I could have used only $014C and compensated by shortening the leadout time.

[The Robman]

I haven't digested the timing differences yet, but I see no reason why we couldn't do this.

I'm having to refresh my memory myself. I'm documenting what times are used in each version of the protocol right now. From first glance, it looks like the times may just be wrong in the version used in the Slingbox, so we might be able to simply pretend that they don't have the $016C protocol loaded and be OK.

[The Robman]

I've just started reading your code to see how you did this and it looks like the 7th byte should really be $80 or $00 (not $40 or $00) because you're grabbing the MSB from it to use as the control bit. Do you agree?

Ah, my devious plan is revealed! I was reserving bit 7 for possible use in controlling the final-frame toggle, should it be necessary to add it. Using bits 6 & 7 like this, I can test both bits and zero the 7th byte with one shift instruction.

A-ha, I see what you're doing. So any value other than zeroes in the 7th byte will cause the OBC bytes to be swapped.

[The Robman]

My initial conclusion is that UEI simply got the 1st leadout time wrong in versions 1 and 2, which means the following remotes have the bad version:

Version 1:
URC-2050
Atlas 3000
Slingbox PL
Slingbox PK
Slingbox RV

Version 2:
15-100

The times used for the pairs all look close enough that I don't think it would make a difference.

I see what they did with the leadout on the most recent version. This was done to make it easier for people to press consecutive buttons, like when they might be entering a channel number. Basically it doesn't enforce the long leadout time if the button is no longer held. We definitely don't need that for the Slingbox, but we might want to consider adding it back for regular remotes.

[mr_d_p_gumby]

The times used for the pairs all look close enough that I don't think it would make a difference.

I used the 15-135 CBL/1187 as a reference for my executor. I averaged several IRWidget captures using the built-in executor and compared them to captures of mine.

I see what they did with the leadout on the most recent version. This was done to make it easier for people to press consecutive buttons, like when they might be entering a channel number. Basically it doesn't enforce the long leadout time if the button is no longer held. We definitely don't need that for the Slingbox, but we might want to consider adding it back for regular remotes.

It is more responsive with the (approximately) 80 mS leadout chopped into 7 pieces. The "fix" for repeats that they used only works when 2 repeats are requested (i.e., in a macro). The method I used in my previous version uses one more byte, but works with any number of repeats. In any case, it will add a fair amount to the size of the executor, so we would probably need to have both available.

[3FG]

I really can't come up with anything better than XMP-1 and XMP-2, so my vote would be to just stay with those names.

If we only use one executor for both XMP-1 and XMP-2, then I think we should not have separate entries for XMP-1 and XMP-2. There's too many protocols in the drop down list already. The add-in I made for protocols.ini provides XMP-1 as the default and uses a checkbox to select XMP-2.

Perhaps we can name a single protocol XMP-1/2. That's a numerical pun....meaning 1 or 2 but also half sized.

I don't understand the usage of PIDs. Is it OK to list both XMP and XMP-1/2 as 016C, even though they use different executors? Is there any conflict if the remote has a built-in 016C, and the user uploads the compact upgrade and protocol upgrade?

[The Robman]

I don't understand the usage of PIDs. Is it OK to list both XMP and XMP-1/2 as 016C, even though they use different executors? Is there any conflict if the remote has a built-in 016C, and the user uploads the compact upgrade and protocol upgrade?

In this case, if we think that using Mike's new executor will result in less memory usage than using the built-in executor, we will basically act as though the original executor doesn't exist and every one will get a protocol upgrade for this protocol.

It was more complicated with the $007E executor which started off just as the Pioneer DVD executor, then they took out some of the special logic and made it a 2-byte code so that it would also work for Pioneer TVs. They kept on changing it, each time adding some additional functionality, so this became really difficult to handle on our end.

[mathdon]

I haven't had time to digest the latest postings on XMP, but I have a question that I think is separate from those discussions. I now have a DecodeIR 2.40 Beta 2 that can handle what have been called OEM1 (nibble 4 of the fixed data provided to the executor) and OEM2 (byte 3 of both the fixed data and the signal) and my question arises from that.

My concern is that OEM1 is not really an OEM code. It is not present in the signal, it is (as I understand it from Mike) a set of flags, essentially in comp form as they all have a default value 1. Only the top bit is currently used, which when set to 0 causes a final frame with a toggle nibble of 9. When DecodeIR detects such a final frame it sets OEM1 to 7, otherwise it is set to 15. You need to learn a short keypress for this to show up, but I have had no problem doing that in learning on my URC-7781 from the built-in 016C protocol on my URC-7940.

I think we should regard that nibble 4 as a protocol parameter rather than an OEM code, and name it Parm or something similar, as in the NEC protocols in RM. Byte 3 would then be the only OEM code. That gives us four setup items: Device, Subdevice, OEM, Parm. But now there is also another parameter, the one that selects between XMP-1 and XMP-2 in the XMPsmall entry for RM.

Two different types of parameter, one (Parm) that genuinely affects the signal and the other (the XMP-1/2 selector) that is just an instruction for the executor on interpreting a single OBC value. I feel this is getting too complicated. I would prefer it if we eliminated one or other of the parameters. We could go back to XMP-1 and XMP-2 and use the Parm parameter, or we could perhaps have XMPsmall that does both XMP-1 and XMP-2 with no final frame and XMPsmall-9 that does them both but with a final frame with toggle nibble 9.

I don't have strong feelings about the way to go, but I do want the output of DecodeIR and the input of RM (with 3FG's protocols.ini entry) to use the same language. I think my preference would be to revert to separate XMP-1 and XMP-2 entries in protocols.ini and keep the Parm parameter, as this leaves open the possibility of using Parm values other than 7 and 15 if UEI starts to use any of the other three possible flags.

It would be nice to have some consensus before I post the Beta 2.
___________________
Graham

[The Robman]

I haven't checked what bits UEI might treat as flags in their more recent versions of this executor (I will report back on that) but the three nibbles that you mention actually are part of the signal. The 4 bytes of fixed data that the UEI executor uses are all in the signal exactly as you see them.

What we've been debating is how to report them as device codes. In most cases the 4th nibble is "F" and the 3rd byte is "44", so when we see a deviation from that, we can consider those to be different OEM codes.

For the most part, the flags that Mike was referring to we flags that he was intending to introduce himself for his version of the executor (the idea being that he would replace the 4th nibble with "F" in the code). He later changed his mind and added a 7th byte of fixed data instead.

[mathdon]

Rob, setting nibble 4 of the fixed data to 7 instead of F does cause a final frame to be generated with a toggle nibble of 9, and nibble 4 of the data that is sent is F, not 7. That is what Mike said, and I have verified that with the UEI 016C protocol on the URC-7940.
________________
Graham