Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 9 of 9

Thread: sgtl5000 32 bit ADC and DAC

  1. #1

    sgtl5000 32 bit ADC and DAC

    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?

  2. #2
    Senior Member
    Join Date
    Jul 2020
    Posts
    1,042
    96kSPS is the highest supported data rate according to the datasheet, which uses MCLK = 24.576MHz (x256)

  3. #3
    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?

  4. #4
    Senior Member
    Join Date
    Jul 2014
    Posts
    3,159
    Quote Originally Posted by Neal View Post

    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?
    You may look into
    https://github.com/WMXZ-EU/test_sgtl5000

    above 240 kHz there is some degradation

  5. #5
    Senior Member
    Join Date
    Jul 2020
    Posts
    1,042
    Quote Originally Posted by Neal View Post
    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.

  6. #6
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    24,270
    Quote Originally Posted by Neal View Post
    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).

    Click image for larger version. 

Name:	DSC_1371_web.jpg 
Views:	27 
Size:	152.6 KB 
ID:	23882

    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.

  7. #7
    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.

  8. #8
    Senior Member
    Join Date
    Jul 2014
    Posts
    3,159
    Quote Originally Posted by PaulStoffregen View Post
    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.

  9. #9
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •