3
$\begingroup$

Recently I've made a simple single IF superheterodyne SSB receiver for 40 meter band. The schematic is available here [PDF]. VFO and BFO are based on Si5351, the AF amplifier is LM386. It works OK but there is one annoying issue I couldn't solve so far. When I change the frequency I can hear a popping sound in the headphones.

I thought this could be an RFI from an 1602 LCD and/or the I2C bus. However this theory was not confirmed. When the text is updated on the LCD without changing the frequency there is no popping sound. I also tried to add a simple RC high-pass filter to the AF amplifier. According to the datasheet, LM386 has input impedance ~50 kOhm. Thus with 10 nF capacitor on the input it will form an high-pass filter with cutoff frequency ~300 Hz. This didn't help either.

Then I thought maybe the problem will go away when I place the receiver in a proper aluminum enclosure with good ground plane and move AF amplifier away from the VFO. Sadly this made no difference.

The problem is that I have little understanding of what exactly causes this popping sound and how to diagnose such problems. Hopefully someone who also encountered such an issue could explain how to deal with it? I tried to Google the problem. It seems to be quite common, but I didn't manage to find a solution or an explanation of the effect.

$\endgroup$
2
  • 2
    $\begingroup$ Does it only happen as you change frequency? I'm wondering if it's something related to the VFO/Si5351. Could it be that as you re-program the PLL for a new frequency it generates artifacts. Or maybe it's some interaction between VFO and BFO (both are generated from the same Si5351 module I suspect)? $\endgroup$ – Buck8pe Jan 19 at 8:33
  • $\begingroup$ @BrianK1LI I did, see the answer below. $\endgroup$ – Aleksander Alekseev - R2AUK Jan 20 at 15:41
4
$\begingroup$

I think I figured this out. By looking at VFO with an oscilloscope I could catch a brief glitch (~1.5ms) in the signal when the frequency is changed:

enter image description here

It was hard to notice because you can't easily trigger on this. I had to manually trigger single captures while tuning for some time to see this.

Then by googling "si5351 output glitches" I've found this piece of code on the QRP Labs website. The comment states:

Reset the PLL. This causes a glitch in the output. For small changes to
the parameters, you don't need to reset the PLL, and there is no glitch.

Then I realized the source of the problem and how to fix it. Here is the original version of my code:

void changeFrequency(int32_t delta) {
    targetFrequency += frequencyStep*delta;
    if(targetFrequency < 7000000) {
        targetFrequency = 7000000;
    } else if(targetFrequency > 7200000) {
        targetFrequency = 7200000;
    }

    if(targetFrequency < 10000000) {
        Fvfo  = Fbfo-targetFrequency; // LSB
    } else {
        Fvfo = Fbfo+targetFrequency; // USB
    }
    si5351_EnableOutputs((1<<2));
    si5351_SetupCLK0(Fvfo, SI5351_DRIVE_STRENGTH_4MA);
    si5351_EnableOutputs((1 << 2)|(1<<0));
}

Here si5351_SetupCLK0 is called every time the frequency is changed. The procedure changes the PLL, MS and Rdiv settings for the channel. As an author of this Si5351 driver I'm well aware that PLL settings are always the same for frequencies below 81 MHz (also this is a documented behavior which can be relied on in the future versions).

Thus the code was changed as following:

void changeFrequency(int32_t delta) {
    static bool pllSetupDone = false;
    si5351PLLConfig_t pll_conf;
    si5351OutputConfig_t out_conf;

    targetFrequency += frequencyStep*delta;
    if(targetFrequency < 7000000) {
        targetFrequency = 7000000;
    } else if(targetFrequency > 7200000) {
        targetFrequency = 7200000;
    }

    if(targetFrequency < 10000000) {
        Fvfo  = Fbfo-targetFrequency; // LSB
    } else {
        Fvfo = Fbfo+targetFrequency; // USB
    }
    si5351_EnableOutputs((1<<2));

    si5351_Calc(Fvfo, &pll_conf, &out_conf);
    if(!pllSetupDone) {
        // Setting up the PLL causes a brief (~1.5ms) glitch in the VFO output
        // which sounds like a loud popping sound the the speaker.
        // By setting up the PLL only once we get rid of this popping sound.
        si5351_SetupPLL(SI5351_PLL_A, &pll_conf);
        pllSetupDone = true;
    }
    si5351_SetupOutput(0, SI5351_PLL_A, SI5351_DRIVE_STRENGTH_4MA, &out_conf);

    si5351_EnableOutputs((1 << 2)|(1<<0));
}

