Synchronization Problems with Parallel Input DAC's

Discussion in 'The Projects Forum' started by MasterSnow, Jan 19, 2009.

  1. MasterSnow

    Thread Starter Member

    Jan 18, 2009
    22
    0
    Hello all,

    First off, new user here. Many thanks to this website for hosting the wonderful Lessons in Electric Circuits text over the years. :)

    Now, I am wondering if anyone has come up with a solution to the following problem. I have been trying to create an arbitrary waveform generator by utilizing a PIC12F683 to generate pulses which are varied in frequency (a time domain signal like a sine wave or just a linear ramp is modulated in the train). Next, I have a counter IC stage that effectively converts my high speed pulse train into a parallel up-counting or down-counting output. Lastly, I have a parallel input DAC that is hooked bit-for-bit to the counter output.

    This system works beautifully in principle, but I ran into a problem that took me some time to track down. On my DAC output signal, I get spiking at times when multiple bits from the counter must transition at once. This is because they are slightly out of phase (usually by < 10 ns). So the DAC might read maximum value for a few ns before all of the bits catch up.

    A few solutions I thought of: find a counter and DAC combo that use gray codes instead of binary, find an intergrated "counter DAC", find a DAC with a slower response time so that the out of phase delays don't matter, or get a better counting source.

    For reference, the pulse train is updating at ~2.4 MHz. I've had no luck with finding an integrated solution or ANYTHING that uses gray codes other than rotary encoders (which I think is a shame). I really do like my current setup of a single pulse train from a tiny PIC with hardware to create the parallel output. However, I could always do something different, and may have to. I'd rather not have to use a serial protocol DAC, as those would require a far faster microcontroller to provide the data at the rate I want.

    Anyhow, just curious if anyone has any thoughts (or IC part #'s ;)) on this subject. Thanks!

    -MasterSnow
     
  2. eblc1388

    Senior Member

    Nov 28, 2008
    1,542
    102
    Do you aware of the difference between ripple and synchronous counter?
     
  3. MasterSnow

    Thread Starter Member

    Jan 18, 2009
    22
    0
    Aye, I am aware. I am certainly using a synchronous counter in this design.
    74F269 is the part # if you care to look.

    Thanks for the reply!
     
  4. Ron H

    AAC Fanatic!

    Apr 14, 2005
    7,050
    657
    DAC glitches at the major bit transitions are a fact of life. I encountered this over 30 years ago. I solved it by sample-and-holding the output after the DAC output has settled (just before the next transition). S&H design is not trivial.:eek:
     
  5. eblc1388

    Senior Member

    Nov 28, 2008
    1,542
    102
    Since the OP uses 8-bit counter outputs for DAC, would using a R-2R network instead of the DAC helps to elimate glitches?
     
  6. MasterSnow

    Thread Starter Member

    Jan 18, 2009
    22
    0
    Aye, thanks for the reply.

    How did you check for output settling? Did you wait some amount of time or did you have a system that checked for stability?

    I agree though that this is a fact of life for binary counting systems...however, it seems that for those of us that want a continuous transition, that gray code counting would be an ideal solution. Is there anything wrong with the idea of a gray code-interpreting parallel DAC?

    -MasterSnow
     
  7. MasterSnow

    Thread Starter Member

    Jan 18, 2009
    22
    0
    eblc1388

    I don't know if using that would help (I assume you mean connecting this network to an Op Amp?). It would just make the output look like the input, even if the input is wrong for a few ns. Depending on the Op Amp's slew rate, one could still see some large spike errors.

    Thanks for the reply!

    -MasterSnow
     
  8. Ron H

    AAC Fanatic!

    Apr 14, 2005
    7,050
    657
    R-2Rs were the kind that I was deglitching.:mad: This was for composite video with a sample rate of 14.3 MBPS (70ns per sample). DAC glitches cause major chroma errors with composite video.
     
  9. eblc1388

    Senior Member

    Nov 28, 2008
    1,542
    102
    Hi MasterSnow,

    As per Ron_H's suggestion on using sample and hold to isolate the glitches, more infos on how to tackle the problem can be found here:

    Smart DAC Deglitch Circuit
     
  10. MasterSnow

    Thread Starter Member

    Jan 18, 2009
    22
    0
    Thanks for the application note link. Unfortunately though, I really need glitching that is below the mV level. I think I'm just going to have to have a reality check and spend more money to create a higher performance system. ;) Still, I feel like this whole scheme could have worked if gray code DAC's existed (I don't feel like trying to make one).

    -MasterSnow
     
  11. Ron H

    AAC Fanatic!

    Apr 14, 2005
    7,050
    657
    I think Gray code DAC designs do exist. I don't know of any commerially available ones.
    A Google search brings up patent references for Gray code DACs. I didn't register on their sites, so I couldn't look at the designs.
    Since you will generally have some sort of low pass filtering after a DAC, small glitches caused by the S&H which have constant amplitude, independent of code transitions, are generally not a problem.
     
Loading...