By now it might seem like there’s no new way to build a binary clock. It’s one of the first projects many build to try out their first soldering irons, so it’s a well-traveled path. Every now and then, however, there’s a binary clock that takes a different approach, much like [Stephen]’s latest project which he calls the byte clock.
The clock works by dividing the 24-hour day into half and using an LED to represent this division, which coincidentally works out to representing AM or PM. The day is divided in half over and over again, with each division getting its own LED. In order to use this method to get one-second resolution it would need 16 LEDs, but since that much resolution isn’t too important for a general-use clock, [Stephen] reduced this to eight.
Additionally, since we’re in the Internet age, the clock has built-in WiFi courtesy of a small version of Python called WiPy which runs on its own microcontroller. A real-time clock rounds out the build and makes sure the clock is as accurate as possible. Of course an RTC might not have the accuracy as some other clocks, but for this application it certainly gets the job done.
WiPy is the name of the board – it uses micropython. The WiPY is an ESP32 platform
Time for a “useless clock contest” maybe? How about a clock that counts from 0 to 65536 during the day (so each count is a little slower than a second) and shows the bits in Gray code?
Or if we’re doing Wifi, a clock with a Wifi access point that changes its SSID to the current time every minute (second?) :)
I have a plan to do exactly that (count 0-65535), but show the result in hex on a seven-segment LED display. Each ‘tick’ is about 1.3 seconds.
Nifty project and a great write-up.
Practical or not, it’s always interesting to see a unique approach to a common task.
Appreciate the approach. Very thoughtful of adding the LEDs according to the required resolution.
I like how the clock measures time “in binary” in the sense of being all about halves. It would be very interesting to think of the day in halves, quarters, eigths, sixteenths. These may actually be very human timescales.
Of course, you never know until you try. But it’s a simple enough project that I bet it would only take a sixteenth to build something up.
Hate to be a stickler, but one second resolution requires 17 bits. This is why DOS only tracked files to two second resolution.
True that! Never thought about why but its totally obvious now I think about it!
It’s a binary clock in the exact same way every other binary clock is, the only difference being it chooses to count not seconds or minutes, but abstract units equalling 337.5 seconds, that happen to total 24 hours when you add up 256 of them. For me that puts this on a novel vs. useless scale very, very close to the latter.