PID $016C: XMP Protocol

[mr_d_p_gumby]

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.

I tend to agree. As I mentioned, the official UEI XMP executor ignores the 4th nibble of fixed data as far as what data is actually transmitted (i.e., it does an OR of $0F on that byte). So far, they have used only one of those bits as a parameter to control the final frame toggle. I reserved bit 7 of the 7th byte in my executor for the same purpose (though it is not implemented yet). In other similar situations, like the NEC you mentioned, we've let optional parameters control operational characteristics such as this. In this case, we'd have a Parm that defauilts to 15, and could be 7 if the final frame toggle is activated. Or, it could be 0 and 8, and we'd do the inversion in RM & KM.

I would much rather see a single OEM Code byte for the 3rd byte. Given that the UEI executor always transmits the 4th nibble as $F, I would not expect to ever find a different value being decoded, regardless of what fixed data is used for the executor. Should we someday find something that is other than $F being transmitted, we can always add another OEM code or parameter. This would also require a different executor, as the current official one is incapable of transmitting anything else.

As to the XMP-1/XMP-2 situation, all DecodeIR needs to do is indicate which one is applicable to the data being decoded. Exactly how the user chooses one or the other need not be a concern to DecodeIR, as long as the indication is clear. I do not this this should be a "parameter". 3FG's checkbox is easily understood, as long as DecodeIR indicates such.

The 4 bytes of fixed data that the UEI executor uses are all in the signal exactly as you see them.

... except for the 4th nibble of fixed data, which it forces to $F, and the 2nd nibble of fixed data, which it ignores and replaces with an internally calculated checksum.

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.

Agreed with respect to the "44" byte, but the "F" byte is not data. The executor is hard-coded to transmit it as "F". As fixed data, it controls behavioral characteristics of a specific UEI executor, and I think it should be called a parameter. If UEI were to change their mind about how they arrange & use the fixed data, how would DecodeIR be aware of it without any change in the actual data transmitted?

[The Robman]

I understand that, but you also implied that the nibble wasn't present in the final signal, which isn't the case, that's what I was trying to make clear.

Version 0 and version 1 of the UEI code didn't treat any of the data as flags. In version 2 they started treating that bit in the 4th nibble as a flag, so they also added code to overlay the nibble with the value "F". So from a DecodeIR perspective, you can assume that you will always find "F" in the data.

If you find a different value, you could treat it as a different OEM code, but only versions 0 and 1 of the official code would be able to re-produce it, versions 2 and 3 will reset that nibble to "F" regardless of what value was supplied.

Here's the code that grabs the nibble to be used later:

Code: Select all

LD   W8,R04    - save the 2nd byte into scratch register W8
OR   R04,#0Fh  - set the right nibble of the 2nd byte to "F"

Then later in the executor, after the repeats have stopped, there's this...

Code: Select all

BTJRT LFF4A,W8.3 - test bit3 of W8, if it's 1 skip to exit

OR    R08,#90h   - set bit3 and bit0 of 2nd nibble of part2
LD    W6,#07h    - set index to part2
CALL  LFF97      - re-calculate the checksum for part2
CALL  LFF4B      - send complete signal

RET   

There are two setup codes that I know of that use this final frame, those being SAT/1730 and SAT/1931, both found only in the URC-7525 remote.

[The Robman]

The 4 bytes of fixed data that the UEI executor uses are all in the signal exactly as you see them.

... except for the 4th nibble of fixed data, which it forces to $F, and the 2nd nibble of fixed data, which it ignores and replaces with an internally calculated checksum.

True, but they only added the code to force the "F" value recently, the first two versions of their executor just passed the "F" value from the fixed data to the output. Plus, even though it's true that the executor code re-calculates the checksum, up until recently UEI were nice enough to put the right value in their fixed data, they've only recently started to supply fixed data with the checksum set to zero.

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.

Agreed with respect to the "44" byte, but the "F" byte is not data. The executor is hard-coded to transmit it as "F".

You're talking about the executor whereas Graham is talking about DecodeIR, so from his perspective it's still data. In other words, the actual signal that DecodeIR gets to look at with include a nibble of data with the value "F". The fact that UEI decided to re-purpose it, doesn't change the fact that it's still there.

As fixed data, it controls behavioral characteristics of a specific UEI executor, and I think it should be called a parameter. If UEI were to change their mind about how they arrange & use the fixed data, how would DecodeIR be aware of it without any change in the actual data transmitted?

For the most part, DecodeIR can be ignorant of the specifics of the executors, it's concerned with protocols. So, in the event that it detects a final frame, it should report that fact to the user (how it reports it doesn't matter). Then when the user sets up his upgrade in RM or KM, there should be a parameter that let's him select the final frame. How that parameter gets passed to the executor is of no concern to DecodeIR, that's a matter for protocols.ini and KM to work out.

[mr_d_p_gumby]

[Sorry if my previous remarks caused any confusion; that was not my intent. I was only trying to clarify what Graham needs to do with DecodeIR to display the XMP information.]

