LED - uniformity issues
LED - uniformity issues
LED - uniformity issues
LED - uniformity issues
LED - uniformity issues
LED - uniformity issues
LED - uniformity issues
LED - uniformity issues
LED - uniformity issues
Tektronix 314: Arduino speed measurement - 0.1µs/d…
Arduino speed measurement - 2µs/div
Jyetech - Arduino speed measurement
SMD rework - ChipQuik test set
LT1618 - step-up LED driver
My makeshift office
ATmega64
ATmega168 chips en masse
Electronics goody bag
600x 270Ω - Resist !
ChipQuik SMD rework - applying paste flux
ChipQuik SMD rework - adding the alloy
ChipQuik SMD rework - adding the alloy
ChipQuik SMD rework - dead chips
Seeedstudio 3W LED bar
RGB Matrix V3.04 - assembled back side
RGB Matrix V3.04 - assembled front side
RGB Matrix V3.04 - assembled + matrix
RGB Matrix V3.04 - translucency
RGB Matrix V3.04 - translucency
RGB Matrix V3.04 - pseudo Xray
PCBlurr
RGB Matrix V3.04 - front
RGB Matrix V3.04 - back
Jyetech scope - improved back plate
Jyetech scope - improving the back plate
Jyetech scope - improved back plate
imgp2009
imgp2008
imgp2007
imgp2006
imgp2001
imgp2000
creative chaos
almost done ?
a long way to go
See also...
Keywords
Authorizations, license
-
Visible by: Everyone -
All rights reserved
-
155 visits
LED - uniformity issues


Quite a few LEDs emit too much red. I will need some sort of dot correction to compensate ;-(
8 out of 10 boards have issues.
The manufacturer recommended using drivers that support dot correction. Also they don't check/sort the chips with respect to emittance before assembly. DUH! I wonder why all the other boards I got from them before were perfectly OK.
I implemented dot correction to the latest firmware of my controller, but it costs some speed. The dot correction is stored in PROGMEM and the reads seem to be somewhat slow. I'm also facing a few casts back and forth between int8_t and unit8_t which also takes time.
I think I'll have to rewrite the framebuffer code to allow gamma correction as well. Currently a single run of the ISR refreshes the full display and blocks other stuff for about 50% of cpu time. A rewrite to just do one intensity level per ISR run would spread the load more evenly and may be better for other jobs like I2C and serial.
For dot correction on driver level I'd have to switch some chips. No time for that right now. Getting flawless LED boards would be much better.
8 out of 10 boards have issues.
The manufacturer recommended using drivers that support dot correction. Also they don't check/sort the chips with respect to emittance before assembly. DUH! I wonder why all the other boards I got from them before were perfectly OK.
I implemented dot correction to the latest firmware of my controller, but it costs some speed. The dot correction is stored in PROGMEM and the reads seem to be somewhat slow. I'm also facing a few casts back and forth between int8_t and unit8_t which also takes time.
I think I'll have to rewrite the framebuffer code to allow gamma correction as well. Currently a single run of the ISR refreshes the full display and blocks other stuff for about 50% of cpu time. A rewrite to just do one intensity level per ISR run would spread the load more evenly and may be better for other jobs like I2C and serial.
For dot correction on driver level I'd have to switch some chips. No time for that right now. Getting flawless LED boards would be much better.
- Keyboard shortcuts:
Jump to top
RSS feed- Latest comments - Subscribe to the comment feeds of this photo
- ipernity © 2007-2025
- Help & Contact
|
Club news
|
About ipernity
|
History |
ipernity Club & Prices |
Guide of good conduct
Donate | Group guidelines | Privacy policy | Terms of use | Statutes | In memoria -
Facebook
Twitter
Sign-in to write a comment.