Now the expansive call si5351_SetupPLL is made only once, the glitch is gone and the popping sound is eliminated. Well, almost. You can still hear a very quiet popping when the antenna is disconnected. But there is no popping when the antenna is connected. Interestingly you can observe the exactly same behavior in QCX transceiver made by guess which company.

$\endgroup$
2
  • 1
    $\begingroup$ Good to hear you got this sorted! This will definitely help many hams as the Si5351 is a very popular VFO. $\endgroup$ – Buck8pe Jan 20 at 16:16
  • 1
    $\begingroup$ Glad you solved this! Many hams have been plagued with this problem. And don't forget to mark your answer as accepted by clicking the checkmark icon on the left. Otherwise, the system will think it still needs solving and will keep pushing it to the top. $\endgroup$ – Mike Waters Jan 20 at 21:15
3
$\begingroup$

Try powering the LM386 temporarily off a battery. if the popping stops, then the cause is a surge being conducted into the 386 from the supply that feeds the rest of your circuit.

Normally, you would bypass the power input of the 386 to ground with a hefty electrolytic capacitor (50 to 100mfd) and then shunt that with a fast-acting cap (0.01 to 0.1uF) to prevent surges from upsetting the 386. If your circuit doesn't have these bypass caps, try adding them.

$\endgroup$
1
  • $\begingroup$ I gave it a try. Sadly in my case it made no difference. The popping is still present when I power the AF amplifier from a separate 9V battery. $\endgroup$ – Aleksander Alekseev - R2AUK Jan 20 at 14:07
1
$\begingroup$

Since it happens when switching frequencies, I suspect glitches of some form in the local or beat frequency oscillators' output.

The mixers simply multiply the "signal" by the oscillator. Any noise or glitch in the oscillator outputs will be reflected in the mixed outputs.

You may be more sensitive to BFO glitches, since the output is at DC, not a higher intermediate frequency.

The glitch could be as simple as a phase change in the oscillator or a missed cycle. That will add a DC component to the signal, which will turn into a DC shift in the mixer output.

Since the passband of the mixer and audio amplifier probably does not go to zero Hz, it will sound like a click.

Are you actually changing the BFO frequency? In most multi-conversion receivers it is only the first local oscillator whose frequency changes by tuning. Other oscillators may change frequency for other purposes, such as switching between USB and LSB, but for tuning up and down the band they are typically constant frequency.

$\endgroup$
2
  • $\begingroup$ In my application BFO is about 12 MHz. It's never changed or turned off, only VFO changes. The block diagram of the receiver is available here eax.me/superhet-receiver And here is a firmware eax.me/files/2021/01/40m-superhet-receiver-firmware.tgz As a side note I experimented with other crystal filters, with different IF (9 Mhz, 11.059 MHz), the behavior is always the same. $\endgroup$ – Aleksander Alekseev - R2AUK Jan 20 at 14:13
  • 1
    $\begingroup$ Do you have a scope you could use to look at the BFO and LO outputs? Set up a loop with a gp pin to use as the scope trigger, switching the oscillator to frequency A when you raise the pin and back to frequency B when you lower it. Look for anything interesting, like shifts in the average value, missing cycles, or lengthened cycles. You should see nothing on the BFO, but if you do you've found the source of the clicks. Then comes the process of finding the cause. If the BFO is clean, look at the IF output for any visible glitches. If there are glitches in the IF, check for LO glitches. $\endgroup$ – cmm Jan 20 at 14:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.