Code for Osmart brand XBox DVD Remote

[Flavor]

Actually, I was using it more over the weekend and I noticed some unwanted behavior.

The GBX protocol seems to repeat keys rather quickly. This is somewhat nice on keys like the arrow keys, but even the arrow keys repeat a bit too fast (and a bit too soon). If I have a menu that spans the entire screen (vertically), I bet it takes less than a second to go from top to bottom. That may seem nice, but it makes it a little difficult to hit the right option without overshooting it.

The real problem is for the other keys. Immagine if you are going though a menu system where you would normally do something like choose item #1 and hit select, then from the sub-menu choose the third item and hit select, and finally choose the video you want to watch and hit select.

If the select button repeats too quickly, when you hit it to choose the first menu item #1 it sends repeating selects so that you immediatly choose the first item from the sub-menu.

Also, on XBMC when it's initially loading a video, a box pops up saying "Caching" and you can hit select to cancel it. Often when I hit select to choose a video, it sends an extra select and cancels it immediatly.

My initial idea is to go back to my learned signals (which didn't repeat at all) for all the functions except the arrow keys. Though, I would like to know if there is a "real fix" for my problem.

[johnsfine]

It's hard to get the two level repeat timing (long pause between the first and second frame then short from then on). That can be done, but needs some expert coding.

To simply increase the time between repeats is easy. I don't have the files handy here. I'll try to remember tomorrow if Rob doesn't give that answer first.

[Flavor]

The two-level repeat thing would be really nice.

Though, even just the increase between repeats would be better than it is now. Really, being able to disable repeating on certain buttons would be an improvement.

Thanks!

[johnsfine]

Sorry I took so long.

The pause between frames is controled by one value in the protocol upgrade. It's currently set to about 7 milliseconds.

To change it, select the protocol within IR.EXE and click the EDIT button. It will show a string of numbers that looks like:

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

To get 20 milliseconds, make the change in bold below

3D 90 02 8B 15 88 25 08 08 03 0C 00 F0 01 04 02
F8 27 00 01 04 00 F0 FF FF 05 8D 01 46

For 50 milliseconds.

3D 90 02 8B 15 88 25 08 08 03 0C 00 F0 01 04 02
F8 63 00 01 04 00 F0 FF FF 05 8D 01 46

For 100 milliseconds.

3D 90 02 8B 15 88 25 08 08 03 0C 00 F0 01 04 02
F8 C3 00 01 04 00 F0 FF FF 05 8D 01 46

The max changing just that number is around 132 milliseconds.

3D 90 02 8B 15 88 25 08 08 03 0C 00 F0 01 04 02
F8 FF FF 01 04 00 F0 FF FF 05 8D 01 46

For 200 milliseconds you change much more:

3D 90 02 8B 16 88 A5 40 08 08 03 0C 00 F0 01 04
02 F8 86 A0 01 04 00 F0 FF FF 05 8D 01 46

I can't imagine you want more than 200 milliseconds.

[The Robman]

I took a look at this protocol earlier and the lead-out time after every 2nd repeat shows up as about 130k. Having just seen this same lead-out time with the Solidtek keyboard, I know that this may really mean that the 2nd lead out time is alot longer than that and the 130k time is just the maximum that a JP1 learning remote can capture.

[johnsfine]

I know that this may really mean that the 2nd lead out time is alot longer than that and the 130k time is just the maximum that a JP1 learning remote can capture.

Correct.
That's one of many reasons I prefer using an IR sensor and captureIr program rather than learning.

[The Robman]

Hey Flavor,
Give this upgrade a try and see if it works a little better...

Version #1

Upgrade Code 0 = 2F D0 (DVD/2000) Xbox GXB (KM v8.35)
DF 00 E8 FE 7E 41 88 A1 A2 A4 A8 1C 2C 34 4C 54
64 7C 8C 94 A4 48 18 00 7A 4A 49 33 1B 29 61 31
51 49 2B 2A 62 1A 32 52 4B
End

Upgrade protocol 0 = 01 DF (S3C8+) Xbox GXB (PB v3.11)
3D 90 51 8B 12 85 24 08 05 03 0C 00 F0 01 04 02
F8 0D AC 01 04 00 F0 18 08 56 C1 07 87 21 03 29
03 B0 C6 F6 01 46 37 60 07 C6 F8 F5 88 F6 01 58
6E F6 01 0A 7B ED AF
End

[Flavor]

Thanks Robman. I tried it, and it is better. Unfortunately, it's still rather fast.

I'm not sure what you changed. Did you just up the delay between repeats, or did you change the deal where it takes longer between the first press and when the repeating starts?

Anyway, it's more usable now, but it still repeats a little fast. Well, I should be more specific. When I want it to repeat, this is a good rate. When I don't want repeating, it's a bit quick. It would be nice to have a longer delay between the first signal and the second, but after that, the repeats are fine.

Thanks. I really appreciate all the effort.

[The Robman]

That's the answer I was expecting and I know what to do next.

The original signal sends the data followed by a short delay, then the data followed by a long delay, etc, etc. John's version just did the short delay, this one adds a longer delay after every second repeat.

JP1 learning remotes have a limitation when learning long delays as they tap out at 130,000 us. The protocol I created uses a 130,000 delay after every 2nd repeat. I wanted you to test it first to see if that's enough before I add logic to make the delay longer.

Try using this protocol instead. This version sends the max delay 3 times, if it's still not enough, you can increase it by increasing the number in red below.

Version #2

Upgrade protocol 0 = 01 DF (S3C8+) Xbox GXB (PB v3.11)
3D 90 51 8B 12 85 24 08 05 03 0C 00 F0 01 04 02
F8 0D AC 01 04 00 F0 18 08 56 C1 07 87 21 03 29
03 B0 C6 F6 01 46 37 60 0B 4C 03 C6 F8 F5 88 F6
01 58 4A F7 6E F6 01 0A 7B E9 AF
End

[Flavor]

Sadly, I think it's worse.

On the original remote, it sends a signal IMMEDIATLY when you hit the button. Then, it waits N usec and starts repeating. The repeats are probablly like N/4 usec. Sorry, but I don't know what N is.

On your new protocol, it does not send a signal immediatly. It waits X usec and then sends a signal, waits another X usec and sends the signal, repeat forever.

Forgive me if I'm oversimplifying, but that's what it seems to do.

Here are the problems with the new protocol.

1) If you quickly hit an arrow repeatedly, it will do nothing. Like, if you wanted to go down 3 times, and you just hit it (BAM-BAM-BAM), it might not do anything at all. You'd have to hold it down for X usec before it would send a signal.

