JP1 Remotes

The Robman wrote: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 the 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.

That analysis sounds pretty good to me.

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

Excellent!

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?

Yeah, I think so.

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).

I wouldn't mind doing that. Though, I assume that you guys don't live in Minneapolis.

You know, it just occured to me (after you mentioned lending my remote to John) that the guy that I borrowed this JP1 cable from has a "better" learning remote, too. I don't think it'd be great to steal his remote, but there's a good chance I could bring my XBox remote to his house and he could see if his remote could learn the signals.

It always seemed odd that my RadioShack remote couldn't learn the signal properly. If I could get his remote to learn the signal, would that .ir dump help you at all? Would it be just as good as CaptureIR?

It doesn't matter where each of live as we have a postal service here in the US!

Don't bother trying another JP1 learning remote as we've already established that the longest gap that a JP1 remote can learn is 130k uS, and your gap appears to be longer than that.

Keep an eye on this thread this evening as I'm hoping to have a new protocol for you to try later.

Awesome. Thanks!

OK, here ya go. This version seems to perform well in my tests. I tried pressing different buttons in quick succession and it seems to work.

Based on our previous discussion, I have set the long gap time to approx 140k uS. If this version repeats slower or faster than the original, you can adjust it by changing the value below that appears in red, which I don't believe you've tried ding with any of the previous protocols that I've posted. This time you'll see that the value is 0C, this is the hex value for 12. If you want to reduce the delay a little, change it to 0B (for 11) or 0A (10). To increase it, try 0D (13) or 10 (16).

Version #4

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 6E 37 61 F9 4C 0C F6 01 0A FB
0B C6 F8 14 00 F6 01 58 4A F2 8B E7 AF
End

Regression.

Well, not exactlly. The initial button press is a LOT better, now. I can hit the button repeatedly and it will respond nicely. The original feels somehow more smooth when pressed repeatedly, but I wouldn't even say that I'd notice the difference unless I was looking for it. So, initial press is great!

Now, the bad news. If I hold the button down, it only seems to send a single signal. It doesn't repeat at all.

I'm sorry that I didn't tweak your hex code setting before. I felt like there were bigger problems at the time, and you always gave me a new block of hex before I had much of a chance to test anything new.

I do understand hex, and I even understand the ASM that shows up in the protocol info box in IR.EXE. Well, I should say that I understand some of it. I don't know what BTJRT does, and of course, I don't know what registers hold what and what routines you're CALLing. I can read assembly in general, but I don't know anything about the JP1 ASM.

I'm still appreciating your help, and I'm getting more interested in the whole thing the more I learn about it.

Thanks.

Well, I'm completely baffled, I've tested this extensively learning from one remote to another and the signal looks qood. I really think it's up to you to do some experimenting now.

If you set the red byte down to 01, you'll get an 18k uS delay, then as you increment it, you will increase the delay by about 10.1k uS. A value of 0C will give you a delaye of about 130k uS, which should get you back to the version that worked but still repeated a bit too quickly. A value of 0D should give you approx 140k uS delay, which should be what you're looking for. If it turns out that the jump from 130k to 140k is too big and you think the real value is somewhere in the middle, you can reduce the value that's being loaded into RF8 (address $FF31) and increase the number of times it's sent (by increasing the value loaded into RC4 (address $F2A).

The value loaded into RF8 is the delay time. I have this code in a loop which is controlled by the RC8 register.

Hey Flavor, did you do any more testing?

No, unfortunately, I haven't had a chance. There's a good chance that I'll get some time tonight, though. I'll mess around with the variable you set up and see if any values work.

Thanks!

Flavor wrote:I don't know what BTJRT does, and of course, I don't know what registers hold what and what routines you're CALLing. I can read assembly in general, but I don't know anything about the JP1 ASM.

I don't know the jp1 asm either, but BTJRT is a cool, composite command - bit test followed by go someplace relative (+-127 bytes). Official name is something like Bit test and jump if true. The operands are jump destination and bit number to test if set. Doesn't affect any flags.

Just FYI, you can look up any instructions that you don't understand here:
http://www.hifi-remote.com/files/chip-m ... on-set.pdf

Thanks Liz. That makes perfect sense!

Hey Rob. I just tried a few different values for the variable you wanted me to tweak. They all had the same effect. The repeating does not work.

I was also wondering if there's a doc that tells what the function calls do and what the return values are.

Also, is there an assembler for this?

Assembler: http://www.hifi-remote.com/forums/viewtopic.php?t=5248
is included in the Protocol builder. Read two instruction readme files.

There is also a standard s3c8 assembler with somewhat different, slightly non-standard syntax here and there but permits conditional assembly:
http://www.hifi-remote.com/forums/viewtopic.php?t=4608

You can take the protocol Rob makes, put it through Decode in PB, and then into the assembler sheet. Have fun

Flavor wrote:Hey Rob. I just tried a few different values for the variable you wanted me to tweak. They all had the same effect. The repeating does not work.

Well, I'm totally baffled then, because a value of 0C should have given you approx 130k uS delay, which is exactly what one of my earlier versions produced which you said worked.

Are you 100% positive that you loaded the new protocol correctly? I'm pretty sure you did, but it wouldn't be the first time that we've spent ages trying to get something working only for the user to come back with some DUH statement. For instance, could you try re-loading one of the previous versions just to verify that it works the same way that t did before.

To make discussion about this protocol easier I have gone back and given all of the versions unique numbers and have edited the following discussion to refer to them by number.

Hopefully John is still watching this thread. John, could you try capturing the data from version #4 and see what timings you get please.

I'll try to get to it today.