A stich in time... (clock project)

[SecretSquirrel]

I took a look at decoding a divide by sixty ring counter. Turns out that it's relatively easy to do a matrix decode. One counter selects row, the other columns, and you get exactly one LED lit. In this schematic, it's 10 columns by six rows. All that is needed is an extra PNP transistor per row. So assuming you already have an output buffer transistor, driving sixty LEDs takes six extra transistors and six extra resistors. Not to shabby.

ring_decode_schem.png (58.84 KiB) Viewed 37051 times

In practice, it will take more than that. Probably an extra transistor per counter stage to provide a separate buffer for the LEDs. It's possible that by multiplexing, I could still do single RGB leds for the ring. I believe it would only take six extra transistors, two each for hours, minutes, and seconds.

I also took the 7 seg decoder testing and put it into a full blown clock circuit, with multiplexed digits.

ring_clock_schem.png (69.95 KiB) Viewed 37051 times

There are 199 transistors in the above schematic. Adding the LED ring, would add another 45. There is stuff missing from that schematic though. It doesn't have the 1pps derivation counter. It also doesn't reset the hour counter at 12, or 24. I set up the counters to be able to do twenty four hour mode. At least one example I looked at simply used a 12 stage counter for the hours, rather than a 10+2 (12 hour) or 10+3(24 hour). If I limit myself to 12 hour mode, that is a possibility, but I'd like to be able to do a proper reset to zero. I have a vague idea how to do it, but testing is needed.

--SS

[SecretSquirrel]

More later, but here's a teaser...

IMG_20210305_220204.jpg (158.02 KiB) Viewed 37051 times

[SecretSquirrel]

As obvious from the above post, things have moved from simulation to the physical world. This is actually important as things that work in simulation don't always behave quite the same way when actually built. This is doubly so when doing simple simulations, as I am. I'm not doing things like accounting for stray bread board capacitance.

One place simulation vs reality raised it's head was in the pulse generation circuit for the counter input. This was the original circuit.

orig_pulse_generator.png (10.1 KiB) Viewed 37049 times

The circuit worked just fine when built, however the resulting pulse was two short to reliably trigger the counter. Random stages would trigger for each pulse. Testing with a signal generator showed that a 1ms pulse would reliably trigger. Even shorter would probably work just fine, but the lowest duty cycle the signal generator could do was 0.1%. At 1Hz, that works out to be 1mS. So the pulse generator circuit got modified a bit.

Screenshot_20210308_092049.png (19.97 KiB) Viewed 37049 times

The other problem that came up was the pulse output would ring on the rising edge. This ringing would cause multiple triggers of the counter. The 10nF cap on the output squashed the ringing, resulting in clean triggering of the counter.

The prior post shows the a breadboard version of a divide by 60 counter with 10 stage + 6 stage ring counters. Here is a video of it in operation.



In the video, it's being driven at 10Hz to demonstrate the full count without having to wait a full minute.

--SS

[meerkt]

No harm in doing exactly the same more publicly, also freely editing after the fact.

Unless it's mainly those self-imposed expectations...

[SecretSquirrel]

IMG_20210307_214214_1.jpg (145.81 KiB) Viewed 37042 times

This add the matrix decode for sixty LEDs. My order of generic 5mm red LEDs show up. The column drivers are between the LEDs and the row drivers are to the right. The LED matrix is a stand alone add on, meaning it has it's own output drivers, tapped off the counter. These are used directly for the columns and are used to drive the PNP row drivers in the row section. Removal of the counter state display LEDs in the final project would reduce the transistor count. If my counting is correct it's 59 transistors (22 PNP, 37 NPN) without the state display LEDs and their drivers.



The above video is with a 10Hz clock so that it cycles through the complete count in a reasonable time.

Now I need to look at whether I can reset the ring counters to a starting pattern without adding a whole lot of transistors. The hour count is interesting as it starts at 01 and counts to 12, in 12 hour mode. In twenty four hour mode, it counts for 00 to 24.

--SS

[SecretSquirrel]

Project time has been limited for the last week, but I managed to fit a little in here and there and come up with a reset circuit.

reset_circuit.png (7.71 KiB) Viewed 37037 times

