My DIY Soundcard interface for measurement aka' SuperRanger

Could the 9-10KHz noise come from the display circuits or the processor? Those have been problems for many in the past. The broad peak would support some rapidly changing source. You could make a pickup coil and "sniff" around the circuits for noise sources.
 
  • Like
Reactions: lykkedk
@1audio Yes it could be an issue with the ESP32 and in the beginning I found out that lowering the freq. to 10MhZ when stable it removed all this... Thanks it reminded me that I should test this again to be sure after I use the Cosmos with a lower noisefloor than my Behringer.
 
The fast transistion for all those functions get into everything. You may need a shield container for them or even a seperate box. Displays are notorious for noise. Tek used to provide metal screens for the scopes to deal with noise radiation. I suspect LCD OLED could be worse than a CRT. And you are way down in the noise with this stuff.
 
  • Like
Reactions: lykkedk
Hmm... I thought I allready figured it out long ago, by disabling wifi, bluetooth etc... and lowering the Mhz to 10.
Remember that when using the Behringers -145dB noisefloor the spikes went away this way.

But I know it's possible to have relay's on and putting the ESP32 into deepsleep mode, maybe it will do the trick? Let's see when I get to it 😊
Actually it was a good feeling finding this out.

The screenshoot is taking without warming the SuperRanger and Cosmos for say 15min. as usual, but it's sure looking good.

Gain is unity when all relays are off like this screenshoot below ::

Oled on ESP32 off.jpg


IMG_7399.jpg
 
So it did actually trick me figuring out if I could remove the noise by setting the ESP32 into deepsleep mode.
It showed that the processor was not the main cause of this problem.

The difference between 240MHz and the 10MHz and completely off is not that big, but there is some noise/grass. The MHz is lowered into 10MHz as soon as the measurement is "stable" (fast enough for stepped sine)
The cause for the 9KHz bump was the OLED screen's charge pump, and as soon as I in software turned off the screen, the bumb was gone 😎

Hmmm lessons learned, but good thing is I learned some more timed delay and 1. button logic programming.

I did reprogram the button used to switch between SE and Bal. input, so button now have both long and short press.
Long press = change between SE and Bal. input.
Short press = OLED autooff or allways on.

So when I choose OLED autooff, the display turns off as soon as measurement's are stable... It's working perfectly, better as I could have hoped for.

It cannot be seen on the pictures, but the THD, THD+N, 2.H, 3.H etc... are not much deviated from what I get running directly into the CosmosADC.
I will try to do some more measurements on some of the gainsteps, but it sure are looking good to my eyes.
I will also post some "reallife" measurements, but I need a short break....

Thank's for all the helping until now 😊

Jesper.

void DisplayOFF() {
display.sh1106_command(0xA4);
display.sh1106_command(0xA5);
//display.sh1106_command(0x81);
display.sh1106_command(SH1106_DISPLAYOFF);
Display = false;
//DisplayAutoOFF = true;
}

void DisplayON() {
display.begin(SH1106_SWITCHCAPVCC, 0x3C);
Display = true;
//DisplayAutoOFF = false;
}

SMSL.jpg


FreqResponce384k.jpg


Zoomed noisefloor.jpg


PLAIN Display OFF vs. ON vs. 240, 10MHz.jpg
 

Attachments