In message <1Kqdncn027VuGnPQnZ2dnUVZ_s2dnZ2d@web-ster.com>, Tim Wescott
<tim@seemywebsite.com> writes

>So, is it too weird to blink the lights under software control at 50 or
>100Hz?  They'll appear to be steady to the naked eye, but if you wave
>the instrument in the air (it's hand-held) then a running processor
>will show you a train of dashes, while a dead one will show you a solid
>streak.

 Another trick would be to wave your hand, fingers spread in front of
the 100Hz LED. You will get a stroboscopic effect and the LED will seem
to blink slower.
-- 
 To reply, my gmail address is nojay1              Robert Sneddon

On 6/8/2011 11:03 AM, 1 Lucky Texan wrote:
> On Jun 8, 9:58 am, D Yuniskis<not.going.to...@seen.com>  wrote:

>> Yes, most digital cameras will (though I can't speak for all!).
>> But, an Ir LED doesn't tell the customer "power is on", etc.
>> In fact, it might result in more support calls:  "The power
>> indicator (that *must* be what this thing does, right?) on
>> my Wonkerator8000 doesn't light up!"
>
> Just label it 'warning light'.

Hmmm... you don't, by chance, work for MICROSOFT???  ;-)
(sure sounds like the way *they* would "solve" the problem.
And, then, file for PATENT PROTECTION on their innovative
new idea!  :-/ )

On Jun 8, 9:58=A0am, D Yuniskis <not.going.to...@seen.com> wrote:
> On 6/8/2011 7:17 AM, 1 Lucky Texan wrote:
>
> > On Jun 7, 5:25 pm, D Yuniskis<not.going.to...@seen.com> =A0wrote:
> >> If stuck with a monochromatic LED, you can duty cycle modulate
> >> to get a "signal" that someone knowing what to look for can
> >> easily detect -- yet, to others, is nonexistent. =A0E.g., at startup,
> >> run LED at 100% for 1.0 second (or some nice easily recognizable
> >> duration). =A0Then drop down to ~80% for your "normal" indication.
>
> >> The drawback of this approach is that it isn't static -- you need
> >> to see the processor coming out of reset in order to sense the
> >> change in intensity. =A0(you could also modulate the duty cycle
> >> with a very low duty cycle square wave so the lamp briefly
> >> brightens periodically)
>
> > A steady-state full intensity duplicate right next to the 80% one
> > would give you enough contrast.
>
> Yes, but that adds a component just to give you a "reference"
> (I think the point is to get as much information out of the
> least componentry)
>
> > I wonder if cellphone cameras could 'see' an infrared LED? The
> > customer would see nothing, but your phone could be used to
> > troubleshoot/confirm operation.
>
> Yes, most digital cameras will (though I can't speak for all!).
> But, an Ir LED doesn't tell the customer "power is on", etc.
> In fact, it might result in more support calls: =A0"The power
> indicator (that *must* be what this thing does, right?) on
> my Wonkerator8000 doesn't light up!"

Just label it 'warning light'.

Op 08-Jun-11 16:17, 1 Lucky Texan schreef:

> I wonder if cellphone cameras could 'see' an infrared LED? The
> customer would see nothing, but your phone could be used to
> troubleshoot/confirm operation.

All cellphones with camera I have had so far were able to see IR LED's. 
It is a great diagnostics tool to check IR remotes.

On 6/8/2011 7:17 AM, 1 Lucky Texan wrote:
> On Jun 7, 5:25 pm, D Yuniskis<not.going.to...@seen.com>  wrote:

>> If stuck with a monochromatic LED, you can duty cycle modulate
>> to get a "signal" that someone knowing what to look for can
>> easily detect -- yet, to others, is nonexistent.  E.g., at startup,
>> run LED at 100% for 1.0 second (or some nice easily recognizable
>> duration).  Then drop down to ~80% for your "normal" indication.
>>
>> The drawback of this approach is that it isn't static -- you need
>> to see the processor coming out of reset in order to sense the
>> change in intensity.  (you could also modulate the duty cycle
>> with a very low duty cycle square wave so the lamp briefly
>> brightens periodically)
>
> A steady-state full intensity duplicate right next to the 80% one
> would give you enough contrast.

Yes, but that adds a component just to give you a "reference"
(I think the point is to get as much information out of the
least componentry)

> I wonder if cellphone cameras could 'see' an infrared LED? The
> customer would see nothing, but your phone could be used to
> troubleshoot/confirm operation.

Yes, most digital cameras will (though I can't speak for all!).
But, an Ir LED doesn't tell the customer "power is on", etc.
In fact, it might result in more support calls:  "The power
indicator (that *must* be what this thing does, right?) on
my Wonkerator8000 doesn't light up!"

On Jun 7, 5:25=A0pm, D Yuniskis <not.going.to...@seen.com> wrote:
> Hi Tim,
>
> On 6/7/2011 1:20 PM, Tim Wescott wrote:
>
>
>
>
>
>
>
>
>
> > A long standing habit with me is to make sure that whenever possible,
> > any processor for which do the system design blinks at least one LED
> > under software control, and has at least one LED on at any given time.
> > This isn't just whim -- when you've got a headless system, and it's
> > sick, you can knock down the top two problems by looking at the lights:
> > "is there a light on?" -- yes, you've got power, no, you don't; "do you
> > have blinky?" -- yes, the processor is at least basically functional,
> > no, the processor (or software) is dorked.
>
> > Now I've got a customer who has a system and who wants the lights to
> > stay on steady. But I really like my little diagnostic (it's saved my
> > hind end numerous time with manufacturing and service personnel).
>
> > So, is it too weird to blink the lights under software control at 50 or
> > 100Hz? They'll appear to be steady to the naked eye, but if you wave th=
e
> > instrument in the air (it's hand-held) then a running processor will
> > show you a train of dashes, while a dead one will show you a solid stre=
ak.
>
> I like using bicolor LEDs for this purpose. =A0I arrange the hardware so
> that a "reset" processor leaves the red lamp illuminated. =A0Once the
> processor gets to "some point" in it's BIST, I have it toggle the
> LED to Green (substitute whatever colors you have available). =A0Once
> the system is running, I drive it with AC to yield Yellow.
>
> This tells me:
> - power is available (else it is a D.E.D.)
> - processor hasn't managed to get started doing *anything*
> - processor has achieved "minimal sufficiency" (whatever that
> =A0 =A0means... maybe "I appear to be working but my runtime is corrupt)
> - processor is actively running
>
> [note that I don't rely on this for the *user*. =A0To her/him, the
> light is on YELLOW or off -- the RED and GREEN states are transitory
> so he/she need not be able to comment on their actual color]
>
> I like to drive visible indicators syntonous with the local LFC.
>
> > I've got to blink the lights for certain error conditions anyway, so
> > it's not like I'm adding a bunch of work to do this.
>
> If stuck with a monochromatic LED, you can duty cycle modulate
> to get a "signal" that someone knowing what to look for can
> easily detect -- yet, to others, is nonexistent. =A0E.g., at startup,
> run LED at 100% for 1.0 second (or some nice easily recognizable
> duration). =A0Then drop down to ~80% for your "normal" indication.
>
> The drawback of this approach is that it isn't static -- you need
> to see the processor coming out of reset in order to sense the
> change in intensity. =A0(you could also modulate the duty cycle
> with a very low duty cycle square wave so the lamp briefly
> brightens periodically)

A steady-state full intensity duplicate right next to the 80% one
would give you enough contrast.

I wonder if cellphone cameras could 'see' an infrared LED? The
customer would see nothing, but your phone could be used to
troubleshoot/confirm operation.

Tim Wescott wrote:

> So, is it too weird to blink the lights under software control at 50 or
> 100Hz?  They'll appear to be steady to the naked eye, but if you wave
> the instrument in the air (it's hand-held) then a running processor will
> show you a train of dashes, while a dead one will show you a solid streak.

A simple "Its running' has saved me a lot of hours of debug time.

One blinking light use might be to broadcast current status messages.

w..

David Brown <david@westcontrol.removethisbit.com> writes:

> On 07/06/2011 22:20, Tim Wescott wrote:
>> A long standing habit with me is to make sure that whenever possible,
>> any processor for which do the system design blinks at least one LED
>> under software control, and has at least one LED on at any given time.
>> This isn't just whim -- when you've got a headless system, and it's
>> sick, you can knock down the top two problems by looking at the lights:
>> "is there a light on?" -- yes, you've got power, no, you don't; "do you
>> have blinky?" -- yes, the processor is at least basically functional,
>> no, the processor (or software) is dorked.
>>
>> Now I've got a customer who has a system and who wants the lights to
>> stay on steady. But I really like my little diagnostic (it's saved my
>> hind end numerous time with manufacturing and service personnel).
>>
>> So, is it too weird to blink the lights under software control at 50 or
>> 100Hz? They'll appear to be steady to the naked eye, but if you wave the
>> instrument in the air (it's hand-held) then a running processor will
>> show you a train of dashes, while a dead one will show you a solid streak.
>>
>> I've got to blink the lights for certain error conditions anyway, so
>> it's not like I'm adding a bunch of work to do this.
>>
>
> In my experience, the first thing you do with a new board is get a
> blinking LED to work.  (The second is to find a way to update the
> firmware safely in-system, so that the board can ship even though the
> software is not finished....)

Ha ha how true that is :) And it's often the hardest part of getting to
grips with a new chip. You have to delve into linker scripts, relocating
sections into RAM so you can run the bootloader there so you can
reprogram the flash... By the time the bootloader is written I usually
know the systen well enough that the rest is simple.

[...]


-- 

John Devereux

David Brown wrote:

> If the customer wonders why it is blinking, you can always tell him it
> is a power-saving technique.  Blinking an LED at 50% duty cycle at 100
> Hz will use half the power of a 100% duty cycle, but appear about 90% of
> the brightness.

In things I did, we called it a "heartbeat", and the customers were fine 
with that -- our particular customers were, anyway.

	Mel.

On 07/06/2011 22:20, Tim Wescott wrote:
> A long standing habit with me is to make sure that whenever possible,
> any processor for which do the system design blinks at least one LED
> under software control, and has at least one LED on at any given time.
> This isn't just whim -- when you've got a headless system, and it's
> sick, you can knock down the top two problems by looking at the lights:
> "is there a light on?" -- yes, you've got power, no, you don't; "do you
> have blinky?" -- yes, the processor is at least basically functional,
> no, the processor (or software) is dorked.
>
> Now I've got a customer who has a system and who wants the lights to
> stay on steady. But I really like my little diagnostic (it's saved my
> hind end numerous time with manufacturing and service personnel).
>
> So, is it too weird to blink the lights under software control at 50 or
> 100Hz? They'll appear to be steady to the naked eye, but if you wave the
> instrument in the air (it's hand-held) then a running processor will
> show you a train of dashes, while a dead one will show you a solid streak.
>
> I've got to blink the lights for certain error conditions anyway, so
> it's not like I'm adding a bunch of work to do this.
>

In my experience, the first thing you do with a new board is get a 
blinking LED to work.  (The second is to find a way to update the 
firmware safely in-system, so that the board can ship even though the 
software is not finished....)


I would say a 100 Hz blink would be fine, and appear steady in normal 
use.  50 Hz is too slow - if you see it from the corner of your eye, it 
would appear unstable.

If the customer wonders why it is blinking, you can always tell him it 
is a power-saving technique.  Blinking an LED at 50% duty cycle at 100 
Hz will use half the power of a 100% duty cycle, but appear about 90% of 
the brightness.