Project Logs

Collapse

• Dead-bugging the HT16K33

  Stephen Holdaway • 04/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:

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

  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:

  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:
  

  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:
  

  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 Holdaway • 04/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.

  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 Holdaway • 12/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:

  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:

  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 Holdaway • 11/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.
  

  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.

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

  Stephen Holdaway • 11/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:

  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:

• Enclosure complete

  Stephen Holdaway • 11/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 Holdaway • 11/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 Holdaway • 05/22/2017 at 10:34 • 3 comments

  Preface

  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 Holdaway • 02/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 Holdaway • 02/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