Any good TDA1541A DAC kit?

[Tazzz]

I would also make provision for detecting when the incoming data is in synch with the local clock ,conversion with randomized squarewaves on the data pin makes for unpleasant noise

[s3tup]

My take on the 1541, work in progress. At least the layout is mine
No SPDIF input stage is implemented yet, as i'll try to make it with back-sync to the PC - 2 SPDIF connectors, IN and OUT. With local 384Fs clock source near the DAC.

I haven't connected the DGND, AGND and AGND2 for a reason - they all should be connected together, but i have to try various ground connection schemes first.
As whether i should connect the output ground near the +5V, -15V, or between DEM - or connect the AGND and DGND together near the -5V, or near the AGND pin.

The I2S attenuator/slew limiter will be fine-tuned in place.
No DEM reclocking, as i feel these largish DEM filter caps will clean-up the current much better than the current averaging network made by DEM current source switching. The DEM switching should switch, no matter an what frequency - the "T" of filtering caps in much greater than "T" of the DEM switches.

CXD1244 DF here, as the only one suitable for 1541.

There will be reclock from MCLK (XTAL@384Fs or recovered from SPDIF, user selectable) prior to passing the I2S to the attenuator.

[ThorstenL]

Hi,

Originally Posted by s3tup

The I2S attenuator/slew limiter will be fine-tuned in place.

....

CXD1244 DF here, as the only one suitable for 1541.

Digital Filter Chips are jitter central. Abandon all hope on good performance, lest you re-clock the output of the digital filter. Sound quality even after that will be ordinary.

If you must oversample, do it in the PC and use a better quality algorithms than what you find in decade old digital filters.

Originally Posted by s3tup

No DEM reclocking, as i feel these largish DEM filter caps will clean-up the current much better than the current averaging network made by DEM current source switching.

I think you are seriously mistaking how things work.

DEM reclocking makes sure of two things:

1) Avoid beat tones from interactions between the DEM clock and sample rate, if they are not synchronised

2) Make sure all DEM elements are used for each sample, this means absolute errors may be larger and are not randomised, but relative errors now n \o longer have a random extra error added.

DEM Filter Capacitors filter the switching glitches, which will be at several 100KHz, so we want low ESR and low ESL at those frequencies. Current amounts also vary between the MSB decoupling one sand the lower bits.

Ciao T

[s3tup]

Originally Posted by ThorstenL

Digital Filter Chips are jitter central. Abandon all hope on good performance, lest you re-clock the output of the digital filter. Sound quality even after that will be ordinary.

DF ain't good nor bad on the jitter front, as long as they are reclocked afterwards. They don't relate to any timings beside data integrity, and as long as no errors are introduced to data, the calculations will be precise on the math frontend. Then i'll shape their math output to external Xtal, and get both precise digital filtering and timing with no loss of bits (as much as possible, given the DF FIR filtering algorithms).
The PC will be synced with Xtal, therefore everything will be synchronous - no async reclocking with missing bits.

Originally Posted by ThorstenL

If you must oversample, do it in the PC and use a better quality algorithms than what you find in decade old digital filters.

It's a good thing for PC DAC, but everything goes wee when we introduce 176kHz SPDIF. It is quite high sample rate for SPDIF, and really dependant on the SPDIF I/O capabilities on both sides.
Eventually, the 1541 will die with it's 5.6MHz DEM clocking rate, if DEM will be clocked from BCLK.
1.4MHz doesn't seems right for the NOS too. Clock dividers should be used...

Originally Posted by ThorstenL

I think you are seriously mistaking how things work.

DEM reclocking makes sure of two things:

1) Avoid beat tones from interactions between the DEM clock and sample rate, if they are not synchronised

2) Make sure all DEM elements are used for each sample, this means absolute errors may be larger and are not randomised, but relative errors now n \o longer have a random extra error added.

I think we should split the cases of OS and NOS.

First of all, how many elements we have which are being switched, and how long is their sequential pattern? I guess they aren't random switching, therefore they should form a kind of repeatable pattern, which will affect DAC output - we will see the pattern on the DAC output if we use FFFFFF on I2S, and cycle the DEM with LR clock. To make the DEM switch thru all of the states per single LR clock (given we have DEM sequence length of N), we need Fcosc=N*Fs. Not more not less than multiples of N*Fs.
If we get the clocking wrong, we will get repeatable pattern on DAC output, which will repeat itself, and show-up on THD plot as stick(s).
If we do so, we get N glitches of DEM per sample.

Then let's check the DEM clocking from the aspect of NOS/OS.
NOS has Fs of 44100Hz. The datasheet-recomended frequency for Cosc is around 400kHz, which overclocked, but marginally covered by BCLK/2=700kHz (or BCLK/4=350kHz) given the BCLK=32Fs.
For BCLK/2 we get 16 iterations of DEM, and for BCLK/4 = 8 itertations.
Looks marginally fine, as long as we have 4, 8 or 16 combinations of elements.

