FM tweaks from Telegram

[max-arnold]

Below is a post by Kalipso2004 in the TG channel (source). Reproducing it here so it is not lost in the chat history:

I wanted to propose my additions to the source code, namely:

1. Adjust the FM radio signal reception and processing mode by adding the following to the useBand function (main .ino file) after the lines:

if(band->bandMode==FM)
  {
    // rx.setMaxDelaySetFrequency(60);
    rx.setFM(band->minimumFreq, band->maximumFreq, band->currentFreq, getCurrentStep()->step);
    // rx.setTuneFrequencyAntennaCapacitor(0);
    rx.setSeekFmLimits(band->minimumFreq, band->maximumFreq);
/*—————————begin———————*/
    rx.setFmStereoOff();   // Some might not like this, but in such a small receiver, stereo isn't needed, in my opinion  
    rx.setProperty(0x1105, 127); // Registers 0x11xx configure thresholds for hard "MONO" mode  
    rx.setProperty(0x1106, 127);
    rx.setProperty(0x1108, 33);
    rx.setProperty(0x1300, 255); // Registers 0x1300 to 0x1305 configure SOFTMUTE mode. My observations: in urban conditions, FM stations are received reliably,  
    rx.setProperty(0x1301, 4);  // and when tuning between stations, there's no characteristic hissing—almost complete silence  
    rx.setProperty(0x1302, 22);  // This register specifically controls the audio suppression strength (in dB) during tuning
    rx.setProperty(0x1303, 4);      
    rx.setProperty(0x1304, 32700);  
    rx.setProperty(0x1305, 32700);  
    rx.setProperty(0x1800, 127);  // Registers 0x18xx configure thresholds for hard "MONO" mode
    rx.setProperty(0x1801, 127);
    rx.setProperty(0x1804, 127);
    rx.setProperty(0x1805, 127);
    rx.setProperty(0x1808, 0);
    rx.setProperty(0x1809, 0);
    rx.setProperty(0x1900, 0);  // Registers 0x19xx control the noise suppressor. Although the SI473x chip isn't officially listed as supported,  
    rx.setProperty(0x1901, 48);  // I can neither confirm nor deny this. There's no audible difference, but it doesn't interfere. Can be removed if needed.
    rx.setProperty(0x1902, 64);
    rx.setProperty(0x1903, 300);
    rx.setProperty(0x1904, 125);
    rx.setProperty(0x1A00, 1);    // Registers 0x1Axx handle the "cutting" of high-frequency components from the audio signal, which,
    rx.setProperty(0x1A01, 1);    // in the case of a small speaker in the receiver, provides interesting possibilities for frequency correction. 
    rx.setProperty(0x1A02, 10);
    rx.setProperty(0x1A03, 32760);  
    rx.setProperty(0x1A04, 1);      
    rx.setProperty(0x1A05, 100);    
    rx.setProperty(0x1A06, 0x0055); // This register allows selecting audio cutoff frequencies 
/*—————————end————————*/

(All of this is detailed in the AN332 document.)

And by default, I set the FM bandwidth to 84 kHz.

2. Increase the I2C bus speed to 1200 kHz. The SI473x chip handles this speed reliably—tested on multiple samples. Interface responsiveness improves. Where needed:

   Wire.begin(ESP32_I2C_SDA, ESP32_I2C_SCL, 1200000L);
   rx.setI2CFastModeCustom(1200000L); // Such lines should be reviewed across all source files and the speed replaced.

3. Another thing—increase the PWM frequency for backlight control to 32000 Hz (the "whine" in the final audio signal disappears).

4. Uncomment the line related to the antenna capacitor.

5. Remove the delay at the end of the LOOP cycle in the main .ino file.

Well, that seems to be everything.

I’ll mention again — all of this is based on my personal observations during experiments with SI4735 and SI4732 chips paired with ESP32 and RP2040.

[max-arnold]

I do not have plans to enable the MONO mode (many folks use external stereo speakers or headphones), but the backlight tweak and i2C speed look interesting.

[EmEiBee]

I agree. Mono mode doesn't make sense. When using the internal speaker, both channels are combined anyway.

However, I think the other ideas are very good.

[buddy-kilo]

Mono can be advantageous in low-signal conditions, and it's not simply a matter of combining both channels through the internal speaker by the way. True mono mode (stereo decoder disabled) offers a better signal-to-noise ratio.

[max-arnold]

@G8PTN Hi Dave!

I remember you did some experiments with the backlight PWM frequency. What is your opinion on the following suggestion?

Another thing—increase the PWM frequency for backlight control to 32000 Hz (the "whine" in the final audio signal disappears).

[G8PTN]

Hi Max,
The original Ralph Xavier code had the backlight PWM frequency set to 2 kHz and I could hear the tone on the headphone output.
I increased the frequency to 16 kHz so that it was high enough for it not to be heard.
The frequency could be increased to 32 kHz, but it may also increase the RFI on received signals at harmonics of 32 kHz.
The behaviour may also be different with hardware that has the headphone amplifier fitted. I only have V1 hardware without the amplifier.

73, Dave

[EmEiBee]

Question:
Which version has a headphone amplifier? Did I miss something, or perhaps a circuit diagram?

[G8PTN]

Which version has a headphone amplifier? Did I miss something, or perhaps a circuit diagram?

Hi,
The hardware versions that I am aware of are summarised in the table below. The version identifier is for my reference.

Images of most of the versions are shown in the attached thread.
#103 (comment)

I hope that covers your question.
73, Dave

[EmEiBee]

Then I haven't missed anything.
I have no idea what the V1 use; must be different from SI4732...
From V2 up, the headphones are driven directly by the SI4732 (respectively in V1 the chip at place of the 4732). The 4732 has a small, rudimentary, and very low-power headphone driver stage; it's not sufficient for anything more.

As far as I know, a version with an explicit downstream headphone amplifier doesn't exist (yet).

In one of the later versions, the small NS4160 could be replaced with a Class-D stereo amplifier and used to power the headphones and the internal speaker.

This would offer two advantages:

• Full power even with low-impedance headphones based on the operating voltage (which could also be powered by UB instead of 3.3V)
• Frequency response adjustment to "tweak" the frequency response / boost the bass and treble...

But it can also cause problems:

• Class-D and similar digital amplifiers naturally generate a lot of QRM, which we don't want in the radio; the display already generates enough QRM...

[max-arnold]

Here is another V3 variant with a different Hi-Z layout

[G8PTN]

Hi,
On V1, the Si4732 drives the headphone output port directly. The SI4732 also drives the speaker amplifier (NS4160) when the headphones are not plugged in.

The SI4732 can not drive the relatively low impedance (32Ω) on the 3.5mm socket when headphones are used. My understanding is that the additional chip on V2 and V3 is a headphone driver and sits between the SI4732 and 3.5mm socket.

The NS4160 can operate in Class-AB or Class-D. I think the ats-mini firmware always tries to operate it in Class-AB to minimise RFI, although the power is less if operating in Class-D.

An extract from the datasheet is shown below for information.

73, Dave

[EmEiBee]

Sorry, but I'm sure you are on the wrong path.

If you can see here #103 (comment) the 4732 left and right outputs goes via a C direct to the headphone jack. If headphone is not connected, the left & right signal is passiv mixed down to mono via R21 || R20 -> C20 -> R24 -> Input of NS4160

[G8PTN]

Hi,
I did not show the two resistor passive mixer on the output of the switched 3.5mm, pins for simplification.
73, Dave

[EmEiBee]

Hu?
Okay... But trace the output signal from the 4732 to the jack and then to the 4160.
The jack is definitely in the signal path from the 4732 TO the 4160, and therefore behind the jack. How is it supposed to pass a nonexistent signal to the headphones when the headphones are plugged in, and via what path?
Not to mention that the 4160 is a pure mono amp...

[G8PTN]

Hi,
With reference to the V1 schematic.

For hardware V1, the signal nets marked “L” and “R” are from the SI4732.
For hardware V2, and V3, the assumption is that signal nets marked “L” and “R” will be from the headphone buffer chip.

• When the headphone jack is not inserted:
  Pin 3-5 of the 3.5mm socket are shorted.
  Pin 4-6 of the 3.5mm socket are shorted.
  This signals from “L” and “R” (via the 3.5mm socket) are passively mixed together and feed the mono speaker amplifier (NS4160).

• When the headphone jack is inserted:
  Pin 4-6 of the 3.5mm socket are open.
  Pin 3-5 of the 3.5mm socket are open.
  No signal is fed the speaker amplifier.
  The “L” and “R” signals (L = Pin 3, R = Pin 4) are connected to the “ring” connections on the (TRRS) stereo plug (i.e. to the headphones).

73, Dave

[EmEiBee]

Ok... Just show me the "headphone buffer chip" please. Maybe I'm blind...

[G8PTN]

Ok... Just show me the "headphone buffer chip" please. Maybe I'm blind...

Hi,
The schematic is for V1, so you will not see the headphone buffer chip.
I have not seen any published schematics for the V2 or V3 variants.
Someone should be able to trace the connections from the V2/V3 PCB's and create a schematic !
Unfortunately, I only have V1 hardware.
73, Dave

[EmEiBee]

This one is explicitly labeled V1. As you can see, there's no NS4180 mono amp installed. Therefore, I assume the previous schematic is V2.

This also matches my V2 receiver, which doesn't have a buffer on the board; at least, I haven't found one.

I'd be happy to open it for you and take enough pictures...

But actually, I haven't found a schematic (yet) that's explicitly labeled V2.

[G8PTN]

This one is explicitly labelled V1. As you can see, there's no NS4180 mono amp installed. Therefore, I assume the previous schematic is V2.

Hi,
No, the schematic you attached labelled "V1.0" is not for the ATS-MINI.

The previous schematic is for ATS-MINI V1. If you have V2(B) hardware, the headphone buffer will be underneath the display as previously mentioned.

I am not sure what model the schematic label "V1.0" is for, but it looks like it has lots of nice features.
The main features are:

• Switched RF filtering
• Airband down converter circuitry
• SI5351 clock generator for stable reference and local oscillator for the down converter.
• I2S digital audio

I am not sure that it will support SSB, since the I2S interface is used on the SI4732 and as far as I know the SSB patch can't be used with I2S. Nevertheless, the schematic is interesting. Please provide any links to the actual hardware .

73, Dave

[EmEiBee]

The schematic comes from here: https://xtronic.org/circuit/rf/si4732-si4735-radio-pro-mini-radio-receiver/
I only have searched for pictures, so I haven't looked into the website where it comes from.

Meanwhile, I'm lost... Also about the many schematics. I also think it needs a central overview. GIT isn't the best place for that due all the information are extremely fragmented. Or I'm the only one see it this way?

If someone find a schematic of the V2 and V3 it will be very helpful I think. It's a shame when we keep talking past each other because of different baseline data.

You've certainly shown a lot of patience; thank you for that.

Have to reset and reboot my brain now...

[max-arnold]

Some experiments with V2(B) from the same person https://t.me/talkradio/174172/216671

Rough translation:

Recently, I compared the FM signal reception quality between hardware versions 1 and 2(B) of the ATS Mini. The result: Version 1, without any hardware modifications, picks up the signal very well and reliably under fairly challenging conditions—without interference and even with the antenna not fully extended—while successfully decoding RDS signals.

Version 2(B), in its unmodified state, performs very poorly—reception is unstable, and sometimes you have to move around to get any signal at all. The signal is drowned out by noise to the point where the broadcast station becomes inaudible, even though the signal indicator shows full strength. As mentioned somewhere before, the noise seems to come from the headphone amplifier HT4832.

I decided to experiment. First, I routed its sleep mode control pin to a separate ESP32 pin with code modifications—no luck, the noise persisted (though slightly reduced). Then, I adjusted its circuit in our device according to the datasheet (for reference: the audio signal path is as follows—output from SI4732 goes to the headphone amplifier, then from the headphone amp through a mechanical headphone jack switch to the speaker amplifier input; the "mute" circuit grounds the signal right after the SI4732 output).

I discovered an inaccuracy in the SI4732-to-headphone amp input connection—according to the datasheet, the signal should go to the inverting input of the amplifier channel, but in reality, it was connected to the non-inverting input. I fixed it. Even after replacing all supporting components per the datasheet, the issue remained.

Additional observation: The internal power converter frequency (on CAP+ and CAP- pins), as measured by an oscilloscope, was around 430 kHz (though the datasheet for a similar amplifier, PAM8908, specifies ~1.2 MHz).

Finally, I reworked the circuit to match Version 1—i.e., disabled the headphone amplifier entirely—and the reception came back to life! All available stations immediately appeared, and even the auto-scan now locks onto every station at the exact right frequency.

Yes, there’s no headphone amp now, but at least the FM reception works—even with a non-extended antenna. Next, I’ll test shortwave (SW) reception. I also modified the AM/FM input section according to AN383 (added a 33 pF capacitor and a 220 µH inductor).

Seems like this version took a wrong turn somewhere.

Along the way, I compared the impact of the NS4160 amplifier in Class AB vs. Class D modes—no effect on reception or sound quality, but Class D saves an extra 20 mA of current.

And that’s the result of my two-day experiment!)))))