2) X is currently too large for repeating purposes.

This does not seem to coincide with how you explained that it should work, Rob. I wish that my remote would learn from the XBox remote, but it will only do it if I don't hold the button down (no repeats).

I could set up LIRC on my linux box to grab 'em (if that would help), but I think I'd need some more instruction on that. I had LIRC running for my MythTV at one time, but it's been quite a while.

Thanks again!

[The Robman]

Try this one instead. With the red 03 set the way it is, the gap is just a little bit longer than the original protocol I posted, and when you increase the value it will go up in smaller increments.

Version #3

Upgrade protocol 0 = 01 DF (S3C8+) Xbox GXB (PB v3.11)
3D 90 51 8B 12 85 24 08 05 03 0C 00 F0 01 04 02
F8 0D AC 01 04 00 F0 18 08 56 C1 07 87 21 03 29
03 B0 C6 F6 01 46 37 60 0B 4C 03 C6 F8 61 A9 F6
01 58 4A F7 6E F6 01 0A 7B E9 AF
End

[johnsfine]

I used CaptureIR to look at Rob's new protocol upgrades.

Version #1 has a 7515 uS gap the first time and a 132882 uS gap the second and alternates from then on.

Version #2 alternates similarly, but with 383615 uS as the long gap.

Version #3 alternates similarly, but with 157132 uS as the long gap.

From both Rob's comments and a glance at the code, I expected the first three pairs to have different timing than the remaining pairs. But a long press of the version #2 captured 10 frames consisting of 5 identical frames and a similar press of the version #3 captured 14 frames consisting of 7 identical pairs. I'll try to find time later to see what went wrong.

On the original remote, it sends a signal IMMEDIATLY when you hit the button. Then, it waits N usec and starts repeating. The repeats are probablly like N/4 usec. Sorry, but I don't know what N is.

On your new protocol, it does not send a signal immediatly. It waits X usec and then sends a signal, waits another X usec and sends the signal, repeat forever.

I'm having trouble coming up with an explanation for that. When I first read it, I assumed the original remote sent a pair of frames before the long gap and Rob's version didn't. But I see Rob's version does sent a pair of frames before the first gap. I guess I need a better understanding of what the original sends. But are you sure about that initial delay? (Are you sure the remote was aimed well for the first press?).

[The Robman]

I can't explain the one where my protocol didn't cause any reaction for a few seconds, but overall my guess as to what's going on is something like this.

Let's say that the long gap sent using the original remote is 200,000 uS.

When he tested the code with the 133,000 uS gap, it repeated too quickly because the gap was too short.

Then he tested the code with the 383,000 us gap, but this time the gap was too long, so the device assumed the button had been released, so it stopped looking for the repeat sequence. Then a few uS later along comes the signal again, so the device assumes the button has been pressed again and it starts the whole "listen and wait" process again.

I had hoped Flavor would edit the specified byte to try adjusting the gap time to see what works best, but I don't think he did.

The version with the too long gap was repeating the 130,000 uS gap for as long as was specified. The current version repeats a 50,000 uS gap for as long as is specified (by the counter in red), which hopefully gives you more ability to get the time as close as is necessary to the orginal gap.

[Flavor]

Okay guys, sorry for leaving you hanging. Yesterday was pretty hectic.

I just tested version #3. The speed of the repeats is only SLIGHTLY slower than the original. It's a good speed for me.

The only thing different between it and the original now is the initial button-press. If you want to tap the button a few times successively, the original responds very nice. My RadioShack remote, however, does not. If you were just after a single button press, most of the time you wouldn't notice it. But, it's just enough to tell that it's not quite right.

Also, the original remote sends a signal, then waits and then starts repeating. Your protocol doesn't seem to do that.

Anyway, if it stays like this, I would be satisfied. Though, I would say that it would be nice to get it closer to the original.

What's CaptureIR? Is it something that I can use? I have a serial port IR receiver somewhere.

Thanks!!!

[The Robman]

Let me see if I understand your results correctly. When you tried version #1 (which has a gap of about 132k uS), it repeated alot faster than the OEM remote, then when you tested version #3 (which has a gap of about 150k uS) it repeated a bit slower than the OEM.

Therefore, it sounds like the correct gap is somewhere between those two values.

Another difference is that you have to wait for the gap to finish before you can press the button again, I can fix that.

The final difference is that my protocol repeats right away whereas the OEM waits for a second or so before it starts repeating.

Have I summarized it correctly?

Seeing as how you are mostly happy with the current performance of your JP1 remote, maybe you could loan the original remote to John so he can accurately capture the signals using his CaptureIR device (of course, assuming he's willing to do it).

As for "what is CaptureIR?" check out this very long thread...
http://www.hifi-remote.com/forums/viewtopic.php?t=4797