Time Circuits Timepiece

A practical-size, Back to the Future themed digital clock mimicking the "Present Time" portion of the DeLorean's time circuit displays.

Similar projects worth following
Back to the Future time circuits are a bit over done around the internet, but my desk could really do with a functional tribute to the trilogy. Let's make a nice digital timepiece.

- It should tell the time
- It should automatically know the time using some reliable source (GPS time or NTP over WiFi)
- It may have an annoying alarm

Bonus points:

- Use the year segments to display something more useful on a cycle: temperature, humidity, or perhaps a terrible rendition of the game Snake.

Road map


  • Design and build an enclosure reminiscent of a single section/row of the time circuits
  • Cap open ends and access ports on the enclosure with 3D printed parts
  • Source material for display covers (transparent perspex/acrylic)
  • Create a schematic for the electronics (botched v1)
  • Design PCB layout(s). (botched v1)
  • Manufacture PCBs (botched v1)
  • 3D print mounts to slot into the enclosure and hold PCBs in place
  • Fit display covers to enclosure
  • Redesign schematic and PCB after messing up the first version
  • PCB v2 away to a fab
  • Assemble display board v2
  • Debug brightness issues

In progress

  • Write display driver firmware (STM8S)

To do

  • Develop firmware for control board
  • Use GPS to set time automatically and prevent drift.
    (Alternatively, use WiFi + NTP)
  • Future: Design a v3 board with a driver capable of delivering 2A continuously?

See the Project Log for further details.

Do not use: OBSELETE AND BROKEN - Kicad schematic and PCB layout at v2

Zip Archive - 1.98 MB - 11/27/2018 at 11:31



DWG format drawing for milling the enclosure

DWG Drawing - 148.89 kB - 02/28/2017 at 10:13



Drawing for milling the enclosure

Adobe Portable Document Format - 61.92 kB - 02/28/2017 at 10:13


BTTF Clock.step

STEP file for the enclosure exported from Autodesk Fusion 360.

step - 237.45 kB - 02/28/2017 at 10:06


BTTF Clock.f3d

Autodesk Fusion 360 model archive (source) for the enclosure

