Is there any multichannel DAC easy to DIY in 2023?

[voodooless]

Maybe not put in a random value

How big is the offset?

 

[MCH]

Maybe not put in a random value

View attachment 314100

How big is the offset?

The offset is 26.8 mV. If you appythe formula, you get a value that in binary is more than 16 bits, that's why I ended up trying random values.
Chances are very high that I just don't understand the calculation

 

[voodooless]

Or it’s higher than you can compensate for… the question is, where does it come from?

 

[meooms]

Nice to have results!
For the DC offset I would check if pin 7 and 24 have exactly equal resistances to the ground plane, same for 12 and 19.
Further look for equal voltages on 10 and 21.
Tempting to try the DC-offset registers if nothing else works. Maybe it is a normal problem to have with this chip? I have never seen this in other DACs, but these have always been current outputs.

 

[MCH]

Or it’s higher than you can compensate for… the question is, where does it come from?

I have no clue. And what surprises me more is that it is not symmetrical. Channels 2468 read 0.0 mV. Both sides Ged fed by the same analogue power line and there is nothing else connected to it nor any other component anywhere close. The schematic is quite simple actually.

 

[MCH]

Nice to have results!
For the DC offset I would check if pin 7 and 24 have exactly equal resistances to the ground plane, same for 12 and 19.
Further look for equal voltages on 10 and 21.
Tempting to try the DC-offset registers if nothing else works. Maybe it is a normal problem to have with this chip? I have never seen this in other DACs, but these have always been current outputs.

Thanks! Will test that.
Well, the only existence of the offset adjustment registers might mean that is the case, I guess.

 

[meooms]

I have no clue. And what surprises me more is that it is not symmetrical. Channels 2468 read 0.0 mV. Both sides Ged fed by the same analogue power line and there is nothing else connected to it nor any other component anywhere close. The schematic is quite simple actually.

maybe a bad capacitor (leaky) on the GSN_L? Try desoldering them perhaps?

 

[MCH]

desoldering

 

[meooms]

I feel your pain

 

[MCH]

Nice to have results!
For the DC offset I would check if pin 7 and 24 have exactly equal resistances to the ground plane, same for 12 and 19.
Further look for equal voltages on 10 and 21.
Tempting to try the DC-offset registers if nothing else works. Maybe it is a normal problem to have with this chip? I have never seen this in other DACs, but these have always been current outputs.

voltages in pins 10 and 21 identical 3.297V
resistance to ground plane in pins 7 and 24 "0.1 Ohm", that is the minimum value my cheapo multimeter reports, so no significant
resistance to ground plane of pins 12 and 19 is not possible to measure as they are connected to the pad below the IC.
the one thing that makes the two sides non simetrical is the capacitor to pin 18 that goes to a vias to the power line that feeds channels 2468, see picture below. I don't think this should have any relevance, specially if you think that those are the "good" channels, but wanted to mention it. i guess it is not ideal to place that via there...

(note that the problematic channels are those to the right of the picture (1357))

 

[MCH]

Guys, i am starting to think that the DC offset i measure might not be what i think it is.
To make it clear, the 26 mV that i measure in channels 1357 only are measuring with a multimeter in DC between the output pins of those channels and ground. The same measurement in channels 2468 is 0.0 mV. The 26 mV disappear when i turn off the DAC via i2c (i mean, the chip is still on, but its DAC section is off)
I thought that if this is a real DC offset present in the signal when playing music, i should see it in the capture of my ADC. So i just played some music and captured with the soundblaster Xfi HD card and reduced the volume of the signal little by little. i was expecting to see one of the channels with the signal permanently above (or below) 0, but this is what i get (super zoomed in):
channel 1:

channel 2:

i see no offset there. maybe the ADC is DC decoupled? I also own a motu ultralite mk5, that is DC coupled on the outputs (not sure about the inputs), but i would like to understand this a bit better before plugging my board to it, i don't want to break the Motu...

Hardware wise i plan to substitute the caps on pins 11 and 13 for new ones, but i ran out of 1uF caps, so it will have to wait...

 

[meooms]

