JP1 Remotes

I just bought this "command center" that sits under my Xbox.
http://www.geeks.com/details.asp?invtid=GXBICCX

It is an input switcher with a universal remote control to switch inputs and control the DVD functions of the xbox like the origional Microsoft remote, but uses different codes then the origional one. The remote has to be one of the cheapest remotes I have ever seen with buttons that are way too small and close together to use. Of course I will be throwing it into a drawer when we get this going for JP1.

I have uploaded my IR here with several of the commands learned.
http://www.hifi-remote.com/forums/dload ... le_id=1474

I would like to attempt to build a protocol for this myself if that is what is required, if someone would give me a starting point on protocol building, or for someone to explain what steps I should take next to see if it matches up with any existing upgrades already done.

1. Device: Game-Elements GXBICCX
2. Type of device: xbox input switcher/dvd control
3. JP1 Remote model: 8810
4. JP1 user? OF COURSE!
5. Still have original remote? yes
6. Checked Yahoo file section? yes
7. Checked Pronto file section (at R/C)? yes

Thanks
Mitch

I just added a very preliminary decoder for this protocol to DecodeIr and uploaded that version to:

http://john.fine.home.comcast.net/ir/Decode_IR_DLL.zip

Those decodes don't break out the device or OBC bits. They just display the 12 information bits in msb hex and the one bit parity. For example, the '1' key decodes as
GXB-A81.1 meaning the 12 bits are A81 in hex and the parity is 1.

Did you learn all the functions of the original remote?

Is anything special about the last three signals you learned?

The 4'th bit does not seem to be included in the parity computation and that bit is different in the last three signals vs all the others, which makes it strange either way (as a device bit or as a function bit).

The protocol looks roughly like:

(38.3K,520,msb)<1,-3|3,-1>(1,-1,D:4,F:8,P:1,1,-7m,1,-1,D:4,F:8,P:1,1,-130m)+

That's pretty easy to do in PB, except for the fact that the frame gap alternates between a tiny value (7 milliseconds) and a value too big for OFA learning to measure (at least 130 milliseconds). Very possibly the actual device is picky about that gap and you could get decent results with some single value.