SAT/1931 is also in the URC-8350.
SAT/0707 in the URC-8203 and SAT/1061 in the Slingbox JU have the 3rd byte as 0.

To answer Graham more directly with my two cents:

A) OEM Code (0..255) for the 3rd byte.

B) If the 4th nibble is not F, then OEM Code 2 (0..15), otherwise omit. This should reflect the actual data in the bitstream (not the presence or absence of a final frame toggle).

C) Show the toggle nibble. T=0 for 1st frame, T=8 for others, T=9 for final frame if present.

D) Somewhere in all this, show the XMP-1/XMP-2 status.

The above information should allow RM & KM to configure any possible XMP executor.

Of course, I am just a non-attorney spokesperson, so others should feel free to comment or suggest other approaches.

[The Robman]

For what it's worth, I totally agree, well put Mike.

[mathdon]

Here's what I am converging towards, expressed in terms of Mike's labelled points:

A) Agreed. OEM code (0..255) for 3rd byte.

B) If the 4th nibble is not F, the protocol will not be recognised as XMP. With all the relaxation of conditions I have had to make to put in the error corrections, I think I must test this value otherwise there is too much danger of other signals being recognised as corrupt XMP.

C) DecodeIR no longer reports individual frames, it reports on the whole signal. There is only one protocol line returned, even when the toggle value changes during the course of the signal. (This has been so since v2.38, it's not new to this one). The behaviour of the toggle is checked internally in DecodeIR and if there are alternative permitted behaviours that should be distinguished then it will report them in the Misc column. I think this is the first protocol in which that is necessary, however.

I see the need to separate the way DecodeIR reports it from the way the alternatives are coded in the fixed data, so I suggest that there are two Styles of XMP protocol, Style 1 (the default) with no distinctive final frame and Style 2 with a final frame that has toggle nibble 9. I propose that the Misc column includes "Style 2" when this final frame is detected but omits "Style 1", leaving this to be inferred by default.

If the concept is OK, is there a better term than "Style"?

D) I suggest DecodeIR sticks to XMP-1 and XMP-2 as protocol names (and of course just XMP if both OBC values are nonzero). Personally I would like RM and KM to use XMP-1 and XMP-2 as well, even if they have a common executor, but if they don't then users will have to use XMPsmall or whatever for both of them.

Are we getting anywhere near a consensus on this?

BTW The code to test for Style 2 is written and tested. You need to "learn" a short keypress for that final frame to get into the learned signal, but that's easy enough if you are aware that it is needed.
___________________
Graham

[The Robman]

I think we're very close here.

Regarding if the "F" nibble isn't "F", I'm OK with it not being reported as "XMP", if we ever find an XMP signal with some other value in that spot, we'll deal with it then.

Regarding when there's a final frame, I'm undecided whether it would be better to display a different protocol name (like "XMP-FF") or whether there should be something in the Misc column, but as long as the info is displayed somewhere, I'm good with it. Keeping in mind that in most cases the final frame won't be captured, I think it should be displayed in a way that catches the user's eye, so that they know it's present. I would prefer to see something like "Final Frame" rather than "Style 2" in the Misc column, if you decide to go that way.

I agree with (D) regarding XMP-1/XMP-2, so I'd like to see RM and KM follow suit.

[mr_d_p_gumby]

B) If the 4th nibble is not F, the protocol will not be recognised as XMP. With all the relaxation of conditions I have had to make to put in the error corrections, I think I must test this value otherwise there is too much danger of other signals being recognised as corrupt XMP.

Sounds fine to me. (I could be wrong, but I suspect that the reason it would always be F is to serve as a timing reference for the device that is trying to decode the signal.)

C) DecodeIR no longer reports individual frames, it reports on the whole signal. There is only one protocol line returned, even when the toggle value changes during the course of the signal. (This has been so since v2.38, it's not new to this one). The behaviour of the toggle is checked internally in DecodeIR and if there are alternative permitted behaviours that should be distinguished then it will report them in the Misc column.

I tend to agree with this approach. It will certainly be more understandable to a novice user.

I think this is the first protocol in which that is necessary, however.

What, you mean no more "Whats a JVC2?" questions!

I see the need to separate the way DecodeIR reports it from the way the alternatives are coded in the fixed data...

I think both Rob and I absolutely agree on this point.

...so I suggest that there are two Styles of XMP protocol, Style 1 (the default) with no distinctive final frame and Style 2 with a final frame that has toggle nibble 9. I propose that the Misc column includes "Style 2" when this final frame is detected but omits "Style 1", leaving this to be inferred by default.

"Style" sounds friendlier than "Parm", but in essence they are the same thing. Comparing to the NEC case, the Parm value just happens to correspond to the value in the fixed data, but it's easy enough for RM/KM to translate other values into what the executor needs. Perhaps in this case we could default to Style=0 (omitted) and Style=1 for the final frame toggle. Either way this approach leaves open other possibilities. After all, they still have two unused bits in the toggle nibble to play with.

If the concept is OK, is there a better term than "Style"?

Style is fine with me. (I think its been used elsewhere too. Fujitsu comes to mind.)

D) I suggest DecodeIR sticks to XMP-1 and XMP-2 as protocol names (and of course just XMP if both OBC values are nonzero). Personally I would like RM and KM to use XMP-1 and XMP-2 as well, even if they have a common executor, but if they don't then users will have to use XMPsmall or whatever for both of them.

