hi e17,
Try this cut down sim.
I guess you realise that you will not get uF capacitors at the tolerances you are calculating, typically they can be +/-10%, some as bad as 40%.
You should have a trim pot in series with the rtc fixed resistor so that you can set the frequency to suit the cap.

I will look at the timing within the CD4024B, let you know what I find.

Why don't you use a 3.2768kHz xtal for the 4060 and follow it with a CD4013 for a 1 sec pulse.

I have read the other thread, could you summarise exactly what you are trying to do.?
E

 

hi,
There is a timing error in the CD4024B, this is from the LTS user group Lib
See what I can find.
E

 

hi,
There is a timing error in the CD4024B, this is from the LTS user group Lib
See what I can find.
E

Glad to know it's not just my insanity!

 

hi,
Been busy checking a number of the CD4000 type counters in the lib, they all have the same problem.
E

 

What problem did you find with the 4020 model Eric? I incorporated the guts of that into a 4060 model that I home-brewed and it seems ok (apart from being slow, as per the other models in that family).

 

hi alec,
The q0 and q1 sections have glitch pulse causing mis-counting, plot attached.
The CD4020 does the same thing.
I was going to PM you to do a verify check.
Eric

 

hi e17,
Try this cut down sim.
I guess you realise that you will not get uF capacitors at the tolerances you are calculating, typically they can be +/-10%, some as bad as 40%.
You should have a trim pot in series with the rtc fixed resistor so that you can set the frequency to suit the cap.

I will look at the timing within the CD4024B, let you know what I find.

Why don't you use a 3.2768kHz xtal for the 4060 and floow it with a CD4013 for a 1 sec pulse.

I have read the other thread, could you summarise exactly what you are trying to do.?
E

Sorry my numbers in that post were misleading. The multiple decimal places were just because I copy and pasted out of the spreadsheet I used to calculate things. I don't need any accuracy at all - this is really just a mental exercise for me. Of course, you're right that if I were building the physical circuit in reality I'd probably want to either use a trim pot or possibly a crystal depending on the required accuracy.

As for summarizing what I'm trying to do, the desired circuit behavior is as described a few posts ago:

