8811 Backlight Malfunction with Extender-V3.2 an new 8811

nevolc · Post by **nevolc** » Sun May 01, 2005 4:51 pm

I tried the mods Hal suggested. The BackLight still occasionally repeats but never more than 2 or 3 cycles (use to get 2-6 cycles of my ~5 second timer with 6 being more common). I think most people could live with this BackLight behavior since you no longer have 30 second sequences of backlighting romping the batteries.

It still appears keys in rapid succession are causing at least 90% of the repeats. I would estimate the repeats are happening less than 20% of the time but this probably correlates to your programming. In my case, I use a lot of macros - some of which repeat the same key.

I've only done limited testing but I couldn't tell any difference with 2 NOPs versus 3 NOPs. Before, 3 NOPs were required to prevent the Extender from locking up right away and this is no longer a problem.

I have experienced a lockup or two - this could be something I caused. I also had two "sit over-night" lockups after I tried just the "DI" mod at L50. I'll continue to test tonight. Again, this is the best fix yet with the possible exception of a lockup.

In case I made a dumb error making the code delta changes, here is my L5-L50 (sorry for formatting):

Code: Select all

L05:	TM	R_Flags, 1      ;Light enabled
	JREQ	L18             ;No
	CALL	LightOn         ;Yes: Turn it on

L10:	CALL	WaitNoKeys	;Wait for no keys pressed
	DI
	LD	RF1, WC		;Enable button sense interrupts
	CLR	RF2		;Clear pending interrupts (buttons)
	CALL	LedOff		;11; Turn LED off

L18:	CALL	SelectTimeout	;Select timeout value
	JRNC	L40		;No Timeout needed
L20:	LD	R4A, 4C		;Set timeout
timeout_patch = $$-1
	CLR	R_IFlags	;Interrupt flags
	CALL	StartT0		;Start timer0
L30:	IDLE
	RL	R_IFlags	;Test interrupt flags
	JREQ	L30		;No interrupt flags set
	JRC	L50		;Keyboard interrupt flag set
	CALL	HandleTimeOut	;Turn off backlight and Clear shift flag
	JR	L10

L40:	EI
	LD	RFB, A5		;Enable stop
	STOP
	NOP
	NOP

L50:	DI
	CALL	LightOff
	CALL	DebounceKeys	;Keypad scan
	DEC	R_Closures	;Exactly one key pressed?
	JRNE	L05		;No
.
.

As before, I'll be glad to test any code suggestions.

Thanks for your help.

mtakahar · Post by **mtakahar** » Sun May 01, 2005 7:16 pm

nevolc wrote:It still appears keys in rapid succession are causing at least 90% of the repeats. I would estimate the repeats are happening less than 20% of the time but this probably correlates to your programming.

I think it's because the extender turns off the light before checking whether it's a valid key press. Let's move the LightOff a few lines below.

Code: Select all

L50:    DI
        CALL    DebounceKeys    ;Keypad scan
        DEC     R_Closures      ;Exactly one key pressed?
        JRNE    L05             ;No

        CALL    LightOff
        LD      R_Mac, AR_MacLim-1;Init macro pointer

Hal

nevolc · Post by **nevolc** » Sun May 01, 2005 11:12 pm

I tried the revised L50 code. It didn't change the remotes behavior. Some keys still repeat the Backlight cycle 2 or 3 times. I haven't seen it go past 3 cycles a single time.

I haven't experienced any lockups this evening. I'll see if the 8811 makes it overnight without a lockup.

mtakahar · Post by **mtakahar** » Mon May 02, 2005 12:21 am

Sorry, I found another stupid mistake. The line immediately after "L05:" had to jump to L10. Perhaps this doesn't fix the backlight problem, though, because this change only affects the cases where the backlight is disabled.

Code: Select all

L05:    TM      R_Flags, 1      ;Light enabled
        JREQ    L10             ;No
        CALL    LightOn         ;Yes: Turn it on

L10:    CALL    WaitNoKeys      ;Wait for no keys pressed

Can you tell me in which of the following cases you are still seeing the problem?