[Hamberthm]

Hi @max-arnold !

Thanks for your work. It's nice to see I'm not the only one with a very poor performing V2.
May I ask how you disabled the headphone amp precisely? Did you simply cut power to it? Did you re-route the audio out?

Thanks!!

[max-arnold]

@Hamberthm Hey!

The post above was authored by Kalipso2004 on the TG channel, you can ask him directly here: https://t.me/talkradio/174172/216671

[max-arnold]

In my own quick comparison, V2(B) has:

• worse rssi/snr https://t.me/talkradio/174172/214048
• Seek often stops on frequencies with no signal https://t.me/talkradio/174172/214053
• loud click when changing modes (due to lack of the mute circuit) - this was fixed in firmware

[EmEiBee]

MVI_0138.mp4

I can't detect any loud clicking here.

With the SEEK... Is that what I'm demonstrating here? The reception level almost always shows full deflection, and the scan only stops on strong stations.

I haven't noticed this before because I usually use FM.

[Cormel980]

The hardware versions that I am aware of are summarised in the table below. The version identifier is for my reference.
Clarification is needed, there may be more versions.
There are 2 different amplifier chips for headphones: HT4832 (analog of TPA6132A2 TI) and LM4809.
Phones are usually connected via high-capacity, ~100 uF, large separation capacitors. The HT4832 has a connection without these dc-blocking output capacitors, for this purpose a negative supply voltage is created - a DC Charge Pump inverter, which creates great interference with reception, and the TI manufacturer does not recommend use in radios.
The LM4809 is a classic 2-channel amplifier, which naturally does not create interference.
AMNVOLT V3 is available:

