XU216-512 THD+N/signal shaking Topic is solved

Technical discussions around xCORE processors (e.g. General Purpose (L/G), xCORE-USB, xCORE-Analog, xCORE-XA).
User avatar
pucur
Junior Member
Posts: 5
Joined: Thu Nov 30, 2017 9:22 am

XU216-512 THD+N/signal shaking

Postby pucur » Fri Sep 25, 2020 12:07 pm

Hello,
I have been struggling with this strange problem for a few weeks that I have never seen before, so I would appreciate any advice or idea.

We have a cooperation with the MQA and they gave us the FW for our XMOS/Audio project. We are using ES9038 DAC that has integrated jitter eliminator, but even with that, we have some strange behavior on the output.
MCLK=24.**/22.***MHz, I2S communication...
1. With the MQA FW, the signal (1kHz) is shaking a little and THD+N is about 0.4%, after a few minutes THD is good, and the shaking that we see on the oscilloscope/analyzer disappears. And this is a case with any sample rate.
I'm not sure what is the problem THD or Noise because I measure on the analyzer 0.4% noise and low THD, or sometimes the opposite. But when I measure the SNR it is good. All I see is that shaking.
2. With XMOS reference FW (without MQA), the situation is a little different. The output is good for a sample rate <176.4kHz, but for 176.4kHz and higher s.r. I get 0.8%THD+N and after a few minutes it became stable.
3. Everything is at the Tile0: I2S, USB, I2C, QSPI for the flash, MCLK... I tried without gpio pins but the result is the same.

We tried a lot of things but I think that its not an HW problem because DAC works with the SPDIF input and also when we wire the I2S signal from the XU208 processor (I think that's the worse scenario, wires from the board to board and it works). The clock is good, we are using the PLL IC that has 2 MCLK outputs for DAC and XMOS, we have already used it with the XU208 and everything was perfect. I have compared the clocks, I2S signals with the XU208 board and everything is the same. I can't measure jitter but it looks fine, or the same as with XU208.
When we turn on the device and leave it for about 10min and then play the 1kHz, the output has high THD+N (0.4 - 0.8%) at the beginning, so I believe it is not up to the PSU or PLL, it should become stable for that time.
When we turn on the device and play the 1kHz, then stop it, after a few minutes when we play it again it is good.
If we change the sample rate on the analyzer after we get a steady output (good THD+N), it becomes unsteady again and THD+N is >0.4% like from the beginning.
I tried to find a difference in the PSU, I2S, Clocks... before and after the steady output but I didn't succeed.

I got the advice to try to make some kind of jitter eliminator with a FPGA/Latch... But they said that on their board it work fine even without it. I think that I don't need it, same configuration and PCB layout worked perfectly with a XU208.

I must admit that I'm very confused because I tried everything that comes to my mind in this couple of weeks.
You do not have the required permissions to view the files attached to this post.
View Solution
User avatar
mon2
XCore Legend
Posts: 1831
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Fri Sep 25, 2020 3:37 pm

Hi. Not an audio developer but wish to share a similar case for another OEM...be sure that your code is not attempting to communicate with I2C bus devices that are not present in your box. If you have such "ghost code" then the I2C IP will keep retrying to ping the missing device(s) numerous times (believe that 2000 is the XMOS default value) before declaring a timeout. This retry cycle will starve the bandwidth from other code runs on the CPU. At the very least, can affect the USB IP timing and perhaps the issue you have raised. It has been a while since we reviewed the source code but believe there is a define for the # of retries that you could reset to 0 or 1 and see if this impacts your outcome. Or just correct the source code to just not communicate with the I2C bus address of the missing device(s).

Please review and share your update on this thread.
mmar
Active Member
Posts: 61
Joined: Fri Jul 05, 2013 5:55 pm

Postby mmar » Sat Sep 26, 2020 1:58 pm

Try other DACs or 2xMCLK.
User avatar
pucur
Junior Member
Posts: 5
Joined: Thu Nov 30, 2017 9:22 am

Postby pucur » Wed Oct 07, 2020 8:34 am

Hi,
I'm using one I2C to communicate with PLL IC and it works well, sending bytes just one time. I don't know is there any other I2C but I don't see it declared in the XN file.
It works the same with 2xMCLK, I didn't try other DACs, this one should work well.
I saw some activity on the QSPI_D3 of flash memory but I believe it is OK because I saw it on the XU208 project too.
Is there anything else I can try?
mmar
Active Member
Posts: 61
Joined: Fri Jul 05, 2013 5:55 pm

Postby mmar » Wed Oct 07, 2020 8:27 pm

Check all samplerates without upsampling to 384k, and as you write DAC ES9038 have jitter eliminator , that need MCLK higher as BCLK , but you write MCLK=24.**/22.***MHz, I2S communication. When MCLK equal BCLK internall pll ES need amount of time to lock , and without lock is THD as you see.
User avatar
pucur
Junior Member
Posts: 5
Joined: Thu Nov 30, 2017 9:22 am

Postby pucur » Thu Oct 08, 2020 11:28 am

Thank you very much mmar.
I've disabled upsampling and made MCLK x2. Now it is good for 176.4/192kHz SR, I can't play 384kHz from the analyzer but will find a way how to test it and maybe increase MCLK more if I need to.

Who is online

Users browsing this forum: No registered users and 4 guests