sgtl5000 32 bit ADC and DAC

Status
Not open for further replies.

Neal

Well-known member
In my application, everything I am using 32 bit integers exclusively. I would like to use the 32 bit mode in the sgtl5000 as well.

As far as I can tell the following lines of code from the i2s library are already transferring things in 32 bit mode:

I2S1_TCR4 = I2S_TCR4_FRSZ((2 - 1)) | I2S_TCR4_SYWD((32 - 1)) | I2S_TCR4_MF | I2S_TCR4_FSD | I2S_TCR4_FSE | I2S_TCR4_FSP;
I2S1_TCR5 = I2S_TCR5_WNW((32 - 1)) | I2S_TCR5_W0W((32 - 1)) | I2S_TCR5_FBT((32 - 1));

I2S1_RCR4 = I2S_RCR4_FRSZ((2 - 1)) | I2S_RCR4_SYWD((32 - 1)) | I2S_RCR4_MF | I2S_RCR4_FSE | I2S_RCR4_FSP | I2S_RCR4_FSD;
I2S1_RCR5 = I2S_RCR5_WNW((32 - 1)) | I2S_RCR5_W0W((32 - 1)) | I2S_RCR5_FBT((32 - 1));

When I view the Din and Dout sgtl5000 signals on an oscilloscope, 32 bit data is being sent from the ADC and I can write 32 bit data to the DAC. However, the library control_sgtl5000.cpp sets the device for 16 bit operation with this instruction:

write(CHIP_I2S_CTRL, 0x0030); // SCLK=64*Fs, 16bit, I2S format
//write(CHIP_I2S_CTRL, 0x0000); // SCLK=64*Fs, 32bit, I2S format

When I use the commented out line enabling 32 bit mode, the Din and Dout are the same as when it is set for 16 bit operation.

Am I missing something, or does the sgtl5000 always input/output 32 bit data? Or is there a way you can get to 192 kHz if you use 16 bit mode only?
 
96kSPS is the highest supported data rate according to the datasheet, which uses MCLK = 24.576MHz (x256)
 
Yes I realize that the it is only spec'd to 96 kHz. I guess I was hoping there was some magical overdrive mode.

The real dilemma I am having is that it appears the sgtl5000 ADC outputs 32 bits and the DAC accepts 32 bits no matter what the CHIP_I2S_CTRL register is set to. If it always running in 32 bit mode, why have the control bits in the register?
 
If it always running in 32 bit mode, why have the control bits in the register?

Because chips like this are synthesized from hardware description libraries shared between many other chips, the
silicon foundaries don't start afresh for each design, they have libraries of functional blocks and just plonk them
in - the generic I2S interfacing block clearly supports several datawidths.

I see nothing to indicate the SGTL5000 ADC/DACs are any more than 16 bit - the performance is commensurate
with this - however they might be 20 bit or 24 bit, its hard to tell without detailed characterization - if you get
32 bit streaming working you'll be able to figure this out by feeding signals below the 16 bit LSB level.

Since its got its own DSP blocks it makes sense that the interface is more than 16 bits whatever the precision of
the ADC/DAC, to reduce quantization noise in the effects processing.
 
The real dilemma I am having is that it appears the sgtl5000 ADC outputs 32 bits and the DAC accepts 32 bits no matter what the CHIP_I2S_CTRL register is set to.

This is how I2S works.

Teensy sends BCLK and LRCLK to the SGTL5000 chip. Then it transmits data bits on each BCLK. In the mode we use, the SGTL5000 has no control over the clocks. It has to use whatever clock it gets from Teensy.

The I2S protocol automatically adapts to the number of bit times the clocks offer. If there are only 16 bit times and the chip has more data bits, it only transmits the 16 most significant bits and the rest are discarded. If the clock offers 32 bit times and the chip has less than 32 bits, it transmits all the bits is has and then just sends logic low during the other bit times.

Here is a capture of the actual LRCLK, DATA, BLCK between Teensy 4.1 and the audio shield (rev D).

DSC_1371_web.jpg

Normally I just do a screen capture. But the scope's screen capture gives a single waveform snapshot. I guess I could turn on persistance or other fancy features, but instead I used a camera with a long 1/10 second exposure, so you can get a better look at how the waveforms really appear (sorry, shooting a video clip is beyond what I'm doing for this message).

Teensy transmits 44.1 kHz LRCLK and 2.82 MHz BCLK, so there are 32 bit times on each phase of LRCLK. You can clearly see the SGTL5000 is transmitting 24 bits and always sending zeros in the final 8 bits.

You can also see the bottom 9 to 10 bits are pretty much random. I did this test with wires shorting the line level inputs to GND. Even though it sends 24 bits, the reality is not even the top 16 bits are all noise free. I'm sure a number of people might debate whether there's something useful in those lower mostly-random bits. Even if you don't agree those lower bits are "totally worthless", I hope you can get a sense from this image of how little value they really offer.

Even though Teensy transmits 32 bit times, we only capture the data bits from the upper 16.



If it always running in 32 bit mode, why have the control bits in the register?

That is indeed a very good question.

Usually those settings only have any effect when the chip is transmitting BCLK and LRCLK. In that mode, it needs to know how to create those clocks, since it is in charge of making them and sending them.
 
Thanks for the responses. Paul I did the same test you did with two exceptions. I bypassed the line in and line out series capacitors and fed in a very clean DC signal into the ADC and measured the DAC DC output signal. Also, I was running at 96 Khz.

My scope has an i2s decode mode so I could display the actual 32 bit data in and out. I thought I received relatively stable data over the 32 bits.

Here is the problem however. I had a brain freeze and accidently reversed the DC voltage into the line in to the ADC and blew up my chip. I ordered a new Audio board this weekend and will rerun the test. I will post the i2s output I get when I rerun the test. I may have made a mistake in my first test.
 
You can also see the bottom 9 to 10 bits are pretty much random. I did this test with wires shorting the line level inputs to GND. Even though it sends 24 bits, the reality is not even the top 16 bits are all noise free. I'm sure a number of people might debate whether there's something useful in those lower mostly-random bits. Even if you don't agree those lower bits are "totally worthless", I hope you can get a sense from this image of how little value they really offer.
As I'm one of the people Paul is most likely referring to.
What you see on a scope is broadband noise. However, if you look to a spectrogram you can see tonal that are not easily seen on broad band time series. Sure, the human ear has some finite bandwidth exceeding well 1Hz, but human ears are not everyone's application.

Note, I do not argue that all the 24 bits are useful, but 18 (108 dB//MSB) should be possible with good signal conditioning.
I do also not argue, that SGTL5000 is the best ADC on the market, but it's cost-effective up to 16 bit (96 dB//MSB).
And finally, the whole signal conditioning is extremely important.
 
I got my replacement Audio board running and reran my tests. I reconfirmed that Paul's observations are accurate in my test setup as well. The ADC transmits 24bits regardless of the CHIP_I2S_CTRL register data length setting. Additionally only about 14 bits of the ADC output remained stable, even with my direct DC into the LineIn pins. But I still have a fairly noisy prototype setup. I am confident When I have a clean analog chain into the sgtl5000 I will be able to extend the number of useful ADC bits. BTW, my application is in the spectral domain where the extra bits of ADC precision are very useful.
 
Status
Not open for further replies.
Back
Top