Keith's Electronics Blog

Circuit Layout

The same time alone in the car solidified my thinking about the bus architecture I want to use to get the control lines from the microcontroller to the 16-channel LED drivers.

Each digit of the clock will have 28 LEDs, plus two for inter-digit colon and one for decimal point; hence 32 channels / two driver chips per digit. Probably six of those banks in the whole clock, for HH:MM:SS or MM:SS.TH, depending on the operating mode.

I’ve settled on this plan: Each digit will be independently addressed. The two A6276 chips within each digit will be chained together in serial, but all the different digits will fan out in parallel. That means strobing 32 bits of font data for every character change, which is (1) the minimum required, because that’s how many it takes to change the data anyway; and (2) a nice maximum, compared to strobing all 192 every time.

Here’s where it gets fun, and where my time spent growing up studying 8-bit microprocessor circuits pays off. It takes three lines (data, clock, and latch) to operate a series-chain of 6276es, so at first glance this plan looks like an 18-line architecture; and that’s more pins than I have available on the PIC18F2322 LogoChip.

But the way the drivers work, it doesn’t matter what’s in the serial-in buffer until you enable the latch to that chip, which captures the serial-input buffer it into the parallel-output buffer. Ergo use a single data/clock output pair from the LogoChip to all the characters at once, and only use six separate lines for the latch controls. Yeah, it seems a little odd to deliberately shift meaningless data into all the chips all the time, but there’s really no harm in it. Tee-hee.

It boils down to having a system-wide data bus with enable lines to select which chip listens, which is how every multichip computer (even the ones old enough for me to comprehend their design ) is built.

I’m even going to be a good boy and check the fanout, to make sure the LogoChip can drive that many 6276 inputs (or whether I’ll need to interject a buffer).

Board Layout

I’d like to start drawing out the circuit in EAGLE, but it doesn’t have a library entry for the 6276, and I haven’t checked on the DS1302 and DS1340 yet. I’ll probably have to design symbols for them.

Another set of questions revolves around whether the entire display will be a single ~2″ x ~12″ PCB, or a set of adjacent smaller PCBs that tie together. I kind of like the aesthetics of a single PCB; I kind of like the maintainability of smaller PCBs that permit swapping out single digits if LEDs fail, which gets the clock running again quickly. Hm, if I did do that, I’d want some kind of test harness that was ready and waiting to plug in and drive the lone digits.

Either way, I picture laying out the board as individual modules, with a control bus that extends across the entire width. Then the design isn’t dependent on the decision, and we can make it pretty late in the process.

One other consideration is manufacturing the PCB. I had assumed I’d use EAGLE; but of course the free version only edits boards up to about 3″ x 4″, which wouldn’t be nearly big enough for the full board. Maybe it’s time to learn to use FreePCB, which has always been my plan for laying out larger boards.

Also, I assume I’ll hand-draw and hand-etch the board rather than have it produced commercially, and my friend Joel’s drilling machine only has a travel of about 12″. If the display board is monolithic, I might have to produce drill files such that I could drill half the length of the board, flip it end for end, and drill the other half. I obviously wouldn’t get perfect alignment, but I think I could get close enough to be satisfied. It’s still a significant extra hassle, as is coming up with a much larger etching tank than the plastic case I’m currently using.

Ultimately, though, I want to make as many decisions as possible based on what’s right for the project, not what’s easiest to get away with. I don’t feel bad about DIY frosting the narrow-angle clear LEDs, because I think the result is about the same. But that’s not true of the difference between a single long board and a bunch of plug-in modules, whichever way we decide would be better.

I’m starting to gather parts to prototype the blue LED clock.

LED Drivers

I ordered four samples of the Allegro Microdevices A6276 constant current 16-LED driver chip that I want to use to run the display. I didn’t care whether I got traditional or lead-free; but due to availability and the way their sample fulfillment process works, they’ve sent me four lead-free and will send me four traditional when they restock their samples. Cool.

LEDs

I’ve purchased 500 blue LEDs (10,000 mcd) on eBay from Best Hong Kong for $50.35 with free shipping and free resistors.

I haven’t figured out their pricing scheme, other than arbitrary. On their web site, these LEDs (AFAICT) are $.18 each, or $90 for 500; on eBay, they were $50, with a Best Offer option that suggests they’re willing to negotiate even further. That suggestion seems to be incorrect, though–they gave no response whatsoever to my two offers and my ask seller a question.

