Truncated match.
PICList
Thread
'Multiplexing Seven Segment Displays'
1997\09\15@180044
by
Shane Nelson
Hi guys,
I'm in need of some advice regarding multiplexing seven seg
displays. I have 4 displays on 12 i/o pins, and have two
concerns:
1) Visibility.
What is the optimum "on time" vs "off time" for best
visibility, while at the same time having enough remaning cpu
time to be able to handle various other tasks?
2) Current consumption.
How do I determine how much current the leds are going to
need, and how can I keep these values w/in the current specs of
the pic? All the microchip literature seems to suggest that you
can drive leds directly. I've been doing it that way but have a
feeling I've been exceeding current specs on the i/o ports.
Thanks for any help! :)
-Shane.
1997\09\15@185216
by
Martin R. Green
|
Ok, there's a couple of fairly simple calculations that will tell you what
you need to know, but Microchip is being a _wee_ bit optimistic.
For maximum brightness, to minimize I/O load on the PIC, and to get the
best efficiency from the driver transistors (discreet or in the PIC), you
should use the longest character on time you can. All LED's should be
sequenced in less than 1/30 second to avoid flicker (a few rare people can
detect flicker at this high rate so you might want to use 1/40th or 1/50th
sec. instead). Now divide that value by the number of LED's and you have
your scan time per character. For instance, if you have eight 7 segment
LED's, and you want a full scan in 1/30th of a second, each character
should get 1/240th of a second. At this speed, given a reasonably normal
clock speed, you will have oodles of time to process other stuff between
display servicing calls.
Note that because you have to write the character PIC port separately from
the segment port, you may get some segment "bleed" due to the short time
that the segment outputs from the PIC are for a different character than
the character output from the PIC. The simple solution for this is to
write a 0 (or FF, depending on CA or CC LED's) to the segment port to blank
the display just before you write to the character port. Then write the
character port, followed by the new value for the segment port. Voila, no
more bleed. This applies to other multiplexed display types too, such as
VFD's.
As for current, there are two parts to this, one for LED current, and one
for PIC drive current.
In general, to get a multiplexed LED to display the same brightness as a
direct driven LED you should overdrive each segment by the duty cycle of
the scan. That is, in our 8 LED example, if the LED display the brightness
you need at 20mA per segment when driven directly, then you need to drive
it at 160mA per segment to get the same brightness when multiplexing, since
each LED is only on for 1/8th of the time. In my experience, LED's seem to
be able to take this low duty cycle overdrive with no problems, but if you
are squeamish about it, you can edge the calculated current down a bit, but
be aware you may not get the brightness you need.
The other side to the current equation is the PIC drive capabilities, and
this is where there are a couple of gotchas. Each PIC port pin can source
20mA and sink 25mA, so you can see from this that using our calculated
drive current of 160mA per segment is going to be optimistic at best. I
have no idea whether the maximum values specified by Microchip are affected
by the duty cycle, probably a bit, but even at low duty cycles, sinking
160mA into a PIC port may be pushing it. This of course doesn't even
account for the character driver port, which must be able to handle the
segment current times the # of segments. In our 7 segment example above,
each character could draw up to 1120 mA, albeit at the 1 in 8 duty cycle.
So you can see why Microchip specify a maximum of 7mA per segment in the
direct drive multiplex example application notes. You have to use some
pretty small and efficient LED displays to get adequate brightness at 7 mA
per segment, especially at low duty cycles.
The other big gotcha, that is not obvious in the PIC specs is that although
each port pin can source 25mA, the total for _all_ pins is 50mA, which
really limits the real world drive capability of a PIC, IMHO. That 7mA per
segment restriction in the app notes takes this into account (7mA time 7
segments = 49mA).
So you can see why, IMNSHO, despite Microchip's examples, it is not really
practical to drive a multiplexed LED display directly from a PIC, at least
not the character drive anyway. You can probably get away with driving the
segments directly, and driving the characters via transistor or other
buffers, but this will require fairly efficient or small LED's.
HTH - Martin R. Green
spam_OUTelimarTakeThisOuT
bigfoot.com
----------
From: Shane Nelson[SMTP:.....iKILLspam@spam@CHEETAH.SPOTS.AB.CA]
Sent: Monday, September 15, 1997 6:03 PM
To: PICLISTKILLspammitvma.mit.edu
Subject: Multiplexing Seven Segment Displays
Hi guys,
I'm in need of some advice regarding multiplexing seven seg
displays. I have 4 displays on 12 i/o pins, and have two
concerns:
1) Visibility.
What is the optimum "on time" vs "off time" for best
visibility, while at the same time having enough remaning cpu
time to be able to handle various other tasks?
2) Current consumption.
How do I determine how much current the leds are going to
need, and how can I keep these values w/in the current specs of
the pic? All the microchip literature seems to suggest that you
can drive leds directly. I've been doing it that way but have a
feeling I've been exceeding current specs on the i/o ports.
Thanks for any help! :)
-Shane.
1997\09\15@192726
by
TONY NIXON 54964
I have multiplexed 4 x 7 segment displays.
I used 220R resistors in series with the segments and these are
driven directly from the port pins. Each display common was controlled by a
BC547 transistor with a 4K7 base resistor. (Common cathode displays).
The IRQ which updated the displays was set to 5mS. So each display is
on for 5mS and off for 15mS. 25% duty cycle. The display brightness
is good even under fluro lighting. The chip is running at 10MHz.
In the IRQ, all displays are turned off for 5 NOP's, then change
digit data, another 5 NOP's, then the next display in the sequence is turned on.
This works fine for my application.
Regards
Tony
Just when I thought I knew it all,
I learned that I didn't.
1997\09\15@215427
by
bfehrenb
On 15 Sep 97 at 18:44, Martin R. Green wrote:
> In general, to get a multiplexed LED to display the same brightness as a
> direct driven LED you should overdrive each segment by the duty cycle of
> the scan. That is, in our 8 LED example, if the LED display the brightness
> you need at 20mA per segment when driven directly, then you need to drive
> it at 160mA per segment to get the same brightness when multiplexing, since
> each LED is only on for 1/8th of the time.
I don't believe this is true. The human eye seems to respond more to
the PEAK of the intnesity. Thus only a marginal decrease in
brightness is observed when the displays are mux'd at 20 ma in your
example.
--
Bob Fehrenbach Wauwatosa, WI .....bfehrenbKILLspam.....execpc.com
1997\09\15@222118
by
Pedro Drummond
Martin R. Green wrote:
>
>> In general, to get a multiplexed LED to display the same brightness as a
>> direct driven LED you should overdrive each segment by the duty cycle of
>> the scan.
Bob Fehrenbach wrote:
>I don't believe this is true. The human eye seems to respond more to
>the PEAK of the intnesity. Thus only a marginal decrease in
>brightness is observed when the displays are mux'd at 20 ma in your
>example.
I have tried this peak response test since I saw it being mentioned in The
Art of Electronics. There, it is said that it is better to have 160 mA
multiplexed than 20 mA continuous, because of our eyes' peak response (we
would see it brighter, being multiplexed); well, it definitely does not
happen to me.
Also, I see a major difference between mux'd 20 mA and continuous 20 mA. I
tested this with red LEDs, LCDs backlights, everything. Maybe it's me.
1997\09\16@005624
by
mikesmith_oz.nosp*m
|
On 15 Sep 97 at 18:44, Martin R. Green wrote:
{Quote hidden}> Ok, there's a couple of fairly simple calculations that will tell
> you what you need to know, but Microchip is being a _wee_ bit
> optimistic.
>
> For maximum brightness, to minimize I/O load on the PIC, and to get
> the best efficiency from the driver transistors (discreet or in the
> PIC), you should use the longest character on time you can. All
> LED's should be sequenced in less than 1/30 second to avoid flicker
> (a few rare people can detect flicker at this high rate so you might
> want to use 1/40th or 1/50th sec. instead). Now divide that value
> by the number of LED's and you have your scan time per character.
> For instance, if you have eight 7 segment LED's, and you want a full
> scan in 1/30th of a second, each character should get 1/240th of a
> second. At this speed, given a reasonably normal clock speed, you
> will have oodles of time to process other stuff between display
> servicing calls.
>
> Note that because you have to write the character PIC port
> separately from the segment port, you may get some segment "bleed"
> due to the short time that the segment outputs from the PIC are for
> a different character than the character output from the PIC. The
> simple solution for this is to write a 0 (or FF, depending on CA or
> CC LED's) to the segment port to blank the display just before you
> write to the character port. Then write the character port,
> followed by the new value for the segment port. Voila, no more
> bleed. This applies to other multiplexed display types too, such as
> VFD's.
>
> As for current, there are two parts to this, one for LED current,
> and one for PIC drive current.
>
> In general, to get a multiplexed LED to display the same brightness
> as a direct driven LED you should overdrive each segment by the duty
> cycle of the scan. That is, in our 8 LED example, if the LED
> display the brightness you need at 20mA per segment when driven
> directly, then you need to drive it at 160mA per segment to get the
> same brightness when multiplexing, since each LED is only on for
> 1/8th of the time. In my experience, LED's seem to be able to take
> this low duty cycle overdrive with no problems, but if you are
> squeamish about it, you can edge the calculated current down a bit,
> but be aware you may not get the brightness you need.
>
> The other side to the current equation is the PIC drive
> capabilities, and this is where there are a couple of gotchas. Each
> PIC port pin can source 20mA and sink 25mA, so you can see from this
> that using our calculated drive current of 160mA per segment is
> going to be optimistic at best. I have no idea whether the maximum
> values specified by Microchip are affected by the duty cycle,
> probably a bit, but even at low duty cycles, sinking 160mA into a
> PIC port may be pushing it. This of course doesn't even account for
> the character driver port, which must be able to handle the segment
> current times the # of segments. In our 7 segment example above,
> each character could draw up to 1120 mA, albeit at the 1 in 8 duty
> cycle.
>
> So you can see why Microchip specify a maximum of 7mA per segment in
> the direct drive multiplex example application notes. You have to
> use some pretty small and efficient LED displays to get adequate
> brightness at 7 mA per segment, especially at low duty cycles.
>
> The other big gotcha, that is not obvious in the PIC specs is that
> although each port pin can source 25mA, the total for _all_ pins is
> 50mA, which really limits the real world drive capability of a PIC,
> IMHO. That 7mA per segment restriction in the app notes takes this
> into account (7mA time 7 segments = 49mA).
>
> So you can see why, IMNSHO, despite Microchip's examples, it is not
> really practical to drive a multiplexed LED display directly from a
> PIC, at least not the character drive anyway. You can probably get
> away with driving the segments directly, and driving the characters
> via transistor or other buffers, but this will require fairly
> efficient or small LED's.
Good coverage of led muxing. What do you think of the idea of muxing
even *faster*, and driving only *one* segment at any one time, at the
absolute max currents? That wouldn't violate the pin or package
limits, but would increase s/w complexity.
MikeS
<mikesmith_oz@nosp*m.relaymail.net>
(remove the you know what before replying)
1997\09\16@010224
by
Shane Nelson
On Tue, 16 Sep 1997, Mike Smith wrote:
>
> Good coverage of led muxing. What do you think of the idea of muxing
> even *faster*, and driving only *one* segment at any one time, at the
> absolute max currents? That wouldn't violate the pin or package
> limits, but would increase s/w complexity.
> MikeS
> <mikesmith_oz@nosp*m.relaymail.net>
> (remove the you know what before replying)
>
That crossed my mind too. Another possible asset would be the
exact same amount of current going through each segment. I've
found that when you light an entire digit (for the number 8) it
isn't as bright as when you light only a few segments (like the
number 1). Has anyone done this? Any comments?
1997\09\16@022546
by
Pasi T Mustalahti
|
On Mon, 15 Sep 1997, Shane Nelson wrote:
{Quote hidden}> Hi guys,
>
> I'm in need of some advice regarding multiplexing seven seg
> displays. I have 4 displays on 12 i/o pins, and have two
> concerns:
>
> 1) Visibility.
> What is the optimum "on time" vs "off time" for best
> visibility, while at the same time having enough remaning cpu
> time to be able to handle various other tasks?
>
> 2) Current consumption.
> How do I determine how much current the leds are going to
> need, and how can I keep these values w/in the current specs of
> the pic? All the microchip literature seems to suggest that you
> can drive leds directly. I've been doing it that way but have a
> feeling I've been exceeding current specs on the i/o ports.
>
>
> Thanks for any help! :)
>
> -Shane.
>
PTM: I Have a proto on my table with PIC16C84 and 3 additional
chips (74HCxx and 4xxx). It has 5 x 7-segm LED, 25 keys, one beep, 2
digital inp and 10 digital outp. The board is eating 25 mA with the
LED's ON and 1 mA OFF. I use 10 mA per a LED segment. It the prosessor
stops the LED's don't destroy themselves. If You are absolute sure your
program is going to run flawless ad infinitum you can use even 1 A at
90% dead time.
The LED's are driven with 4511 decoder/latch/buffer so that there is a 1:5
mux in them with no dead time.
Using HighBright LED's you could have even more numbers. My friend made a
timer without external latch. With 1:4 mux and about 10% dead time
visibility is fine.
Negative point in this kind of drive is that you can't have ABC.. on the
LED's, only 123... Even a HEX-driver (0..9A..F) would be nice, but for
some odd reason these ABCDEF have been left out of all the cheap
LED-drivers.
(No, I'm not giving the schema out before Xmas :)
--------------------------------------------------------------------------
PTM, EraseMEpasi.mustalahtispam_OUTTakeThisOuTutu.fi, ptmustaspam_OUTutu.fi, http://www.utu.fi/~ptmusta
Lab.ins. (mikrotuki) ATK-keskus/Mat.Luon.Tdk OH1HEK
Lab.engineer (PC support) Computer Center OI7234
Mail: Turun Yliopisto / Fysla, Vesilinnantie 5, 20014
Pt 02-3336669, FAX 02-3335632 (Pk 02-2387010, NMT 049-555577)
--------------------------------------------------------------------------
1997\09\16@025256
by
tjaart
|
{Quote hidden}> On Mon, 15 Sep 1997, Shane Nelson wrote:
>
> > Hi guys,
> >
> > I'm in need of some advice regarding multiplexing seven seg
> > displays. I have 4 displays on 12 i/o pins, and have two
> > concerns:
> >
> > 1) Visibility.
> > What is the optimum "on time" vs "off time" for best
> > visibility, while at the same time having enough remaning cpu
> > time to be able to handle various other tasks?
> >
> > 2) Current consumption.
> > How do I determine how much current the leds are going to
> > need, and how can I keep these values w/in the current specs of
> > the pic? All the microchip literature seems to suggest that you
> > can drive leds directly. I've been doing it that way but have a
> > feeling I've been exceeding current specs on the i/o ports.
> >
> >
> > Thanks for any help! :)
> >
> > -Shane.
If you use an emittor follower on the PIC pin (that drive the LEDS), you
can charge a cap through a diode. The LED draws its current from the cap
via a current limiting resistor. This will introduce some latency, but
your
LED's will be switched on 100% and won't POP if your program freezes.
I don't particularly feel like ASCII art, but if you want me to, I will
attempt to draw it...
--
Friendly Regards
Tjaart van der Walt
@spam@tjaartKILLspamwasp.co.za
________________________________________________________
| WASP International http://wasp.co.za |
| R&D Engineer : GSM peripheral services development |
|Vehicle tracking | Telemetry systems | GSM data transfer|
|Voice : +27-(0)11-622-8686 | Fax : +27-(0)11-622-8973 |
| WGS-84 : 26010.52'S 28006.19'E |
|________________________________________________________|
1997\09\16@030914
by
Lauw Lim Un Tung
On Mon, 15 Sep 1997, Shane Nelson wrote:
> >
> That crossed my mind too. Another possible asset would be the
> exact same amount of current going through each segment. I've
> found that when you light an entire digit (for the number 8) it
> isn't as bright as when you light only a few segments (like the
> number 1). Has anyone done this? Any comments?
>
may be transistor switch at the common pin too small, so large amount
current cannot flow throught it (clipped).
1997\09\16@041738
by
mikesmith_oz.nosp*m
On 16 Sep 97 at 9:24, Pasi T Mustalahti wrote:
<snip>
> (No, I'm not giving the schema out before Xmas :)
Why Xmas?
MikeS
<mikesmith_oz@nosp*m.relaymail.net>
(remove the you know what before replying)
1997\09\16@041747
by
mikesmith_oz.nosp*m
On 16 Sep 97 at 8:53, Tjaart van der Walt wrote:
<snip>
> If you use an emittor follower on the PIC pin (that drive the LEDS),
> you can charge a cap through a diode. The LED draws its current from
> the cap via a current limiting resistor. This will introduce some
> latency, but your LED's will be switched on 100% and won't POP if
> your program freezes.
Thats cute! You've introduced 'phosphor persistence' to an LED!
Although - I suspect Shane was going for a zero or minimal external
parts count.
If you wanted a 'debugging circuit' until your s/w was 100% (hah!)
you could use series caps / resistors and a few diodes to stop
overshoot.
>
> I don't particularly feel like ASCII art, but if you want me to, I
> will attempt to draw it...
>
Yuk! What's a civilised gfx format that we can all read? (that a
schematic package outputs - hpgl, eps?)
MikeS
<mikesmith_oz@nosp*m.relaymail.net>
(remove the you know what before replying)
1997\09\16@041749
by
mikesmith_oz.nosp*m
On 15 Sep 97 at 23:05, Shane Nelson wrote:
<snip>
> That crossed my mind too. Another possible asset would be
the
> exact same amount of current going through each segment. I've
> found that when you light an entire digit (for the number 8) it
> isn't as bright as when you light only a few segments (like the
> number 1). Has anyone done this? Any comments?
>
Another thought would be randomising (pseudo) the order you switch
segment to segment to digit *completely* I find the normal digit
strobe effect quite irritatting, but if it was randomised, one
mightn't notice it.
MikeS
<mikesmith_oz@nosp*m.relaymail.net>
(remove the you know what before replying)
1997\09\16@110917
by
Martin R. Green
|
|
I'm not sure this would help. Yes you could drive each segment with a
higher current directly, but you would have seven times more things to MUX,
so the duty cycle would now be 1 in 42 instead of 1 in 8, so the perceived
brightness would drop to too low a level to be practical, without driving
the LED's with 7 times more current (1120 mA), which again is too much for
the PIC. Unfortunately, a catch-22.
Of course, if the human eye responds more to the _peak_ intensity than the
average intensity, as has been suggested in this list, then your suggestion
might work, but I have not found this to be the case.
The other challenge with MUX'ing all segments separately is that you would
need 42 port pins, unless you used some kind of external S2P chip (or
several), which kind of defeats the "PIC direct drive" theme of this
thread.
Finally, and this is not something I mentioned in my original post, LED's
have a fairly high capacitive component, making them tend to stay on a
little after the drive current is removed (I learned this when I built a IR
R/C device operating at 40KHz). The faster you MUX them, the more likely
you are to encounter segment bleed, for a different reason than the one I
mentioned in my original post. This might not prove to be a problem, but
it needs to be considered.
As I stated originally, I believe Microchip's examples are highly
optimistic. the only LED's I can see them working well with are those tiny
"bubble" LED's with little magnifying lenses over each character. These
have minuscule current requirements.
CIAO - Martin R. Green
KILLspamelimarKILLspambigfoot.com
----------
From: Mike Smith[SMTP:mikesmith_oz.nosp*RemoveMEamTakeThisOuTrelaymail.net]
Sent: Tuesday, September 16, 1997 12:46 AM
To: spamBeGonePICLISTspamBeGonemitvma.mit.edu
Subject: Re: Multiplexing Seven Segment Displays
On 15 Sep 97 at 18:44, Martin R. Green wrote:
> Ok, there's a couple of fairly simple calculations that will tell
A _bunch_ of my original post snipped.
> efficient or small LED's.
Good coverage of led muxing. What do you think of the idea of muxing
even *faster*, and driving only *one* segment at any one time, at the
absolute max currents? That wouldn't violate the pin or package
limits, but would increase s/w complexity.
MikeS
<mikesmith_oz@nosp*m.relaymail.net>
(remove the you know what before replying)
1997\09\16@110922
by
Martin R. Green
|
|
Sounds like you are one of those rare souls with a very short retinal
persistence. I find no noticeable flicker, or "strobe", on any LED
displays where all characters are scanned on less than 1/30th of a second.
You are a prime example of doing "worst case" design, and going for a
1/40th or 1/50th of a second full scan.
I have heard of people that get headaches watching commercial movies
because the 1/24th of a second frame rate flickers dramatically to them.
CIAO - Martin "long persistence" Green
TakeThisOuTelimarEraseMEspam_OUTbigfoot.com
----------
From: Mike Smith[SMTP:mikesmith_oz.nosp*RemoveMEamTakeThisOuTrelaymail.net]
Sent: Tuesday, September 16, 1997 4:09 AM
To: PICLISTEraseME.....mitvma.mit.edu
Subject: Re: Multiplexing Seven Segment Displays
On 15 Sep 97 at 23:05, Shane Nelson wrote:
<snip>
> That crossed my mind too. Another possible asset would be
the
> exact same amount of current going through each segment. I've
> found that when you light an entire digit (for the number 8) it
> isn't as bright as when you light only a few segments (like the
> number 1). Has anyone done this? Any comments?
>
Another thought would be randomising (pseudo) the order you switch
segment to segment to digit *completely* I find the normal digit
strobe effect quite irritatting, but if it was randomised, one
mightn't notice it.
MikeS
<mikesmith_oz@nosp*m.relaymail.net>
(remove the you know what before replying)
1997\09\16@112750
by
Josef Hanzal
<snip>
> So you can see why, IMNSHO, despite Microchip's examples, it is not really
> practical to drive a multiplexed LED display directly from a PIC, at least
> not the character drive anyway. You can probably get away with driving the
> segments directly, and driving the characters via transistor or other
> buffers, but this will require fairly efficient or small LED's.
Using low current display is really essential. I got good results with
Packard's HDSP-H111 or HDSP-H101 in triplexed display. Their nominal current
is 2 mA, but I used 1k resistors in series with cathodes which yields about
1 mA per segment. At that current the display still shines very nice.
Regards
Josef
1997\09\16@114851
by
Martin R. Green
|
|
2mA is indeed very low current for decent brightness on a LED display. I
assume by "Packard" you mean this is a Hewlett Packard device? What is
the display height, colour, etc.
Something with these specs might just work in Microchip's examples.
Martin R. Green
EraseMEelimarbigfoot.com
----------
From: Josef Hanzal[SMTP:RemoveMEeuroclassEraseMEEraseMEPHA.PVTNET.CZ]
Sent: Tuesday, September 16, 1997 11:33 AM
To: RemoveMEPICLISTspam_OUTKILLspammitvma.mit.edu
Subject: Re: Multiplexing Seven Segment Displays
<snip>
> So you can see why, IMNSHO, despite Microchip's examples, it is not
really
> practical to drive a multiplexed LED display directly from a PIC, at
least
> not the character drive anyway. You can probably get away with driving
the
> segments directly, and driving the characters via transistor or other
> buffers, but this will require fairly efficient or small LED's.
Using low current display is really essential. I got good results with
Packard's HDSP-H111 or HDSP-H101 in triplexed display. Their nominal
current
is 2 mA, but I used 1k resistors in series with cathodes which yields about
1 mA per segment. At that current the display still shines very nice.
Regards
Josef
1997\09\16@115849
by
mikesmith_oz.nosp*m
On 16 Sep 97 at 10:39, Martin R. Green wrote:
> The other challenge with MUX'ing all segments separately is that you
> would need 42 port pins, unless you used some kind of external S2P
> chip (or several), which kind of defeats the "PIC direct drive"
> theme of this thread.
>
Not what I meant. Common the segments, and connect one per PIC pin.
Thats 8pins. Now connect the 4 cathodes from each display to its own
pin. Thats 12 total.
Software -
Set all cathode IO pins low. Now tris them
Set all segment IO pins hi and tris them.
For the segment you want on, turn the 2 corresponding tris bits off
(not trissed) - briefly...
I'm a little tired, but I don't think this will reverse-bias any of
the unused LEDS.
4 resistors, max, in the common cathode leads.
MikeS
<mikesmith_oz@nosp*m.relaymail.net>
(remove the you know what before replying)
1997\09\16@120302
by
Shane Nelson
Yep, he means HP. Here's some specs from the Allied catalogue:
HDSP-H101
Color AlGaAs Red
Typ Intensity Per Segment 700 ucd @ 1mA
Dimensions .67"H X .49"W X .31"D
Price $2.47.
On Tue, 16 Sep 1997, Martin R. Green wrote:
{Quote hidden}> 2mA is indeed very low current for decent brightness on a LED display. I
> assume by "Packard" you mean this is a Hewlett Packard device? What is
> the display height, colour, etc.
>
> Something with these specs might just work in Microchip's examples.
>
>
> Martin R. Green
>
RemoveMEelimarTakeThisOuTspambigfoot.com
>
> From: Josef Hanzal[SMTP:
EraseMEeuroclassspamspamBeGonePHA.PVTNET.CZ]
>
> Using low current display is really essential. I got good results with
> Packard's HDSP-H111 or HDSP-H101 in triplexed display. Their nominal
> current
> is 2 mA, but I used 1k resistors in series with cathodes which yields about
> 1 mA per segment. At that current the display still shines very nice.
>
> Regards
>
> Josef
>
1997\09\16@120923
by
Shane Nelson
On Tue, 16 Sep 1997, Martin R. Green wrote:
> 2mA is indeed very low current for decent brightness on a LED display. I
> assume by "Packard" you mean this is a Hewlett Packard device? What is
> the display height, colour, etc.
>
> Something with these specs might just work in Microchip's examples.
Yep. The part microchip used in AN590 was HDSP7503:
Color: High Efficiency Red
Typ Intensity per segment: 980 ucd @5mA
Size: .5"H X .3"W X .24"D
Cost: $1.97
-Shane.
1997\09\16@134301
by
Martin R. Green
|
|
Those are some pretty good specs, .67 height is quite good, but my only
challenge is that I _detest_ red displays, and other colours always draw
more current. Oh, well, beggars can't be choosers, I guess.
CIAO - Martin R. Green
RemoveMEelimarKILLspambigfoot.com
----------
From: Shane Nelson[SMTP:iSTOPspamspam_OUTCHEETAH.SPOTS.AB.CA]
Sent: Tuesday, September 16, 1997 12:06 PM
To: spamBeGonePICLISTSTOPspamEraseMEmitvma.mit.edu
Subject: Re: Multiplexing Seven Segment Displays
Yep, he means HP. Here's some specs from the Allied catalogue:
HDSP-H101
Color AlGaAs Red
Typ Intensity Per Segment 700 ucd @ 1mA
Dimensions .67"H X .49"W X .31"D
Price $2.47.
On Tue, 16 Sep 1997, Martin R. Green wrote:
{Quote hidden}> 2mA is indeed very low current for decent brightness on a LED display. I
> assume by "Packard" you mean this is a Hewlett Packard device? What is
> the display height, colour, etc.
>
> Something with these specs might just work in Microchip's examples.
>
>
> Martin R. Green
>
KILLspamelimarspamBeGonebigfoot.com
>
> From: Josef Hanzal[SMTP:
EraseMEeuroclassEraseMEPHA.PVTNET.CZ]
>
> Using low current display is really essential. I got good results with
> Packard's HDSP-H111 or HDSP-H101 in triplexed display. Their nominal
> current
> is 2 mA, but I used 1k resistors in series with cathodes which yields
about
> 1 mA per segment. At that current the display still shines very nice.
>
> Regards
>
> Josef
>
1997\09\16@180544
by
M Walter
>As I stated originally, I believe Microchip's examples are highly
>optimistic. the only LED's I can see them working well with are those tiny
>"bubble" LED's with little magnifying lenses over each character. These
>have minuscule current requirements.
>
>CIAO - Martin R. Green
>@spam@elimar@spam@spam_OUTbigfoot.com
Martin, I just finished a small beginner project using a PIC and 7 segment
display. Since I had them, I used one of those "bulle" LED's. Price was
right and availability great (ie I had some in the junkbox). Worked fine
being driven directly.
Mark Walter
1997\09\16@212617
by
Marc 'Nepomuk' Heuler
Hi Martin (Martin R. Green), in <spamBeGone01BCC208.270817E0KILLspamifs-greenm.sybase.com> on Sep
15 you wrote:
> All LED's should be
> sequenced in less than 1/30 second to avoid flicker (a few rare people can
> detect flicker at this high rate so you might want to use 1/40th or 1/50th
> sec. instead).
I can see the 70Hz flicker of my monitor, if it is below the view center
(ie I look slightly above the monitor). 30 Hz is awful, especially if the
display is moving (or I am moving). It's one of these eye-catchers in
cheap coin solariums. The display pushes on your sight everytime you come
or leave.
1997\09\17@025741
by
mikesmith_oz.nosp*m
On 16 Sep 97 at 13:34, Martin R. Green wrote:
> Those are some pretty good specs, .67 height is quite good, but my
> only challenge is that I _detest_ red displays, and other colours
> always draw more current. Oh, well, beggars can't be choosers, I
> guess.
Does anyone like red? I find it objectionable for clock radios.
Probably because of the eye's non-sensitivity down that end of the
visible spectrum. Take it you are referring to the different Vf for
the yellow/green ones. I've never seen a blue (LED) seven segment
display - anyone?
MikeS
<mikesmith_oz@nosp*m.relaymail.net>
(remove the you know what before replying)
1997\09\17@103437
by
Martin R. Green
1997\09\17@153513
by
Herbert Graf
-----Original Message-----
>Does anyone like red? I find it objectionable for clock radios.
>Probably because of the eye's non-sensitivity down that end of the
>visible spectrum. Take it you are referring to the different Vf for
>the yellow/green ones. I've never seen a blue (LED) seven segment
>display - anyone?
Nope, although I'm sure it would cost a BUNDLE, one single blue LED is
enough. TTYL
1997\09\17@155755
by
Eric van Es
|
Martin R. Green wrote:
> The moving beam on a CRT introduces new visual problems that are not
> present with a simple "all-at-once" display like a MUX'd display or
> motion
> picture. As you state, 70Hz is borderline for a CRT, especially if
> your
> monitor forces you to use interlaced scanning (my old NEC 3D at
> 1024x768
> required 72Hx interlaced). Luckily my new Viewsonic 21" gives me 87Hz
> @
> 1280x1024.
>
Do you need higher refresh rates, because the monitor has a large area
to refresh?The 7seg would be very small...
> A 50Hz scan should be sufficient for a LED bar, but there is no reason
> you
> can't go to 100Hz if you want.
After all the lightsbulbs in SA all run off 220V 50Hz. Only sometimes
you detect a flicker - usually when there's a power dip. I suppose it's
because the filament does not dissipate its rated power and
illuminescence....
Cheers!
--
Eric van Es | Cape Town, South Africa
RemoveMEvanesspamBeGoneilink.nis.za | http://www.nis.za/~vanes
LOOKING FOR TEMPORARY / HOLIDAY ACCOMODATION?
http://www.nis.za/~vanes/accom.htm
1997\09\18@025811
by
Pasi T Mustalahti
|
|
On Wed, 17 Sep 1997, Eric van Es wrote:
> Martin R. Green wrote:
>
> After all the lightsbulbs in SA all run off 220V 50Hz. Only sometimes
> you detect a flicker - usually when there's a power dip. I suppose it's
> because the filament does not dissipate its rated power and
> illuminescence....
>
PTM: If you put a diode in series with a pulp you got a very annoying
flicker in spite of the resulting 25 Hz. This same 25 Hz doesn't flicker
in TV or movies. I have myself started to speak about the dead time.
In case of the pulp and the diode the dead time is <50%, in movies about
5..10% (?) and in TV it depends of the phosphor.
Phosphors user in CGA and VGA are rather 'fast'. In Hercules and MDA they
used slow phosphors. Because of this fast phosphor you got to use high
scanning rates in VGA.
This dead time seems to be very good explanation. I have not tested yet,
but I have a very good testbench for this, so I might some of these days.
Our staff in psychology has made this kind of work for years and they have
_very_ interesting results about movies, TV and brains. One of the best is
(as I understood it) that our center of speaking in the brains have the
same resonance frequency as this flicker. It means that you will have
troubles when you try to speak while watching TV. This also explains why
it is so difficult to leave the TV when you have started to look.
--------------------------------------------------------------------------
PTM, spamBeGonepasi.mustalahti@spam@spam_OUTutu.fi, TakeThisOuTptmustaspamutu.fi, http://www.utu.fi/~ptmusta
Lab.ins. (mikrotuki) ATK-keskus/Mat.Luon.Tdk OH1HEK
Lab.engineer (PC support) Computer Center OI7234
Mail: Turun Yliopisto / Fysla, Vesilinnantie 5, 20014
Pt 02-3336669, FAX 02-3335632 (Pk 02-2387010, NMT 049-555577)
--------------------------------------------------------------------------
1997\09\18@191229
by
peter
|
Pasi T Mustalahti wrote
> > After all the lightsbulbs in SA all run off 220V 50Hz. Only sometimes
> > you detect a flicker - usually when there's a power dip. I suppose it's
> > because the filament does not dissipate its rated power and
> > illuminescence....
> >
> PTM: If you put a diode in series with a pulp you got a very annoying
> flicker in spite of the resulting 25 Hz. This same 25 Hz doesn't flicker
> in TV or movies. I have myself started to speak about the dead time.
> In case of the pulp and the diode the dead time is <50%, in movies about
> 5..10% (?) and in TV it depends of the phosphor.
snip
> --------------------------------------------------------------------------
> PTM, pasi.mustalahtiEraseMEutu.fi, RemoveMEptmustaEraseMEspam_OUTutu.fi, http://www.utu.fi/~ptmusta
> Lab.ins. (mikrotuki) ATK-keskus/Mat.Luon.Tdk OH1HEK
> Lab.engineer (PC support) Computer Center OI7234
> Mail: Turun Yliopisto / Fysla, Vesilinnantie 5, 20014
> Pt 02-3336669, FAX 02-3335632 (Pk 02-2387010, NMT 049-555577)
> --------------------------------------------------------------------------
Your flicker is at 50Hz not 25Hz
@spam@peterRemoveMEEraseMEcousens.her.forthnet.gr
More... (looser matching)
- Last day of these posts
- In 1997
, 1998 only
- Today
- New search...