on LM4809, the circuit matches the datasheet:

To improve the reproduction of low frequencies in headphones, I replaced C25,C26 and 2xCi to 10 uF

dc-blocking output capacitors are located next to the encoder:

C25, C26 are crossed, as the left and right channels are reversed

[DB9JG]

Hi, I look at this interference topic more regarding interference (birdies) of the AM/SSB shortwave signals, less the FM-Radio reception. I noticed that especially when doing reception test between 144 kHz and 200 KHz, when often changing the antennas or particularly without an attached antenna.

In the comparison between my ATS Mini radios version 1 and version 3, it is noticeable that V3 has significantly more spurious responses (birdies), particularly hearable when no antenna is connected. V1 shows similar issues as well - but only less massive.

I was able to determine that some of the birdies are caused by the backlight PWM signal. My favorite HJBerndt firmware supported my search by allowing to change the backlight PWM frequency by the menue controll. If I set that as high as possible, the gaps between the noises are getting bigger.

The class-D amplifier with its harmonics of about 450KHz, seems to be more relevant in the FM range.

Some other birdies come from the parallel bus of the display, which is not easy to shield. I tried that with the V1 hardware by a inserting a grounded layer of copper foil between the lines and the PCB. This made not the absolutely game changing effect, but it was noticable.

However, many more and louder spurious responses / birdies arise because the supply voltage of the new impedance converter FET of V3 is not stabilized but is taken before the voltage regulator.
This does produce a somewhat higher supply voltage for the FET, but this voltage is unstable and contains interference pulses generated by the ESP32. This signals cause a lot of the birdies! Therefore, after having cut the supply trace of the FET(!!!!), I used the much cleaner and stabilized 3.3V supply voltage (Vcc_Radio) to supply the FET. Vcc_Radio is best available at pin 10 of the SI4732.
As a result, the number of birdies has now been significantly reduced in my modified AMNVOLT ATS Mini RX V3 .