Congratulations! Looks like it is working fine now.
Any reason for the cap substitution?
On another topic; the DC offset value had to be stored in 2 registers. Never got this to work for the signed double THD compensation in the ES9038pro. I simply split the double in a high and a low nible. Even tiny compensations (e.g. -10) had extreme results on the THD.
I think it had something to do with little-endian order in combination with a signed double. Do you know how to store a 16 bit signed value over two 8 bit registers?

 

[MCH]

Congratulations! Looks like it is working fine now.

thanks, i still think it might be the ADC i use to capture the signal is DC decoupled, but don't know...

Any reason for the cap substitution?

not really, other than changing the only component that is external to the DAC chip that is different for one group of channels vs the other. btw, i just desoldered the 4 1uF caps that go to pins 10 11 20 and 21 and measured them. the only value out of the normal was on cap to pin 11, that was 1.57 uF. Changed caps to pins 10 and 11 for others "borrowed" from another PCB. The 26 mV are still there

On another topic; the DC offset value had to be stored in 2 registers. Never got this to work for the signed double THD compensation in the ES9038pro. I simply split the double in a high and a low nible. Even tiny compensations (e.g. -10) had extreme results on the THD.

I am 99% sure the formula in the datasheet is wrong. This is what the datasheet says:

I mean, if you do the math, this would allow only for very tiny corrections... seems that it would be the right formula for 24 bits register, and what the heck is 2^24 -1??? It would make much more sense if the formula was like this:

(@amirm any chance for a formula editor?)
this would allow you to use 15 bits to cover all the range from V to V0ffset and bit 16 for positive/negative sign. I would bet something the formula in the datasheet is a typo. I checked the other ESS DAC that has voltage outputs (ES9033Q) and the datasheet shows the same formula though..... hmmm

btw, i would like to learn more about THD compensation. Do you have a link that explains how it works?

 

[meooms]

I agree that your calculation is more likely.
My problem is how to distribute 16 bits over 2 8 bit registers. Which bits go first (LSB should go in the first register, MSBs in the second according to little endian) but never got it to work in my arduino code. Any ideas on why?
E1DA has an app that can do this for their DAC, very nice interface. See

 

[MCH]

I agree that your calculation is more likely.
My problem is how to distribute 16 bits over 2 8 bit registers. Which bits go first (LSB should go in the first register, MSBs in the second according to little endian) but never got it to work in my arduino code. Any ideas on why?
E1DA has an app that can do this for their DAC, very nice interface. See

thanks!
the datasheet says this (for ES9080, i would assume it is the same for other ESS dacs):

and BTW, gave it another go with the soldering iron, risking even more than in previous attempts, AND THE DC OFFSET IS GONE!!!!!!!! cant believe it, finally!! i know qfn ics wouldnt be easy to solder the first attempt.... I am happy, i am going to give the DAC section an ok, and move on to the microcontroller work

 

[voodooless]

I agree that your calculation is more likely.
My problem is how to distribute 16 bits over 2 8 bit registers. Which bits go first (LSB should go in the first register, MSBs in the second according to little endian) but never got it to work in my arduino code. Any ideas on why?

Datasheet indeed says LSB first. How do you do it in code?

 

[meooms]

Datasheet indeed says LSB first. How do you do it in code?

LSB first. But I think the problem is in splitting the 16 bits into 2 times 8 bits. I use int16 and int8 for this in c++, maybe this does not work well with lowbyte and highbyte function.

 

[voodooless]

LSB first. But I think the problem is in splitting the 16 bits into 2 times 8 bits. I use int16 and int8 for this in c++, maybe this does not work well with lowbyte and highbyte function.

The int is whatever the CPU uses. The endianness is undefined in C(++). Better do the splitting yourself:

LSB = value & 0xff
MSB = value >> 8

 

[meooms]

The int is whatever the CPU uses. The endianness is undefined in C(++). Better do the splitting yourself:

LSB = value & 0xff
MSB = value >> 8

Thanks! I'll try that. Have to dig up the code from somewhere on my pc

 

[MCH]

Example from the datasheet. They split and don't even bother writing 114 and 118, that must be all 0: