Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In fact, this is one of the central design points he mentions within the first two lines of TFA: no point in a clock with a milliseconds place if it doesn’t display each millisecond legibly.

> Summary

The specifications for the clock were as follows:

* Millisecond precision, with no perceptible jitter

* Display clearly, without flicker, when filmed at very high framerates (20,000fps or more). The brightness should still automatically adjust, of course, and without the use of PWM



This reminded me how in Japan, 700 people were rushed to the hospital after watching pokemon on TV [1] due to 12Hz red/blue flashing frames, but now I understand that’s not the case here.

[1] https://www.neurology-asia.org/articles/19991_001.pdf


I’m guessing you’ve already realized this, but in case it helps clarify things for someone else:

The signals rates mentioned in the article are with respect to how frequently the segments are updated, not the brightness. (With the one exception being the colons being PWM controlled, IIRC).

PWM means Pulse Width Modulation. Controlling a (perceived) light intensity of an LED via PWM means (if we pretend for the sake of simplification that the voltage rise and fall is instantaneous, etc) quickly turning the LED fully on and fully off, varying the duty cycle to achieve the desired perceived brightness. This project avoids the flickering inherent with PWM by not using PWM: the voltage itself is set to some fixed value for a given target brightness.

(If one then wonders why this wouldn’t be the default approach for such things: microcontrollers often provide a built in means for PWM output, but it’s less common to have built in true, non-PWM analog outputs, requiring additional parts (thus more cost, more complexity) to implement variable voltage control).


Thank you for your time to explaining this. Really appreciated.


I’m missing the part where he succeeded at that. In the demo I just see #88 the entire time.


Look at later in the video: https://youtu.be/XL2cZjO5IUY?t=370


Ah. I believe the “correct” solution is you record at high speed and down sample for the big screen in order to avoid the motion blur. There are a couple scenes before he gets to the real high speed where he’s showing the clock slowed to 1/10 speed at which point the 100ths place is only a little slow to update. I’m still seeing some alpha nerd room for making the LEDs tick over faster. Maybe the Mark V.


Interesting, that makes sense as a way to depict individual numerals. But even at film/screen framerates, isn’t the basic motion picture idea that you’d get an illusion of continuity? The digits would flicker but the overall effect would still be something of a blur?

I have to imagine that, as his 20,000fps-or-whatever example demonstrates, you’d run into exposure challenges at speeds fast enough to capture individual digits on this particular clock




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: