Its always better to slave the transport blah blah blah

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
regal said:
Ok the first diagram has an obsolete part CS8402A with TXP outputing a RS422 compatible line driver. The datasheet makes no mention of the clock coming out of TXP.

The cs8402a is an spdif transmitter. Of course you can use a newer part like cs8406, just work out the details.

The txp output is connected to an optical spdif transmitter (totx***). This spdif feed you will connect directly to a pc soundcard. You will be slaving the soundcard.

Then you take the spdif out from the card and input it to the cs8412. You´ll have a synchronous system and galvanically isolated (optical toslink), and no modding involved.

-Alexandre
 
The basics are simple but you need to work out how to adapt it to your particular configuration.

So, you create a DAC with a master clock in it, reclocking important signals. You have to take care of clock distribution :

* take the raw clock and use two buffers from it,
- one to feed the jitter-sensitive inputs of the DACs
- and another one to feed the rest of the circuit

* reclock the input signals
* etc

Then, you have to send the clock back to the digital source so that everything is in sync.

If your CD player uses the same clock freq as the DAC, you might be tempted to send the clock directly. It is doable but has its problems (sending a ~15 MHz signal through cables without impedance matching will make a nice radio transmitter).

The best solution is to use a SPDIF transmitter chip (the choice is yours) to generate a SPDIF signal with the DAC master clock. You can use a blank audio signal or not.

Then, you either use a soundcard which can sync on a SPDIF input, or add a SPDIF input to your CD player and a PLL to up the clock to the frequency the CDP likes. This way if you change CDP you just have to change the PLL settings.
 
regal said:
I think it is a hoax. DIY, no it hasn't been done.

It has been done DIY style: I do it all the time. You don’t often see it done in DIY projects because it requires basic knowledge of digital circuits and the use of synchronous counters. That’s something even our resident clock monger knows nothing about. He insists a ripple counter is the correct way to divide a clock!

This diagram shows what to do in the DAC. In the CDP, install a matching transceiver the same way you would install a snake oil XO.

If after studying the data sheets you can’t figure out how to make a divide-by-256/768 synchronous counter, you ought to try a different hobby because digital audio is way over your head.
 
A possible approach to slaving the transport but keeping the DAC as the master: Remove the transport's crystal and inject an output from our master oscillator to the "input" pin of the xtal pin pair of the old oscillator. Crystals attached directly to big digital chips typically have an "output pin" (which drives the crystal to resonate) and the crystal then feeds an "input" pin. This input you can remove the crystal and inject an external (typically TTL type levels) clock of the same frequency as the crystal was. If you don't have the diagram or datasheet of the chip, just try experimentally both pins and one will work. If you have a scope handy, probe both pins. The one with the nicer digital clock is the output, the one with a more analogish clock is the input.

Okay, but a major issue is that different transports and CD players use several different frequency crystals. 11.2896, 16.9344, and various simple multiples or divides thereof. Or 27MHz if it's a DVD player. So you'd need to create (as a kit) a universal master oscillator with several choices of divide down frequencies. And you'd pick the one you'd need to drive a line driver to drive a coax cable (75ohm) that would be used to send it to the transport to inject it into the above crystal oscillator circuit (with the crystal removed). Another output from this master oscillator kit would be used to feed the DAC chip in the DAC box directly. You could probably be okay to leave the SPDIF receiver clorck regenerator alone, but disconnect its clock from the DAC chip's clock input. Whatever jitter will be removed by the solid clock feeding the DAC chip itself. The DAC chip is where "The rubber meets the road". You can have jitter elsewhere, but not at the DAC chip. (what the industry should have done was to make the transports the slave, and the DAC box the master, but that would require a second 75 ohm patch cord). One more thing, we will want to be able to adjust the phasing of the clocks from the master oscillator to be sure that the DAC chip is clocking in the middle (in the time domain) of the audio bits/bytes. When data is quite stable. To avoid bit errors (which will be quite obvious when they happen).

