ADC problem? waveform peaks wrap - diyAudio
Go Back   Home > Forums > Source & Line > Digital Line Level

Digital Line Level DACs, Digital Crossovers, Equalizers, etc.

Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 18th August 2011, 12:38 AM   #1
branm is offline branm  United States
diyAudio Member
 
Join Date: Apr 2005
Location: LA
Default ADC problem? waveform peaks wrap

I have an opamp driving a CS5361 ADC. The digital signal goes through some DSP and then out to a DAC and another opamp. My observation is that the waveform after the last opamp is clipped and fractions of the peaks are 'not in place.' It appears as if the waveform is wrapping around to the negative side. And if i decrease the input signal to a very small level the waveform suddenly is better.

I narrowed the problem down to the ADC. It was replaced and suddenly the waveform is fine now. But i would like to know what happened with the old ADC

I did some google seaches for the answer, but found no technical explanations ... orther than something about an ADC overflow and bad clocks.

Any ideas? What's going on?
  Reply With Quote
Old 18th August 2011, 01:41 AM   #2
rsdio is offline rsdio  United States
diyAudio Member
 
Join Date: Feb 2008
Location: Seattle
I'm not really sure. I would have guessed that the DSP was responsible for the wrapping, since it is so terribly easy with most general-purpose processors to overflow a binary register and get that exact result. However, you say that you eliminated the DSP as a possible source and also that replacing the ADC solved the problem.

I do recall "from the old days" that certain forms of digital conversion were prone to overflow distortion, and also that newer chips have increasingly been designed to circumvent this problem. Unfortunately, I cannot remember exactly how overflow and wrap-around distortion is created in the conversion process.

There are many methods for ADC technology. The three that I can think of right away are successive approximation, flash conversion, and delta-sigma. There are surely other types. I would imagine the SA and flash converters would not wrap-around, but would simply hard-clip. Delta-sigma, though, could easily wrap around if the 1-bit to multi-bit accumulator was not protected against overflow.

Heading over to the Cirrus site for the CS5361 Product Data Sheet, I see that this chip uses delta-sigma technology. They claim that it has overflow detection, but apparently this is presented on a single output pin, regardless of whether the left or right channel is overflowing, and the output is held for a certain amount of time.

Did your circuit utilize the /OVFL output pin? I would imagine that you could attach this to a front-panel LED with the appropriate current limiting resistor, and then you would have an indication of a problem. With this chip, it seems that the only fool-proof method of operation is to have a human operator manually turn down the input gain until the OVFL is no longer triggered. You might also want some kind of latch circuit in case the operator looks away long enough to miss a distortion event, and then provide a button to clear the OVFL Hold.
  Reply With Quote
Old 18th August 2011, 01:43 AM   #3
diyAudio Member
 
abraxalito's Avatar
 
Join Date: Sep 2007
Location: Hangzhou - Marco Polo's 'most beautiful city'. 700yrs is a long time though...
Blog Entries: 101
Send a message via MSN to abraxalito Send a message via Yahoo to abraxalito Send a message via Skype™ to abraxalito
Sounds to me that someone's not using saturating arithmetic in the digital signal processing. For a replacement ADC to fix your problem that would indicate there's different DSP algorithms within the two chips. Have you talked to Cirrus to see if they've revised the chip since your first one?
__________________
No matter if we meanwhile surrender every value for which we stand, we must strive to cajole the majority into imagining itself on our side - Everett Dean Martin
  Reply With Quote
Old 18th August 2011, 08:15 PM   #4
branm is offline branm  United States
diyAudio Member
 
Join Date: Apr 2005
Location: LA
Thanks for the detailed responses!

I just chked my schematic and it turns out the original design doesn't use the /OVRFL pin. It is NC. We haven't had to use that feature (in the product here at my work) but that would've definitely indicated overflow. I've seen other faults in the board but never this one, so I thought i'd ask here.

I'm not sure i understand Abraxalito's post ... "indicate there's different DSP algorithms within the two chips..." The signal chain is as follows: opamp -> CS5361 ADC -> DSP -> DAC -> opamp ... I don't see two chips here with different DSP algo's .. Am I missing something?

At any rate, replacing the original (problematic) CS5361 with another CS5361 solved the problem somehow. I guess the ADC just happened to be DOA.

Thanks guys!
  Reply With Quote

Reply


Hide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Resonance Peaks NTSBuilding Multi-Way 7 4th February 2010 09:16 PM
Where are peaks and nulls most offensive valleyman Full Range 3 21st November 2008 05:00 PM
Square waveform test/simulate problem mclarenpingu Solid State 3 2nd February 2008 04:08 PM
Powered sub peaks MichaelJHuman Multi-Way 0 9th September 2005 11:39 PM
How wrap transformer... MaXiZ Power Supplies 6 13th May 2005 09:52 PM


New To Site? Need Help?

All times are GMT. The time now is 01:48 PM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2014 DragonByte Technologies Ltd.
Copyright 1999-2014 diyAudio

Content Relevant URLs by vBSEO 3.3.2