Talk:Charlieplexing

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing (Rated Stub-class)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 Stub  This article has been rated as Stub-Class on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
 
Note icon
This article has been automatically rated by a bot or other tool as Stub-Class because it uses a stub template. Please ensure the assessment is correct before removing the |auto= parameter.

Keep this page, please. The multiplexed display was fundamental to the development of (inter alia) the pocket calculator, and deserves a better technical writeup on Wikipedia. Charlieplexing is an interesting footnote, and should be included for completeness. IanHarvey (talk) 21:49, 11 February 2008 (UTC)

I would like to comment that this is actually a very important technique for driving a display with a smaller number of i/o pins than traditional multiplexing. It is actually more important now than ever before with the increased integration of embeded computers in appliances and other devices. This technique allows smaller processor chips with fewer i/o pins to do more work, and for commercial products will tend to drive the cost down by preventing an engineer from having to choose a larger chip to support a project. This is critical where the product is a disposable device such as a single use camera, or a device with limited space such as a watch or a battery with a built-in meter. This also reduces the consumption of resources such as copper, so it can be considered an earth friendly technology, making it more than a footnote. Georgedotcom (talk) 00:17, 10 March 2008 (UTC)

I found about this topic while watching a clip on youtube, but I have to say that the way it's explained here is very confusing. I'm going to try and understand it better and fix this article so it's a little clearer. --79.36.181.209 (talk) 09:00, 25 May 2008 (UTC)

Can anyone put a circuit diagram of it on here? Pi.1415926535 (talk) 18:17, 13 June 2008 (UTC)

Seems to me that the linked Microchip article "Complementary LED Drive" serves the requirement of a published third-party article. BrianWilloughby (talk) 07:12, 1 July 2008 (UTC)

I have removed the notability template, I think it's good now. Thanks for adding references. Gigs (talk) 05:28, 30 October 2008 (UTC)

Contents

[edit] Duty Cycle-> Refresh Rate

I changed the name of the "Duty Cycle" section to "Refresh Rate" but I'm still not happy with that term as used in that section. To me, the refresh rate is how often the whole display gets activated once (alway 50 Hz, in the section), but what the section is saying (the number of times a LED has to be addressed for possible activation) might be called the "LED write rate" or "LED Activation Rate." Perhaps scan rate from CRT raster technology, but that seems to imply a horizontal line acrosss a display. Maybe pixel rate?Benbradley (talk) 21:52, 4 November 2008 (UTC)

Also, I wonder if it actually true that you always only can activate one LED. Consider a set of three IOs with 6 LEDs. Then imagine setting IO A to logic low. You then can set both other IOs to either logic H or Z, thereby activating two LEDs at the same time. Do his round robin style.

In the example with three IOs this means every LED is on for 1/3rd of the time, not 1/6th. Correct?

TomFTom Frey (talk) 10:21, 12 November 2008 (UTC)

The Duty cycle is just 1/N, where N is the number of drive lines. For example, if you have 9 IO or driver lines, then at any given time 1 line will be performing the same function as the digit driver in a normal multiplexed display and the other 8 will be the same as segment lines in a normal muliplexed display. So with 9 lines you can drive 9 digits of 8 segments. A normal multiplexed LED display would use 9 digit lines and 8 segment lines and also have the same 1/9th duty cycle, but using a total of 17 IO lines rather than the 9 lines of the Charlieplexing method. The number of segments you can drive with "N" lines using Charlieplexing is N x N-1. With normal multiplexing, for N lines the maximum number of segements you can drive is for a square matrix of equal number digits and segments. So N/2 * N/2 = N^2 / 4. The duty cycle issue is what sets the practical limit on the number of segments driven. 16 lines would drive 16*2=15 = 240 segments, but with a duty cycle of 1/16. Normal multiplexing to drive 240 segments would take 15+16 = 31 pins and would have a slightly better duty cycle of 1/15. —Preceding unsigned comment added by 71.116.113.160 (talk) 16:06, 29 November 2008 (UTC)

[edit] Errors in Article

The section on current is almost entirely wrong.

"Due to the decreased duty cycle, the current requirement of a charlieplexed display increases much faster than it would with a traditionally multiplexed display. As the display gets larger, the average current flowing through the LED must be constant in order for it to maintain constant brightness, thus requiring the peak current to increase proportionally. This puts a limit to the size of the display, as when the peak current flowing through the LED’s when they’re turned on exceeds the LED’s ratings, charlieplexing is not a possibility."

The decreased duty cycle is balanced by the fact that only one LED is lit at once. 10 LEDs all at 10mA constantly consumes 100mA. 10 LEDs all at 100mA with a 10% duty cycle and no two LEDs on at the same time also consumes 100mA. So current requirements should stay constant for a given number of lights each emitting a given amount of light.

In fact, the light output increases faster than the current, so putting 100mA/10% duty through an LED will give you more light output than 10mA/100% duty. So current requirements actually *decrease*.

This is a simple energy equation. Charlieplexed displays are in no way inefficient and this paragraph suggests that they are.

