Posting Comment for "19 LED Animated Christmas Star"

*Author Name
Email Address
Website URL

About Posting a Comment

Comments are moderated before they will appear on the website, this is a manual process and may take some time. Please be patient.

Author Name is a required field.

Email Address is optional, but without one I won't be able to contact you back. It is never shown or linked on the website. You can always just email me if you'd rather not post a public comment. I generally reply in-line with a comment rather than email you back, unless I want to discuss something in private or off topic. Please check back to see when I reply.

Website URL is optional, if supplied the Author Name will be hyperlinked to this URL.

You may use wikitext in the body, preview may be handy here. Don't worry if you can't figure them out, just give me a hint what you want linked to what and I'll do it during moderation. Wikitext is not BBcode!

Spammers: Please don't bother wasting your time scripting up posts to this form. Everything is moderated, your post will never be seen on the web even transiently, there is no way to even view it by its internal ID, it will never be indexed. I will simply delete your post in the moderation interface. If I'm your target audience you're really on the wrong track; I'll never click on a URL in your garbage. The post content is not emailed to me (and I don't use a Win32 mail client anyway), I view the posts in plain text in the moderation interface so no clever tricks of any kind will make anything you type be interpreted by anything other than me, a human. Just give up and go elsewhere please!

11th April 2010 00:39

Alan Yates wrote...


I chose to make the charlieplex loop take essentially constant time to ensure constant individual LED brightness. As you suggest, this may not work very well with low-efficiency LEDs as their drive duty-cycle is quite low (~ 1/NB_LED) and there is a limit to the peak currents the MCU pin drivers can deliver/sink (and the LEDs tolerate).

Your solution likely works better with low efficiency LEDs, but I'd imagine the individual LED brightness varies a lot with the number of lit LEDs? In fact I'd assume it is almost constant display brightness, rather than constant individual LED brightness?

I found that effect unpleasant, especially with displays of large physical extent where they are "painted" with an essentially constant amount of brightness spread out on an area proportional to the number of lit elements. That said the brightness variations associated with constant-drive to each LED may be distracting to an observer as well, especially in a dark room or if their attention is directed elsewhere... I find my tolerance for flashing object in non-foveal vision is a complex function of its pattern, subtended area on the visual field and the ambient brightness.

My code takes NB_LED * ~200 us + K (some roughly constant "wasted" time) to do each display scan and an individual LED is lit for ~200 us each scan (duty cycle of approximately 1/NB_LED - practically constant). Yours takes ~200 us for each lit LED plus some (likely different) wasted time with each LED being lit for ~200 us (duty cycle of approximately 1/NB_LIT_LED).

The constant "wasted" time per cycle is more significant for your code as well, as the loop executes faster so more time is wasted on average with less LEDs lit. This effect tends to counteract the duty-cycle reduction though.

The 200 us dwell time on each LED can be changed of course. Reducing it raises the frequency of the drive signal and tends to run into slew-rate limits of outputs, while also making the constant wasted "think" time more significant wrt the lit time. Increasing the delay obviously eventually runs into the human flicker fusion frequency, but makes the waste time and electrical drive limits insignificant.

One advantage of your method is the supply current is almost constant.

I'd say in summary: your method is fine, but only use it if you must (or prefer the effect) - otherwise use high-efficiency LEDs and a constant duty-cycle drive.



9th April 2010 21:13

Sylvain wrote...

Hello Alan,

Very nice piece of work, I like the idea of the interpreter, very clever.

Just like you, I like making circuits with the fewest number of components and the smallest microcontrollers! It makes look at the generated code and makes you think how to tweak and improve your C code to gain ROM/RAM or speed.

Anyway, you might be interested in a quick improvement I made to your code. As I didn't have high brightness LEDs, it turned out that the Charliplexing method was consuming much of the time checking for OFF LEDs. That is when you have a frame with only one or two LEDs to be lit, the Charlieplexing goes through the 19 LEDs anyway. The big drawback is that a single LED over 19 is as bright as 19 LED over 19 as the same amount of time is spent for each LED.

To gain brigntness with the LEDs I had, I just looked for ON LEDs in the displayState variable. Of course the brigntness will be the same if the 19 LED are driven high, but you gain lots of brightness when this number decreases. Here is an example:

void charlieplex (void) { uint8_t led, map, set, unset; uint32_t decal; for (led=0, decal=1L; led<NB_LED; led++, decal<<=1) { if (displayState & decal) { map = pgm_read_byte(&ledMappings[led]); // get current LED DDRB and PORTB values set = 1 << (map & 0x0F); unset = 1 << ((map & 0xF0) >> 4); DDRB = set | unset; PORTB = set; _delay_us(200); } } DDRB = 0; PORTB = 0; }

Keep up with your good work!

Best regards,


25th December 2009 02:04

Alan Yates wrote...


Thanks mate, Merry Xmas to you and yours as well!

The circle thing is my old dekatron emulator. The PostScript used for the layout of the star actually has its beginnings in that project. Of course building it discrete is kinda crazy, it would have been much easier to use a 4017.



23rd December 2009 06:55

marxy wrote...

Very nice work Alan. I also like the whirling circle display in the background.

Your trumpet playing is coming along pretty well too.

Merry xmas.