JP1 Remotes

johnsfine · Posted: Sat Nov 01, 2003 11:12 am Post subject:

If you really want it to feel like commodore 64 programming, you could download the documentation on S3C80 assembly language programming and then write a custom protocol for the device that needs fast keypresses.

Just as the extender calls the keyboard subroutine itself rather than returning control to the built in programming, a custom protocol could call the keyboard subroutine itself instead of returning control to the extender. It could do fast processing for certain keys, sending their signals right away, bypassing the whole process of returning control and redispatching. Then it could send signal even faster than the unextended remote.

That's a bit easier than a whole new extender, but quite a bit harder than a typical custom protocol, so only recommended if you've had experience with micro computer (such as those you listed, and/or current embedded systems) assembly programming.

lisadaveh · Joined: 17 Oct 2003 Posts: 19

I looked at it, and I really think I can do that programming of the chip. Although I have done some more experimenting, and have found that the remote is blinking its LED more often than Girder is recognizing the signals. Girder recognizes the OEM remote keypresses in realtime (very quickly)

I Read in the Yahoo forums where the Creative remotes signals are hard to learn because they may use some weird NEC protocols.

After reviewing some posts in this forum, I think I may have found my slow keypress solution. I think I may have built my advanced device in KM incorrectly, and I am sure you guys can help me get this one straight.

When I learn the Creative remote buttons into my 8810W, Ir.exe shows me two protocols in its learned signal screen. NEC and a NEC1 protocol. I am not sure how to program this in KM, but have inferred from previous posts that there may be some PARM value I can input to make the keypress present properly to my IR reciever.

My current KM upgrade file simply uses the NEC1 protocol and the buttons on my remote only intermittently are recognized by Girder. If I put a PARM value of 5A in the PARM field of KM on the same protocol file, I get somewhat better results in girder recognizing each keypress.

I have read Rob's documentation of the whole $005 hex value thing, and to be honest, I really dont understand it. I really wanted to see if one of you guys could look at my screenshots of my learned IR signals and let me know what parm value I should be using (and/or what protocol) in KM to make this device work properly.

http://lisadaveh.home.comcast.net/8810Wremotes/LEARNEDCOMPARE.HTM

I really appreciate your help, and if I get it figured out, I can post an upgrade in the files section to help out others with this remote setup. It is probably a pretty popular setup as it is less than 10USD on many sites.

PS: I realize the button codes/ EFC codes in the above example are not the same codes, but it is a trend for all buttons on the two remotes. i.e. I did not learn the same exact buttons in the example.....

The Robman · Posted: Mon Nov 03, 2003 11:10 pm Post subject:

Dave,
Rather than post screen shots to your web site, you could always just load an IR.exe dump in the Diagnosis Area, which we could then open using IR.exe and see the real thing.

Anyway, what you need is an NEC1 signal that repeats the data portion twice instead of once. I had to look it up myself in this thread: http://www.hifi-remote.com/forums/viewtopic.php?t=169 but here's what you need to do.

In KM, select NEC1 as per normal, then enter a parm value of '22'.

How did I figure this out?

Well, the normal hex value for a 2 device NEC1 signal is $20, which in binary is 00100000. Then if you read the thread I linked to, it says that bit1 needs to be set if you want the data portion to repeat twice, so setting bit1 gives you 00100010, which when converted back to hex gives you $22
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

lisadaveh · Joined: 17 Oct 2003 Posts: 19

Rob, Once again you are the man!

For whatever reason, now I think I understand your $005A post (didnt realize/remember bits worked like that). Tried your 28 in the PARM and it didnt work very well. This was to set bit 3 (i think)

So I put 22 in the PARM option (to represent bit 1 I think) and it works very good now. I have analyzed the signals now and they are very much the same for both OEM and OFA.

"If B3 is set, use NEC2 for the repeatable buttons (ie, VOL+/-, CH+/-, REWIND and F.FWD).
If B1 is set, send the signal 2 times before jumping to the IR engine. "

Thanks for all your help, and let me know if you think my changing the PARM to 22 is wrong ( I think you meant to say '22' not '28').

PS, that $005A post of yours is pretty helpful, maybe we should see if the guy who writes KM would like to put somthing like that in the protocol help section of KM for NEC protocols.

The Robman · Posted: Tue Nov 04, 2003 9:00 am Post subject:

Good going Dave. I guess I need to take longer to read my own posts, I don't know why I came away thinking it was bit3 not bit1 that needed changing, but I described the process in detail so you could do it yourself if needed and it obviously paid off.

Just FYI, to help anyone else who might read this in the future, I have edited my original post to reflect your comments.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

nsysblh · Joined: 02 Nov 2003 Posts: 20

Just to add to the confusion, I've been playing around with the 3.1 extender on a 8810w I just bought. Strangely, it locked up the first 3 times I loaded the extender. Then it looked like it was working. It did control some devices. However when I tried to reload it into IR, it wasn't correct at all. IR complained about fixed data being wrong and it looked like the eeprom image wasn't right. I think the checksum was bad too. I just re-uploaded the extender and it crashed again. Put the non-extended programming back and it is ok.