When you press the backlight button to enable the backlight.
When pressing a button (other than the backlight) while the backlight is lit.
When pressing a button (other than the backlight) while the backlight is enabled but off (i.e. the backlight went off because of the timeout, and you are waking it up.)

Also, would it be possible that the problem coinsides with a button press that happened right at the moment the backlight was about to go off? I know this sounds difficult to tell, but you can try it with the timer set to a longer period.

Hal

nevolc · Post by **nevolc** » Mon May 02, 2005 4:32 pm

I made the L05 code change - as you predicted, no change in backlight behavior. Here are responses to scenario questions:

A) press the backlight key to enable it - the light comes on for one cycle. I don't believe I have ever seen the backlight repeat a cycle by being turned on.
B) press button while backlight is on - the backlight goes out briefly while I press another key and appears to reset the timer based on the last keypress so that you get at least one full cycle of backlight after you stop pressing keys. I sometimes see the backlight "repeat" two or three cycles of light after the last keypress. There is a brief (milliseconds) backlight turnoff between the repeating cycles when they occur which makes it easy to count how many times it repeated.
C) press button while backlight is off but enabled - backlight comes on after button released. Like case "B" above, I sometimes see the backlight "repeat" two or three cycles of light after the last keypress.

I decided to try pressing each key once and observe how often the backlight "repeats" (yes, I should have tried this sooner). The answer for 98% of the keys that are not macros or LDKP is never. I have only found one "plain" key of a particular protocol that will cause two backlight cycles and it does so consistently. So the backlight repeat problem (when it occurs) seems to be an additional "keypress" when the backlight was already on. In the case of a macro, I assume the keystrokes sent after the initial command emulate this behavior.

The code changes so far have definitely reduced the number of occurrences of backlight "repeats" and the actual number of repeats (2 or 3 now). With Extender V3.2 (three NOPs), I commonly saw 6 repeats. Also, it appears two versus three NOPs is not significant now. With Extender V3.1 (two NOPs), the Extender would lock up almost immediately on my 8811s that misbehave.

mtakahar · Post by **mtakahar** » Tue May 03, 2005 12:54 am

nevolc wrote:B) press button while backlight is on - ... I sometimes see the backlight "repeat" two or three cycles of light after the last keypress. There is a brief (milliseconds) backlight turnoff between the repeating cycles when they occur which makes it easy to count how many times it repeated.
C) press button while backlight is off but enabled - backlight comes on after button released. Like case "B" above, I sometimes see the backlight "repeat" two or three cycles of light after the last keypress.

With the changes made by now, the only case that would blink the backlight is the LightOn near the L05 turning it on and HandleTimeOut turning it off. We should be able to rule out a possibility of reaching to the LightOff after "DEC R_Closures; JRNE L05" because WaittNoKeys should clear up all the pending key interrupts. The timer0 is also unlikely to be the cause as we are clearing R_IFlags. There's a possibility of the "RL R_IFlags" hack not working, but I don't see how at the moment.

I have only found one "plain" key of a particular protocol that will cause two backlight cycles and it does so consistently.

Would you care to tell us which one?

This makes me think something in that specific protocol executor is triggering a h/w interrupt.

So the backlight repeat problem (when it occurs) seems to be an additional "keypress" when the backlight was already on. In the case of a macro, I assume the keystrokes sent after the initial command emulate this behavior.

Actually, no. All macro key strokes are executed in a single cycle, and it won't come back to the point accepting another button press until the extender finishes execution everything, and the light is off all the time until it comes back. I wonder if the macros that triggers the problem includes a command that calls that specific protocol you mentioned above. LKP uses the same timer0, and it could disturb the backlight, but normally it doesn't because the timer0 gets reset once comes back to the main loop.