Finally, an LED's current limitation is in fact a power dissipation limitation. You can supply a 30mA LED with 300mA for 10% of the time and it should not overheat. However, you may need to increase the switching frequency in this case. The current limit is not a limit on *peak* current, but a limit on *power* which is a function of *average* current. Limits on peak currents are not quoted for LEDs. —Preceding unsigned comment added by 91.84.151.241 (talk) 17:55, 20 January 2009 (UTC)

The first LED I took a look at the datasheet for ( http://www.rapidonline.com/netalogue/specs/55-1790e.pdf ) clearly had both a DC forward current and a pulse forward current specified. While for the LED junction itself power is roughly proportional to the peak current other parts (such as bondwires to the package) will likely have a resistive characteristic and hence a power disipation proportional to the RMS current.
While you may be able to run some 30ma LEDs at 300ma 10% of the time I doubt they would survive very long at 3A 1% of the time.
There is also the issue that charlieplexing is largely pointless if you cant use the microcontrollers built in tristates (since controlling a tristate generally requires two lines). Most microcontrollers only have about 20ma or so drive on thier IO lines.
In summary charlieplexing is a neat hack for running a small (say 20) group of LEDs that don't have to be particularlly bright off a microcontroller while saving on IO and not using any external active components but for a larger grid you are going to run into issues and will do better using conventional multiplexing (and if you are short of IO putting a 1-of-n decoder on one side of the matrix). Plugwash (talk) 00:53, 22 January 2009 (UTC)
But in the light of the section above (Duty Cycle-> Refresh Rate), which makes clear that the duty cycle using charlieplexing is only slightly less than that for traditional multiplexing, is there really a substantial disadvantage? Quote: "16 lines would drive 16*2=15 = 240 segments, but with a duty cycle of 1/16. Normal multiplexing to drive 240 segments would take 15+16 = 31 pins and would have a slightly better duty cycle of 1/15." There certainly is a peak current limit for LEDs, but this problem is exactly the same as for a traditionally multiplexed LED array. So this is not a specific problem to charlieplexing. The sentence

Due to the decreased duty cycle, the current requirement of a charlieplexed display increases much faster than it would with a traditionally multiplexed display

from the article is therefore wrong --Tom Frey (talk) 02:32, 27 March 2009 (UTC)

Perhaps a better way to phrase the problem is that brightness drops faster with increasing Charlieplexed matrix sizes compared to other techniques. Since brightness is very important to some applications, and since increased current is required to maintain brightness, I think that's whence the original current comment stems. However, the real limiting factor is that Charlieplexing puts a circuit up against the maximum current limitations of an LED far quicker than other matrix configurations. Thus the repeated axiom that Charlieplexing is best for small numbers of LEDs and pins. You certainly don't want to try Charlieplexing 200 LEDs if you want them to be bright and have multiple LEDs appear to be lit simultaneously. BrianWilloughby (talk) 17:31, 6 January 2011 (UTC)

[edit] Requirement for tristate

"...if external tristates must be used then each tristate will require two output lines to control eliminating most of the advantage of a charlieplexed display."

Is this actually correct? Most external tristate drivers do require 2 lines to drive them, but it must be possible to make an external tristate driver that works with only one input line. For example, if the microcontroller has outputs that are either +5V, 0V, or floating, what about a weak pull-to-centre resistor network (say 100k from the pin to each rail), so that the float is biased at 2.5V, and then drive 2 symmetric transistor/diode networks: the lower half would be 4 diodes in series with the (NPN) base-emitter junction (thereby turning on only when the voltage exceeds 3.1V, and the upper (PNP) half only turns on when the voltage is below 1.9V. —Preceding unsigned comment added by 87.194.171.29 (talk) 02:53, 24 January 2009 (UTC)

Certainly possible in theory but i'm not convinced it's particuarlly practical compared to other options like decoder chips. Plugwash (talk) 13:05, 21 February 2009 (UTC)
I am with plugwash on this one. Gugaplexing (see e.g. http://blog.makezine.com/archive/2008/06/charlieplexing_times_two.html) uses discrete transistors to do something similar - even giving you the possibility to control twice as many LEDs. But to be honest, this means a lot of effort and as plugwash states, it is probably more space / effort / cost effective to use external logic like shift registers or decoders. But perhaps I can make suggestion. It isn't really necessary to drive the LEDs symmetrically. I don't know if it is frowned upon, but here is a link where I describe this compromise in detail: http://tomscircuits.blogspot.com/ Tom Frey (talk) 07:46, 21 April 2009 (UTC)


[edit] Charlieplexing is based on an idea from the 1970s

Christopher Malinowski's German patent in 1979 (on which U.S. patent 4,319,227 is based) describes how to drive e.g. 12 LEDs on 4 wires, etc. Is there anything new in Charlieplexing other than doing exactly the same thing but with a microcontroller?

[edit] The clock in the picture

is backwards! —Preceding unsigned comment added by Fastfourier (talkcontribs) 15:18, 11 October 2010 (UTC)

Personal tools
Namespaces
Variants
Actions
Navigation
Interaction
Toolbox
Print/export