f3d - 568.25 kB - 02/28/2017 at 10:05


  • 1 × 360mm x 1" x 2" galvanised rectangle hollow section (RHS) The stock I found has 1.6mm walls
  • 13 × 0.8" 16 or 14 segment common cathode display I used the green KingBright PSA08-11GWA
  • 1 × DS3231 RTC (or any other RTC module if you're using your own controller setup)
  • 4 × 3mm green LED These are for the AM/PM indicators and time separator
  • 2 × TPIC6B595D power shift register Common cathode digit sinks

View all 11 components

  • Dead-bugging the HT16K33

    Stephen Holdaway04/16/2020 at 23:28 2 comments

    Another year has gone by with this project waiting quietly in the bookshelf. It's time to finish it off.

    The Holtek HT16K33 LED driver IC was brought to my attention in the last year, and it looks ideal for driving 16 segment displays: a 16 x 8 common-cathode driver controlled over I2C. The chip was released around 2010, but isn't (currently) listed by any US-based distributors. If I'd known about this chip at the start of the project, we would've been done and dusted years ago on the first PCB revision!

    Re-spinning the display PCB is off the table as I've already spent way more than I wanted to on PCBs for this project. The current revision is still useful for mounting and connecting segments, but I'm going to need to dead-bug some HT16K33 chips as none of the footprints on the board can accommodate its 28-pin package. To drive the whole display I'll need two HT16K33 drivers.

    Initial testing

    To check the performance of the HT16K33 against the existing driver circuit, I borrowed 6 digits from the original assembly and wired a them along with a single HT16K33 to an unpopulated PCB. Desoldering all those digits is considerably easier now I have a proper desoldering gun, but it's still 208 joints for the whole display so takes a while.

    With some I2C communication hacked into the existing STM8S firmware, I was able to do a side-by-side comparison with the original driver assembly.

    When multiplexing only 7 digits, my original driver is a little dimmer than the HT16K33, but still passable:

    Custom driver powering 6 digits compared to HT16K33 driven segments
    Custom driver multiplexing 7 digits (top) compared to HT16K33 driven segments (bottom)

    When multiplexing 13 digits however, my design is barely bright enough to read, which is the problem the last few project logs have discussed:

    Custom driver powering 13 segments compared to HT16K33 driven segments
    Custom driver multiplexing 13 digits (top) compared to HT16K33 driven segments (bottom)

    The HT16K33 retains the brightness shown here across a full 8 digits per chip, so it's a much better solution for this project. It won't be pretty having two dead-bugged chips on the board, but it will at least make this a functional display for use in daylight.

    Hacking in the new drivers

    Each HT16K33 is attached to the PCB dead-bug style with double-sided tape, then 26 point-to-point connections need to be made per chip. To help with wiring upside-down, I copied the pinout diagram from the datasheet and mirrored it so it matched my view:

    ht16k33 pinout mirrored

    On top of the point-to-point wiring, I needed to fit in two 4.7K pull-up resistors for the I2C bus, plus a diode and resistor to set the I2C address on one of the chips:

    Schematic from HT16K33 datasheet showing wiring for address configuration

    To avoid a tangled mess of through-hole components, I hand-drew a little mask for a circuit with 1206 size components and etched that. This was fairly quick as getting a good copper mask using a photo-resist tends to be the most time consuming part of making boards at home:

    Home made hand-masked tiny PCB

    With all of that in place, this rather extensive bodge is complete:

    Next up: completing the firmware to use this display as a clock. I won't leave this running all of the time as I already have a few clock projects running in my small apartment, but it'll make a nice show-piece.

  • We need more power!

    Stephen Holdaway04/03/2019 at 08:54 3 comments

    This board has been sitting on my desk for a couple of months since assembly, waiting for some debugging attention to sort out its low brightness and hot running. I finally got around to it today, prompted by someone showing interest in the build. I've been putting off debugging it because I had mentally tagged this as an unknown, probably hard electrical problem, but it turned out to be fairly straight forward.

    After a couple of hours of hacking in a separate drive voltage for the display segments and some fiddling, the problem basically comes down to the power that can be sunk into the pair of TPIC6B595 shift registers used to select the active digit. Doing some back of the envelope math that I really should've done earlier, if every segment is on at the ideal drive current of 20mA, that requires:

            [16 segments] x [20mA] x [13 digits] = 4.1 Amps

    In a more typical scenario where an average of half the segments are on, that still requires 2A to drive. The datasheet for the TPIC6B595 power shift registers states that each one has an absolute max sink capability of 500mA. In practice, sinking even 250mA into each one on this board makes them too hot to touch. There wasn't much room for the ground plane with via stiching that the datasheet recommends to pull heat away from the chips, so that doesn't help the situation.

    A bit of trace cutting and bodge soldering further demonstrated this power bottleneck for me. Boosting the supply voltage for the LED drivers between 6V and 12V gained a small amount of brightness, but made the TPICs scorching hot as they needed to sink 5+ Watts at the higher voltage. After removing the fairly low-value resistors I had on the LED driver current control pins (Rext) to increase the pulsed current from 20mA to around 60mA (in theory), changing the voltage had no impact on brightness.

    I'm not entirely sure why the LED drivers aren't delivering more current even when configured to drive 60mA, but I suspect the TPIC chips' thermal regulation mentioned in the datasheet is preventing sinking too much current. Trying to drive a segment across 13 digits with the 30mA being delivered doesn't give a bright display as it's equivalent to driving a single segment with only 1.5mA.

    Where to now?

    There are two design options I see going forward from here:

    1. Create a new driver that uses descrete FETs to sink the digit current. 
    2. Split the driving into two sections that each drive up to 7 digits. The display is an ok(-ish) brightness when the currently available power is used to drive half the digits instead of all 13.

    Option two isn't ideal as it would be still be limited by the TPIC's capacity to sink, wouldn't be blazingly bright, and would require a duplicate of the segment shift registers, LED drivers and current setting resistors which adds 40+ components.

    More useful brightness in daylight when driving only 7 instead of 13 digits

    A third option would be to complete this project with the rev 2 board as a toy since I already have a digital clock in the appartment that's running all the time. I still like the idea of making a daylight-visible version of this project, but also on my mind is that it will likely cost $10 - 20 NZD each year in power alone to run a brighter version of it 24/7..

    Regardless of the solution for the driver, any further revision is definitely going to involve a display board that simply exposes the segment and digit pins through a pin header. That big board is expensive, and it needs to be reusable! I was on the fence with this for rev 2 and ended up thinking "I've got it this time" so didn't bother. I did not in fact "have it this time". Not going to make that mistake again!

  • It works, but needs improvement

    Stephen Holdaway12/01/2018 at 23:44 0 comments

    After a few more evenings with this project, it's technically working, but the display isn't as bright as I'd like.

    Here's a quick update in photos:

    The rest of the assembly went smoothly.
    The display controller was programmed to multiplex through all of the digits with all segments enabled. After testing all segments were driving correctly with a loose LED, I soldered in the first digit.
    All digits soldered in!
    Programmed the display controller to output a fixed string to test the mapping from char to segments was working correctly.

    Making it brighter

    The display looks pretty bright in the above photos, but that's mostly from dim ambient light combined and the camera's ISO ramped up to compensate. Under daylight indoors, it looks more like this which isn't ideal:

    The digits are lit one at a time with all of their configured segments, making  the duty cycle around 1/13. The display is a good brightness when driving 4-6 digits only, and the segments are plenty bright when not multiplexed, so the dimness is definitely multiplexing related.

    The optional external resistor on each LED driver IC allows configuration of up to 60mA driving current, instead of the default 20mA. Chucking in some low value resistors to get the LED drivers to 60mA did help a little, though the segments are unevenly lit now as I only had "10%" tolerance resistors lying around:

    Testing higher drive current (note the uneven segment brightness)

    With this higher current demand, I also had to chuck on a bunch of extra capacitors:

    I'll keep working away at this as I'd really like the display to be brightly visible indoors during the day (not in direct sunlight, just bright ambient light).

    Increasing the voltage supplied to the LED drivers would work very well to solve this, but this doesn't seem feasible due how I'm controlling the LED drivers; since the 5V is supplied for the "segment off "state rather than the pin going high-Z, the LED driver would turn on in the off state (current can sink from the >5V supply into the 5V being supplied). I tested this on the bench with a loose driver IC, and it turns on even with +Vs at 6V and GND at 5V.

    If I can't find another solution, I may be tempted to hack the two spare TPIC power shift registers I have into the place of the 74HC595D's so this higher drive voltage for the LEDs would work...bit of a last resort bodge to do that though.

  • Rev 2 initial bring-up

    Stephen Holdaway11/27/2018 at 11:07 0 comments

    Rev 2 boards arrived yesterday. This was my first order from JLCPCB, and the PCBs seem to be decent quality. Shipping time to New Zealand was excellent at just 3 days! I've previously used SeeedStudio, but their shipping charge was extortionate at $60 USD for this order, so I figured I'd try JLC.

    New board from JLCPCB
    JLCPCB board close up

    Working in the smallest blocks possible, I first attached the STM8S chip and a few capacitors to verify the micro could be programmed on the board. Immediately had to troubleshoot a short across VCC and GND which turned out to be a dead 0602 capacitor - I'd apparently overheated it with hot air. Switched to using the soldering iron, replaced the capacitor, and the programmer could write to the chip fine:

    It's nice that the STM8 chips don't require any external components to test. Their reset circuitry is internal, and aside from a couple of capacitors there's nothing you can really miss that will prevent it from working.

    STM8 mounted on PCB

    Next I added the minimum components needed to control a single segment: one each type of shift register, a bunch of passives and one of the LED driver chips.

    I hadn't pre-written any code for this driver, but after about an hour with the help of a logic analyser to help me spot stupid late night mistakes, I had control of a single segment on 8 digits:

    DSView: pushing into two shift registers with a shared data line

    It's certainly nice to know that nothing fundamental is messed up, though I did spot a silkscreen error I missed: One of the segment names by one of the LED drivers is "M" instead of "N".

    Taking a lesson from rev 1, I won't be soldering any of the 16 segment displays until I've verified the board is completely working. De-soldering a dozen 16 segment displays was a particularly unpleasant experience and it's not a process I want to repeat again.

    Next step is to add the remaining segment drivers and confirm that's working, then add the remaining components outside of the main driver: AM, PM and time-separator drivers, the buzzer and pin headers.

  • PCB Revision 2: "Let's make one that works this time"

    Stephen Holdaway11/18/2018 at 03:52 3 comments

    After letting this project rest for a good 15 months (with occasional tinkering), I've picked it up over a weekend, verified the new schematic with its shift-register + LED driver configuration to drive the common-cathode 16-segment displays is sane, and completed the layout for the new board.

    Since the last update I posted here, the main changes have been:

    • A 20 pin STM8S microcontroller is now on the board to manage the display. This is probably overkill, but I have a bunch of these parts lying around, so figured I'd use one.
    • The shift registers controlling the segments have been replaced with 74HC595Ds, since these don't need to sink much current. Digits are still sunk by the more expensive TPIC6B595Ds, since these need to handle up to 400mA when all segments in a digit are on.

    I was unsure all of the driver circuitry was going to fit on in the limited space there is around through-holes, but managed to get it all in:

    Time Circuits PCB layout

    Coming back to this project fresh also let me pick up a few mistakes:

    The two PORTB pins on the STM8S003F3 are "true open-drain" pins that don't have the ability to run in push-pull mode (ie. source current).

    I've added high value pull-ups to both of these pins so they can drive logic levels.

    The 74HC595s enable each segment's LED driver by sinking its GND pin, but will provide +5V to this pin when not sinking, rather than being high-Z.

    Applying 5V to GND shouldn't be an issue unless the driver's +Vs sags or there are spikes on its GND at +5V that create a significant reverse voltage. The BCR402W datasheet states an absolute maximum rating of 0.5V reverse on any terminal, but in practice I've seen no adverse effects testing this on the bench for 30 mins at 5V reversed (which is 10x the reverse voltage than I'd expect to see in this circuit). With reversed polarity I can't detect any current until 9.63V, where 50 nA flows, and at 32V only 1 mA flows.

    If this diagram in the BCR402W datasheet is actually representative of its internals, the reverse voltage tolerance of GND to +Vs should be greater than 0.5V - probably limited by the emitter-base breakdown voltage of the PNP transistor (typically around 5V). I'm fairly confident these aren't going to explode suddenly from small excursions past the 0.5V limit in the datasheet, but if segments begin to quit I'll have a possible culprit.


    • The NPN BJT on the buzzer was wired up as PNP in the original layout.
    • Segments 11, 12 and 13 were misaligned vertically by 0.5mm in the original layout.

    The rev 2 schematic now looks like this:

    Time Circuit Schematic

    After another round of checks, I'll send this off to the fab!

    If I've screwed something up this time around, it should hopefully be possible to bodge, unlike the previous disaster.

    Edit: I made some last-minute mistakes on the silkscreen which I picked up after ordering, but fortunately I'd made a typo in the fab's submission form, so they rejected the order. The submitted board now looks a bit tidier:

  • Enclosure complete

    Stephen Holdaway11/04/2017 at 00:25 0 comments

    This case has been watching me from above my desk, 90% complete, for the last 8 months. I sat down last night with a craft-knife, Dremel and sandpaper to finish it off:

    The display windows/covers are 2mm thick transparent black acrylic, cut and shaped by hand and friction-fit into the milled chassis. These were cut to their rough size by scoring the acrylic and snapping against a hard edge, then refined with 180 and 320 grit sand paper to have a tight fit in each dimension. The corners were then rounded gradually to the right fillet by rotating each corner against a spinning sandpaper bit mounted in a Dremel:

    Once the corners matched the slot they were filling, each cover was encouraged with a cloth-covered hammer to seat in its slot. Repeated tapping with a hard object didn't cause any of the covers to shatter when seating, though the shocks going through the case did cause a chip on one of the already mounted covers. Not too noticeable...just adds a bit of character:

    If any of the covers do end up shattering, I have enough spare acrylic to fix a few of them anyway.

    I originally ordered some 3mm tinted polycarbonate cut to shape in February to use for these display covers, however this ended up being too transparent to obscure unlit segments from view. 3mm was also too thick for this material, causing noticeable refraction when viewing the display off-axis.

  • Driving 16-Segment Displays (let's try this again)

    Stephen Holdaway11/01/2017 at 11:42 1 comment

    After failing fairly fundamentally in my first attempt to drive 16-segment displays with 7-segment drivers, I've gone back to the drawing board.

    Monolithic 16 or 14 segment drivers?

    The MAX7291/MAX7221 7-segment drivers *can* be used to drive 14 or 16 segment displays (per this application note), but it's a bit of a hack. To pull it off I'd need 8x MAX7221 for this application (4 digits per pair of ICs), and would still need to dedicate processor time to constantly alternating shutdown of each pair of drivers. Not really ideal or practical.

    Dedicated ICs for driving 14 or 16 segment common-cathode displays seem pretty rare as far as I can tell. Maybe there's a lack of demand for them these days, considering there's many other smaller, cheaper and better display technologies available. Maxim have their MAX6954 16-segment driver, but at $30 NZD a pop at the time of writing and requiring two of them for this application, they're too expensive.

    There are plenty of monolithic, multi-channel LED driver chips available, though these are mostly (if not all) designed as current sinks rather than high-side drivers: they'll only work with common-anode displays. The 16-segment displays I have are common-cathode, so as convenient as these drivers would be, they're not an option for this project.

    I would say "do more research before getting excited and buying parts", but I'm actually glad I picked up the 16-segment digits when I did. The Kingbright PSC08-11GWAs were just under a buck each (NZD) at the end of 2016, and they're now almost $4 each. As with dedicated segment driver ICs, there just doesn't appear to be a demand for 16-segment displays like these. To be fair, I've only once noticed a 16-segment display in the wild in all of the last year, and it was in an elevator in Montreal. Not sure how old the building was.

    Keeping things discrete

    With a reasonably priced monolithic solution unavailable (and committed to using common-cathode displays), I'm going to take a shot at building a custom driver circuit with discrete components.

    At the moment I'm eying up:

    • 20x BCR402W constant current, high-side LED drivers (16 segments, 1 decimal point, time separator and AM/PM indicators).
    • 4x TPIC6B595 power shift registers to control current sinking and enabling 16 of the BCR402W drivers.

    The low-volume cost of buying these components is around $15 NZD.

    Two of the TPIC6B595s would be daisy-chained for clocking through the 13 ground pins of the digits. The other two TPICs would be daisy-chained to control segment illumination:

    Using these power shift registers to sink the BCR402W ground (control) pins is complete overkill due to their tiny current requirement, but this setup frees up 12 MCU pins over controlling the segments directly from the MCU, and it's not introducing extra components. Alternatives are:

    • use a MCU with more pins and control the LED drivers directly; or
    • use a simpler LED driver (eg. NSI45020AT1G) + shift register(s) + 16 MOSFETs or BJTs + support passives; or
    • use an I/O expander to free up pins on the MCU. This looks like an interesting solution, though I'd prefer not to using SPI or I2C for this (seems like it would be introducing unnecessary complexity).

    What would you do?

  • A mildly expensive lesson about making small prototypes

    Stephen Holdaway05/22/2017 at 10:34 3 comments


    I don't think I mentioned it in any previous project log, but this was my first go at sending a PCB to be manufactured at a fab house. Given that the order was $40 USD, I was a little nervous that some mistake in my schematic or layout would render the boards completely useless.

    PCB arrival

    The boards I ordered from Seeed Studio late February arrived on March 20 - two months ago now. I had been waiting a month for these to arrive from the time I ordered, so I was pretty excited to get a board up and going when they arrived!

    Read more »

  • Display filter preview

    Stephen Holdaway02/28/2017 at 10:33 0 comments

    I've ordered some 3mm grey tinted polycarbonate cut to shape, which should arrive tomorrow. In the meantime, here's an experiment using 2mm transparent black/grey acrylic, cut to size by hand and sanded to shape with sandpaper and the help of dremel with a sanding bit.

    This is going to look awesome.

  • PCB renders

    Stephen Holdaway02/26/2017 at 00:25 0 comments

    To celebrate sending these layouts off to a fab house, here are some renders:

    (The pin header for the control board faces the wrong way in these renders, but it lines up correctly with the control board pins)

View all 15 project logs

Enjoy this project?



Andrew wrote 12/27/2022 at 06:41 point

Thanks for the inspiration on this. I rolled my own version of this using the ht16k33 modules driven by an esp32-s2 and an mp3 module for some sounds. One of my quickest project builds! Came together beautifully but I manually wired all of the dispaly modules mounted in a 3d printed frame. Super bright, average current about 200ma.

  Are you sure? yes | no

Tim wrote 04/16/2020 at 14:14 point

Hi - just came across this interesting project.  I noticed the V1 Kicad file ( is marked obsolete, but V2 files are not present.  (I'm assuming rev2 means V1 rev2, and if V2 had been uploaded, the Obsolete tag would have been deleted) 

  Are you sure? yes | no

Stephen Holdaway wrote 04/16/2020 at 23:46 point

Hi Tim,

That zip is the V2.0 board shown in the latest project logs if you're interested in inspecting it closer - sorry about the confusing naming. I've marked that as obsolete to discourage people from building it as the display driver design does not work well and is fairly dim (as noted in the last few logs).

I've just published a project log I had in draft about dead-bugging a better dirver into the existing PCB:

I may update the kicad schematic and layout to use this better driver, but I won't be sending it to fab myself so would only do that if people are interested in making their own without touching the layout and schematic.

  Are you sure? yes | no

Bharbour wrote 11/01/2017 at 17:20 point

A trick that I have used in the past for driving a lot of segments is to make my own shift register with 74HC374 octal D latches. When I did it, I implemented it as a SPI type interface, with a separate shift register and holding register which doubles the number of chips required. Instead, just blank the displays while shifting because the shift time is so small. This would let you skip the hold register. The 74HC374 chips can sink or source 20mA or so for each bit. Use a small N Channel MOSFET with the source pin grounded for the common cathode pins and just use the '374 pins driving the display anodes through current limiting resistors. You would still need to do the digit to segment conversion and handle the digit muxing in software.

The 74HC374 is an octal D type flip flop chip. There are 8 D type flip flops on a common clock and reset line. To turn this into a shift register, use the D1 input as the chip data in and tie Q1 to D2, Q2 to D3... to drive the next chip, connect it's D1 input to the previous Q8 output. Each segment or cathode ckt gets driven off the Qn outputs. My apologies if this is something you already understand.

When I did this, it was controlling 24 segments and it worked well. As many segments as you need to handle, it might just be simpler or cheaper to use the integrated driver chips you mentioned, but this trick is worth looking at. If you need more detail on this let me know.


  Are you sure? yes | no

Stephen Holdaway wrote 11/02/2017 at 03:41 point

Thanks, that's really useful to know! I was casting around for more basic shift registers than the TPIC6B595 that could sink current, so that's perfect. Digging around a bit, the 74HC595 will do the same job but has the shift and store functionality out of the box (and it's only slightly more expensive than the 74HC374). I'll pick a few DIP packages up locally and have a play 👍

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates