Headset noise when printing

[aclassifier]

I use xTIMEcomposer 14.4.1 and an X2 Explorer board to read a mic and output to a headset. To come to this point, there are several queries (by me) and answers (by you!) on this forum.

My question is why do I get noise in the headset on every print to XTC? I did not get this with the round mic array board. I think the processor is halted while the XTAG does the printing(?)

I have one mic plus one that isn't mounted, since I need only mono, but this is needed for the ICS-52000 on the EV_ICS_52000-FX from InvenSense. The 4-mic boards from NotWired.co did not work, got the money back. The headset DAC is PIM544 from Pimoroni, containing a PCM5100.

Do I get the noise because of by SW bit-banging (no external PLL) or because the PCM5100 headset amp behaves differently from the DAC CS43L21 on the round board? I have not figured out whether it's the headset or the mic that generate this noise, or maybe even both.

I do all clock handling for 16 kHz stereo by bit banging in XC. Getting exactly 1024 MHz or 512 kHz I do by altering some almost correct values, but inside duty cycle requirements - adding up to exact values. This works beautifully for both mic and headset. So there is no external PLL connected.

I assume that on the round board wit its external PLL, the output ports will be just as halted during the prints as with my bit banging? Hmm..

[MaximLiadov]

>> why do I get noise in the headset on every print to XTC?

The most obvious explanation is ground loops. https://en.wikipedia.org/wiki/Ground_loop_(electricity)
Noise and pickups from the digital part go to the ground bus and you hear it because the output voltage is a potential between a signal and ground. Usually you break the ground loop when you disconnect the XTAG from your PC.

[Ross]

>> why do I get noise in the headset on every print to XTC?

The most obvious explanation is ground loops. https://en.wikipedia.org/wiki/Ground_loop_(electricity)
Noise and pickups from the digital part go to the ground bus and you hear it because the output voltage is a potential between a signal and ground. Usually you break the ground loop when you disconnect the XTAG from your PC.

Could try and battery powered laptop I I guess?

[aclassifier]

Thanks, both. But no, I don't think it's a ground loop. I did have a scope connected, but I have an isolation trafo with it (NOT SMART FOR HIGH VOLTAGE MEASUREMENTS). However, disconnecting the scope and powering the board from a power bank did not help.

What stops when XTAG does prints, by the way?

But I also have another problem: noise from I2C. Even if I have twisted the cables and inserted 22 Ohm serial resistors to make the lines as balanced as possible, when my code updates the display or FRAM module, I also get noise. It's kind of the same noise as the one I'm talking about. I thought they were two matters, but maybe they aren't.

I have been planning to change the cables to shielded, that may solve the I2C interference problem. Also in the I2C I have tried a small serial resistor and small caps to slew rate limit. But it did not help. And then it's strange that digital pulses should interfere with other digital noise (I2C -> PDM).

I may of course have a ground loop here, with the analog parts of PIM544. But I have been aware of those since the sixties, when there was a time to scratch build stereos, and a 2 mV magnetic pickup should keep quiet in a box with bloating two times 20W! It did, in the end. (It still exists on some shelf)

[MaximLiadov]

>> since the sixties

Modern headphones have very high sensitivity, up to 115 dB/mW, so now we hear what we didn't hear before.
Nowadays, proper audio design means multilayer PCB and separation of analog and digital grounds.
Highly recommended: https://youtu.be/ySuUZEjARPY?t=4461

P.S. I didn't mean to be disrespectful. Just shared my thoughts.
P.S.S. In our commercial product, we have 127 dB dynamic range @ 4 Vrms at the audio input and absolutely flat noise spectrum. That means pitch-black silence. We have dedicated analog and digital PCBs. Just 4-layer design PCB is enough.

[MaximLiadov]

>> analog parts of PIM544

Uses PAM8908 with 100 dB SNR. But declared it could be powered directly from the digital part: "A high power-supply rejection ratio (80dB at 1kHz) allows this device to operate from noisy digital supplies without an additional linear regulator." Sounds a bit doubful to me. I would try to power the analog board from a dedicated battery.

[aclassifier]

Thank you! No offense in anything!

I'll follow this up when I know where the source of the problem is. Right now the pendula is moving towards the mic, not the headset.

[aclassifier]

I now know more.

If I turn all debug printing off then the rather long noises in the headset playback are gone. I don't know if this is because the XTAG 3 stops the cores or not.

Now, when I write to the display through I2C at the same time, this is reduced to some times audible weak clicks. Writing to the display is caused by button clicks.

If I just write to the display for ten push button presses and then don't update the display the next ten then the tiny click is not audible at all when the display is not written to.

But the important thing is that when I write to a port for the scope, pulses that inform about the mic input samples, I do see strong samples on that barely audible click. Even when the display goes dark by itself, with an I2C sequence without any click from any button, I do see that high volume sample when I2C works with the display.

In other words, it's the mic that picks up these signals. Adding more decoupling caps to the ICS-52000 did not help.

Writing to the headset PIM544 is not the problem.

I have not shielded any cables yet, they are still twisted and braided.

The pulses for the mic are on J1 pin 19, 21, 23 and for the I2C on J1 37 and 38 - quite far apart.

I did read that making the I2C pull-ups weaker may help, but also that having some of them around is perhaps not a good idea. I will look at this, whether I2C pull-ups to get the speed at more than one place may be a last test to try to get away with that click.

[akp]

Just checking:
1. Do you have XTC run/debug set so it is using XScope output server and not JTAG I/O server?
2. You have a config.xscope file in your project? Mine is in my src directory and looks like:

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<xSCOPEconfig enabled="true" ioMode="basic">
</xSCOPEconfig>

[aclassifier]

Thanks for the response!

I have experimented with xscope, but I did run the JTAG I/O server.

If I tried your config.xscope and ticked the "Run XScope output server" in the debug config, I still got the clicks (which _might_ come from the I2C), but my debug window did not print a character from my code.