The LEDs have a 20° viewing angle, which is too narrow. Jeremy and I tested some of my Phillips LEDs, and they’re so directional we’re afraid we might not be able to see both ends of the clock from the same viewing position. However, I scuffed one up with 1500-grit sandpaper, and it looked fantastic–a very uniform brightness from a wide range of viewing angles. Yes, it’d be nice to just buy frosted ones, but I can’t find them in the quantity I need for anywhere near the price. I expect I’ll dedicate a buffing wheel to being a scuffing wheel when the LEDs arrive.

Timekeeping

I had several hours to myself in the car in the last couple of days, and did some thinking about timekeeping and battery backup. As much as I’d enjoy programming timekeeping functionality in the LogoChip, I shudder to think of dealing with backup during power loss.

I could take a reference timekeeping source from the 60Hz line supply like consumer alarm clocks, but then I’d have to switch to the internal oscillator for timekeeping when the clock was unplugged. To do that with any more accuracy than my alarm clock, I should compare the oscillator to the line frequency during normal operation and record the actual number of oscillator cycles per period. Add in dealing with battery changes–and do you have to recalibrate from scratch if you do lose all power? Or add a 1-bit NVRAM chip to the design? All of that’s doable, but ecchhh. I’ve started thinking about using an external real-time clock (RTC).

I have an old Dallas NVRAM/timekeeper DIP (probably lots of them, actually), which provided RTC functionality for 8088-vintage computers. Unfortunately, it’s made to work with a microprocessor and has 8-bit and wider address and data buses, registers, etc. Way too many pins to work with a small microcontroller, when I already have other pins to deal with to drive the LEDs.

Google on “real time clock” integrated circuit led me via Wikipedia to Maxim/Dallas. I feel like I’m starting to get a clue about browsing manufacturer’s offerings–after looking up their 1309, I visited related products and found the DS1340 I²C RTC with integral trickle controller to recharge the backup battery, and the DS1302 RTC with trickle-charge and a simple three-wire serial interface. I ordered samples of the DS1340C SOIC with internal 32KHz crystal, the DS1302 DIP, and (bless Maxim!) the external crystal for the 1302.

Allegro LED Drivers

I ordered a handful of A6276 16-bit LED driver sample chips Friday. If you look closely at the construction of the CK-3000, you can see that they effectively use three LEDs in a row for each segment of a seven-segment display. That makes a total of 21 LEDs in a digit, plus 2 for an inter-digit colon and 1 for a decimal point, for a grand total of at most 24 per digit. Sounds like a 16-bit driver plus an 8-bit driver, or sharing three 16-bit drivers across two digits.

Font Decisions

So if the LEDs are just grouped in threes to make up a seven-segment display, why not use a seven-segment display driver and save the hassle of a 24-bit driver? Because I’m utterly enamored of the idea of making the digits as perfect as possible within a 5×9 matrix. So when it’s time to make a 3, I don’t want to do this: I want to do this:

I drew up three sets of fonts to represent different LED-driving strategies.

The first font is what you get by driving each strip of three LEDs as a segment in a seven-segment display–all three in each strip are on or off at the same time. (I assume this is how the CK-3000 works.) This would take 21 LEDs and seven drivers for each digit. To me, this looks even worse than a standard seven-segment display, because the corners are missing. Normal seven-segment displays have the segments “mitered” into the corners, but this has a gap in each corner.

The second font is what you could get using the same LEDs, but with a separate driver line for each LED. It still has 21 LEDs, but each LED can now be controlled independently.

With independent control of the LEDs, I was able to “round out” a couple of the digits–particularly the 3. I like the way the 3 looks, but the contrast between the good 3 and the bad 4–or between the top and bottom of the 2 and 5–makes this an even worse choice, in my opinion.

If I’m going to bother making a clock like this, I want it to be as close to perfect as possible. The third font uses more LEDs than the CK-3000: 28 LEDs, to be precise. It uses the original three LEDs for each of the seven segments, plus fills in each corner (see especially 4 and 7; as well as 1, 2, and 5) and the middle of each edge (see especially 0 and 1; as well as 4, 5, 6, 7, and 9).

Finally, it adds one extra LED inside the perimeter of the lower half to round the lower curve of the 2. It’s a small thing, but it transforms into .