So, my experience is really no different than anyone else (when it didn't work with their 8810w)

And, I am not sure what this all means. Maybe I'll try 2.4 in a while. How easy would it be to program a 'extender really is running' button? Sorta like the 4 flashes at the start of extender load that is called while it is actually in control. After that something to unload it may be useful too. I realize the only thing that can really be done with it unloaded is to hit TV power to reload it again, however the only way to reload now if it really is running (or crashed) is the reset line on the JP1 connector.

Hmm. I just thought about it a little. I guess you could fairly easily write a protocol / device upgrade that called the flash 4 times routine and put it in as a macro on a button that the standard programming won't let you use as a macro. So, the only way the routine would be called would be if the extender was running normally. Or you could flash the backlight...that would be a good indicator too (unless you put the macro on the backlight button)

edit: Ok, 2.4 seems to work fine for me too. And I have found an indicator that the extender is running. If you press and hold the setup (shift) and the light doesn't go out (or doesn't come on), then it is running ok. If the normal key parser is running, it will eventually blink twice to indicate programming mode is selected.

I'll go take a look at the code differences and see if anything jumps out at me.

second edit: Ok, adding 2 nops after the stop seems to do it. I'd think a couple of nops after the idle would be a good idea too...but r2 only had them after the stop.

Can anyone else verify that this works for them?

lisadaveh · Joined: 17 Oct 2003 Posts: 19

Two nops after the stop?
Why not two nidles after the idle?
Or the classic nop stop idle hop
Just put the nop stop on the idle top
and then the extender will have a fender bender.

(In case you can't tell this was my best impresion of Dr Seuess...
thank you, thank you very much) he he he

johnsfine · Posted: Wed Nov 05, 2003 6:48 am Post subject:

nsysblh · Joined: 02 Nov 2003 Posts: 20

There are 3 nops after stop and idle in the examples in the programming guide. however when it comes to explainig why, they don't.

I figured if it was good enough for 2.4. it was good enough for 3.1

anyway, some ucontrollers do advance to pc when going into hibernation. however they also clearly document this and tell you to pad the source code. in any case, since the instructon after the stop is a 3 byte instruction, advancing one or two bytes would definately cause the code to behave badly.

maybe idle is better because it doesn't shutdown the oscillator.

Why does the backlight flicker with extender3 active? Is that a feature?

BTW: I am using ext3 fine on a 8810w with the only change as stop / nop / nop

edit: looks like the rdf is patching 2 bytes ahead in the eeprom of the actual backlight timer patch spot. because of the 2 nops. the shift patch is still ok.

dtrump · Joined: 21 Sep 2003 Posts: 81 Location: Des Moines, IA

ti83programmer · Joined: 13 Oct 2003 Posts: 60

I just thought I would post a weird observation I just had with my URC-8810w. I was running the 3.1 extender (which I've always had no problems with), and then replaced the batteries because the current ones were pretty much dead and causing the extender to quit several times. I tried activating it and it went all screwy like people have been reporting here. I re-uploaded the extender and still had problems. The remote wouldn't even work until I unplugged the JP1 cable, and then it blinked twice (which I know happens to some people, but it NEVER did for me before this point), so I uploaded a clean slate dump to it, and then did a 9-8-1 reset, and then re-uploaded the extender and it's like it was before. I don't know exactly what caused any of this, but it's fixed now...maybe it'll help one of you.

johnsfine · Posted: Sun Nov 23, 2003 8:26 am Post subject:

My fault. I still haven't had time to replace the extender with one that adds the two NOPs.

Your results are consistent with all the other observations that the two NOPs are only needed when the battery voltage it toward the high end of legal battery voltages.

nsysblh · Joined: 02 Nov 2003 Posts: 20

Hmm. I'm using NiMH in mine and it fails w/o the 2 NOPs. Even if they are fully charged, they will still only be at 1.2x4 or 4.8V and alkalines would be at 1.5x4 or 6V. I'm wondering if it isn't a different rev of the chip or slightly different circuit in the remote.

eadries · Joined: 30 Dec 2003 Posts: 2

Hey my 8810w has this problem too, could you post a fixed extender w/ nop's?

tau166 · Joined: 08 Dec 2003 Posts: 19

[quote="eadries"]Hey my 8810w has this problem too, could you post a fixed extender w/ nop's?

I am also interested in an update/fix.

I had another slightly different error with Extender 3.1 on a URC-8811.

Sometimes when I upload my new program to the remote, the 4 digit device code for RCVR becomes corrupted (i.e. changed to another number). It's only for RCVR, nothing else.

I am using an upgraded device, but the same code works and uploads fine when put on any other device.

I don't have a second cable to check if that is the problem, but I assume if i have a bad cable the corruption wouldn't be this specific.

Any thoughts anyone?

Thanks.