Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oldskool Demo on a 7 Segment Display

plingboot.com

Post reply on HN
Print view View original

21–27 of 27 posts

Re: Oldskool Demo on a 7 Segment Display

#21

Post by ChuckMcM »

wnesensohn wrote: post #19
mschuster91 wrote: post #16

Earlier quoted context omitted.

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.

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 bright…

These particular modules consume seem to consume at most about 10W each. But yes, it is brighter than a TV.

Re: Oldskool Demo on a 7 Segment Display

#22

Post by ChuckMcM »

i336_ wrote: post #13
ChuckMcM wrote: post #8

Earlier quoted context omitted.

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…

_Wow_, that is truly impressive. $3.7k for a ~2x1.5m² RGB (!!) display - and no added costs (besides a like 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 watc…

The interface is this: "on/off", "line selectx4", "clock", "latch", "R", "G", and "B".

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.

Re: Oldskool Demo on a 7 Segment Display

#23

Post by mschuster91 »

wnesensohn wrote: post #19
mschuster91 wrote: post #16

Earlier quoted context omitted.

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.

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 bright…

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.

Re: Oldskool Demo on a 7 Segment Display

#24

Post by i336_ »

ChuckMcM wrote: post #22
i336_ wrote: post #13

Earlier quoted context omitted.

_Wow_, that is truly impressive. $3.7k for a ~2x1.5m² RGB (!!) display - and no added costs (besides a like 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 watc…

The interface is this: "on/off", "line selectx4", "clock", "latch", "R", "G", and "B". 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…

After staring at that repo for a bit (my understanding of C is minimal, and I've never done any embedded work although I definitely want to) I finally got the "OH, the six set_pin() calls are R, G, B for two sets of rows on two panels" (in clock_two_rows()) it kinda clicked and made sense.

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?

Re: Oldskool Demo on a 7 Segment Display

#25

Post by ChuckMcM »

i336_ wrote: post #24
ChuckMcM wrote: post #22

Earlier quoted context omitted.

The interface is this: "on/off", "line selectx4", "clock", "latch", "R", "G", and "B". 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…

After staring at that repo for a bit (my understanding of C is minimal, and I've never done any embedded work although I definitely want to) I finally got the "OH, the six set_pin() calls are R, G, B for two sets of rows on two panels" (in clock_two_rows()) it kinda clicked and made sense. 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…

You don't need assembly, you just need a common "sync" line where all the computers start at a given point.

Re: Oldskool Demo on a 7 Segment Display

#26

Post by i336_ »

ChuckMcM wrote: post #25
i336_ wrote: post #24

Earlier quoted context omitted.

After staring at that repo for a bit (my understanding of C is minimal, and I've never done any embedded work although I definitely want to) I finally got the "OH, the six set_pin() calls are R, G, B for two sets of rows on two panels" (in clock_two_rows()) it kinda clicked and made sense. 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…

You don't need assembly, you just need a common "sync" line where all the computers start at a given point.

Right. That makes sense.

I haven't fully mentally appropriated how far embedded computing has come. I would have solved this by counting instruction lengths :)

Re: Oldskool Demo on a 7 Segment Display

#27

Post by waveydavey »

userbinator wrote: post #10

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"…

Trying to understand his code. It looks like B and C's mask constants are correct. Look at the pixel map, B and C are the only segments with a pixel offset. His 'bittest' is a cast to bool!? anything not 0 becomes 255 to mask against the seg bit? Strange. Surely there's a case with something like this to unroll loops to simplify
Post reply on HN