DIX4192: SPDIF-output: AESOUT vs. TX

Intellectual 280 points

Replies: 24

Views: 167

Part Number: DIX4192

Hello TI,

I just received the prototype boards with the SRC4192 as an SPDIF-input / receiver,

and I have a working SPDIF-transmitter based on a DIX4192.

Between DIX4192 = transmitter and SRC4192 = receiver are optical drivers and receivers, working with 3.3V.

All worked fine until I switched the transmitter's sampling rate to 192kHz: the receiving SRC4192 could not lock.

I checked the receiver with other 192kHz sources (Crystal's codec CS4265 and some XMOS chip): no problem at all with 192kHz.

After many other failed attempts I finally changed the DIX4192 = transmitter side from AESOUT to TX+, and lo and behold, that works!

I checked both signals (AESOUT / TX+) on an oscilloscope, and they look identical.

Crystal's CS8422 has no problem receiving data when the transmitter is using AESOUT.

So what is going on there?

Is there some "PRO"-bit set with AESOUT or anything else?

24 Replies

  • Correction:

    the receiver is the SRC4392, not the SRC4192.

  • ... and still having loss of lock every now and then.

    Only with 192kHz or 200kHz as input sample rates.

    This does not happen with the CS8422 as SPDIF receiver, and not with the CS4265 as a transmitter...

    ???

  • In reply to Christian Erle55:

    Christian Erle55

    ... and still having loss of lock every now and then.

    Only with 192kHz or 200kHz as input sample rates.

    This does not happen with the CS8422 as SPDIF receiver, and not with the CS4265 as a transmitter...

    ???

    Did you see my response to your other question?

  • In reply to Christian Erle55:

    Hi Christian, 

    I'm sorry you are having these issues. One thing to consider is that the AESOUT does not have the same drive strength as the TX+ pin, so it may be possible if you have any series resistance on this line and/or sufficient parasitic capacitance that the AESOUT pin is unable to keep up with the slew rate necessary to drive a 192kHz signal at 3.3V. 

    Another possible source of error is that the DIT transmitter on DIX4192 and DIR receiver on SRC4392 both require reference clocks that should be multiples of your intended sample rate, and if the reference clock you are providing has too much jitter this could potentially lead to missing clock edges, which will cause the DIR to unlock (even missing a single edge can be problematic). It may be that the Cirrus receiver you are using is more tolerant to this jitter, but I'm not sure.

    Best,

    Zak

    Regards,

    Zak Kaye
    Precision Data Converter Applications

  • In reply to Andy Peters:

    Hi Andy,

    over here in Germany, 7AM now, work starting...

    To your reply in the other thread:

    I definitely need the SRC, and it is in the signal path:

    SPDIF --> RX1 --> SRC --> I2S (MCLK)

    I know that the PLL-settings refer to the known MCLK, so I change these registers according to the I2S / MCLK-side.



  • In reply to Zak Kaye:

    Hi Zak,

    1) drive strength: no, I checked it on the scope, signals look perfect, nice flanks, no overshoot. And AESOUT works with the CS8422 as a receiver. As I said, on the scope the AESOUT and TX signals look identical.

    2) jitter: no, pretty sure that we're really clean on that too, because our analyser software is providing high resolution FFTs and signals are super clean.

    Our system is used for NVH stuff including high resolution RPM measurements, so we need to have clean clocks.

    So this new prototype board with the SRC4392 is part of that system, the sender with the DIX4192 is obviously another external device, but running on similarly accurate clocks.

    Yesterday I checked every signal, played with every component in the signal path and with all the registers on both sides, still losing lock regularly with SPDIF rates of 192kHz and 200kHz.

    Any more ideas?

    I do not want to switch back to the CS8422 because it does not provide full access to channel status and user data.

  • In reply to Christian Erle55:

    Christian Erle55

    Hi Andy,

    over here in Germany, 7AM now, work starting...

    To your reply in the other thread:

    I definitely need the SRC, and it is in the signal path:

    SPDIF --> RX1 --> SRC --> I2S (MCLK)

    I know that the PLL-settings refer to the known MCLK, so I change these registers according to the I2S / MCLK-side.

    Hi, Christian,

    It's evening here in the US, almost time to sleep,

    I am looking at my code for a recent SRC4392 design I did and I use the same signal path you describe. I have a fixed reference clock of 24.576 MHz, input on the RXCKI pin. This clock is constant, regardless of input sample rate. Therefore, the PLL1 register settings never change. This is the key thing to understand here.  PLL1 generates a high-frequency clock (98.304 MHz) that is used to oversample the incoming AES3 signal and decode it.

    PLL2 takes the output of the AES3 decoder and synthesizes a new MCLK (called RXCKO) which is at the correct oversampling frequency for the input sampling frequency, that is for a 48 kHz sample rate input RXCKO is 12.288 MHz and for 44.1 kHz RXCKO is 11.2986 MHz. Note that the latter is [I]not[/I] related to the PLL1 reference clock! I've verified this in my design up to 192 kHz (from an XMOS thing, yes) and indeed it works for all sample rates. The data sheet even says that you can use the common 27 MHz clock for the PLL1 reference clock, and that's not related to any standard audio sample rate, and the DIR still works.

    You should enable the RXCKO output pin and look at it with an oscilloscope to prove this for yourself. Also monitor the LOCK output, which tells the status of PLL2; when that's true, RXCKO will output a clock at the oversampling frequency related to the input. It is instructive to configure the chip to enable RXCKO to toggle even if PLL2 isn't locked.

    Next is the SRC block. This block too has a reference clock input, which should be at whatever rate your I2S port (and the DAC connected to it) should run at. So for 200 kHz output sample rate the SRC reference clock should be 25.6 MHz. For 192 kHz this should be 24.576 MHz. The only configuration for the SRC block is to set its input source (set it to the DIR output). The rate detector automagically determines the input-to-output rate ratio with no intervention required.

    All of this is a long-winded way of saying: [I]the only configuration you need for the signal path you describe is to set the PLL1 constants based on the reference clock you provide to the DIR.[/I] The rest of it just works. The only reason to change the PLL1 constants is if its reference clock changes, and generally there's no reason at all for it [I]to[/I] change.


    One more thing. ASRCs are commonly used to "clean up" jitter from the AES3 data. So while you could use the RXCKO output for your DAC's MCLK input, you get better converter jitter performance by using an oscillator for that. So this oscillator needs to drive the SRC reference clock as well as the DAC's MCLK. And it can drive the DIR's reference clock, too, as a convenience. And it must also be the audio serial port's (I2S port) master clock source. LRCLK and BCLK are divided down from that clock. 

    But if your I2S port drives a DSP or something not a DAC, then jitter on the recovered clock doesn't matter. The DSP won't take in the modulator clock, anyway, it'll just shift in using BCLK. So you could use RXCKO as the SRC's reference clock.

    Hope this helps. The part really does work as advertised.

  • In reply to Andy Peters:

    Hi Andy,

    thanks for your late night reply!

    I have already considered all the above in my design.

    Further info:

    - The SRC4392's port A I2S  is connected to an FPGA and is controlled like an ADC slave.

    - I2S sampling rate may change, our system offers 24/48/96/192kHz (with MCLK at 24.576MHz (or half for 24kHz)) and 25/50/100/200kHz (with MCLK = 25.6MHz or half).

    - The PLL1 registers are set according to the system's sampling rate / MCLK.

    - LOCK pin and lock interrupts are constantly monitored, and results are compatible with what I see in the audio output (data lost when lock is lost)

    - reference clock for RX is MCLK

    I have 3 sources for testing:

    1) some cheap XMOS USB-to-optical-SPDIF thing which can deliver up to 192kHz output (so nice to see the FFT of a digitally synthesized sine! ;-) ), this one has a standard TOSLINK optical output.

    2) a CS4265 codec with up to 192kHz output, optical driver is a versatile link thing AFBR-1624Z - which has the same wavelength as TOSLINK, but can easily drive 100m of optical cable, tested and working in industrial settings

    3) another prototype board with TI's DIX4192 and the same versatile link driver as in 2), now sourced by the TX+ pin

    Reference for comparison are existing SPDIF input boards with the CS8422, 2 versions with different optical receivers (TOSLINK & versatile link). These run in parallel with the exactly same I2S interfaces and signals. As mentioned before, the CS8422 versions are working perfectly with all 3 sources (even with the DIX4192's AESOUT output).

  • In reply to Christian Erle55:

    I checked the RXCKO output and played with the PLL1 registers:

    it's definitely the receiver and PLL1 which is causing the problems.

    When lock is lost, also RXCKO goes low, otherwise it shows the SPDIF's MCLK.

    So I played with the PLL1 register settings and found out that if I tune these, I can get a stable signal, no matter what the sampling rates are.

    The not so funny thing is:
    I have 2 identical prototype cards, after having tuned PLL1 with card 1 to about 100MHz (datasheet says 98.304MHz), on card 1 everything was stable.
    Then 1 used the exact same settings on card 2 (checked all components and connections) - and did not get always a stable signal. Very frustrating...

    Again, this problem occurs only with SPDIF sampling rate 192kHz or 200kHz.


    Below are the settings for card 1, which worked for every combination of IO rates:
    ("TAS" is our measurement system)

    for SPDIF sampling rates <=100kHz all combinations of TAS sampling rates
    and PLL1 settings work!
    
    TAS 200kHz, SPDIF 192/200, several sources
    SRC4392
    RX PLL1:
    0x21 0xDF 0xBD
    P = 2
    J = 7
    D = 8125
    K = 7.8125
    PLL1 = MCLK * K / P = 100.0000 MHz
    
    TAS 192kHz, SPDIF 192/200, several sources
    SRC4392
    RX PLL1:
    0x22 0x05 0x64
    P = 2
    J = 8
    D = 1380
    K = 8.1380
    PLL1 = MCLK * K / P = 99.9997 MHz
    

  • In reply to Christian Erle55:

    Christian Erle55

    - The SRC4392's port A I2S  is connected to an FPGA and is controlled like an ADC slave.

    - I2S sampling rate may change, our system offers 24/48/96/192kHz (with MCLK at 24.576MHz (or half for 24kHz)) and 25/50/100/200kHz (with MCLK = 25.6MHz or half).

    - The PLL1 registers are set according to the system's sampling rate / MCLK.

    - LOCK pin and lock interrupts are constantly monitored, and results are compatible with what I see in the audio output (data lost when lock is lost)

    - reference clock for RX is MCLK

    Ok, I admit I'm confused, let me understand it.

    1. The FPGA is an I2S data sink. For our purposes we can consider as you say that an ADC with I2S port is connected to the FPGA. Got it.

    2. The FPGA's I2S port is a slave, so the SRC4392 provides LRCLK and BCLK along with the data.

    3. Your design provides a 24.576 MHz clock or a 25.6 MHz clock to both the FPGA and to the SRC; only one is active at a time. The selected clock acts as the audio serial port A's master clock as well as the SRC's reference clock.

    4. For convenience reasons, the selected MCLK above is also used as the DIR (S/PDIF input) reference clock. When the clock changes, you load the correct PLL1 settings to ensure that PLL1's synthesized output is the 98.3 MHz noted in the data sheet.

    5. The idea here is to take the S/PDIF input at any sample rate (standard or not) and convert it to a specific sample rate which may be standard or not. (That's what ASRCs are for!)

    6. The problem: The DIR fails to lock reliably at either 192 kHz or 200 kHz input sample rates. As you note, this points to an issue with PLL1.

    So -- 

    The data sheet has a section on Page 40 titled "Applications Information." It has a peculiar recommendation:

    The substrate ground, BGND (pin 44), should be connected by a PCB trace to AGND (pin 10). The AGND pin is then connected directly to the ground plane. This connection helps to reduce noise in the DIR section of the device, aiding the overall jitter and noise tolerance for the receiver.

    There is also a comment about putting a small series resistor or a ferrite bead between the 3.3 V rail and pin 9 which is noted as "DIR comparator and PLL power supply."

    On my boards I did both (that series resistor is 5.1 ohms). Did you? My design locks the PLL reliably at 192 kHz. I can't test at 200 kHz because I don't have anything convenient that can generate S/PDIF at that rate.

    I assume TI wouldn't put such recommendations in the data sheet if they didn't matter. (And yeah, I know, some old converter data sheets offer the bad advice about splitting ground planes and joining them under the converter chip ...) This means that TI knows the receive PLL1 is sensitive to noise on its power supply rail and the substrate of the device, and these two suggestions are their mitigation.

    Anyway, that's about all I got. Good luck/