• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required as is 20 years of participation in forums (not all true). Come here to have fun, be ready to be teased and not take online life too seriously. We now measure and review equipment for free! Click here for details.

ESS THD ‘Hump’ Investigation

jackenhack

Active Member
Joined
Oct 25, 2018
Messages
164
Likes
342
Location
Stockholm, Sweden
#1
THD Hump?
Time to decode the setup for the ESS DAC. I don't know if it's correct to post this in this forum thread, or if it's better to start a new thread, please give me a hint. Anyway, I've been interested in what @amirm has called "the ESS hump", where the measurements have a rise in THD when doing IMD measurements. By checking how the DAC is set up, we can start to see why some implementations don't have that problem. I know that both @amirm, me and others have had a suspicion of the built-in THD compensation available on the ESS DAC's. So let's go down the rabbit hole and see if that's the case.
IMG_2832.jpg

So I've hooked up my Khadas DAC to my logic analyzer and dumped the communication between the XMOS USB chip and the ES9038Q2M chip. I'm going to over-explain everything so even if you don't have the knowledge of electronics or how it works; you will still be able to follow along.

I2C (pronounced eye-squared-cee)
First, let's start with how the XMOS chip communicates with the DAC to set it up on startup. It uses a hardware protocol called I2C, which was developed by Philips back in the '70s for communication between IC chips. The protocol is very simple; it only needs two signal lines, one is a clock signal called SCL and one called SDA for data. You have a Master IC that talks to Slaves on the two lines. There can be several Masters and Slaves on the same lines because all the chips have an ID-number so that the Masters can address the specific chip with a corresponding ID number.

Communication
The Master initialise either a read or write to a specific register. The IC's have two specific addresses, one for writing and one for reading. In our case, the ES9038Q2M has 0x90 as write and 0x92 for reading. The numbers are in hexadecimal. What we are interested in at first is what registers are written to, and with what value.

Boot sequence
I have uploaded the boot sequence in a file you can download and follow along. All you have to do is to download the Saleae logic analyzer software. You can use it without any logic analyzer connected and load my file without a problem.

logic-captured.png

Sanity check
Let's first see if I managed to capture values that is correct. First, we need to get hold of the datasheet for the ES9038Q2M DAC. Having to do that is usually done by signing a non-disclosure agreement, which is stupid in my humble opinion, but they've decided to do that. Fortunately for us, there is a multitude of places to download it anyway.

In the datasheet, there are several registers for setting up the DAC. They go from 0 to 102. The first 52 to are read/write, 53-54 are reserved, and 55 to 102 are read-only for checking status.

So let's check if our data looks sane.

So register 0 sets up the oscillator drive, clock divider and soft reset and is by default 0. Checking the captured data, that is precisely what we get.

register-0.png


Register 1 is for input selection. It's easier to set the display of the captured data to binary because the register has several bits that determine different functions. Input select are designated with [1:0] which in normal speak means bit 0 and 1. The default setting is 00, which we have, so let's continue to check the bits.
Auto select: bits 2 and 3 specifies what kind of input signal the DAC is to expect.
2'b11: automatically select between DSD, SPDIF or serial data (default)
So this seems to be set to the standard values as well. Looking good.
Next is serial_mode. That should be set to 00, which it is. After that, bits [7:6] selects the word length of the audio data, and it should be set to 11. So it is. So we can now be quite confident that we have valid data captured.

register-1-capture.png


THD compensation
thd-bypass.png

So now we can check if the Khadas DAC uses the THD compensation by checking the value of register 13: THD Bypass.
Here bit [6] determines if the THD compensation is activated. However, here's a trap. There's a glaring error in the datasheet. Looking at the information about the default values, it shows that bit 6 should be 1 by default, but if you look further down, it says that 0 enables the THD compensation. I would guess that the first entry, that you need a 1 in bit [6] enables the THD compensation. That means that the Khadas DAC does not have THD compensation enabled because it sends 0x00 to that register.
If we check register 23-24, which is a 16-bit signed coefficient for correcting second harmonic distortion, that value is set to 0.
The same goes for register 25-26, which is not set at all.

