Does anyone know if the SGTL5000 has anti-alias filters in the analogue gain stage before its ADC. The reason I ask is simple enough. I am fighting to get noise levels to an acceptable level. I have already followed a few hints such as disabling the ADC HPF, this did help. However I still have noticeable levels of noise. Before I start pulling apart the board and addressing things such as precise regulation and filtering of VDDA etc. I wanted to know if it worth the effort to add an analogue AAF before the linein. The noise is clearly coming from the ADC as I have carefully tested the DAC performance and it is good. However I see about 2-3 bits of noise on the ADC and its not random, it clearly has some harmonic content. When signal levels are very low, this causes quite noticeable distortion. So which do I attack first, the power supply lines, grounding... or an external AAF? Any experience out there?
Anti Alias filters on SGTL5000
- Thread starter aidyw
- Start date
- Status
PaulStoffregen
Well-known member
Yes, it does. Years ago I did quite a bit of testing with a signal generator sweeping a sine wave frequency. It's quite good at working all the way up to about 21 kHz. Then the input rapidly decreases as you sweep the frequency higher, with pretty much zero response above 22 kHz. I didn't test over 30 kHz. There very well may be really high frequencies in the range it oversamples that do interfere.
If you have access to a suitable signal generator, you can test the performance (or presence) of the aa filter by injecting a signal above the nyquist freq. The signal will appear as a folded image reflected at the nyqyist point, i.e. 32khz signal should show up as a 10khz spike, along with some harmonics.
I noticed some spikes in the upper region, like 8khz @ -84db, but the actual frequency seems to change depending on the Teensy clock speed, which would indicate that the noise is induced by coupling somewhere. Definitely audible when the volume is cranked up
Since this chip is not a high end codec, the actual dynamic range may be less than 16bits, probably more around 80db at best.
Marc
I noticed some spikes in the upper region, like 8khz @ -84db, but the actual frequency seems to change depending on the Teensy clock speed, which would indicate that the noise is induced by coupling somewhere. Definitely audible when the volume is cranked up
Since this chip is not a high end codec, the actual dynamic range may be less than 16bits, probably more around 80db at best.
Marc
Thanks guys, I would have been surprised if it was not there. But very glad you have proved it. As to the question of quality. I will approach this from the supply lines first now I know the AAF is in place. I did this with the audio shield for the LPC1768, (TLV320) and managed to squeeze a good 6-8dB extra out of the ADC simply by paying very careful attention to noise on the VDDA and also carefully avoiding coupling AGND to any traces that might be carrying switching currents from the MCU or codec itself. It's a kinda painful process, but hey....
Paul, if you have any PCB drawings, that would help, otherwise I'll be forced to first unsolder the shield and secondly spend hours squinting through an eye-piece. If I can investigate on the computer before I heat up the iron it would be helpful.
Regards
Paul, if you have any PCB drawings, that would help, otherwise I'll be forced to first unsolder the shield and secondly spend hours squinting through an eye-piece. If I can investigate on the computer before I heat up the iron it would be helpful.
Regards
DD4WH
Well-known member
Hi Paul & others,
I may be misunderstanding the way the codec in the audio board works, but with the Teensy Convolution SDR I use the audio board with frequencies up to 192kHz (with Frank Bs sample rate change code) and it works pretty well.
My "Audio" comes from a quadrature sampling detector and contains frequencies from 0 Hz to 192kHz (I & Q, which are 90 degrees out of phase) which are fed into the R and L LINE inputs of the audio board. I can see the whole 192kHz wide spectrum in the FFT1024-based spectrum display and my DSP code demodulates an audio signal from these two signals (eg. a wideband STEREO FM modulated signal with a bandwidth of 192kHz is demodulated in high quality). Bandwidth is 192kHz with 192ksps, because I use the TWO ADCs digitizing the same signal (90 degrees apart), so I am not violating Nyquist here ;-).
I also dynamically use the analog gain control of the SGTL5000 (0-22.5dB, sgtl5000_1.lineInLevel) to amplify my signal, if needed.
So I am now a bit confused, because I believed (and was happy about that) there was NO antialias filter. If there is an antialias filter with a cutoff frequency of 22kHz, why should I be able to use the LINE IN input for a 192kHz wide signal? But maybe there is a misunderstanding on my side . . .
All the best,
Frank
P.S.: Also, the MIC input does not seem to have an antialias filter, because we sucessfully used it as an input for an ultrasound microphone (up to 48kHz) and for a VLF receiver for a standard time station at 77.5kHz . . .
I may be misunderstanding the way the codec in the audio board works, but with the Teensy Convolution SDR I use the audio board with frequencies up to 192kHz (with Frank Bs sample rate change code) and it works pretty well.
My "Audio" comes from a quadrature sampling detector and contains frequencies from 0 Hz to 192kHz (I & Q, which are 90 degrees out of phase) which are fed into the R and L LINE inputs of the audio board. I can see the whole 192kHz wide spectrum in the FFT1024-based spectrum display and my DSP code demodulates an audio signal from these two signals (eg. a wideband STEREO FM modulated signal with a bandwidth of 192kHz is demodulated in high quality). Bandwidth is 192kHz with 192ksps, because I use the TWO ADCs digitizing the same signal (90 degrees apart), so I am not violating Nyquist here ;-).
I also dynamically use the analog gain control of the SGTL5000 (0-22.5dB, sgtl5000_1.lineInLevel) to amplify my signal, if needed.
So I am now a bit confused, because I believed (and was happy about that) there was NO antialias filter. If there is an antialias filter with a cutoff frequency of 22kHz, why should I be able to use the LINE IN input for a 192kHz wide signal? But maybe there is a misunderstanding on my side . . .
All the best,
Frank
P.S.: Also, the MIC input does not seem to have an antialias filter, because we sucessfully used it as an input for an ultrasound microphone (up to 48kHz) and for a VLF receiver for a standard time station at 77.5kHz . . .
Last edited:
PaulStoffregen
Well-known member
I'm currently traveling, writing this reply from my laptop in a hotel room. I won't have regular access to my desktop system until after the Memorial Day (USA holiday) weekend.
Edit: this may not help a lot, but I can tell you there are no traces routed underneath the SGTL5000 chip. It's a QFN part with a large center ground pad. Traces do route under the SD socket. Hopefully the schematic should give you a good idea of where they go.
Last edited:
Hi All,
Well this little codec is stubborn. I just would like to run a few questions by you all, see if you have any experience beyond my experiments. Having looked at the specs of the SGTL5000, when running on VDDA of 3.3V we should expect 90dB dynamic range from the ADC. Now this is already only 14bits precision. However I can not get any better than 12bits, in fact a little less than 12 in fact. I have tried just about everything I can think of to reduce this noise. Just as a run down.
From what I can see the audio shield has AGND and DGND tied together directly under the codec. I can't see this for sure, but I think it's obvious as the PAD of the IC is available on the non-component side of the board and all the digital grounds disappear under the IC. The AGND IC pin only pops out to be attached to the bypass caps. So with this in mind.
1. I connected VDDA giving it its own regulator and LC filters on the rails, much bigger than those on the board, should have -3dB at < 500Hz, like overkill, but clean.
2. I star grounded directly to the PAD on the IC, with fat mutli-core wires, to minimize any digital switching currents that might be in the analog ground path.
3. I heavily filtered the VAG pin, with 4 separate caps. Each a decade apart, to try to ensure that the bypassing is truly even across the entire working frequency range.
4. I added a small resistor between VDDIO and its regulator, to try and force digital switching currents to bypass through the 0.1uF cap and not through the ground circuit if possible. Although having a tied ground under the chip makes the validity of this questionable.
6. I took all input signal grounds also directly to the star point on the chip.
7. I added a 3rd order differential input anti-alias filter before the ADC, driving it from balanced line inputs and referenced to VAG through a buffer. Its clean and frequency response as good as expected from 3rd order. This helped the most, by changing the characteristics of the noise. Significantly less alias artifacts, and more pink hiss. But still I see 4-5 bits of noise.
8. I tried both increasing and reducing the various bias currents in the chip, no obvious effect.
9. I tried disabling and just freezing the ADC HPF, little effect.
10. I switched off ZCD on both HP and ADC, this was slightly noticeable. But nothing dramatic.
Bottom line, nothing helped much. I've spent so long now with different approaches, I just can not get down to 14bits. I have kinda shaped the noise into something palatable, but its not exactly hi-fi. I think 14bits would be acceptable but loosing 4-5 bits is very much border-line.
Things I have not done.
1. Separated the Teensy 3.2 from directly above the codec. I might try a little spaghetti see if I am coupling across the few mm the separates them.
2. Totally split the AGND and DGND. This is almost impossible without major surgery on the audio shield board.
Has anyone ever gotten 14bits precision out of the SGTL5000?
I've run out of ideas, any help much appreciated.
Aidan
Well this little codec is stubborn. I just would like to run a few questions by you all, see if you have any experience beyond my experiments. Having looked at the specs of the SGTL5000, when running on VDDA of 3.3V we should expect 90dB dynamic range from the ADC. Now this is already only 14bits precision. However I can not get any better than 12bits, in fact a little less than 12 in fact. I have tried just about everything I can think of to reduce this noise. Just as a run down.
From what I can see the audio shield has AGND and DGND tied together directly under the codec. I can't see this for sure, but I think it's obvious as the PAD of the IC is available on the non-component side of the board and all the digital grounds disappear under the IC. The AGND IC pin only pops out to be attached to the bypass caps. So with this in mind.
1. I connected VDDA giving it its own regulator and LC filters on the rails, much bigger than those on the board, should have -3dB at < 500Hz, like overkill, but clean.
2. I star grounded directly to the PAD on the IC, with fat mutli-core wires, to minimize any digital switching currents that might be in the analog ground path.
3. I heavily filtered the VAG pin, with 4 separate caps. Each a decade apart, to try to ensure that the bypassing is truly even across the entire working frequency range.
4. I added a small resistor between VDDIO and its regulator, to try and force digital switching currents to bypass through the 0.1uF cap and not through the ground circuit if possible. Although having a tied ground under the chip makes the validity of this questionable.
6. I took all input signal grounds also directly to the star point on the chip.
7. I added a 3rd order differential input anti-alias filter before the ADC, driving it from balanced line inputs and referenced to VAG through a buffer. Its clean and frequency response as good as expected from 3rd order. This helped the most, by changing the characteristics of the noise. Significantly less alias artifacts, and more pink hiss. But still I see 4-5 bits of noise.
8. I tried both increasing and reducing the various bias currents in the chip, no obvious effect.
9. I tried disabling and just freezing the ADC HPF, little effect.
10. I switched off ZCD on both HP and ADC, this was slightly noticeable. But nothing dramatic.
Bottom line, nothing helped much. I've spent so long now with different approaches, I just can not get down to 14bits. I have kinda shaped the noise into something palatable, but its not exactly hi-fi. I think 14bits would be acceptable but loosing 4-5 bits is very much border-line.
Things I have not done.
1. Separated the Teensy 3.2 from directly above the codec. I might try a little spaghetti see if I am coupling across the few mm the separates them.
2. Totally split the AGND and DGND. This is almost impossible without major surgery on the audio shield board.
Has anyone ever gotten 14bits precision out of the SGTL5000?
I've run out of ideas, any help much appreciated.
Aidan
I just wanted to add, there seems also to be rather obvious problems with channel separation with the SGTL5000. I was hoping to try using the L & R channels as differential inputs, as I only need one channel for my project, its a digital crossover for an active speaker. Therefore each speaker has its own teensy setup. However as the SGTL5000 has only a single ADC, this approach probably wont work too well, as it is sampling a slightly different time points. I already tried to see if subtracting L from R would improve the noise, it does not, but even so, this approach will buy me 3dB gain, as I will have twice the dynamic range from the input. Its probably the best option I have left to get the noise down further.
How goes development on the higher quality codec Paul?
I wonder what thoughts you have around choice of codec. From my perspective 24bits is nice to have, but at the end of the day. I am happy with 16bits, so long as it can actually be achieved. Just my 2 cents, I would like to see:
1.True stereo ADCs. With externally drivable VAG.
2. Differential inputs on the ADCs if possible. (Like the one inside the Teensy MCU actually!) I wonder if its would actually perform better.
3. A board layout with proper ground plane and separated AGND and DGND, giving the option as to where they are joined.
I'm not the most experienced with codecs, but I have worked on a few, and every time without fail, achieving data-sheet levels of performance has evaded me. What am I doing wrong?
Aidan
How goes development on the higher quality codec Paul?
I wonder what thoughts you have around choice of codec. From my perspective 24bits is nice to have, but at the end of the day. I am happy with 16bits, so long as it can actually be achieved. Just my 2 cents, I would like to see:
1.True stereo ADCs. With externally drivable VAG.
2. Differential inputs on the ADCs if possible. (Like the one inside the Teensy MCU actually!) I wonder if its would actually perform better.
3. A board layout with proper ground plane and separated AGND and DGND, giving the option as to where they are joined.
I'm not the most experienced with codecs, but I have worked on a few, and every time without fail, achieving data-sheet levels of performance has evaded me. What am I doing wrong?
Aidan
Hi Paul et al,
Just wanted to let you know. I have totally re-written my driver library for the mbed platform. It now uses DMA. Much better I feel. I have published it and it is available here:
https://developer.mbed.org/users/aidan1971/code/SGTL5000/
Also supporting 192Kb/s. Though even so, at this rate the time available on the Teensy to do anything is very limited.
Maybe you would like to link to it from the Teensy information pages. I for one would have bought a Teensy much sooner if I knew that a codec with functional library was available.
In regard to the noise. I have cleaned everything up to a level I feel I can not improve on. However I will push further. Bottom line I now have separate regulation to each element. (VDDA, VDDD, Teensy). I have LF noise (< 200KHz) on the VDDA at around 800uV (with high frequency interference 10Mhz+) not sure what difference it will make trying to suppress this. I have placed a ground plane, (copper board, parallel to the Teensy shield). Brought every ground connection through onto the ground plane, split return paths as much as possible, and broken any traces on the Teensy shield where appropriate.
Bottom line, the noise is now very much pink, a smooth and consistent hiss, with no evidence at all of digital artifacts. However the noise is there, persistent and constant. around 4-5 bits peak-2-peak. So let's call that 2-3 bits RMS. Have I really hit the limit of this codec?
Regards
Aidan
Just wanted to let you know. I have totally re-written my driver library for the mbed platform. It now uses DMA. Much better I feel. I have published it and it is available here:
https://developer.mbed.org/users/aidan1971/code/SGTL5000/
Also supporting 192Kb/s. Though even so, at this rate the time available on the Teensy to do anything is very limited.
Maybe you would like to link to it from the Teensy information pages. I for one would have bought a Teensy much sooner if I knew that a codec with functional library was available.
In regard to the noise. I have cleaned everything up to a level I feel I can not improve on. However I will push further. Bottom line I now have separate regulation to each element. (VDDA, VDDD, Teensy). I have LF noise (< 200KHz) on the VDDA at around 800uV (with high frequency interference 10Mhz+) not sure what difference it will make trying to suppress this. I have placed a ground plane, (copper board, parallel to the Teensy shield). Brought every ground connection through onto the ground plane, split return paths as much as possible, and broken any traces on the Teensy shield where appropriate.
Bottom line, the noise is now very much pink, a smooth and consistent hiss, with no evidence at all of digital artifacts. However the noise is there, persistent and constant. around 4-5 bits peak-2-peak. So let's call that 2-3 bits RMS. Have I really hit the limit of this codec?
Regards
Aidan
Paul, I thought I would let you know a couple of things.
Regarding the noisy SGTL5000. I did find a little something, quite interesting. The CODEC has a debug register, one of the options is to disable dithering. This is enabled by default. Hey presto, full resolution. Hmmm, well, I don't suppose they enabled dithering by default for no reason! Anyway I think this explains the noise floor.
Secondly. I have fully re-worked my mbed library for the SGTL5000. It now supports dual codecs, and all the double buffer pointer swaps for DMA etc are coded in assembler, so the library takes <800nS to do its thing every FIFO shift. Still available at the same URL you see in this thread below.
I can see that I'm rather alone when using Teensy on the mbed environment. However as I said, I like it. No frills... and well, maybe a little extra effort, but easy does not force the learning curve. I kinda like it that way. A big thanks for your efforts with the Teensy platform. It really is a very compact and useful Teensy weensy thing. I like it!
Regards
Aidan
Amazing work on the noise performance!
Aidan: This is amazing work! Over here I've tried the Fe-Pi for the raspberry pi. Also an SGTL5000 based board. It also has the same problems. ADC noise is extreme. DAC noise is fine. Now making my own SGTL5000 board, and the same ADC problems pop up.
So, what in your experience was _the_ main fix to improve the ADC SNR? Was it adding separate regulation for every element? The DEBUG bit made me twitch a little. The fact that dithering is off by default creates the impression that nobody ever got the SNR up to a point where it would ever be necessary. Lol.
Aidan: This is amazing work! Over here I've tried the Fe-Pi for the raspberry pi. Also an SGTL5000 based board. It also has the same problems. ADC noise is extreme. DAC noise is fine. Now making my own SGTL5000 board, and the same ADC problems pop up.
So, what in your experience was _the_ main fix to improve the ADC SNR? Was it adding separate regulation for every element? The DEBUG bit made me twitch a little. The fact that dithering is off by default creates the impression that nobody ever got the SNR up to a point where it would ever be necessary. Lol.
Hi,
I never truly solved it. Every step I took made subtle improvements but in the end I came to the conclusion that it is what it is. The CODEC itself does not have exactly hi-fi quality datasheet specs. 85dB SNR. I suppose this is quoted under ideal conditions, but its not great. Indeed if you take a look you see that in bypass mode (ie. not using the ADC) the SNR goes up to 98dB. Although I'm not 100% sure, I also think the ADC its also multiplexed between L & R inputs. There is only really a single ADC.
Anyway, well regulated separate supplies. Careful separation of analog and digital grounds and careful pre-filtering, it was possible to get close to the specs given, but I turned my attention to other devices. I became convinced that the biggest issue is that the ADC does not have differential inputs. At such low signal levels at the ADC front end, you require super clean ground and references, with low uV levels of accuracy. In the application I have been developing, which has power amplifiers just a short copper hop away which are delivering +1000W of audio output, truth is I could not keep it clean enough.
Having said all this, I would like to add that I think Paul made an excellent choice in the SGTL5000. It packs a lot of very useful relatively easy to implement features in a very low cost device. It a great little CODEC. I imagine for battery operated low power applications it is excellent. I came to love it really.
But it is a bit noisy, Still I might well go back and give it another try
But in reality I think I would need an ADC with differential inputs. BTW the Teensy itself has a differential input ADC and it also implements hardware averaging. If it was not for the fact that I need some external DSP functions from any codec I choose, I would actually see just how much mileage it was possible to get out of the Freescale chip and use the SGTL5000 as just a DAC.Good luck
Aidan
Hi,
I never truly solved it. Every step I took made subtle improvements but in the end I came to the conclusion that it is what it is. The CODEC itself does not have exactly hi-fi quality datasheet specs. 85dB SNR. I suppose this is quoted under ideal conditions, but its not great. Indeed if you take a look you see that in bypass mode (ie. not using the ADC) the SNR goes up to 98dB. Although I'm not 100% sure, I also think the ADC its also multiplexed between L & R inputs. There is only really a single ADC.
Anyway, well regulated separate supplies. Careful separation of analog and digital grounds and careful pre-filtering, it was possible to get close to the specs given, but I turned my attention to other devices. I became convinced that the biggest issue is that the ADC does not have differential inputs. At such low signal levels at the ADC front end, you require super clean ground and references, with low uV levels of accuracy. In the application I have been developing, which has power amplifiers just a short copper hop away which are delivering +1000W of audio output, truth is I could not keep it clean enough.
Having said all this, I would like to add that I think Paul made an excellent choice in the SGTL5000. It packs a lot of very useful relatively easy to implement features in a very low cost device. It a great little CODEC. I imagine for battery operated low power applications it is excellent. I came to love it really.
But it is a bit noisy, Still I might well go back and give it another try
Good luck
Aidan
Thanks for the detailed response!
Oh, the DAC of the SGTL5000 is really good for the price, and the relatively painless configuration. There are better DACs out there for the same price (some don't even require external XTAL), but they don't have headphone amps. It's the ADC that's the weak bit, like you have mentioned and have tried to counter...
I studied the gerbers of the SGTL5000 Tower Board (have you looked at it?), and indeed they also use split ground planes, hooked up by vias in the ground pad of the SGTL. However, they also use a 4 layer board, ferrite beads everywhere, and the DC/DC converter with inductor and big caps are right next to the CODEC. This increases cost, but maybe it's better than regulating all supplies. Sadly, I don't have this board, and I doubt it's still available..
Tower board schematics:
https://www.nxp.com/downloads/en/schematics/TWR-AUDIO-SGTL-SCH.pdf
Tower board layout & gerbers:
http://cache.nxp.com/files/soft_dev...printed_circuit_boards/bom/TWR-AUDIO-SGTL.zip
In any case VDDD is not connected, and they use the same supply for analog and digital (but supplied over a split plane). This seems to be the very opposite of what you had done, so I'm puzzled.
.. In any case, adding all those components quickly reduce all the cost benefits of such a cheap CODEC. I'm now opting for a Cirrus Logic one (Wolfson): the WM8960, which seems to have a much better ADC, but is 60-70% more expensive. About the differential inputs.. This only raises the SNR 3dB, right? But I understand that any noise on the AGND will definitely affect the ADC, yes. I just wonder why the DAC seems immune to it. Is the ADC input attenuated or so?
- Status