I'm OK with that. For KM, at the moment I am basically following 3FG's approach, except I call the protocol "XMP-1/2" and allow the user to select 1 or 2 as an "XMP Type" (similar to his checkbox). If we decide we want XMP-1 and XMP-2 to be two separate items, it's easy enough for me to change since nothing has been released yet.

Are we getting anywhere near a consensus on this?

I hope so.

[mathdon]

I've adopted Rob's suggestion and abandoned either Parm or Style. If the final frame is present, it says "With Final Frame" in the Misc column. I hope this isn't too confusing, as there is always one frame that is final , but "With distinctive final frame" seems unduly pedantic and very long.

So here's what it looks like at present, with a selection of XMP-1, XMP-2 and XMP signals all with a final frame, generated from my URC-7940 and learned on my URC-7781:



Will this do? There's nothing in the image with a non-default OEM, but if OEM were other than 68 then that too would be in the Misc column.

These examples have caused some more fine tuning of the correction routines. I think I've gone as far as possible with them now.
__________________
Graham

[mathdon]

What, you mean no more "Whats a JVC2?" questions!

I'm afraid there is still a JVC{2} as it is (slightly) distinct from JVC. I have a JVC OEM remote that genuinely sends JVC{2} as distinct from JVC. But there's no more of a JVC signal creating two lines, one of JVC and the next of JVC{2}. You just get JVC. Likewise I've got rid of "a frame of RCA{1} followed by a frame of RCA means that the protocol is RCA(Old)". DecodeIR puts it together and says the protocol is RCA(Old).
_____________
Graham

[The Robman]

I like it Graham. One minor suggestion would be to put the correction info after the "final frame" message (eg, #3 above would become "with final frame. Rec, cor") because the correction info is only of interest to an expert whereas the regular user needs to know about the final frame (keeping in mind that the misc info is sometimes off the screen).

[mr_d_p_gumby]

OK by me. The only down side to this is that if UEI introduces other variations in the future the Misc column is going to get rather verbose. But we can always deal with that if it happens.

BTW, I've shrunk the basic code size of the S3C8 version down to 118 bytes. Adding the final frame toggle adds 10 bytes. I'm still working on ideas to break up the leadout.

So, are we all agreed that there should be separate XMP-1 and XMP-2 entries in RM & KM?

[The Robman]

So, are we all agreed that there should be separate XMP-1 and XMP-2 entries in RM & KM?

I'm OK with it either way, but I think my preference would be for 2 separate entries.

[3FG]

So, are we all agreed that there should be separate XMP-1 and XMP-2 entries in RM & KM?

Um, does that mean to have 5 XMP entries in the list: XMP-1 (UEI), XMP-2 (UEI), XMP (UEI) , XMP-1 (Mike) and XMP-2 (Mike)? I'm not asking about the names themselves, but rather how to handle describing possible combinations of IR protocols and executors.

Or is the idea to have 3 entries: XMP (UEI-like executor), XMP-1 (Mike executor), and XMP-2 (Mike executor)?

I think the 5 entry scenario is 3 more entries than necessary; not a big deal. But the 3 entry scenario will tend to lead users in the wrong direction-- they'll see IRdecode provide XMP-1 as the IR protocol, and therefore choose XMP-1 in RM or KM.

Why do I say wrong direction? Because Comcast alone has 25 million users, and I guess that more than half have remotes with 016C built-in. Add to that Atlas, Vizio and Insignia. I'm new to JP1, so my remotes are designed in 2007 or later: RS-135, Comcast 1067BX3, and RCRP05B. Each has 016C.

So I think the natural flow should be to point users to the UEI executor. That's why I prefer 2 entries-- XMP and XMPsmall, with check boxes to select 1 or 2.

[The Robman]

All good points, maybe that's a good argument for having the 1/2 thing be a selectable option, along with the final frame option.

If we go that route, I see us having three selectable XMP protocols:

1) XMP - this option would use the built-in executor when it's available, and use Mike's code when it isn't.

2) XMP (UEI) - this option would use UEI's code regardless of whether it's built in. (Primarily for testing purposes for experts).

3) XMP (Hacked) - this option would use Mike's code regardless of whether the UEI version is built in. (Primarily for testing purposes for experts).

There would be 2 selectable options:

1) Style: XMP-1 vs. XMP-2 (corresponding to the XMP-1 and XMP-2 displayed by DecodeIR)

2) Final Frame: yes/no

There would be two device codes to enter and one optional OEM code (ie, the "44" byte).

We'll deal with non-F values in the 4th nibble if and when we come across one.

How's that?