LED used to Blink, now it doesn't

From my build at http://whiskeytangohotel.com/ourcatdoor I have noticed a very minor (for my application) problem.

I have a LED that is ON all the time to show that the Imp is powered up and running. The code ‘blinks’ OFF the LED briefly on mechanical switch event. However, the LED is now staying on all the time. The Imp still reads the switch activity and code branches on the switch read as expected.

What could cause the LED not to ‘blink’ off? Obviously, the LED is good (it is ON to show the Imp is running). The switch and code to read the switch is solid (the rig ‘tweets’ as expected). Maybe the Imp output on the GPIO for the LED is ‘bad’?

Just curious for some educated opinions.


Can you post an electrical schematic of how things are wired.

See attached…

If the LED is on, it means pin 9 is low. Either by code writing a zero to it, or because it’s short-circuited to ground. I see that you’re use a 330 ohm resistor as a current limiter, which will result in a current of (3.3 - 1.6) V / 330 ohm (assuming a standard red LED), which is just over 5mA. Slightly over the limit of 4mA, so I doubt this has blown up your output port.
You might even be using a green led, in that case the voltage drop is higher (2.2 V), so the current will be lower, and within safe limits. Are you sure there is no short-circuit to ground in your connections? Try ejecting the imp. Is the LED still on? If yes, you have a short-circuit.

Looking at your code, a couple of suggestions:

  1. Don’t use DIGITAL_OUT_OD_PULLUP. Though technically it should work, there’s zero reason you shouldn’t be using DIGITAL_OUT for pin 9.

  2. To blink the LED, it’s nice to avoid imp.sleep. Try this:

hardware.pin9.write(1); // LED off
imp.wakeup(0.5, function() { hardware.pin9.write(0); } ); // turn LED on again after 500ms

  1. You’re writing pin 9 before configuring it. It should sort itself out after the first event, but really you should configure then write.

Thanks. I tried the ‘marcboon’ suggestion and unplugged/replugged the Imp. Same issue. FWIW, the LED is Blue. I agree that with the 330R it should not be an issue for the Imp GPIO or the LED. As far as a short… i checked it and all is good, but really there is not much to short (or check). The HW is pretty simple and everything is soldered, etc. None the less, I inspected with an DMM and all checks out fine.

As I type this I see a note from Hugo… Stay tuned. Thanks again.

Okay, I’m back…

Hugo, good suggestion on not needing ‘OD’. I probably just did a cut/paste of some code in the beginning. I did change it as you suggested. I did not think it would correct the problem of the LED not turning off and it didn’t.

I implemented your suggestion of not using imp.sleep. Basically, I cut/pasted

imp.wakeup(0.5, function() { hardware.pin9.write(0); } );

as a way to blink off the LED. But… the LED stays on. Hmmm…

That seems to point to a wiring problem or a Imp GPIO problem. I checked the wiring and if it is a Imp GPIO issue I would not replace the Imp anyway because it is working flawlessly in the application.

So… unless there are any other suggestions on code change I will say “thanks, this forum is always wonderfully helpful!!!” and close the thread.

Thanks again.

One more question: when the imp is booting, but the imp’s LED hasn’t gone green yet, is the LED on?

All I can think of is that actually, the LED isn’t in fact connected where you think it is :slight_smile:

Not connected to what I think it is!!! That, sir, is an insult. :slight_smile:

I’m on the road now, but will check out the green light suggestion when I return.


OK… I 'm back again with the new info.

Recap: Blue LED used to blink off at switch detection. Problem stated was it now stays on all the time.

Update: The LED stays off without the Imp socketed (it should).
The LED stays off until the Imp green light comes on (as expected)

Actually, the problem is not as I originally described so sorry to waste brain BTUs. What happens is the LED does blink at switch detection, but it is delayed by many many seconds. Sometime as many as 20 seconds are so. It used to blink immediately. This misled me as I was not patient enough to wait for the blink because I never had to.

Bottom line, Imp is solid. I do wonder why such a long delay. Me thinks another look at my code and this will become clear.

As always. many thanks to the forum for the support. Top notch!

The delay, seeing as it would appear to be executed totally locally, should not be delayed at all… but we’d really need to see your code to determine what might cause the delay.

Hugo, makes sense (I guess) but there is certainly a delay. A long one. The relavant part of the code is below. Thanks.

// function swEvent handles looking for action on the door switch
function swEvent() {
local d = date(); // Date info not sent to twitter. Used only for planner debug
local min = d[“min”];
local hour = d[“hour”];
local sec = d[“sec”];
local state = hardware.pin7.read();

    if (state == 1) {   
    // Blink the LED Off to show a door swing detected
    hardware.pin9.write(1);  // LED OFF
    //imp.sleep(0.5)          // 500mS delay  ((this line and next line)
    //hardware.pin9.write(0);  //  LED back ON ((replaced with line below.  Suggestion from Hugo May 5, 2013)
    imp.wakeup(0.5, function() { hardware.pin9.write(0); } ); // turn LED on again after 500ms (Hugo's line)
    server.show("r="+r+" @ "+hour+":"+min+":"+sec);  //echo to the Imp Planner Blue BOX the generated RANDOM# and time.  Used for debug.
    server.log("r="+r);  //echo to the debug planner window the generated RANDOM# and time.  Used for debug.
    }   // end if state ==0 (or state ==1 depending on NO or NC switch type)
    imp.sleep(10.0);  // switch settle time of x.x seconds (long due you door swing back and forth)       
    server.log(state);  //  echo switch state (O or 1) to planner window for debug pane

} // End function swEvent

// Configure pin 9 as an open drain output with internal pull up
// Configure pin 7 as switch
//hardware.pin9.configure(DIGITAL_OUT_OD_PULLUP); //((replaced with line below. Suggestion from Hugo May5, 2013)
hardware.pin9.configure(DIGITAL_OUT); // (Hugo’s line)
hardware.pin7.configure(DIGITAL_IN_PULLUP, swEvent);

Callbacks set by imp.wakeup() do not run while other Squirrel is also executing. So in your case, the pin9.write(0) that’s meant to happen 0.5s later, only happens after the function swEvent() exits – in other words, after the imp.sleep(10) has happened.



Thanks. I think I understand (barely).

Should I move the
imp.sleep(10.0) line to right after the
imp.wakeup command?

Trivial question, I know, but thanks.

Ideally you shouldn’t be sleeping at all, but rather ignoring additional events that are generated in the 10 seconds after a valid one.

There’s some code I posted for debouncing recently, take a look at that?