Unfortunately there is not the ONE reason for the observed interference in SSB or FM receiving, but a conglomerate of little issues.

I tried to collect my growing findings, results and suggestions at: https://peterneufeld.wordpress.com/2025/06/13/si4732a-minirx-modifications/

[Kalipso79]

In any case, I completely excluded from the source code everything related to the ledcwrite function and simply switched to the classic - digitalWrite. It will affect the extra current consumption, but in my case of use it can be neglected. Who knows how the ledcwrite function is implemented inside the Espressif SDK source code, perhaps setting the extreme values 0 and 255 still does not completely exclude PWM at the output. I have already rewritten the source code for digitalWrite, on FM, naturally, everything is as before - I did not notice much difference, it receives the signal perfectly on a nail. On AM - it is necessary to check in the field on a standard antenna, at home there is no suitable antenna farm for work in the conditions of a "noisy" city.

[DB9JG]

One more note about the display hardware:
My AMNVOLT V3 has a ST7789 with a metallic backplane supposed to be a shield. A good idea but ... this shield radiates the PWM frequency if not connected to ground.

[Cormel980]

max-arnold It is enough to write max at brightness 255 and turn on GPIO 38 to 1. For 0 brightness the display is turned off

Kalipso79 In ats-mini the display makes noise on the air, I lean the telescopic antenna of another receiver against the display, everything is audible. On one of the receivers I had a grounded screen under the display, it was necessary to choose a grounding point. The best is on the battery.