For the OS, our Fs goes to 174kHz, and we can't use it's BCLK/2, BCLK/4 for DEM clocking.
Moreover, if we try to stick to Cosc BW limits of no-more-than 700kHz, we are maxed-out by 4*Fs which is still fine for DEM pattern length of 4. But if we have more than 4 combinations of elements, we don't benefit from per-sample averaging of elements. Say we have 8-cycle combination of elements and 4*Fs clock. Then 1st sample on DAC output will use average from first 4 combinations, and 2nd sample will use 4 other combinations. We get a square wave of Fs/2 on DAC output, which is bad.

On the other hand, if we go with free-running DEM clk, we get some randomness of switching per every sample. It's noise distributes over the spectrum, and we may even benefit from it as from "dithering".

To clearly see the DEM pattern, i think we should remove the DEM filtering caps.

Originally Posted by ThorstenL

DEM Filter Capacitors filter the switching glitches, which will be at several 100KHz, so we want low ESR and low ESL at those frequencies. Current amounts also vary between the MSB decoupling one sand the lower bits.

4.7uF X7R 1206 is ok in ESR/ESL domain? Their leakage current should be concerned too...

[s3tup]

Here is an article about DEM, dated 1976
http://overture.org.ua/wp-content/up...9/00046328.pdf
I need to read it prior to arguing

[ThorstenL]

Hi,

Originally Posted by s3tup

DF ain't good nor bad on the jitter front, as long as they are reclocked afterwards.

Agreed, yet I seem to have missed the re-clocker in your schematic and on your PCB...

Originally Posted by s3tup

It's a good thing for PC DAC, but everything goes wee when we introduce 176kHz SPDIF.

Quad speed SPDIF that locks reliably is now very common. There are chip's from almost any maker. And why not use Quad Speed I2S vias USB?

Originally Posted by s3tup

Eventually, the 1541 will die with it's 5.6MHz DEM clocking rate, if DEM will be clocked from BCLK. 1.4MHz doesn't seems right for the NOS too. Clock dividers should be used...

If you read my earlier notes, I agree on using a Dividier for DEM reclocking.

Originally Posted by s3tup

I think we should split the cases of OS and NOS.

Why? How does the DAC distinuish between being fed 44.1KHz upsampled to 176.4KHz and being feed a non-oversampled 176.4KHz signal?

Originally Posted by s3tup

First of all, how many elements we have which are being switched, and how long is their sequential pattern?

It's in the TDA1541 extended info datasheets...

Originally Posted by s3tup

I guess they aren't random switching, therefore they should form a kind of repeatable pattern, which will affect DAC output - we will see the pattern on the DAC output if we use FFFFFF on I2S, and cycle the DEM with LR clock. To make the DEM switch thru all of the states per single LR clock (given we have DEM sequence length of N), we need Fcosc=N*Fs. Not more not less than multiples of N*Fs.

Correct.

Originally Posted by s3tup

4.7uF X7R 1206 is ok in ESR/ESL domain? Their leakage current should be concerned too...

Maybe. From experience ceramic should not be used here. Use SMD stacked Film, many options now.

Ciao T

[s3tup]

Originally Posted by ThorstenL

Agreed, yet I seem to have missed the re-clocker in your schematic and on your PCB...

Probably you have missed the:

Originally Posted by s3tup

There will be reclock from MCLK (XTAL@384Fs or recovered from SPDIF, user selectable) prior to passing the I2S to the attenuator.

The reclocker was missing because i haven't yet decided which IC to use, and which casing. DIP will look on par with DF and DAC, but a bit clunky.
SOICs are techie, but prevent a nice bypassing under the IC due to VIAs.
I like the way pins are arranged in 574 IC of 74 family. It's quad DFF with positive outputs only, and it has inputs and outputs on opposite edges.
ABT/BCT? BiCMOS looks attractive from propagation delay and power usage points of view...

Originally Posted by ThorstenL

Quad speed SPDIF that locks reliably is now very common. There are chip's from almost any maker. And why not use Quad Speed I2S vias USB?

USB-slave is really nice option, but it is USB, and i'm not aware of publically available, cost effective AND easily implementable ICs, which doesn't require FPGAs, MCUs and preflashing.

SPDIF@174kHz? The issus with SPDIF "as-is" is unresolvable thus requiring us to use reclocking + back-syncing.
I'll try to run my project with oversampling @PC + DF bypass, but i'm uncertain whether i'll be able to make the back-sync thing work at 174kHz.
Without back-syncing it gets even worse as the sampling frequency rises...

Originally Posted by ThorstenL

Why? How does the DAC distinuish between being fed 44.1KHz upsampled to 176.4KHz and being feed a non-oversampled 176.4KHz signal?

It won't distinguish as long as Fs=176.4KHz is on 1541's inputs.
Yet, the BCLK divider for DEM clocking at Fs=44.1k and Fs=176.4k should be different, otherwise DAC will distinguish the change in a bad manner