Here's one more thing you can try:
Change the destination label after "DEC R_Closures" from L05 to L10 (stop turning on the light if it's a bad press. Actually, it gets here when any h/w interrupt wakes up the processor.)

Code: Select all

L10:    CALL    WaitNoKeys      ;Wait for no keys pressed
        DI
...
L50:    DI
        CALL    DebounceKeys    ;Keypad scan
        DEC     R_Closures      ;Exactly one key pressed?
        JRNE    L10             ;No

I don't have much ideas left unless the protocol you mentioned is doing something very interesting.

Hal

jherrick · Post by **jherrick** » Tue May 03, 2005 7:54 am

Cliff,
While following this thread, one thing that I didn't see mentioned was the results of your testing the remotes without the extender. Have you tried them without the extender to see if they exhibit the same behavior? I ask because, in working with things like this it is always best to eliminate the easy things first, as obvious or ridiculous as they may sound.
Jim

Nils_Ekberg · Post by **Nils_Ekberg** » Tue May 03, 2005 8:09 am

I see where Hal is going with this but I am just curious to hear if you get the same results with a longer backlight on timer. I guess I never set things as low as 5 seconds so I was curious if the same thing occurs at say 10 seconds or more. Probably does not mean anything just curious.

mtakahar · Post by **mtakahar** » Tue May 03, 2005 10:10 am

Nils_Ekberg wrote:I see where Hal is going with this but...

You are talking about this part?

mtakahar wrote:I don't have much ideas left ...

nevolc · Post by **nevolc** » Tue May 03, 2005 6:08 pm

THE LAST L50 SUGGESTION FIXED IT!

The backlight works correct at 5.2V, it works correct at 6.4V. This is with two NOPs. I've been testing about an hour with normal backlight behavior. I checked both "bad" 8811s as well as a "good" one. Also tested on my green backlit 8810w.

The key/protocol that repeated the backlight in the previous simple test mode was HouseCode-O from Rob's "X10 Hacked" protocol and the backlight works correct with it now.

Nils, I normally run a 10 second timer - for shift/xshifting as much as backlighting. I dropped to 5 seconds to speed up testing.

Jim, I did do minimal testing without an extender on a "bad" 8811 and it worked OK. This was with 6.4V batteries and why the low voltage "fix" bugged me.

Hal - I really appreciate your time, skill, and effort. Likewise for the other contributors. I'll be running this code on 8811s for many years to come.

mtakahar · Post by **mtakahar** » Wed May 04, 2005 10:11 am

I've uploaded new version in the files section.
6012ex3_3.zip

Now it has LDKP and Device Multiplexer preloaded.

Hal

chakrax · Post by **chakrax** » Thu Aug 04, 2005 7:38 pm

All,

I'm trying to use this extender in a new 8811, and I have backlight issues.

If I turn OFF backlighting before I activate the extender, the remote works, but no backlight. By turning off backlighting, I mean pressing the backlight button so that any further button presses do not cause backlight to come on.

If I leave backlighting ON and active the extender, the backlight just stays on, and does not go off.

Could this happen if I made a mistake with the RDF file? Do I use the latest one that came with IR 6.xx or the one in this zip file?

Thanks for your help.

mtakahar · Post by **mtakahar** » Sat Aug 06, 2005 1:02 am

The RDF included in the latest RDF package is for v3.3. Just install v3.3 if you are not sure what you are using.

Nils or someone else who can: I think it's less confusing if we don't keep the old revisions of the same variants around. Could you delete old ones if you agree?

Thanks,
Hal

Nils_Ekberg · Post by **Nils_Ekberg** » Sat Aug 06, 2005 6:14 am

I am not sure what you mean Hal.

Are you referring to old versions of the RDF's in the distribution zip or the RDF in the extender zip or old versions of the extenders?

Was this problem caused by using an old extender RDF with the newer extender?

mtakahar · Post by **mtakahar** » Sat Aug 06, 2005 9:11 am

I meant old buggy extenders.

Code: Select all

6012ex3_1.zip 
6012ex3_2 
6012ex3_3.zip

All three of those have the same signature but different backlight timer, shift/xshift addresses. The extender will either crash or cause all sorts of problems if you change any of these settings using a wrong RDF.

_x revisions are simply bug fixes and it's just confusing keeping buggy ones around even if there's no RDF issue. I usually overwrite it but I couldn't because I didn't upload _1 and _2.

Hal