5.833kHz clock via CD4040B using color xtal - what's wrong?

Discussion in 'General Electronics Chat' started by SgtWookie, Dec 2, 2009.

  1. SgtWookie

    Thread Starter Expert

    Jul 17, 2007
    22,182
    1,728
    I guess I should've passed over the stupid soup at lunchtime, but for some reason I just can't figure this out at the moment, and it's really bugging me.

    Refer to the attached simulation.

    On the left is a 3.5975MHz TV color burst crystal in a typical crystal oscillator circuit; nothing fancy at all. An inverter to drive the xtal, 20pF caps both sides, current limiting, yadda yadda - it all works fine, and the output from U2B is a nice square wave at 3.5975MHz.

    I'm ANDing together:
    Q0: /2
    Q1: /4
    Q4: /32
    Q5: /64
    Q8: /512
    That should result in a 5,830Hz output.

    It SHOULD be 5,830Hz, but it's twice that; 11.67kHz.

    Where am I going wrong?

    I fiddled around with what should be a simple problem for a couple hours today, and could not arrive at a satisfactory answer.

    It must be something simple that I'm just overlooking.

    What is it?
     
    Last edited: Dec 2, 2009
  2. k7elp60

    Senior Member

    Nov 4, 2008
    478
    69
    I agree with you I don't see a problem. The anding of the outputs results in a division of 614, so 3.5975Mhz/614= 5859.12Hz. I first thought you were using +5V for power, but I see you are using +12V so the 4040 should work fine.
    I just checked pins # of the 4040:
    Q0-PIN 9
    Q1-PIN 4
    Q4-PIN 3
    Q5-PIN 2
    Q8-PIN 12
    It should work if it is wired correct
     
    Last edited: Dec 2, 2009
  3. SgtWookie

    Thread Starter Expert

    Jul 17, 2007
    22,182
    1,728
    It's really odd.

    The input clock looks as good as can be expected for CMOS at that point; a halfway decent representation of a square wave

    The outputs seem to output within reason at their expected times; most importantly Q0. It's within a few percent of expected.

    However, I'm not getting the right divide-by clock out; it's twice what I expected - and I can't figure out why. :confused:
     
  4. davebee

    Well-Known Member

    Oct 22, 2008
    539
    46
    Maybe the 4040 pins don't all reset at the same rate.

    If some outputs clear before others, maybe the reset pulse is being cut short before the 4040 is fully reset?

    You could try adding a little time delay in the line that feeds the reset, like an RC circuit feeding a Schmidt trigger to delay the reset command, and see if that makes a difference.
     
  5. SgtWookie

    Thread Starter Expert

    Jul 17, 2007
    22,182
    1,728
    Nope, that's not it.

    There's a master reset; all pins are reset simultaneously.

    The internal D-type flip-flops are clocked in ripple mode though. Still looking at it.
     
  6. ifixit

    Distinguished Member

    Nov 20, 2008
    639
    108
    Some possibilities...
    1. The input clock must be twice the frequency that you think it is (7195000Hz). Zoom in and look for a double edge that you haven't noticed.
    2. The CD4040 IC is not what you think it is, or the model has a bug in it. If all the 4040 Q connections were shifted down you would get a divide by 306.
    Have you built a circuit that doesn't work, or is this just a simulation only?

    I like a good mystery...
     
  7. SgtWookie

    Thread Starter Expert

    Jul 17, 2007
    22,182
    1,728
    Nope. I also had a diagnostic 4017 in the circuit that I omitted before posting; it output a /10 clock so that I could easily see if "glitches" were occurring in the clock. Its' output frequency was 357.95kHz, just like it was supposed to be.
    It may be "a bug", but then again I think I may be "getting bitten" by propagation delay of the clock. It's a ripple-clocked D-F/F /12 counter with simultaneous resets. Since the oscillator is analog, I have to use analog simulation; won't work with the digital option. I'm using a step of 6nS in the sim; that should be plenty of resolution.

    Just a sim so far. Don't want to build the real thing if it's not working in simulation.

    I think I need a different approach. A synchronous 8-bit binary counter would do the job.
     
  8. davebee

    Well-Known Member

    Oct 22, 2008
    539
    46
    The reason I suggested the reset delay was that I had run into that very problem with an actual circuit a few years ago in a real circuit, where a counters outputs were decoded and fed through logic to the counter reset, but the reset was not being applied for long enough because as soon as any one pin cleared, the reset signal was lost.

    A delay circuit that added just a few hundred nanoseconds of delay into the reset logic path fixed it.

    How does the simulator manage the parts? Does it actually preserve the ripple-count ature of the 4040? If so, maybe that is causing problems, as Q0 will toggle long before the higher bits, sending a reset pulse too early, maybe generating the higher frequency that you're seeing.

    If that is the case then maybe that same sort of reset delay would fix this, as it would filter out unwanted transient pulses in the reset line, only allowing the intended condition to cause the reset.

    Or maybe you could try substituting a chain of clocked counters, like 74HC161s to see if they would make a difference.
     
  9. ifixit

    Distinguished Member

    Nov 20, 2008
    639
    108
    You can't leave the mystery unsolved:(
    1. I would think propagation errors would cause the reset count to be longer and irratic, not shorter and consistant.
    2. Can you test with a lower clock rate just to be sure?
    Have fun
     
  10. SgtWookie

    Thread Starter Expert

    Jul 17, 2007
    22,182
    1,728
    There is noticeable skew in the timing between the input clock and the various stages of the counter. It's pretty difficult to see given the limitations of the particular software that I was using.

    In order to compensate for the propagation delays for the various stages, I would have to add propagation delays to EACH input to the AND gates, the amount of delay depending upon which 4040 output they were receiving their input from.

    This, of course, is a dicey proposition at best. A synchronous counter would eliminate the whole problem.

    Even then, there will be a small error; the result won't be precise.

    Rather than fiddle around any more with discrete IC's, I'll just go the uC route. The timing of the individual clock outputs won't be precise, but by staggering the timing loop variables, over time the average clock pulse width will be far more accurate than I could achieve with these discrete IC's without making it ridiculously complicated.
     
  11. MikeML

    AAC Fanatic!

    Oct 2, 2009
    5,450
    1,066
    Rerun the sim with a 1Mhz square wave in place of the crystal osc. This will show if it is a waveform issue (double edge) or prop. delay issue.
     
  12. SgtWookie

    Thread Starter Expert

    Jul 17, 2007
    22,182
    1,728
    MikeML,
    I'm convinced it's a propagation delay issue. The clock is as clean as can be expected from the output of a 4093 NAND gate switching at nearly 3.8MHz.

    I'd tried it with a slower clock as well; 1MHz crystal. The same "timing glitch" occurs. It simply did not occur to me that the 4040 /12 counter was a ripple counter, and that I'd get "bitten" so badly by it. The 4060 is also a ripple counter.

    Now I have to wonder how many others have been bitten by this same prop delay problem, trying to design divide-by-N counters where N is not a power of 2.
     
  13. MikeML

    AAC Fanatic!

    Oct 2, 2009
    5,450
    1,066
    Actually, you can do parallel decodes off a ripple up-counter (for counter resetting purposes) for bit patterns other than pure powers of two and get away with it. The last bit to change finally satisfies the decode to produce the reset pulse.

    I suspect that your problem is that the duration of the reset pulse is not sufficient to reset all the flops. Note that the reset pulse "goes away" as soon as the speediest flop resets, not necessarily when the last flop resets, leaving the counter with a non-zero value.
     
  14. SgtWookie

    Thread Starter Expert

    Jul 17, 2007
    22,182
    1,728
    Well, there's about 30nS propagation delay per stage in the sim; by the time the clock gets to Q8, that's roughly 270nS of cumulative propagation delay - which is just about one whole clock. Not surprising I'm seeing this glitch.

    The reset pulse is rather short in duration (60nS), but in this case the cumulative propagation delay of the two levels of AND gates (2x30nS) works in my favor. Surprisingly, all of the internal D-flip-flops reset within 10nS of the reset being strobed.
     
  15. THE_RB

    AAC Fanatic!

    Feb 11, 2008
    5,435
    1,305
    Put a low pass filter on the output, you might be getting a very fast glitch on one edge of your output signal and a good frequency meter is possibly fast enough to double clock, even though it looks ok on the cro. That might not be it in your case, but I have seen it happen.
     
  16. eblc1388

    Senior Member

    Nov 28, 2008
    1,542
    102
    Please takes a look at page 4 of the following Motorola MC14040B datasheet. It shows a timing chart and a divide-by-3600 counter. In MC14040B, the outputs are Q1 to Q12 while yours are Q0 to Q11 in the simulation.

    MC14040B

    Therefore your Q8 should be Q9 in MC14040B and is therefore "divide-by-256" instead of divide by 512.

    If you use the Q8 (or Q9 MC14040B) as output without resetting the 4040, the division ratio is 512 but if you acts on the rising edge and reset the 4040 then its divide by 256.
     
    Last edited: Dec 4, 2009
  17. ifixit

    Distinguished Member

    Nov 20, 2008
    639
    108
    I agree with eblc1388, but I don't get up as early as he does.

    Remember back in your first post you said it must be something simple you're not seeing...

    If you count the number of FFs to set the "512" (Q8) AND gate pin to one, you'll see that only 256 clocks are required to set it,
    and then another 51 or so counts to get to a clock count of 307 which generates the reset pulse giving 11.72KHz on the Q8 pin
    output.

    To fix this, assign the proper binary weight of the Q outputs as follows: Q0=1 (not 2), Q1=2, Q2=4....Q8=256, Q9=512, Now
    wire up the AND gates to Q1,2,5,6, & 9. It will now take 614 clocks to get to the reset pattern giving 5.859KHz on Q9.

    Please post more puzzles like this one.
     
  18. Ron H

    AAC Fanatic!

    Apr 14, 2005
    7,050
    657
    In other words, shift all the AND gate inputs up by a bit.
     
Loading...