Anyone trying this in PB should also note: I think [LI][-LO] type lead-out would work for this, but I'm not sure of that. I'm sure [OneOn,-LO] leadout would work, but that would require reversing the definitions of '1' and '0'. (If you look at the digit codes you can see that my IRP definitions of '1' and '0' and MSB are not arbitrary. So using OneOn for leadout would require MSB-COMP translation.

Assuming single byte hex cmd, the parity bit would be hard in PB, and that fourth bit would a problem. So it would be much simpler to just treat all of D:4,F:8,P:1 as a 13bit function using double byte hex cmds.

johnsfine wrote:Did you learn all the functions of the original remote?

Is anything special about the last three signals you learned?

The last 3 I think were most likely the vol +, vol -, and AV select, as you can see from the two new files I uploaded are different then all the rest as they should be. On the second file I uploaded, ( http://www.hifi-remote.com/forums/dload ... le_id=1478 )
Vol +, Vol - corrospond to those keys on the orig remote, and select is the AV select key. These are different and that sounds right, because they all are controls to the switcher box itself and not routed to the xbox for its use. In that file is also the up, down, left, and right that did not fit into the first file.

The first file ( http://www.hifi-remote.com/forums/dload ... le_id=1477 ) contains all the other keys on the remote. They all corospond to the names on the orig remote except for L1=display, L2=title, and L3=back.

Looks like I picked another remote that I should not have used as my first attempt into building my own protocol instead of you guys doing all the work!!!

Thanks for the help.

I did do a quick learn on my 2117, just to make sure I was getting the same info and I did.

Mitch

I tried building a protocol myself but unless there is some help doc on protocol building that I cannot find, I guess it is beyond my current abilities.

Looking at my files, does anyone see a protocol that is already done that might work?

Thanks
Mitch

Sorry. I meant to follow up on this last week and forgot.

I just now slapped something together in PB and RM. It might work. Test it and see. I'll try to find more time to check it myself later:

Upgrade code 0 = 1c dd (VCR/1245) GXB (RM v1.18)
df 00 9a fe f8 61
a8 a0 a8 18 a8 28 a8 30 a8 48 a8 50 a8 60 a8 78
a8 88 a8 90 a1 18 a1 60 a2 30 a4 18 a1 30 a4 30
a2 60 a2 28 88 b8 a2 18 a1 50 a1 48 a2 50 a1 28
a4 28 88 48 88 18
End

Upgrade protocol 0 = 01 df (S3C80) GXB (RM v1.18)
3d 90 02 8b 15 88 25 08 08 03 0c 00 f0 01 04 02
f8 0d ac 01 04 00 f0 ff ff 05 8d 01 46
End

I used VCR mode so I could use the same key placement as the learned signals without keymoves. We can clean up the function names and mode of the upgrade etc. easily after we know if any of it works.

I put the PB file, the rmdu file and the protocols.ini file (needed for the rmdu file) together in this .zip
http://www.hifi-remote.com/forums/dload ... le_id=1649

It works great. I need to install RM I guess to see if it is all setup right to what I had. I have been using KM.

Anyway, the volume controls flicker the recieve led not quite the same as the origional but it seems to work fine. I think it is just a bigger gap on the origional remote between the repeats or something.

Thanks alot. I really wish I could have done it myself, but I guess I have alot more to learn.

Mitch

As I said before, the original signal alternates between two different lead-out sizes. I've forgotten how to do that, so it would need some research time, then manual tweaking of the protocol from PB. So before going to that extra effort, I wanted to see how badly it would work with a single size lead-out.

As a first guess, I made the single lead-out roughly the size of the shorter lead-out in the original. It sounds like you're saying that's good enough.

If more testing shows it isn't good enough, try changing the lead-out in PB, starting from the PB file I posted. You can take the protocol upgrade directly from PB to IR, rather than taking it through protocols.ini and RM (though if we post the results for others we should get the final result into protocols.ini).

If it still isn't good enough without alternating lead-out times, ask again. Maybe Rob will remember enough to easily tweak it for us, or I'll dig through some info I knew once but forgot and then I'll tweak it.

But hopefully your first test was right and the lead-out won't even need tweaking.

After you install RM, you should see a simple correspondence between the hex in RM and the hex from DecodeIr. I only used one of your sets of learned signals to make the RM file, so in addition to fixing function names you'll probably need to add a few functions.

Later I will fix DecodeIr to give device and OBC numbers compatible with the way RM now supports this.

BTW, it wasn't clear from your messages what this thing is called. I named the protocol GXB just to have a working name with XB in it. If you have a suggestion for a more accurate or informative name, tell me before I make the naming in DecodeIr and protocols.ini official.

OK, I added a couple of things that you didn't put in and I uploaded it here:
http://www.hifi-remote.com/forums/dload ... le_id=1651

It all works fine except for the volume blinking the LED on the receiver different then the origional remote, but it still does the vol function just fine so we can leave it alone. I might play with the protocol later to see if I can get it better, but it doesn't really matter.

As for the name: It is made by Gemimi but you will not find that info anywhere on the box or equipment. On the box and Remote it says "Game Elements" and on the front of the device it has a big ICCX on it. Also on the box it says GXBICCX and "Integrated Command Center"

I think Game Elements xbox command center or video/audio switch would be pretty obvious but thats up to you.

Take a look at the file and let me know when/if you want me to move it to the proper place. I am guessing dvd, like the rest of the xbox stuff.

Thanks alot for all the help. One day, I might figure out this stuff for myself.

Mitch

Carwarr wrote:I tried building a protocol myself but unless there is some help doc on protocol building that I cannot find, I guess it is beyond my current abilities.

Here ya go...
http://www.hifi-remote.com/files/help/P ... uilder.zip

Carwarr wrote:OK, I added a couple of things that you didn't put in

Looks good, and I'm glad to see you were able to use RM.

But I have my usual nit-pick (that I have with most upgrades I look at): Are the function names meaningful?

Too many (especially "f rew" and "f fwd") look like they are naming JP1 keys, rather than the original remote's functions. Of course I haven't seen your original remote, so I could be totally wrong.

Carwarr wrote:As for the name: It is made by Gemimi but you will not find that info anywhere on the box or equipment. On the box and Remote it says "Game Elements" and on the front of the device it has a big ICCX on it. Also on the box it says GXBICCX and "Integrated Command Center"

I think Game Elements xbox command center or video/audio switch would be pretty obvious but thats up to you.

I don't see anything in what you just said that tells me a clearly better name for the protocol entry in protocols.ini, thats worth changing from the GXB I put there initially.

For the device upgrade that you should post to the DVD folder, I think "Game Elements xbox" would be good, but that's up to you. This upgrade may be the only use we ever find for this protocol, but we still distinguish devices from protocols and try to give device upgrades more specific names than we give protocols (especially a protocol like this, that seems designed to support more device numbers than the two your upgrade uses).

Carwarr wrote:Take a look at the file and let me know when/if you want me to move it to the proper place. I am guessing dvd, like the rest of the xbox stuff.

As soon as you think it's correct, unless someone jumps up with a good argument for my changing the GXB protocol name in protocols.ini and DecodeIr. If I did change the name of the protocol, then the rmdu file would need to be tweaked for protocol name. But that is independent of your changing the description and name of that rmdu.

As for understanding PB, it seems like you made an attempt to use PB earlier. You have my PB file, so comparing that to what you got by trying yourself may help you understand PB.

The Robman wrote:Here ya go...
http://www.hifi-remote.com/files/help/P ... uilder.zip

Alright! Where the heck did that file come from? I thought I looked everywhere for that! With that and johnsfine protocol and my learned codes, hopefully I can run through it all and understand it for next time.

johnsfine wrote: Looks good, and I'm glad to see you were able to use RM.

Yea, I used RM ok, but I feel much more comfortable with KM. Is there a reason for using RM instead of KM except for making it more "picture"/"user friendly" for the newer computer people who don't even know what DOS was??? Don't get me wrong, it looks like a great program, I just like the way KM does so much just being a spreadsheet.

johnsfine wrote:Are the function names meaningful?

Too many (especially "f rew" and "f fwd") look like they are naming JP1 keys, rather than the original remote's functions. Of course I haven't seen your original remote, so I could be totally wrong.

You must have read my mind. When I build an upgrade, I try to make it with the exact name of the buttons on the origional remote, and all the other buttons are correct.

The two buttons that I have as "f rew" and "f fwd" in the upgrade are actually " |< " and " >| " on the origional remote. I was going to call it "+ track", "- track" or something like that but I figured it was really close enough with the symbols on the UEI remote being |<< and >>|.
What is one or two less then/greater then signs between friends.
But now thinking about it, and it being dvd player controls, I guess maybe I will change that in the final upgrade.

I will probably play around with it for a bit and then throw it up in the "dvd" folder.

Thanks
Mitch

Carwarr wrote: Is there a reason for using RM instead of KM except for making it more "picture"/"user friendly" for the newer computer people who don't even know what DOS was???

RM is much easier to add good support for a new protocol into. I once had the knowledge needed to add something like this to KM with difficulty. But since then, KM has evolved and I've forgotten things, so I wouldn't even know where to start. But for RM it was easy.

It could have been done in KM (and probably in RM as well) using manual mode (rather than by adding what I'm calling "good" support) . But I don't happen to know how. Also, when I next release DecodeIr, it will have device and OBC numbers for this protocol. The "good" support in RM means that RM understands the device, OBC and parity parts of this signal. In manual mode you wouldn't get that. You'd need to stay in hex to have any coordination with DecodeIr. That becomes even worse if I decide (as I typically do) to drop that extra hex info out of the protocol name now that I have confidence the partitioning into device, OBC and parity is correct.

We needed to enter this data initially in Hex. In RM you can enter function data by any of HEX, OBC, or EFC and later edit the same functions any of those ways. I don't use KM much, so I may have missed some improvements, but last time I tried, KM let you enter function data in hex, but you were then more restricted in future maintenance of those functions than if you entered them by OBC or EFC, and you didn't get to see the OBC as a sanity check of the entered hex.

I not only "know what DOS was", I used it when it was new and I used better OS's also named "DOS" on other types of computer before PC's existed. I'm more often accused of being unwilling to drop obsolete methods, than of being too quick to jump to something just because it's new. But I don't understand your objection to RM. RM is more flexible than KM and easier to use. I have great respect for KM as an accomplishment and I know there are a few purposes for which it's better. But for this purpose, RM wins every aspect.

johnsfine wrote:But I don't understand your objection to RM. RM is more flexible than KM and easier to use. I have great respect for KM as an accomplishment and I know there are a few purposes for which it's better. But for this purpose, RM wins every aspect.

No offence to you at all. The impression I got at first glance was RM was a more user friendly version for JP1 remotes. And as it seems as both you and I are "old school", we probably both like to do things the hard way. Well, I shouldn't say hard, I guess I mean more complex way.

But thanks for your take on RM and I will try it out more. I just started out with KM and I had no reason to change. But from your info, it sounds like I need to take a closer look at RM.

L8R
Mitch