[DB9JG]

After reading Dave’s suggestions, I investigated the potential noise sources of an AMNVOLT V3 ATS mini, focusing particularly on the 150 kHz to 300 kHz range in USB mode without an antenna attached.
I found “birdies” originating from:
• Harmonics of the 32.788 kHz clock generator, with the 1st harmonic at 160 kHz
• Harmonics from the backlight, which can be shifted by software and disappear when the brightness is set to zero
• I2C and display noise, presenting as weak, noisy, modulated carriers
I even detached the display, but still experienced noise in the 10m band.
I made several hardware tweaks to reduce the interference:
• Connected FET supply voltage to VCC_radio at pin 10 of the SI4732
• Added a 330 nF capacitor across VCC_radio and GND at pins 14/15
• Installed a grounded shield foil on top of the SI4732
• Placed a grounded shield foil between the display data lines and the PCB, grounded at the SMA socket

These changes significantly reduced the birdies, making them almost disappear into the noise floor when an external antenna is connected.

I did not equipp the I2C lines with LPFs, nor insert an LPF at the Kathode line of the backgroundlight LEDs.
There is still weak but noticeable modulated carrier noise above 20 MHz changing its sound if frequency is tuned and/or display changes.

[DB9JG]

my described changes:

The shield between the datalines and the PCB was an idea that came up after observing this audio effect at the backside of the PCB:

trim.923CCE59-39BA-4829-B311-0B45B50E941C.MOV

[G8PTN]

Hi,
In practice, I found that having the display enabled is the biggest source of random noise (see attached thread).
#74 (comment)

On the ats-mini firmware, when the backlight is OFF, the display is also turned OFF.

When the backlight is at full ON, the main source of interference from the display will still remain.

The total supply current will vary between units, hardware type and other factors such compilation clock frequency, operating mode, volume level, WIFI and so on.

Typical measured values are shown below with ats-mini firmware 2.28.
CPU = 80MHz, Mode = FM, Vol = 35, PSRAM (OSPI) = Enabled

With WIFI enabled, there will be additional RFI, and power supply noise will be significantly higher, which may leak into the audio stages (normally heard as a clicking sound). Although the average current increase with WIFI enabled is around 75 mA, there will be peaks of several hundred mA.

The image below is for an ESP8266 module with WIFI enabled. The average current is approximately 77 mA, but there are peaks close to 200 mA.

73, Dave

[DB9JG]

@G8PTN Thanks for pointing out that “old” discussion!!
Impressive and enlightening!
Particularly this sound example: #74 (comment)

As there will be no way to avoid display signals (except NO display :-)), I will strengthen my efforts to screen the connection lines and components.
And I will look at the two I2C lines and try a better position (preferably near the ESP32) for an additional LPF.

[DB9JG]

I better should have posted this findings about "my fight against the birdies" here and not at
#182 (reply in thread)