So where do we go from here? Well, time to replace the logic analyzer that only reads values and use a Bus Pirate that can inject values to registers instead. However, first I need to get my QuantAsylum QA-401 setup to read the THD correctly and then enable the THD compensation. The next step would be to try to feed coefficient values and try to knock down the already low harmonics. However, that has to be done at a later stage. Maybe we could give the correction coefficient values to Khadas as a Christmas present?
 

Attachments

jackenhack

Active Member
Joined
Oct 25, 2018
Messages
164
Likes
342
Location
Stockholm, Sweden
#3
Does anyone have any information on the coefficient value for the THD compensation for the ES9038Q2M? The documentation is really anaemic when it comes to that information.

I could just bit-bang it, and just write a Python script to inject values.
 

jackenhack

Active Member
Joined
Oct 25, 2018
Messages
164
Likes
342
Location
Stockholm, Sweden
#5
I have let the logic analyzer run for a while, during which I have changed between different formats, like DSD, high-res, but the XMOS doesn't send any new values. It would be a piece of cake to program something like an ATtiny85 microcontroller to inject whatever we like if Khadas is not interested in changing their drivers. Hell, when we have control of the I2C bus, hardware volume control or an OLED display is also easy to design.
 

SchwarzeWolke

Member
Patreon Donor
Joined
Feb 7, 2018
Messages
75
Likes
58
#6
Hm... Does that mean that a lot of ESS DACs have the IMD hump due to an error in the data sheet?
If that is the case, wouldn't it be easy to some of the manufacturers like SMSL or Khadas to send Amir some experimental firmware and he measures the devices like the Tone Board or the SU-8 again?
 

jackenhack

Active Member
Joined
Oct 25, 2018
Messages
164
Likes
342
Location
Stockholm, Sweden
#8
Maybe we could convince @amirm to buy a Bus Pirate? :)

As soon as I get hold of an extra Raspberry Pi, I can set up a measurement of the Khadas DAC using my QA-401 audio analyzer. But the DAC is pretty close to the noise floor of the QA-401. I have built a 1kHz twin-t notch filter, so I can measure lower values, so that's an option. I'll try to get the time to set it up during Christmas.
 

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
16,836
Likes
13,190
Location
Seattle Area
#9

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
16,836
Likes
13,190
Location
Seattle Area
#10
As soon as I get hold of an extra Raspberry Pi, I can set up a measurement of the Khadas DAC using my QA-401 audio analyzer. But the DAC is pretty close to the noise floor of the QA-401. I have built a 1kHz twin-t notch filter, so I can measure lower values, so that's an option. I'll try to get the time to set it up during Christmas.
FYI the problem is also visible in sweeps of THD+N. It is much less pronounced there but visible still. So try that and see if you can detect it.
 
Joined
Oct 26, 2018
Messages
9
Likes
21
Location
The Universe
#11
I talked to Toppings in July about thd_enb value. They said they tested it in their DX7s but was unable to reduce the hump.
My guess is that in several board designs this setting will make little difference.

It is hard for me to imagine that so many manufacturers did not play around with this kind of setting just to see what it does.

Maybe it even needs an extra hardware implementation to be usable?
 

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
16,836
Likes
13,190
Location
Seattle Area
#12
I think we still need to know what it does. They claim it improves THD performance so surely it shows up some place.
 

yue

Active Member
Joined
Jul 21, 2018
Messages
275
Likes
249
#13
I think we still need to know what it does. They claim it improves THD performance so surely it shows up some place.
I already mentioned it various times in the forum. the thd_enb is an on/off boolean to control whether or not to adjust the 2nd and 3rd harmonics. When it's enabled, the developer can adjust thd_comp_c2 and thd_comp_c3 value (both are 16 bit signed) to adjust 2nd and 3nd compensation accordingly.
 

jackenhack

Active Member
Joined
Oct 25, 2018
Messages
164
Likes
342
Location
Stockholm, Sweden
#20
t is hard for me to imagine that so many manufacturers did not play around with this kind of setting just to see what it does.
Yet you see a lot of manufacturers leaving it over the driver development to a German company (which name now eludes me.) I'm pretty sure Khadas uses the XMOS example code without any modifications except sample rates and bit-depth.

There's only one way of finding out. I'll set up the experiment tomorrow and do the experiment. I'll keep updating this thread.
 
Top Bottom