The basic idea of the circuit is that there will be a stream of pulses on the input. If the pulses are spaced by one minute or less, a one hour timer should be running. (If there's a gap of more than one minute in the pulses, the one hour timer should stop. Upon the next pulse, the timer should reset/restart counting the full hour again.) When the timer reaches an hour, it should activate a relay and latch that output so that the relay stays high, regardless of pulse activity, until manually reset.

I'm trying to work out this circuit just as a mental exercise and as a good excuse to get familiar with cd4060 behavior. As it turns out, it's also getting me deeper into the nuts and bolts of LTspice than I had ever been before.

 

HI

1. Use Q4 output of the CD4060B.
2. Change RC timing components to C=220uF, R=910k, RS=9.1M, that will set the period to about 7200 seconds so the Q4 output will go high in 3600 seconds (about 1Hr).
3. You might be able to replace the IC inverters with transistor inverters and get rid of a chip.

BTW- the sim runs faster this way also..
On my system it completes in about 2 minutes.

eT

 

So far Google has failed me. What does the "speed" parameter in the 4024 model refer to? Is it related to simulation speed, slew rate ranges, some sort of holdoff timing? I'm at a loss.

I think it's really interesting that it affects the errant pulses, but since I have no idea what it's supposed to be controlling, I have no idea if it's "ok" for me to be messing with it.

 

So far Google has failed me. What does the "speed" parameter in the 4024 model refer to? Is it related to simulation speed, slew rate ranges, some sort of holdoff timing? I'm at a loss.

I think it's really interesting that it affects the errant pulses, but since I have no idea what it's supposed to be controlling, I have no idea if it's "ok" for me to be messing with it.

The speed parameter affects prop delay. I wouldn't change it.

The CD6040 is better to use anyway...but for long timers, you should use a crystal with it.

 

The CD6040 is better to use anyway

Google can't find that. Did you mean CD4060?

 

The speed parameter affects prop delay. I wouldn't change it.

Awesome, thanks for the explanation.

The CD6040 is better to use anyway...but for long timers, you should use a crystal with it.

Assuming you meant 4060, that is what I'm working with. The 4024 only came up because it's model is used as the base that this 4060 model is built on, so it's the internal 4024 parameters that determine the performance of this particular 4060 model.

 

The q0 and q1 sections have glitch pulse causing mis-counting, plot attached.

I'm not getting any glitches at Q0/1 when I sim the 4020 or the 4024 model operation. Perhaps there are various versions around the web? My CD400.lib file indicates latest revision is 0.62 07/31/2007. It also says "Revision 0.60 04/14/2005 CD4020B, CD4024B, CD4040B clock corrected".

 

hi alec,
This is the header from my lib.
E
D:\Daten\Ltc\CD4000\CD4000.lib
*
* CD40xxx Model libraray for LTSPICE from www.linear.com/software
*
* Revision 0.65 07/19/2014 CD4022B added
* Revision 0.64 09/13/2013 force Q=high if R AND S are high
* Revision 0.63 01/30/2012 prepared B(VDD) in input/output driver models
* Revision 0.62 07/31/2007 CD4510B, CD4516B, CD4029 added
* Revision 0.61 09/24/2005 CD4538B added, CD14538B reset removed from trigger
* Revision 0.60 04/14/2005 CD4020B, CD4024B, CD4040B clock corrected
* Revision 0.59 04/14/2005 CD4020B, CD4024B, CD4040B clock inverted
* Revision 0.58 03/29/2005 CD4017B inverted output Q59
* Revision 0.57 05/03/2004 CD4008B added
* Revision 0.56 08/29/2003

 

I'm not getting any glitches at Q0/1 when I sim the 4020 or the 4024 model operation. Perhaps there are various versions around the web? My CD400.lib file indicates latest revision is 0.62 07/31/2007. It also says "Revision 0.60 04/14/2005 CD4020B, CD4024B, CD4040B clock corrected".
View attachment 132511

For what it's worth, I only got the glitches when feeding the input from a logic gate oscillator circuit (as in the 4060 model referenced above - see my earlier screenshot or eric's last pair of screenshots.)

When I bypassed the oscillator and fed the 4024 input a square wave from a programmed voltage source as you're doing here, it worked fine.

 

Apparently no changes to 4020, 4024 or 4040 since revision 0.60 then. Strange why you get glitches and I don't .

Edit: Posts crossed.

 

Google can't find that. Did you mean CD4060?

Oops...typo..
Yes. CD4060B

 

hi guys,
It appears the RC osc block is creating/causing the miscount, no problem when using a Vsource as an osc.
A simple R/C filter between the 4024 and the oscillator kills the problem, used a 1k and 1no.

Will look deeper.
E

Update:
Here is the glitch , will check the RC timing

 

Awesome, thanks for the explanation.

Assuming you meant 4060, that is what I'm working with. The 4024 only came up because it's model is used as the base that this 4060 model is built on, so it's the internal 4024 parameters that determine the performance of this particular 4060 model.

I wrote the CD4060 model you originally posted. It does not use the CD4000 lib the other posters are referring to. It does not use any behavioral devices and entirely made uses mosfets as in the real CMOS chip. Its oscillator is accurate. There aren't any glitches I know of, but it is slow depending on the choice of timing components. If you use Q4 output and the RC components I mentioned in post 30, it completes in about 60 seconds.

 

Agreed it's the RC oscillator that's the source of the problem, but it's odd that the glitches don't show in the oscillator's output; only in Q0 etc output.
Another fix I've just found is to use the post #26 model with the 4011's speed parameter increased to 1.25 or greater. A few nS shaved off the propagation delay doesn't change the sim accuracy drastically.