Another TDA1541A based dac (dual differential)

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
I invite you to have a look at the conceptual diagram and give your comments.

If it were my design (and I'm currently doing one similar, but using TDA1545/1387) then I'd ditch the CPLDs and use a CPU fast enough to take over their functions. I'm a big fan of the LPC1113 and LPC1313 (though I haven't yet found the latest variant of this latter chip) - they'll do the digital inversion and channel splitting as well as giving the option of adding your own digital filtering. Both have hardware I2C and they're both extremely low power so don't introduce much digital noise. You might keep one of the CPLDs to format the data to feed to the MCU though. Alternatively lots of 74HC595s for serial-parallel conversion.
 
If it were my design (and I'm currently doing one similar, but using TDA1545/1387) then I'd ditch the CPLDs and use a CPU fast enough to take over their functions. I'm a big fan of the LPC1113 and LPC1313 (though I haven't yet found the latest variant of this latter chip) - they'll do the digital inversion and channel splitting as well as giving the option of adding your own digital filtering. Both have hardware I2C and they're both extremely low power so don't introduce much digital noise. You might keep one of the CPLDs to format the data to feed to the MCU though. Alternatively lots of 74HC595s for serial-parallel conversion.

Does it have hardware dsp functions for an i2s stream or are you making what you need in software? Can you get by by running the mcu of MCLK or does it need a higher clockrate?

