
Oldskool Demo on a 7 Segment Display - fourspace
http://www.plingboot.com/2017/02/oldskool-demo-on-a-7-segment-display/
======
pdkl95
> Notice there’s a lot of pixels here that don’t map to any segments, 30% that
> will never be displayed.

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...](http://i1.wp.com/www.plingboot.com/wp-
content/uploads/2017/02/cubez.jpg)

[2] [http://aa-project.sourceforge.net/aalib/](http://aa-
project.sourceforge.net/aalib/)

------
i336_
This is ever so slightly thread-hijacking but I've been wondering something
slightly related for a while now: what's the downright cheapest way to get
into really really big LED matrixes? Like the kind used for signs (of various
sizes; let's say I'm referring to around <2ft sq).

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.)

~~~
ChuckMcM
As it turns out this is getting pretty easy. A de-facto standard has emerged
for these[1] LED modules, both in interfacing and in mounting. I used a couple
in a LED clock[2] which can also tell time in QR Code[3] :-). Basically at $25
each you're looking at $3,750 in modules for a 640 x 480 display that in the
"P3" (3mm dot pitch) size would be 1.92M wide (75.6") by 1.44M tall (56.7").

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...](https://www.aliexpress.com/item/3mm-Indoor-SMD0606-rgb-led-display-
module-192mm-x-96mm-64-32-pixle-Video-images-
picture/1641364020.html?ws_ab_test=searchweb0_0,searchweb201602_3_10065_10000073_10068_10501_10000077_10000074_10503_10000032_119_10000030_10000026_10000023_431_10000069_10000068_10060_10062_10056_10055_10000062_10054_10000063_10059_10099_10000020_10000013_10103_10102_10000016_10096_10000056_10000059_10052_10053_10107_10050_10051_10106_10000097_10000094_10000091_10000007_10000050_10084_10000101_10083_10000100_10080_10000047_10000104_10082_10081_10110_10111_10112_10113_10114_10000089_10000086_10000083_10000041_10000044_10000080_10078_10079_10000038_10073_10000035_10070_10122_10123_10121_10126_10124-10503_10501,searchweb201603_2,afswitch_3,ppcSwitch_1,single_sort_1_default&btsid=0207e271-5f2c-489f-be15-a3aced211e7a&algo_expid=0eab590f-806a-4601-9f5c-1656aa91ca24-0&algo_pvid=0eab590f-806a-4601-9f5c-1656aa91ca24)

[2]
[https://twitter.com/ChuckMcManis/status/794023527720620032](https://twitter.com/ChuckMcManis/status/794023527720620032)

[3]
[https://twitter.com/ChuckMcManis/status/794025248203022336](https://twitter.com/ChuckMcManis/status/794025248203022336)

[4] [https://1bitsquared.com/collections/embedded-
hardware/produc...](https://1bitsquared.com/collections/embedded-
hardware/products/1bitsy)

~~~
i336_
_Wow_, that is truly impressive. $3.7k for a ~2x1.5m² _RGB (!!)_ display - and
no added costs (besides a like <$50 interface controller setup). Nice!

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](http://imgur.com/a/EVYB2). Is this an intrinsic
problem in the driver system or perhaps a camera or encoding/compression
glitch?

~~~
hantusk
You can get an 80 inch TV for the same cost and roughly the same dimensions.

I am curious to understand what this can offer that a TV can't

~~~
mschuster91
1) a LED "wall" is far brighter than a comparably sized TV, that's important
when you place stuff high on a building

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.

~~~
wnesensohn
Regarding point 3: At 150 modules consuming about 25W each, your LED wall is
consuming about 3750W max. An 80" TV will consume about 300W.

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.

~~~
mschuster91
With a LED wall, only the lit pixels will consume power - the backlight of
most TVs is full-on all the time. Only exceptions (iirc) are OLED TVs where
the pixels themselves generate the light, and TVs which have their background
light partitioned to achieve true(r) black by turning down all-black areas.

------
userbinator
_Now, I wonder if I can get an old calculator to play the accompanying 4 track
MOD?_

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;

~~~
SyneRyder
> they have a "wild" category for hardware/exotic demos like this.

Revision 2017 has a Wild competition coming up in mid-April as well:

[https://2017.revision-party.net/compos/other](https://2017.revision-
party.net/compos/other)

------
Renaud
There was an art project done a few years ago using 7-segment displays and
animations, looked quite cool too:

[http://hackaday.com/2013/11/21/7-segment-display-matrix-
visu...](http://hackaday.com/2013/11/21/7-segment-display-matrix-visualizes-
more-than-numbers/)

------
gaius
From the name plingboot I detect an old-skool BBC Micro fan :-)

------
swerner
Add some PWM for grayscale effects.

------
jackhammons
Very pretty. Nice effect!

------
lukas
This is awesome. Thanks for sharing.

------
ajnin
It's amusing but a bit underwhelming, he's simply mapping a grid of pixels to
segments, he's not taking the shape and orientation of the segments into
account at all.

~~~
dang
This style of comment isn't very good here because it comes across as putting
down someone else's work. Some of that is just cultural and linguistic
convention, of course, but on HN it's important; we know from long experience
how it affects the community.

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.

