DIT4192/DIR9001 startup

John,

Are the MCLKs of the DIT4192 and DIR9001 synchronized to their BCLK, WCLK?   If you are able to send a schematic of the ADC, DIR and DIT clock schemes as well this may help to see if there are any issues. 

Hi Patrick,

Sorry for the delay.

The DIR is operating in master mode, so BCLK and WCLK are, by definition, synced. That having been said, I have checked each clock on each chip and all appear to be functioning properly (that is to say, they are synced and at the correct frequencies), regardless of whether it is passing audio or not.

I can send you the schematic for your review, but I would prefer to do so privately. Could I email it to you? 

John,

Since the DIR9001 is in master mode I assume it is being used in XTI mode, where the BCKO, LRCKO, SCKO are generated from the XTI source clock.  Please let me know if this is incorrect.  If this is the case, the DIT4192 is receiving a different mclk.  Is there a way to try the setup where DIT4192 receives the same mclk as SCKO or the XTI source?  This may help to make sure the DIT4192 is synchronized to the output data.

Hey Patrick,

You are correct, however the DIT4192 is on a separate board from the DIR. The only connection between the boards is the AES/EBU link.

My understanding is that, while the DIR is not in an error state (ie, the AES/EBU stream is good), SCKO, LRCKO,and BCKO are all driven by the internal PLL (and thus, at low offset frequencies, the DIT's MCLK). The XTI is only meant to be used when there is no AES/EBU line to lock to. This seems to be consistent with the behavior I've seen from the DIR, so as best I can tell, that part is working as I would expect it to.

What I can't figure out is why the DIR sometimes throws errors every 200 us or so. I don't think the XTI source can cause it to throw an error, correct? Or is there something I'm missing?

did you get to the bottom of this?

I have a DIR9001 doing exactly the same in slave from an I2S transmitter on seperate cards; oscillation is exactly as described

Unfortunately, no. The board that is giving me trouble is currently 400 miles away, so I can't do much more testing on it currently. Maybe you can help...

Perhaps we can start by looking at the eye diagram of the AES waveform at the input to the DIR.

To do this, you will want to probe the input of the DIR (pin 20) with CH A of your scope, while probing BCLK on the DIT board with CH B. You do not need to view CH B, but instead will trigger off its rising edge. Then, set your scope to "persist" mode (each trigger will be saved and overlayed on top of eachother) and let it run for 10 seconds or until the display stabilizes. Lastly, save the resulting waveform and post the result, if you can.

This will give a good starting point. If it falls within spec, the PLL should have no trouble remaining locked to it which would either point to a problem with the PLL or that something else is triggering the AES error output. If it does not fall within spec, then the PLL is probably just falling out of lock due to a bad input signal.

the data from the transmitter is identicle at the RX pin

for TI guys- should RX data be DC coupled or AC coupled (i am using DC but with the crystal chips it was always ac couple)

I have forced receiver to lock to PLL only, thinking this may be source of problem, but device does not lock to 11MHz clock, sits at about half this with the error pin oscillating

could this be to do with filter values for Pll? how are these determined?

regards

clutching at straws - are you running the DIT in Professional mode? (Css=0 Copy=1 L=1) or consumer mode?

How you reset DIR9001 receiver? I use 3pin reset chip MCP120T-300. Maybe your receiver have troubles with reset. And what about RXIN input? It has TTL levels. I used on his input RS485 transceiver 75176 which can convert single-ended commercial S/PDIF or differential professional AES to TTL levels. maybe there can be wrong voltage levels. Another troubles can be ground loops, if you don't use galvanic isolation. I used on input pulse transformer S22083 or DA102C. You can inspire with my S/PDIF receiver, which is available here: http://www.pavouk.org/hw/modulardac/en_dir9001spdif.html

Best regards, Pavel.

reset is from DS1233 so same as yours- boards are galvanically isolated using laser and pin diode receiver, this is an upgrade of a product I have had for 10 years using crystal chips, (moved to TI as it was supposed to be better parts, and had to do far more work than I wanted to do) so with crystal parts I know it works.

If I understand, that you still doesn't know if problem is on the transmitter or receiver side of AES/EBU link. First try to locate on which part is problem. Maybe you can try combine transmitter with other receiver. I have another idea. Check please values of PLL parts around DIR9001, if they are same like in datasheet. Maybe PLL is a little on the corner and have troubles with synchronising to input signal. Also there can be troubles with noise on voltage rails. I don't know if you have properly blocked voltages with capacitors around chip.

using one of my old crystal chipped units I have determined the receive section is fine, locks and receives from cs part; this also vindicates laser/pin section

so problem definately lies in the transmitter i suspect-

Spoke to soon- did a sanity check, DIT to cs8412- works fine as well

so problem only exists DIT to DIR

Now I am at a loss

as the error pin oscillates, the clock strobe fires; the PLL is at 8.3MHz not 12.288 on average as the lock appears to be ok for 8ms unlocked for 20ms

another interesting effect on the generator pcb is that when csel is set for internal clock, the error pin remains high all the time, whether you give it a pll source or not

_ can I get any response from a texas apps engineer please?

Anthony,

Looking at the schematic, it still seems as though the master clock on pin4 of the DIR9001 does not go anywhere, and the DIT4192 is receiving a separate MCLK altogether.  Is there any testing that can be done using the SCKO (pin4) of DIR9001 as the MCLK source for the DIT?  This is something that is usually done to ensure synchronization, an example figure may be pg 26 of the SRC4192 datasheet.

http://www.ti.com/lit/ds/symlink/src4192.pdf

Patrick-

the clocks from both DIR goes to the cpld(IC1), where a valid recovered clock is chosen(and distributed as MCK), or the top DIR is set to internal oscillator mode and all clocks taken from there; so all clocks are syncronous.

I have scoped all the signals and they are spot on. the issue is PLL based i think, but cannot work out what; for the system we use a 10MHz clock, and this is the bit that has me puzzled:

If I apply an aes/ebu signal from an idendical board using the CS8402 through the pin diode, the DIR locks perfectly and the output is fine, when I connect a CS8412 to the laser output of the DIT, it locks perfectly and everything is fine; when I connect DIT laser  to DIR PIN on seperate or the same board, the PLL is unstable and waves around the 10MHz frequency, causing multiple unlocks (error pin oscillates)

this suggests there are no layout issues in the receiver and transmitter sections, as they work with other parts through the same interface; if the receiver had a layout problem it would not lock from any source, and would exhibit the same characteristics, clear lt it does not do that only issue is when fed from a DIT source

this gets stranger-

I have put a crystal unit at the head of the chain, and all works fine down a chain of 3 units; CS8402>dir9001-DIT4096>dir9001

if I put the crystal part at the head of the chain, and measure the Clock out of the receiver on the ti part board, it is in phase with minor jitter on the edges;

If I put the TI board ahead of another TI board the clock jitter is massive between the two waveforms, going way out of sync, hence errors

if I short the 10MHz crystal on the start TI unit, and release, the clocks down the chain sync for a few minutes then drift; this does not happen with the cs8402 board ahead of the chain. this does not happen if I force a reset of the parts

looking at the XTO of the DIR on the TI board at the head of the chain, the ouput is modulated (ie not stable) and this looks to be the route cause of the problem

Any ideas on stabalising the oscillator? I have improved stability by strapping a 10 meg across the xto/xti pins (this is supposed to be internal) and messed with the cap values but it is still modulated

After conversations with TI apps engineers, the problem is with the internal oscillator in the DIR9001; it will not work stably with any other crystal than the 24.576 MHz crystal specified; with any other crystal say 10MHz otherwise it is not stable and jitters between 10 and100KHz; this is not a good result and should be made a lot more clear in the data sheet, pointing to the table 12 in the back on differences with the DIR1703 which lists all the crystals for sampling rates on the 1703 and only one crystal for the 9001 does not suffice.

going to try an external oscillator into the xti pin of the dir to still use the divider chain, otherwise I will have to impliment it seperately.

Unfortunately this will be a board revision, not good with the timescales I have- I am seriously dissapointed with the TI parts

Ok, so I have replaced the XTI with a 24.576MHz clock on both the DIT and DIR and adjusted freq select pins accordingly. Unfortunately, now the DIR only ever tries to output a 96kHz signal. Regardless of what frequency the DIT is set to transmit (I have tried with a measured pulse width at the RX pin of 6.144MHZ and 12.288MHz), the DIR only ever tries to send its output sample rate of 96kHz.

The DIR is set for scko of 512 x fs, which should be 24.576M and 48kHz, respectively. Instead, I am seeing 2x that (and it is failing to lock because of this, of course).

Any thoughts would be greatly appreciated.

it looks like you are set to take the timing chain from the XTI input, which is set in its divide mode and cannot be altered; check the clock source settings or the value of the error pin.

I had enormous expense and trouble with this chipset and will never use again; I have gone back to the slightly more expensive but far better Cirrus parts- unless you are making an external dac these parts are not good

Yeah, I was really hoping I could make these work, but that is looking less and less likely...

Actually, I am using it in automatic mode (error tied to clksel).