JP1 Remotes

[mr_d_p_gumby]

Here's my next attempt:

[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.
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=7772

[The Robman]

[The Robman]

[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.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[mr_d_p_gumby]

[The Robman]

[The Robman]

[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.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[mr_d_p_gumby]

[3FG]

[The Robman]

[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.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[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