Unfortunately, what I just wrote is a systems engineering level description. Useless for any DIY who doesn't have a BSEE degree. The problem is that there is too much variety of CDP/transports and DAC boxes out there to be able to say "cut the blue wire on connector xxx, and connect it to R44 on the end closer to the edge of the board". I.m not sure if a kit with instructions on what to do so any DIY handy with a soldering iron who can do this with a high degree of success can be created.
 
A possible approach to slaving the transport but keeping the DAC as the master: Remove the transport's crystal and inject an output from our master oscillator to the "input" pin of the xtal pin pair of the old oscillator.

Even better, and much easier, is to look at what Guido Tent is doing.

Sending a crystal oscillator waveform across a longish wire, and possibly through a set of dividers, without generating even more propogation delay and jitter than you started with is extremely difficult.

What Guido does is this: You have a master, fixed oscillator driving your DAC through its receiver PLL circuit. This PLL generates a varying DC voltage related to how far + or - the "centre" frequency you are.

You send this DC voltage through a wire - - you don't need much shielding etc. since its variations will generally be below 1hz -- to your transport (or other SPDIF source). You've replaced the clock oscillators in those devices with a VCXO -- Voltage Controlled Crystal Oscillator -- tuned to whatever frequency the device requires (16.xxxmhz, 11.xxxx mhz, whatever). The voltage signal from the DAC master oscillator drives the VCXO so they both vary by exactly the same amount -- thus creating a jitter-free output (combined with the PLL on the DAC). So the oscillators can all be at different frequencies; it's only the variance that you're transmitting from the "master" unit to the "slave" unit/units.

It's worth checking out the explanation on his Tentlabs site -- his XO3 and XO-DAC are the devices in question, but he provides all the information (and sells VCXOs) to roll one yourself. He, as far as I know, is the only one using this VCXO approach, and it seems to sidestep all the awkward transmission-line problems of sending clock signals through wires and dividers.
 
dougigs said:


Sending a crystal oscillator waveform across a longish wire, and possibly through a set of dividers, without generating even more propogation delay and jitter than you started with is extremely difficult.

What Guido does is this: You have a master, fixed oscillator driving your DAC through its receiver PLL circuit. This PLL generates a varying DC voltage related to how far + or - the "centre" frequency you are.

