Oldskool Demo on a 7 Segment Display(plingboot.com) |
Oldskool Demo on a 7 Segment Display(plingboot.com) |
Unfortunately this problem, the slant (italic) added by the hardware, and the bias introduced from mapping the horizontal lines (A, G) to the "left" pixels only, causes artifacts in the output. A good example is the left side of this[1] image, where the bottom of the 7-seg displaying "F" has a large jump rightward to the "1" below it.
To get around these problems, aalib[2] renders each glyph that it will use, and for each block of pixels to display calculates nearest glyph. This automatically provides anti-aliasing for any shape glyph. As you already have the error (remaining distance to nearest glyph) for each group of pixels, it is also easy to add dithering to distribute the error across the image.
[1] http://i1.wp.com/www.plingboot.com/wp-content/uploads/2017/0...
The major issue I'm completely ignorant of is how to get enough I/O that can drive the LEDs directly - I'm assuming something with lots of direct drive I/O and no intermediary components would be the cheapest way to do it (?).
I understand multiplexing is the only way to survive at scale, but for small displays (say, 5x30 (= 150 LEDs)), what solutions would have enough I/O to drive each LED emitter individually, without scanning? I've always wondered what a truly flickerless LED matrix would look like. *
(* Several years ago I had an odd incident where after using a scientific calculator I'd see weird swirling patterns overlaid on top of whatever I was looking at. The LCD itself was not faulty or damaged, and I couldn't see any flickering at all. Considering LCDs run at 30-100Hz, the whole incident (it stopped after a while, I have some theories as to why) made me curious what a truly DC-driven LED matrix would look like.)
All of the LED driving is taken care of by the module, except for multiplexing the 'lines'. So these work by having drivers for one 'line' or LEDs (or 2 lines on the 32 LED high modules). You shift out the bits to them on a 16 pin plug. My clock as using an STM32F4 chip on a 1Bitsy[4] and was doing 240 FPS. Since these micros can be easily paralleled and synchronized you can drive an arbitrarily large sign by adding about $25 per 16 panels. Feeding them all data is a bit more complicated but not terribly so.
[1] https://www.aliexpress.com/item/3mm-Indoor-SMD0606-rgb-led-d...
[2] https://twitter.com/ChuckMcManis/status/794023527720620032
[3] https://twitter.com/ChuckMcManis/status/794025248203022336
[4] https://1bitsquared.com/collections/embedded-hardware/produc...
Hmm. I wonder what the weatherproofing (particularly heatproofing) on these things is like. I know of a time/temp display high up on a building (probably around 1x1.2m²) that is constantly corrupted, I'm wondering if it's the 40°C days around here (Sydney Australia) that keep hitting it...
It's fascinating watching how QR encoding shifts and changes data - some of the time updates just adjust a few pixels, some of them adjust the whole barcode. I wonder what the source data for each frame was (but not terribly so).
So... if I understand right, these are line-buffered? You send it a line's worth of data, hit "go", and it redraws that line? 240FPS is good, wow.
One question: in the first couple of "ticks" of the second hand on the first clock video, I noticed how there appears to be a minor bit of "LED bleed" where some of the LEDs don't switch off for a couple fractions of a second. Curious, I had a look at the video frames: http://imgur.com/a/EVYB2. Is this an intrinsic problem in the driver system or perhaps a camera or encoding/compression glitch?
Add some music and the demosceners at pouet.net might get interested in seeing it; they have a "wild" category for hardware/exotic demos like this.
I agree with the second comment there about replacing the verbose chain of if-statements with a single expression; my first thought upon seeing that was "this really needs to be simplified"; likewise, the second part with 7 nearly identical lines shifting left and then right by the same amount, then multiplying by 255(?!) can be simplified to a loop; the way it looked with lines for B and C having a slightly-different mask constant is misleading, since it looks like a copy-paste error. Here's an (untested) attempt at simplifying the code:
int yoffs[] = { 0, 1, 3, 4, 3, 1, 2 };
shift = 6 - ((digit&3) << 1);
for(segs=0,i=0;i<7;i++)
segs |= !!(screen_buffer[bx+yoffs[i]][bx] & 1 << shift+(i<1||i>2) ) << 6-i;Revision 2017 has a Wild competition coming up in mid-April as well:
http://hackaday.com/2013/11/21/7-segment-display-matrix-visu...
It would be easy to rework this into a good comment by expressing your point additively rather than as fault-finding. For example, mention "shape and orientation of the segments" as the next thing to take into account and add some information about how one might do that. Then you're helping all of us learn.
So the loop is:
1) Clock out a row of R, G, B values for the number of panels you have linked together (64 x n)
2) Turn off the LEDs on that row (enable goes low)
3) Latch the value
4) Select the next row
5) Turn on the display (enable goes high)
(my repo which does this: https://github.com/ChuckM/1bitsy-examples/tree/master/demos/... )
Since there are 16 "rows" multiplexed on to one "row driver" you need to at least clock out a set of all the rows every mS to get a 60Hz refresh rate (or every 250uS for a 240hz rate).
It is "easy" to do 3 bit RGB color (8 colors) since each value in R, G, and B has one bit. To get shades you need to PWM the bits and that consumes more bandwidth (with the 240Hz I can get a nominal 4 'intensities' per color by PWM'ing within the 60 fps rate, more by PWMing across a longer period. (which leads to interesting effects btw).
The panels all come with these neodymium magnetic feet so you can just put up a piece of 20ga sheet and stick up your display very simply.
On the video I expect it is a camera problem, the LEDs turn off pretty much instantly. The only caveat to that would be propagation from board to board of the 'enable' line but that is less than a microsecond.
I'm not 100% on what "line selectx4" does though. And this is all much more foreign than I'd like... but that's fine, I'll figure it out eventually. (The main thing with software is that accidents/learning/experimentation don't cost anything :P)
It would be interesting to get a microcontroller, or set of microcontrollers connected together at very high speed, to clock data out to the panel in perfect lockstep. An excuse to use assembly language perhaps, but only if the driver microcontroller itself is deterministic (a bit of an unknown).
I'm surprised about the bit with the magnets (I guess if you're trying to bolt a computer with a spinning HDD onto the back of it you're doing it wrong).
Good to know the LEDs turn off instantly. Thanks very much for that bit. I do wonder about the board-to-board propagation time, yeah. I take it each board is chained to the next board's enable line (?), or are they all driven from the microcontroller?
I am curious to understand what this can offer that a TV can't
I wonder what the weatherproofing (particularly heatproofing) on these things is like.
LEDs are more sensitive to heat than CRTs or incandescent lamps, but less than LCDs.
2) An ordinary TV is designed to be looked at from the front, a slight angle skews the colors and if it's extreme enough the screen gets totally unreadable.
3) A TV eats up tons of power, a LED wall not so much.
Power consumption of the LED wall will, however, be highly dependent on the displayed content. A white screen will consume most, a black screen basically nothing, but displaying only dark images is not exactly what LED walls are usually used for.
The equation is simple: The brighter, the more power you'll need, and an LED wall is, as you say, far brighter.
I haven't fully mentally appropriated how far embedded computing has come. I would have solved this by counting instruction lengths :)