I strongly suspect that there are positive and negative regs on the board for the output opamps VCC/VEE. The VCCA opamp is better off with its VEE pin connected to ground anyways because it only has to deliver positive output voltage.
The 16 pin qfn is most likely the mute circuitry, but nothing to be found on this chip, at least MY search foo was not good enough 🙂
regarding the feedback circuitry around the AVCC opamp - I tried to reverse engineer this. Don't know if I got it correctly:
Part with designator "X" could be a small ferrite bead (it's grey in the foto) or a cap (unusual color for a cap, all the other ones are yellow/brownish)
Also I don't know what is supposed to be the output of the circuit - A or B. Can't see in the picture as the trace to the DAC's AVCC pins dips below the top layer and I cannot tell wether it's from A or B. I suspect it's A...
Maybe someone with more insight to MFB technology could shed some light on this?
Attachments
Last edited:
What if you power off the dac and ring out the connection between the opamp output pin and an AVCC input pin. Is it 3R3 or essentially zero?
I would certainly do that if I hand one in my hands. I worked solely off the photos though.
PS: My friend also looked at the photos and he's pretty convinced that it's A - he thinks that there is a visible trace to the AVCC decoupling caps.
PS: My friend also looked at the photos and he's pretty convinced that it's A - he thinks that there is a visible trace to the AVCC decoupling caps.
I just fired up LTspice as well. What values did you use for the sim. Did you use a cap for "X"?
And I have a sneeking suspicion that the circuit is not about noise performance but to make the OPA1612 stable with substantial low ESR capacitive load at its outputs
I tried lots of values between 1n to 100u. And tryed lots of different ferrite bad in ltspice standard library. Nothing changed in a good way in the means of noise but it could be for stablity for sure.
Guys could you please enlighten me about;
What if i power OPA1612 opamps with ±10 instead of ±15?
Was it effects THD, or just decrease output voltage?
What if i power OPA1612 opamps with ±10 instead of ±15?
Was it effects THD, or just decrease output voltage?
From what I understand, yes. The maximum output swing will decrease but the THD performance should stay the same. Internal bias currents are regulated by CCSs. You might even gain a little because thermal stress will be lower.
Topping chose +-11v rails for D90. I wondered why since opamps often sound better with higher rail voltages. Tried every voltage in one volt increments from 10v to 15v. Agree with Topping on their choice. +-11v sounded best to me. Haven't done the same experiment with an ESS dac though. I would suggest to try it yourself and see what you think. Its easy enough to do if the regulators have adjustment pots with enough range.
Also IMHO a lot of stuff affecting SQ can be determined with experiments and listening tests (mostly for analog circuitry and power supplies; not so much for digital). Good to be careful deciding what is analog and what is digital. For example clock oscillators are analog. We may hear from some people who disagree on this topic though.
Also IMHO a lot of stuff affecting SQ can be determined with experiments and listening tests (mostly for analog circuitry and power supplies; not so much for digital). Good to be careful deciding what is analog and what is digital. For example clock oscillators are analog. We may hear from some people who disagree on this topic though.
Last edited:
Hello @Markw4
I would use two ES9038Q2M in mono mode for playing PCM and DSD up to highest rates with I2SoverUSBv.III.
I´ve attached a sketch showing the clock distribution:
- first one with external buffered 100MHz clock to the two DAC XI inputs
- second one with buffered MCLK from USB receiver to the two DAC XI inputs
- third solution (not sketched) would be external MCLK also for USB receiver
What for solution is proven and gives good results?
JP
I would use two ES9038Q2M in mono mode for playing PCM and DSD up to highest rates with I2SoverUSBv.III.
I´ve attached a sketch showing the clock distribution:
- first one with external buffered 100MHz clock to the two DAC XI inputs
- second one with buffered MCLK from USB receiver to the two DAC XI inputs
- third solution (not sketched) would be external MCLK also for USB receiver
What for solution is proven and gives good results?
JP
Attachments
Hi JPS64,
I can tell you what I would recommend for the digital front end and clocking. My choice would be to use two clocks (both running at all times, the output frequency selected with a small signal relay with gold contacts). Buffer the relay output with something like NB3L553-D or maybe PL133-27. Might try 805 SMD film caps for clock and buffer bypass. Route clocks from the buffers to the dac chips and to the I2SoverUSB card external clock input. Use the isolated signal from I2SoverUSB to operate the clock frequency selection relay. You can relcock I2S coming from I2SoverUSB, but it has already reclocked there once in a CPLD. You could probably get I2S jitter a little lower with one more reclock near the dac chips, as you show. Sometimes it helps to use larger than predicted series termination resistors at the output of the relclock chip, say, maybe 100-ohms (instead of, say, maybe a more typical 33-ohms). Its one of those things you have to try and see if it helps in your design situation.
It means the dac chips would need to be controlled by some MCU to set the registers for synchronous operation. IME, ESS dacs tend to sound better that way, at least they do for me.
If implemented more or less as above, then the only remaining problems to work out would be AVCC regulation and output stage design.
The above assumes everything is well laid out on a 4-layer PCB with a ground plane. Good to have maybe a +5v power plane or large fill area on one layer. Then local regulators can drop it down to +3.3v as needed near loads such as clocks, buffers, and various dac chip power rails.
I can tell you what I would recommend for the digital front end and clocking. My choice would be to use two clocks (both running at all times, the output frequency selected with a small signal relay with gold contacts). Buffer the relay output with something like NB3L553-D or maybe PL133-27. Might try 805 SMD film caps for clock and buffer bypass. Route clocks from the buffers to the dac chips and to the I2SoverUSB card external clock input. Use the isolated signal from I2SoverUSB to operate the clock frequency selection relay. You can relcock I2S coming from I2SoverUSB, but it has already reclocked there once in a CPLD. You could probably get I2S jitter a little lower with one more reclock near the dac chips, as you show. Sometimes it helps to use larger than predicted series termination resistors at the output of the relclock chip, say, maybe 100-ohms (instead of, say, maybe a more typical 33-ohms). Its one of those things you have to try and see if it helps in your design situation.
It means the dac chips would need to be controlled by some MCU to set the registers for synchronous operation. IME, ESS dacs tend to sound better that way, at least they do for me.
If implemented more or less as above, then the only remaining problems to work out would be AVCC regulation and output stage design.
The above assumes everything is well laid out on a 4-layer PCB with a ground plane. Good to have maybe a +5v power plane or large fill area on one layer. Then local regulators can drop it down to +3.3v as needed near loads such as clocks, buffers, and various dac chip power rails.
Last edited:
Something like that, but I personally would not use clock select pins on the clocks since IME its not the same as leaving them fully running at all times. Also, I'm not a fan of using ferrite beads unless they are proven necessary to solve a problem in a particular design. My unproven suspicion is that they could produce some hysteresis distortion/noise that could cause its own problems. However one could leave pads for ferrite beads and put a zero ohm resistor on the pads if a ferrite bead is not found to be needed during testing.
That´s why I´m using ferrite footprints in the layout. Starting with 0R and if problems use ferrite.
Do you´ve a reference for a good relais?
I´m also wondering, after long Google search, that no I2C ES9038Q2M driver exists!
JP
Do you´ve a reference for a good relais?
I´m also wondering, after long Google search, that no I2C ES9038Q2M driver exists!
JP
There are various small signal relays with gold contacts. One of the smaller types is: https://omronfs.omron.com/en_US/ecb/products/pdf/en-g6k.pdf
or maybe even better:
https://omronfs.omron.com/en_US/ecb/products/pdf/en-g6k_2f_rf.pdf
Regarding a 'driver' for ES9038Q2M, what do mean by that? Software to control the registers?
or maybe even better:
https://omronfs.omron.com/en_US/ecb/products/pdf/en-g6k_2f_rf.pdf
Regarding a 'driver' for ES9038Q2M, what do mean by that? Software to control the registers?
Yes, something running under Linux allowing register configuration.
I´ve Ian´s ESS Controller but would be nice then I´m using USB receiver to have an APP running under Linus (or Windows).
JP
I´ve Ian´s ESS Controller but would be nice then I´m using USB receiver to have an APP running under Linus (or Windows).
JP
People have done it to some extent with command line scripts using RPi. For some other linux platform one might need some kind of a hardware interface, say, maybe USB to I2C. Figuring out how to program the registers isn't too hard. Besides, now that ESS has released ES9038Q2M datasheet we are free to talk about register programming here.
@JPS64: Where did you get your Potato Semiconductor devices? Did you buy them while they were more widely available or from one of the German distributors listed on their website?
Please let us know how to set up for such test so that we can try and see for ourselves.