• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 30 subscribers
  • Views 361 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TLV320ADC3101: AOSR selection for Fs 10416.66667Hz operation (16MHz MCLK)

Avrum Hollinger
Prodigy 10 points
Part Number: TLV320ADC3101


Target operation: TLV320ADC3101, Fs 10416.667 Hz, MCLK = 16MHz, Decimation filter A, Processing block PRB_R1.

I see in the datasheet that for processing block PRB_R1, it states the required AOSR values are 128 and 64. The datasheet also states 2.8 MHz < AOSR × ADC_fs < 6.2 MHz

We have a 16MHz MCLK (system clock), and to get our targeted Fs is 10416.66667Hz, we would divide MCLK by 12 for 128x oversampling, however that would result in AOSRxADC_fs = 1.333MHz < 2.8MHz.  Is the selection of 64 or 128 for decimation filter A a requirement, or can I use an AOSR value of 256? I don't understand why all of the values are available from 1..256, if only the required AOSR values from table 6 are 32, 64, and 128.

Regards.

  • 0
    Prodigy 10 points

    Also, in 11.2.2.1, equation 8 uses the value RC, with a note "RC is a function of the chosen processing block and is listed in the Resource Class column of Table 5." However Table 5 has no such column listed as Resource Class, and "Resource Class" has no other mention in the datasheet. Please correct the datasheet.

  • 0 in reply to Avrum Hollinger
    TI__Genius 13610 points

    The chosen sampling rate and MCLK are are incompatible to the device, you will need end up changing both. Change the Fs to : 8 kHz, 11.025 kHz, 12 kHz, 16 kHz, 22.05 kHz, 24 kHz, 32 kHz, 44.1 kHz, 48 kHz, 88.2 kHz, or 96 kHz and adjust MCLK accordingly until requirement is met.

    10416.66667Hz for sampling rate is not really a option to run at all.

  • 0 in reply to Carson Allen
    Prodigy 10 points

    Can you provide an example configuration for 8kHz, please? I think the same (above) issue applies with respect to AOSR and the constraints detailed in the datasheet.

    If Fs = 8kHz, for AOSR=64, 64*8000 = 512kHz < 2.8MHz

    If Fs = 8kHz, for AOSR=128, 128*8000 = 1.024MHz < 2.8MHz

    These constraints seem to be independent of MCLK, so I'm not sure why that's a consideration. Nowhere does it say that these sample rates (i.e., 8 kHz, 11.025 kHz, 12 kHz, 16 kHz,
    22.05 kHz, 24 kHz, 32 kHz, 44.1 kHz, 48 kHz, 88.2 kHz, and 96 kHz)  are exclusive, rather the datasheet says "The converters can also operate at different sampling rates in various combinations" --- so I don't see why a sampling rate of 10.416kHz is incompatible.

  • 0 in reply to Avrum Hollinger
    TI__Genius 13610 points

    Hello 

    Let me look more thoroughly through these settings and I will respond this next week

    Carson

  • 0 in reply to Carson Allen
    TI__Genius 13610 points

    Hello,

    I admit it could be done but the datasheet seems to be steering against using the frequency you want by pushing towards using the specific lower AOSR to get best performance, so using that sample rate is doable but not anticipated by the design which could factor into quality of output.

  • +1 in reply to Carson Allen
    Prodigy 10 points

    Thanks Carson, though without you putting specific numbers to what you're saying, I'm not clear on what (over) sampling rates you think are achievable.

    I think if TI could give an example of how they suggest an 8kHz sampling rate be achieved, as it is stated that this is a supported sampling rate, we would see where the datasheet needs to be updated (as it is obviously deficient).

    After my own testing, I can say that 10.416kHz is achievable with 128x oversampling. Oversampling at 64x is operational but less performant, however 256x oversampling is degraded and glitchy (and likely out of spec).  Also, oversampling at 120x or 136x seems operational (so 64 and 128 do not seem to be the only acceptable choices as stated in the datasheet).

    How do we get TI to improve the datasheet?

  • 0 in reply to Avrum Hollinger
    TI__Genius 13610 points

    Hello Avrum,

    I agree with what you're saying and am not completely sure myself of what is achievable as my department received these parts from a different team so I have little lab experience with them. The datasheets we publish go through revisions over time when items such as this are noticed, but with large demand and large portfolio, our ability to update our datasheets can take longer periods of time then what would be optimal.

    Situations anticipated were tested and reflected in the datasheet but not everything can be anticipated given the diverse uses of our products and variations of them, but we do try to do the best we can to provide the detail for other engineers to use our product as they desire and thus revisions eventually come to being though it can be a not so simple process.

    Best Regards,

    Carson