Drivers Redux

We’re now up to 28 independently-controlled LEDs per digit, plus optionally two LEDs for colons and optionally an LED for a decimal point. At 31 total per digit, it sounds like two 16-bit LED driver chips per digit, or twelve to sixteen for the whole clock (depending on whether it has a hundredths display).

I’ve been thinking about how to connect the chips to the microcontroller. They’re serial-in chips, so at one extreme, I could string them all out in a giant line and shift all of the characters’ worth of data every time there’s any change. That means that every second, I’d be shifting out another 192 bits of data, which isn’t bad–just annoying. Or every centisecond, I’d be shifting out 256 bits, which is even more annoying.

At the other extreme, I could connect each character’s 32-bit (two-chip) driver to a separate set of pins on the microcontroller, so each character was individually addressable. Since each register needs a minimum of three signal lines to operate (serial data in, clock, and latch), that’d be eighteen signal lines coming out of the microcontroller–which I don’t have enough pins to do on the PIC18F2320, and I’d rather not have to use a PIC18F4320 just to have enough ports.

I could also split the display into smaller serial chunks–for instance, dividing between character pairs (HH : MM : SS) would only require nine signal lines. I could matrix the display, using a combination of source-selection and sink-selection to strobe each character’s worth of LEDs rapidly in sequence. And I could address the driver chips out of the microcontroller, to matrix on the logic side rather than power side; this would require demultiplexing and fiddling with their clock inputs, since the A672x chips don’t have enable inputs per se.

To keep parts count low, and for the sake of simplicity in the software, I’m actually leaning toward the all-serial solution. Yes, it spends a lot of time bit-banging LED data out the ports. But the trade-off is not having to add extra chips for matrixing, and not having to determine in software which characters need to be updated. The software can simply determine the current time and pump the whole thing out to the display.

Of course, I reserve the right to reconsider after I get the chips and start playing with them.

CK-3000

A few days ago, I ran across this custom PC case via the Make blog:

G-Gnome’s “WMD” Case Mod

Via
Build process, part I
Build process, part II

It’s an amazing piece of work–all hand-tooled metal, with lots and lots of polishing.

One thing that caught my attention was the clock display. It looked cool, I loved the way it used individual round LEDs as pixels instead of big segments and made the digits look rounder, and I wanted one. I read through the story. I found that the clock is the CK-3000 from Electronics USA. It’s $360.

That’s just crazy.

Design

Then two thing happened at about the same time. I emailed my friend Jeremy the links to the WMD PC case, and I started thinking about building my own clock as a backlash against the price tag on the CK-3000. Then I was talking to Jeremy about building an eye-searing blue LED model; and the next thing you know, we’re starting to discuss actual details.

Jeremy writes:

I’m mostly after a scary looking display (I realize red would be scarier, but I like blue). Being big(ger than a sane person would want a display) is part of that because something that big MUST be important, but it has to be a manageable size. 3 or 4 feet would probably be the limits for me to find a permanent spot to hang it in the computer room and smaller is not necessarily worse if we can get the feel of the thing right. Being ominous on its own is good, but it should definitely DO something. A regular clock would be bare minimum, a clock that freaks out and does a flashing doomsday 1 minute countdown every hour (or randomly… that would be scarier) would be the kind of thing I’m going for.

And I replied:

Can we make it do that in _response_ to something? Lights turned on or off, loud noise, silence? We can definitely add a horn/buzzer/piercing alarm to sound continuously/beep down the seconds/beep frantically for the last few seconds.

Um, if it’s going to be ominous, it should have a hundredths display, so some of the digits are changing too rapidly to see. The hundredths might remain blank during normal operation and only kick in when we’re down to a minute left, or something.

Technology

I think I may actually build one or two of these. I’d use the LogoChip for timekeeping and display decoding, probably supplemented by watching the 60Hz on the power line. I got a string of 5mm blue LED Christmas lights last winter, and I might get more, or I might get some frosted blue LEDs on eBay.

To drive the display, I’m interested in using Allegro Microdevices’ A6275 and/or A6276, 8- and 16-bit constant-current LED drivers. I saw them used in something linked from the Make blog that I can’t remember now, I ordered a couple of 8-bit sample chips to play with, and I recommended them to Muaz Halim for use in the TechArt exhibit Firefly Environment.