To the right is a two input or gate. The bases of Q66 and Q67 are the inputs and are connected to the stages that represent the maximum desired count. Because the counter outputs are active low, the output of the OR gate will actually be an active low signal despite being positive logic. The pulse generator, fed by the OR gate output, generates a negative pulse on the rising edge of the input. The OR gate activates when the count reaches max. When the count proceeds to the next step, past max, the pulse generator is triggered and it's output is used to reset the counters.

two_stage_counter_w_reset.png (27.45 KiB) Viewed 37037 times

Above is the circuit attached to a pair of 10-stage counters. In the above schematic the count is set to 25. The output of the pulse counter is used to do two things. First, it is used to trigger the stage that should be active on counter reset. This is the line going to the base of the PNP transistor. My initial implementation had just this connection. You can see this in the connection to the second stage counter. It only has this trigger line. This worked fine at 1Hz. At higher frequencies, even 2Hz, the count would start at the reset point, count one step, then jump to the stage past the max point. I don't yet know why it worked at 1Hz, though I suspect it has to do with the capacitor draining its stored charge. The way these counters work is that the transistor pair has a trigger voltage that is higher than VCC and a holding voltage is lower. The capacitor between stages is what boosts the voltage to the following stage above the trigger voltage. The problem is that the capacitor between stages "max" and "max+1" was still charged and could still trigger the next stage. To address this, the output of the reset pulse generator is also used to drain the capacitor. This allows the reset to work properly at higher frequencies.

IMG_20210317_215829_1.jpg (147.52 KiB) Viewed 37037 times

You can see the actual reset circuit in the foreground, above. There are two extra transistors on the breadboard that are the actual output drive transistors. These would represent Q28 and Q62 in the above schematic.

Video of the reset circuit in action. Counting from 0-23 (or 1-24, your choice of interpretation) and resetting to 0.

[SecretSquirrel]

Up to this point, I've been tinkering with ring counter circuits. I have a decent idea of the complexity involved in building a ring counter based version of the clock. I also have confidence that the basic circuits work outside of simulation. So now it's time to look at binary counters for a bit.

A 4-bit binary counter...

IMG_20210319_220839_2.jpg (185.25 KiB) Viewed 37021 times

The counter above counts higher than this one.

IMG_20210304_220709_1.jpg (228.43 KiB) Viewed 37021 times

The catch, of course, is that the 4-bit binary counter outputs binary digits and will need to be decoded to both decimal and to a seven segment display. The question is going to be whether doing that decoding results in less transistors than the ring counter version. The binary counter above has two transistors for the flip-flop and an output buffer that is driving the LED. In the clock circuit, each binary counter stage would have two output buffers as you need both Q and ~Q for decimal decoding. To keep the decode parts count down, the displays would be multiplexed which means the outputs for each counter stage need to be open collector, hence the need for output buffers. You can't use Q and ~Q directly.

--SS

[Captain Ned]

I see Nixie tubes in your future.

[SecretSquirrel]

I went ahead and built up a full div-by-60 version of the binary counter.

IMG_20210330_183939_1.jpg (200.77 KiB) Viewed 36993 times

This has the proper BCD count on both stages, as well as the dual output driver transistors, so it is a reasonable representation of what the counter would look like in the clock.

Of course there is video...


A direct comparison of the two counter circuits.

IMG_20210330_184001_2.jpg (214.8 KiB) Viewed 36993 times

The ring counter uses 52 transistors (includes output drive). The BCD counter uses 28. Decoding the BCD to decimal is pretty straight forward and uses four diodes and a resistor, per decimal output.

One other interesting thing to note is that the BCD counter draws an order of magnitude more power. The ring counter pulls about 10mA. The BCD counter pulls about 90mA. If you think about it, this makes sense. Each stage of the BCD counter always has one transistor on, either for Q or ~Q. With a 1K resistor and 12V supply, this is about 8mA per flip-flop. Since I have output drive transistors, I can probably switch the collector resistor to 10K instead, and bring current usage inline with the ring counter. The ring counter also pulls current through a 1K resistors, but only for the stage that is actively showing the count, and instead of the single transistor drop, there are two diode drops and a transistor drop, plus biasing and the draw is only about 1mA for the active stage. The output driver adds a couple of mA and biasing adds 0.5mA here and there. The result is each ring counter stage pulls about 5mA.

--SS