Xbox GXB protocol

[The Robman]

I've written a new exec for the GXB protocol (see this thread) and I'm taking a lightly different view of the raw data.

I think the first 8 bits are the device code, followed by a 4 bit OBC and a 1 bit parity bit (which is an XOR of the 4-bit OBC).

The data in the 4 bits that I'm calling the OBC increments sequentially. The data for the preceeding 4 bits has just 4 possibilities...

0001
0010
0100
1000

and there's just 5 possibilities for the first 8 bits taken together.

So, for my new exec, I'm using 5 fixed bytes which correspond to the 5 possible device codes. The first 5 bits of the variable data are the OBC followed by the parity. The remaining 3 bits contain the index for the appropiate device code.

Therefore, I'm proposing that DecodeIR be adjusted to reflect this new view of the data, and as soon as Flavor confirms that the new exec works, protocols.ini should also be updated. I don't know how to make protocols.ini calculate the parity bit, so someone else will have to do that (or tell me how to do it).

[johnsfine]

Can you clarify the intent?

I assume the executor change was made in order to allow a smaller device upgrade.

I prefer to make the decodes consistent with our best guess as the original design structure of the protocol. Are you saying this new view represents better insight into that original design? Or just that it is easier to generate it that way.

I guess I need to go back to whatever original data I dig up and try to understand both the timing issue from the other thread and this issue.

[The Robman]

Both.

We both agree that the 1st nibble is part of the device code and we both agree that the 3rd nibble is part of the OBC. So the point of contention is the 2nd nibble.

If you treat the OBC as 4 bits, the data increments sequentially with no gaps. But, if you treat the OBC as 8 bits, there are lots of gaps in the sequence. Looking at the data in the 2nd nibble, I see that the values are

0001
0010
0100
1000

If this nibble was really part of the OBC, given that the lower nibble increments sequentially without gaps, wouldn't it be somewhat logical for the values in this nibble to follow suit, and therefore you would see a much greater range of values here.

Bottom line, I don't see any clear definitive evidence to support including the 2nd nibble in the OBC, where I do see evidence for including it in the device code byte.

Now, purely from an implementation point of view, if I treat the OBC as 8 bits, I have no choice but to make this a 2-byte protocol. But, by treating the OBC as 4 bits (plus a bit for the parity), I have 3 bits that I can use for device code selection, which gives me the ability to mix up to 8 device codes, but as we only need 5 for this device, I set it at 5.

[johnsfine]

So far as I can find, we have only two sets of learned signals for this protocol, both of them JP1 (no CCF files or other sources).

The first set seems to be a subset of the commands of the second set. Interestingly, it seems to have a slightly longer gap between frames in each pair. Except for that timing difference I'd assume they were learned from identical original remotes.

A lot of the structural guesses we make when reverse engineering a protocol like this are really guesses about what the next example of the same protocol will look like.

This sample set has only five possible values for the first 8 bits. Will the next sample have the same five? A different five? More than five?

Maybe this single code set is the only instance of this protocol so any such speculation is meaningless (and the cleanest way to represent THIS code set is the cleanest way to represent the whole protocol).

[The Robman]

If we were writing this exec with a view to it being added to the UEI database, I think we'd need to take a broader view of the possibilities than when we're writing it for a single application, like this.

Given that this exec will always need to be added to the remote's memory, if and when we come across a variation that doesn't fit within the parameters that we've set now, we can simply adjust things at the time.

If the next GXB device calls for more than 5 device codes, as long as it doesn't need more than 8 I can simply increase the number of fixed bytes accordingly. If it needs more than 8, I would need to re-think the OBC/device code split.

But, all of that being said, given the nature of the device that we're dealing with here, I'm not exactly expecting another GXB device anytime soon.