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.
Details
Road map
Done
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?
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:
Create a new driver that uses descrete FETs to sink the digit current.
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!
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 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.
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.
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:
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.
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:
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.
Also:
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:
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:
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.
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).
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!
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.
It became clear pretty quickly that 340 x 40mm isn't a whole lot of space for PCB layout when there are 234 through-holes spread evenly across your board.
Since KiCAD requires some manual prodding to create multiple boards from a single schematic, I had a play with putting all the components on one double-sided board before breaking the project into multiple boards. A bit of fiddling confirmed that both the control and display boards are too complex to route singled sided (without some trickery and a lot of time), so the display board will be a single PCB that I'll have manufactered by a fab house instead of doing it myself.
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.
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 👍
Stephen Holdaway
Christopher Kratz
techav
sjm4306
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.
BobH