# Count number of hours elapsed

It's been a long while since I played with circuits, I'd appreciate a sanity check of the following design; I'm trying to count the number of hours since the reset button was last pressed. Ideally it'd last a long time just powered by batteries, but if I ever get it to work I'll be happy!

(Circuit diagram below)

I calculated my NE555 astable values by brute forcing the equation on Wikipedia for 'common values' of resistors and capacitors which were closest to 3600 seconds (I've added the ruby code below for those interested). Do they seem sensible?

• C: 100mF
• R1: 51KΩ
• R2: 470Ω
• CTL capacitor: 10µF (pulled this out of thin air…)
• This should set the duty cycle to 1.00057 hours.

I'm planning on using the following components - is there anything else I should be taking into account?

• 1x low power NE555 (TLC555)
• 1x quad 2-input NAND (SN7400N)
• 1x dual binary ripple counter (74HC393)
• 2x BCD to 7 segment decoders (4511)
• 1x 2 digit 7 segment display (Common Cathode)
• The above capacitors and resistors - I have literally no idea which ones to pick from the ridiculously vast array out there…

(I realised the NAND logic may not be clear - it took me a while to figure out how to implement an AND + OR combo with NANDs! - so I pulled it out beneath the circuit diagram)

Thanks!

### Reset Logic gate layout

Ruby code for brute-forcing the closest NE555 component values:

require "pp"
capacitor = [1, 1.5, 2.2, 3.3, 4.7, 6.8]
resistor = [10, 11, 12, 13, 15, 16, 18, 20, 22, 24, 27, 30, 33, 36, 39, 43, 47, 51, 56, 62, 68, 75, 82, 91]
powers = [0.001, 0.1, 1, 10, 100, 1_000, 10_000, 100_000, 1_000_000]

target = 3600
tolerance = 1

best = []

ln2 = Math.log(2)

powers.each do |c_p|
capacitor.each do |c_v|
c = c_v * c_p
powers.each do |r1_p|
resistor.each do |r1_v|
r1 = r1_v * r1_p
powers.each do |r2_p|
resistor.each do |r2_v|
r2 = r2_v * r2_p

value = ln2 * c * (r1 + 2*r2)

proximity = (target - value).abs

if proximity <= tolerance
best.push(
proximity: proximity,
value: value,
c: c,
r1: r1,
r2: r2
)
end
end
end
end
end
end
end

best.sort! do |a, b|
a[:proximity] <=> b[:proximity]
end

pp best.take(5)

• What kind of accuracy are you looking for? With those large capacitors, the tolerance is probably 20% at best and the drift rate with time and temperature will be considerable. It would be much better and cheaper to use a low cost crystal oscillator and count it down to whatever rate you want. Commented Sep 18, 2014 at 23:10
• 100mF is a big capacitor. And any reasonably priced one will probably have a 20% or more tolerance, which would impact the accuracy of your timer. Commented Sep 18, 2014 at 23:12
• You really wasted your time trying to pick out "standard" fixed values for your components, because the tolerance on their values is going to be so bad that you're going to have to provide a calibration mechanism anyway. Commented Sep 18, 2014 at 23:12
• Ahh - I figured that'd be the downfall! I don't need great accuracy, but 20% is probably a bit high (I could get away with 10% I reckon) What approach should I try next? @Barry's oscillator + lots of dividers seems like it should work?
– JP.
Commented Sep 18, 2014 at 23:14
• Use a 32768Hz watch crystal and a 4060 to produce a 1Hz tick then divide by 3600 to get hours, then count with a BCD counter. Commented Sep 18, 2014 at 23:31

• The 4511 needs unused inputs tied to an appropriate logic level
• The 4511 needs series resistors on each of the segment outputs to the common-cathode display
• You are using museum-quality TTL, so you should have a pull-up on the RESET input and pull it down to ground with the switch.
• One day (Edit: or one hour) is not a reasonable period to get from a 555 (even a CMOS one). Keep it to 1-10 seconds. The leakage on a 0.1F capacitor would make a mockery of your precise calculations. You can count down a higher frequency if you like. A 74HC4040 prescaler would allow a ~1 second clock.
• You'll never get better than maybe 5% without adjustment on a 555, and even if you trim it, tenths of a percent. That may not bother you, but the count might be off by an hour in ten or twenty without trimming. Think of how many weeks(Edit: days) it would take to trim a timer with a 1-day (Edit: or one hour) cycle!
• I don't know what a 7469 is.. something like a 74390 dual decade counter perhaps?
• 10uF is unnecessarily high for the control bypass- 100nF is more than enough.
• I didn't check your logic (the semi-pictorial is a bit painful to read) but it looks plausible as a plugboard starting point.
• Emphasis on the 4th point about the reasonable frequency. He says 1 day, but the calculations come out to 1 hour (I think he just mistyped). Even 1 hour is awkward for a 555. Commented Sep 18, 2014 at 23:15
• I did mistype - should have been hours, but I'm getting the impression I'm taking the wrong approach here (told you it's been a while :P) any pointers towards better approaches would be appreciated!
– JP.
Commented Sep 18, 2014 at 23:18
• It's not a wrong overall approach. The details are a bit off- in particular the use of the 555. If I thought it was completely hopeless I wouldn't have answered. In 2014, most of use would probably do this with a microcontroller and a page of 'C' code or a couple pages of assembler. Commented Sep 18, 2014 at 23:20
• If you don't care about accuracy (plus or minus a few hours over the course of a few days), the 555 is fine. But pick a much faster frequency. That'll make the components smaller and cheaper. Use cascading counters that act as dividers to get the 1-hour increments you want. If you do need the accuracy, use a crystal-based oscillator. Commented Sep 18, 2014 at 23:24
• Thanks guys, my C is just about good enough to code something like this onto an AVR chip; I'll look at the upfront cost of a programmer (an Arduino these days, I guess?) vs. a faster duty cycle and using a cascading counter (looks like a 0.879s cycle would work for @SpehroPefhany's 74HC4040 to hit an hour) - you've been a great help!
– JP.
Commented Sep 18, 2014 at 23:33