Every time i hear "NOS" i think of DAC running at Fs=44100Hz.
As long as we upsample the signal at some point of digital chain, the whole system shouldn't be called "NOS".

Originally Posted by ThorstenL

It's in the TDA1541 extended info datasheets...

I'll take closer look at these sheets. (Are they from IEEE?)

Originally Posted by ThorstenL

Maybe. From experience ceramic should not be used here. Use SMD stacked Film, many options now.

SMT PPS die when you touch them with soldering iron Lots of care should be taken at soldering time, otherwise we'll hear clicking noises on DAC output when the music hits missing bits.



What about my grounds layout?
I didn't liked the capacitive/inductive coupling of DGND and AGND when they are on top of each other (2-layers), so i decided to move the DGND aside.
By doing this i halved the AGND impedance, got solid AGND layer
But i've got a half-circle loop between -5V and DGND pins with -5V PSU in between. The DAC chip is in center of EMI field produced by currents flowing from -5 to DGND and back given the "right hand rule" is true .

[ThorstenL]

Hi,

Originally Posted by s3tup

Probably you have missed the:

I looked at the schematic and PCB, sorry.

Personally I don't even bother starting on the PCB until I have the basics sorted and maybe breadboarded any stuff I'm not sure will work.

Originally Posted by s3tup

USB-slave is really nice option, but it is USB, and i'm not aware of publically available, cost effective AND easily implementable ICs, which doesn't require FPGAs, MCUs and preflashing.

You could buy something off the shelf (M2-Tech thingey?) and mod it. Not that hard.

Originally Posted by s3tup

SPDIF@174kHz? The issus with SPDIF "as-is" is unresolvable thus requiring us to use reclocking + back-syncing.

But you said you would do that, so where is the problem?

Originally Posted by s3tup

I'll try to run my project with oversampling @PC + DF bypass, but i'm uncertain whether i'll be able to make the back-sync thing work at 174kHz. Without back-syncing it gets even worse as the sampling frequency rises...

Use Asynchronous USB.

Originally Posted by s3tup

Yet, the BCLK divider for DEM clocking at Fs=44.1k and Fs=176.4k should be different,

Why. As long as the minimum of full cycles happen at 176.4KHz it will be fine. At 176.4KHz and at 44.1KHz (Non-OS).

Originally Posted by s3tup

Every time i hear "NOS" i think of DAC running at Fs=44100Hz.

I don't. I think of a DAC running at 1Fs, with FS being anything the DAC can handle (for TDA1541 that would be 384KHz in duplex mode).

Originally Posted by s3tup

SMT PPS die when you touch them with soldering iron

As the late Steve Jobs so famously said to 21 Million iPhone 4 users that complained calls dropped if they held their phone in a certain way: "Then just don't do that!".

Originally Posted by s3tup

What about my grounds layout?

Your call, we all have our preferences.

Ciao T

[s3tup]

Thorsten,
I want to use some SPDIF-like transformer to isolate the Cosc pins from reclocking circuit.
Should i still tie the Cosc pins to -15v with 2k2 resistors? I don't like the idea of polluting the -15v line with digitallish signal, even thru relatively high resistors. I guess i'll need to split the -15v line to two -15 sources, unless there is alternative solution for DEM clocking signal feed.
Also i find it crude to pull Cosc pins to -15v
And i guess pulling the isolated trafo windings to -15v won't work, probably i need to tie the cosc pins between -15v and somewhere at +/-5v.



By the way, if we get constant averaging of current source variations with DEM clocking, then we will get constant sample-to-sample DEM averaged current delivered to each bit.

Then we could introduce leakage current to each bit by tying the DEM filtering caps somewhere, say GND with trimmer resistors.
Then we could be able to fine-tune the current for each available bit.
Yay? Access to bit tuning of bits...

[ThorstenL]

Hi,

Originally Posted by s3tup

I want to use some SPDIF-like transformer to isolate the Cosc pins from reclocking circuit.

Frequency may be too low and impedance too high to use SPDIF Transformers.

The DEM reclocking by ecdesigns that I recommend is balanced, so not much net current, if you want to loose sleep over it add a choke and local decoupling, though given the actual internal TDA1541 schematic I think this could be counter-productive.

Originally Posted by s3tup

Also i find it crude to pull Cosc pins to -15v

Tell that to Rudy Van Plasche. He designed the TDA1540 and TDA1541 that way.

Originally Posted by s3tup

By the way, if we get constant averaging of current source variations with DEM clocking, then we will get constant sample-to-sample DEM averaged current delivered to each bit.

Then we could introduce leakage current to each bit by tying the DEM filtering caps somewhere, say GND with trimmer resistors.
Then we could be able to fine-tune the current for each available bit.
Yay? Access to bit tuning of bits...

Yes, I think you could monkey with that, but I doubt there is much to be gained that way.

Ciao T