Might work, though I'd feed the DAC chip's clock input directly from the master oscillator (which would be located inside the DAC box a few cm away from the DAC chips). The DAC's input latch would reclock away any remaining jitter from the receiver's PLL and jitter from the transport. As long as those jitters never get worse than 1/3 of a clock cycle (assuming you make the DAC chip's internal latch clock in the middle of a bit) the DAC chip removes it all just right before it becomes analog.

dougigs said:

You send this DC voltage through a wire - - you don't need much shielding etc. since its variations will generally be below 1hz -- to your transport (or other SPDIF source). You've replaced the clock oscillators in those devices with a VCXO -- Voltage Controlled Crystal Oscillator -- tuned to whatever frequency the device requires (16.xxxmhz, 11.xxxx mhz, whatever). The voltage signal from the DAC master oscillator drives the VCXO so they both vary by exactly the same amount -- thus creating a jitter-free output (combined with the PLL on the DAC). So the oscillators can all be at different frequencies; it's only the variance that you're transmitting from the "master" unit to the "slave" unit/units.



I don't know if the two jitters would exactly cancel out, but avoiding a clock going thru a patch cable might be worth it. But I see a possible problem of maintaining consistant phasing of the bit edges as seen by the receive circuits in teh DAC box compared against what the transport does if different frequency VCXOs are used. Which may also be a fatal flaw in what I suggested a few posts ago. :) Though whatever jitter gets picked up because of the patch cord would only effect the transport, and that jitter would still be removed by the master clock driving the DAC chip.

My objective is to feed the DAC chip the best jitter free clock (from a good master oscillator) and let other parts of the strictly digital world have some jittery clock. The digitized audio gets passed thru various fifos and packetizers and whatnot and sorted out long before it hits a DAC chip anyway. Some jitter in clocks running that stuff won't matter (unless it gets really bad, of course).
 
wa2ise said:
Okay, but a major issue is that different transports and CD players use several different frequency crystals. 11.2896, 16.9344, and various simple multiples or divides thereof.

What’s so hard about that? I use a standard module on a 1.6” x 0.7” PCB that starts with a 33.8688MHz XO, surface-mount or through-hole, with or without snake oil, and produces 16.9344, 8.4672, 4.2336, 2.1168, 1.0584, 11.2896, 5.6448, 2.8224, 1.4112, 0.7056, 0.3538, 0.1764, 0.0882, and 0.441MHz. All outputs are synchronous and selected frequencies can be true/complement or quadrature. I have no need for DVD frequencies so I didn’t include them.

wa2ise said:
And you'd pick the one you'd need to drive a line driver to drive a coax cable (75ohm) that would be used to send it to the transport to inject it into the above crystal oscillator circuit (with the crystal removed).

Why coax? UTP is good enough for Gigabit Ethernet so why not sub-GHz frequencies? If you use a full-duplex transceiver at each end you can transmit S/PDIF in the same Category-5 cable. And why do you need to remove the crystal? All you have to do is remove the 74HCU04 and replace it with a 14-pin DIP socket. For stock operation, just plug in a 74HCU04. For slave mode, plug in a small daughter board that includes a transceiver and a 74HCU04.
 
Ulas said:


What’s so hard about that? I use a standard module on a 1.6” x 0.7” PCB that starts with a 33.8688MHz XO, surface-mount or through-hole, with or without snake oil, and produces 16.9344, 8.4672, 4.2336, 2.1168, 1.0584, 11.2896, 5.6448, 2.8224, 1.4112, 0.7056, 0.3538, 0.1764, 0.0882, and 0.441MHz. All outputs are synchronous and selected frequencies can be true/complement or quadrature. I have no need for DVD frequencies so I didn’t include them.

That's not the hard part that I'm worried about. The hard part is getting some DIyers to understand how to modify their existing transports (thousands of different designes in the field) with a good success rate. I don't want people ending up with ruined players.... It depends on who our "customers" will be.

Ulas said:

Why coax? UTP is good enough for Gigabit Ethernet so why not sub-GHz frequencies? If you use a full-duplex transceiver at each end you can transmit S/PDIF in the same Category-5 cable. And why do you need to remove the crystal? All you have to do is remove the 74HCU04 and replace it with a 14-pin DIP socket. For stock operation, just plug in a 74HCU04. For slave mode, plug in a small daughter board that includes a transceiver and a 74HCU04.

Most CDPs and transports use a crystal and some caps attached to the xtal osc pins of some big chip. No 74HCU04's.

If you wanted to use cat5 cables, sure it would work, given the right drivers and receivers. I was thinking of using S-video cables myself. Those are just a pair of 75 ohm coax lines in one package.

To allow long cable lengths without signal/clock skews, you could place the master clock oscillator in the transport, and send the data on one coax, and the clock on the other. You could remove the crystal on the receive PLL circuit (and inject the coax clock signal into the 'xtal osc input' pin), and disable its feedback loop. And dial up whatever phasing in the master oscillator driver circuit it needs to receive clean data.
 
wa2ise said:


That's not the hard part that I'm worried about. The hard part is getting some DIyers to understand how to modify their existing transports (thousands of different designes in the field) with a good success rate. I don't want people ending up with ruined players.... It depends on who our "customers" will be.



Why not select a common transport ? Like say a Nad 542 or Music Hall 25.2. I am sure people would be willing to buy a new transport if they had a way to make it a slave. We are talking about a huge step up by slaving.
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.