I had in mind running the spdif receivers in slave mode so I can pick out the i2s with 32bit frames conveniently then use one small cpld (32cells used or thereabouts) for splitting the data into Left and Right and doing the inversion (never minding full 2's complement) This cpld is also used for muxing the different receivers.

Another cpld is configured as an synchronous divider chain with output muxes the mcu can control so for instance the DEM clock rate can be rescaled for different BLCK rates.

The mcu only enables the input recievers and monitor it for a PLL lock signal. When the recievers PLL have locked it compares the MCLK against its system clock to determine the right local mclk to use. This mclk is then enabled and divided down in the cpld and either fed back to the signal source (for instance the juli@ soundcard can be slaved from an external clock)

Or alternatively fed to the mcu which compares it to the incoming mclk to form a digital pll with adaptive low pass filter. This loop would be so slow that the mcu would spend most of its time sleeping only waking up on external interrupts (channel change) or when the control element to the VCXO needs to be adjusted (i2c pot).

When both PLL are in lock the mute relay at the analog outputs clicks of. If the sample rate is higher than 48Khz the sinc correction is also disabled.
 
Does it have hardware dsp functions for an i2s stream or are you making what you need in software?
Mainly hardware with a hint of software. It has no ports labelled as I2S but the generic sync serial port (SSP) can be set into TI mode, 16 bit which gives the data and clock patterns of I2S. Then I software synchronize a general purpose counter to generate the WS signal. Works fine so long as the DAC is 16bits.

Can you get by by running the mcu of MCLK or does it need a higher clockrate?

Running the mcu clock at MCLK is certainly possible but then its a bit hamstrung. The filter I'm working on at the moment has the mcu clock running at 1280fs which is 56.4MHz. It has an internal PLL so you can choose almost any multiple you like but the osc needs to be above 10MHz to begin with so I use 11.2896MHz.

Another cpld is configured as an synchronous divider chain with output muxes the mcu can control so for instance the DEM clock rate can be rescaled for different BLCK rates.

The LPC parts have 4 on-board timers so one of those can easily generate the DEM clock at a software defined frequency.

Or alternatively fed to the mcu which compares it to the incoming mclk to form a digital pll with adaptive low pass filter. This loop would be so slow that the mcu would spend most of its time sleeping only waking up on external interrupts (channel change) or when the control element to the VCXO needs to be adjusted (i2c pot).

Ah I see you could use PWM from one of the timers to the VCXO, saving on the I2C pot.

When both PLL are in lock the mute relay at the analog outputs clicks of. If the sample rate is higher than 48Khz the sinc correction is also disabled.

What are you using for sinc correction?
 
Running the mcu clock at MCLK is certainly possible but then its a bit hamstrung. The filter I'm working on at the moment has the mcu clock running at 1280fs which is 56.4MHz. It has an internal PLL so you can choose almost any multiple you like but the osc needs to be above 10MHz to begin with so I use 11.2896MHz.

The main reason I have for using two cpld is to really cut down on the amount of stuff switching at any one point and really only have useful and integer related clocks running simultaneously at any one time. I guess if you can slave the MCU to MCLK its acceptable but can it handle switching between 11.289 and 12.288 on the fly?

Ah I see you could use PWM from one of the timers to the VCXO, saving on the I2C pot.

The error signal from a normal PLL phase detector could be viewed as PWM and must be followed by an extensive filter. Its pretty much this filter I want to get rid of by moving it to the digital domain.

What are you using for sinc correction?

If I settle on a current conveyor I/V stage without any offset current flowing through the I/V resistor I probably settle for a passive LCR circuit as this can be disabled by short circuiting the inductor with a relay.
 
I guess if you can slave the MCU to MCLK its acceptable but can it handle switching between 11.289 and 12.288 on the fly?

Hmmm, interesting question. As part of the initialisation sequence its normal to switch from the internal clock to external, this doesn't give any problems. But the internal clock is fixed at 12MHz. So I reckon this would work fine provided the CPU's not running from its PLL when the change to the external osc freq takes place. That way any strange behaviour from the PLL for a step change of input freq can't affect the CPU. Once the PLL has settled to the new frequency it can be swapped back in.

The error signal from a normal PLL phase detector could be viewed as PWM and must be followed by an extensive filter. Its pretty much this filter I want to get rid of by moving it to the digital domain.

There's a crucial difference though in the two filters' characteristics. The PLL filter can't be a simple low pass with monotonically decreasing stop band - its normal to introduce a zero into the transfer function to have some phase margin. No such restriction exists on a PWM filter - there's no limit to the HF attenuation achievable.

If I settle on a current conveyor I/V stage without any offset current flowing through the I/V resistor I probably settle for a passive LCR circuit as this can be disabled by short circuiting the inductor with a relay.

What kind of inductor were you thinking of using? Its going to depend on the transimpedance of your I/V stage right? Any idea what you'd be aiming at?
 
IMHO not a good idea, as you load it unnecessarily.

You can easily solve that by using carefully chosen JFETs on the top & bottom half such that the mismatch gives you the bias you want.
Both current sourcing and sinking are possible.
And of course no additional components, and you can hardly get better current sources then the Toshiba JFETs.


Patrick
 
There's a crucial difference though in the two filters' characteristics. The PLL filter can't be a simple low pass with monotonically decreasing stop band - its normal to introduce a zero into the transfer function to have some phase margin. No such restriction exists on a PWM filter - there's no limit to the HF attenuation achievable.

Still, there will be a practical limit to how steep that filter can be so there may very well be a ripple imposed on the VCXO reference from the PWM. I'm quite certain I would be able to see it a sideband later on.

And It will make layout harder as I don't want to place the MCU close to the oscillators, and then I have to chose by routing either the somewhat noisy PWM signal around the board (and creating a current loop in the process) or filter it close to the MCU and route the extremely sensitive control voltage instead.

Using an i2c pot I can just feed it locally from the same quiet voltage as the oscillators and use a pair of dedicated GPIO:s on the mcu for the i2c so nothing disturbs the vcxo voltage unless it time to adjust the clock... maybe I should even use SPI or an buss isolator so I don't even need any pullups between the MCU and my clean oscillator supplies.

What kind of inductor were you thinking of using? Its going to depend on the transimpedance of your I/V stage right? Any idea what you'd be aiming at?

(1K5-8m2) || 3n3 gives something that's IMHO is close enough.
 
Last edited:
And It will make layout harder as I don't want to place the MCU close to the oscillators

Ah I see - our design philosophy differs significantly. I'd definitely want the mcu as close as possible to the clock feeding it. What's the resolution of your I2C pot - 8bits? If its coarse then you might find you're feeding step changes into your VCXO quite regularly.

(1K5-8m2) || 3n3 gives something that's IMHO is close enough.

You're seriously considering an 8.2mH inductor in this network if I read you correctly?
 
Ah I see - our design philosophy differs significantly. I'd definitely want the mcu as close as possible to the clock feeding it. What's the resolution of your I2C pot - 8bits? If its coarse then you might find you're feeding step changes into your VCXO quite regularly.

I actually haven't decided on one yet. I guess the situation would be different if I weren't just using the MCU for housekeeping.

You're seriously considering an 8.2mH inductor in this network if I read you correctly?

Yes.
 
I played around some with a new digital front end for the dac today.

Since everybody here seem to be allergic to anything more complex than a picogate I drawed it up using nothing but... I doubt I will build it this way since the soldering would be nightmare but as a concept it would be cool.

But anyway please have a look. Note however the schematic is not complete and the clocking scheme requires the source to be slaved by wordclock.

The analog outputs are held in mute until both the receiver says it is in lock and the cycle-slip logic have determined that the received wordclock is in fact in phase with the transmitted clock.

(My juli@ soundcard does accept word clock and I can provide my CD with a simple PLL so imho this is a viable option)
 

Attachments

  • DAC_mk3.pdf
    191 KB · Views: 366
Okay.. So here is something more realistic. Note tough this is a first draft schematic and i have not bothered to check it carefully yet so it is bound to be fraught with errors ! Don't anyone try to build this...

The features are as this:

Dual differential as my old dac.
Sample rates accepted are 44.1Khz and 192Khz (Auto detect)
Local Masterclock's (source must accept wclk input)
Passive Sinx/x for 44.1Khz source's
MUTE! when out of lock (Don't ever do anything fancy with clocks without this)
32bit frames.
Staggered clocks the TDA's latches 1/4cycle off anything else
Low noise (really low noise...) for the clocks and the sensitive gates.
Floating supplies (Pre regs not shown)

I'll clean up the schematic during the coming weeks and then start laying out a nice 4-layer board..
 

Attachments

  • DAC_mk2.pdf
    27.9 KB · Views: 387
Thanks Tazzz.
Yes for balanced, between 10 and 20 transistors per channel are needed for a decent discrete I/V running open loop.
On the other hand, i do not know how low the input resistance has to be for TDA1541. With the minimalistic SEN / CEN, paralleling would be required methinks. And a floating supply....
 
Thanks Tazzz.
Yes for balanced, between 10 and 20 transistors per channel are needed for a decent discrete I/V running open loop.
On the other hand, i do not know how low the input resistance has to be for TDA1541. With the minimalistic SEN / CEN, paralleling would be required methinks. And a floating supply....


Excactly times four considering its a balanced design. I will use lots and lots of floating supplies so a couple of more won't be a real hindrance. In my experience anything below 30ohms or thereabouts will work just fine with the TDA.

BUT.. to anyone reading i left out the circuitry to cancel the 2mA offsett current inherent in the TDA1541, i think i will be using a s ervo for it to cancel out the temperature dependance.
 
Excactly times four considering its a balanced design. I will use lots and lots of floating supplies so a couple of more won't be a real hindrance. In my experience anything below 30ohms or thereabouts will work just fine with the TDA.

BUT.. to anyone reading i left out the circuitry to cancel the 2mA offsett current inherent in the TDA1541, i think i will be using a s ervo for it to cancel out the temperature dependance.

Surprised you would do all this work and then dump the i-out into a 30 ohm impedance that puts you at 120mV compliance voltage, I would recommend some prototyping taking a few measurements at 50mv vs 120mv, especially since you are going to greater lengths than most on the digital side to do the differential outputs by channel. I can point you to where some of this has been done, send me a PM if interested.

Also have you tested the word clock "feature" , the quality of the PLL and spdif transmission(s) may be such that you find your master clock will have trouble. I am sure you are familiar with the old silly designs where a DAC's cs8412 was put into slave mode with the masterclock dropped in the DAC. These would work for a little while but skip because of the difference in ppm between the transport clock and the "master" clock in the DAC. Your concept isn't a lot different if you consider the soundcard's PLL using your word clock input, most of the consumer grade sound card word-clock input's I found to be more of a sample rate switcher than a true word clock synch (the synthetic clock derived from the word clock was too far away from the master clock to be useful.)

Just somethings I would proto before having the boards made. Hope this turns out well as the work is inspiring.
 
I have a juli@ soundcard wich I intended to use but I have only assumed they are using the wclk feature appropriatelly for my cd I'll just equip it with an analog pll.

There are recourse other options like adding a secondary preferably digital pll with adaptive filter and clockrate identification but I have not found any reasonably priced vcxo with comparable performance to a fixed frequency clock

If you have experimental data on thd vs output compliance I'd be most curios. I have been to lazy to generate that myself. I'd also be interested on how a dc offsett affects the tda
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.