Sequencing PA – Mosfet to avoid blowouts
Note: IRFZ24N cannot operate at a higher voltage than 12v
There have been many reports of the PA blowing up. The MOSFET can blow up due to high input voltages that can lead to the input gates blowing up or drawing too much current and blowing up the source-drain channel.
We applied an oscilloscope probe to the TX_LINE. The TX_LINE goes high under raspberry Pi control during transmission. We applied the second probe to a dummy load connected to the antenna socket.
Here’s what we found
As you can see, there is an enormously high power spike of 220V peak to peak (more than 100 watts of power). Even more, telling us that the gate RF has 20 volts of RF. The maximum rating for the gate is +/-20V as per the datasheet some of the spikes are hitting that as well.
PA Spike on the Gate
Why is this happening?
The power amplifier is permanently connected between the exciter portion and the harmonic filters. On receive, the power to the drivers and the bias is switched off and the relay K9 with U3 bypass the PA to directly the signal to the rest of the radio.
When the transmission ends, the TX_LINE goes low and the power to the PA is switched off, simultaneously, the relay K9 and the analogue switch U3 are released, allowing the RF to flow back from the PA output to the input. The power amplifier takes a few hundred microseconds to power down as the bypass capacitors still hold a charge. This sets up the oscillations that we are seeing. To confirm this, I desoldered C14 and the spike went away, (it also renders the receiver dead) by breaking the feedback loop.
The spike of the oscillations remains on for as long as the bypass capacitors of the PA hold a charge and they quickly discharge, killing the oscillations. Not quick enough to do damage.
What is to be done?
The powering up and down of the PA has to be sequenced. When we switch to transmit, we must first switch off the relay and U3, give it a millisecond and then power up the PA. When transiting to receive from transmit, we have to follow the reverse sequence. First power down the PA, wait for the caps to discharge and then switch the relay K9 and the switch at U3 to bypass the PA.
How can it be done?
The PA power is turned on and off in the existing sBitx when TX_LINE goes high at the gate of Q10. Now, instead of the TX_LINE, we take another GPIO line (we can call it TX_POWER) to separately control the powering up and down of the PA. This makes the spike go away.
Four things to do:
Step 1: Pull in the new code from GitHub. This software mod does not impact the unmodded sBitx but it can potentially blow up the modified sBitx if this mod is not in place.
Power on the sBitx, open the terminal with Ctrl-Alt-T and type the following:
cd sbitx
git pull
./build sbitx
Step 2. Cut the track that brings the TX_LINE to the gate of the Q10
Step 3. Add a wire from the Gate of Q10 to be taken to pin 36 of the Raspberry Pi’s connector on the digital board
4. Solder the wire coming from the Q10 gate to pin 36 of the Raspberry Pi’s connector on the digital board.
Result
You can see that the spike is gone
Eliminating Periodic Noise in the Speaker (Developer Edition)
The LM380 audio amplifier is picking up the Wifi RF and it results in a noise that repeats every 8 seconds of so as a series of quick pulses.
The noise is not present if you use earphones as they bypass the LM380 audio amplifier.
The current solution is to just turn off the WiFi and use Ethernet instead for the Internet.
Reset sBitx using the settings.ini
Reset your sBitx by pulling the latest code from GitHub
cd /home/pi
mv ./sbitx ./sbitx.old
git clone https://github.com/Bias your finals
- Set both the pots to the minimum current
- Select Mode as USB. Reduce the MIC to zero.
- Press the PTT.
- Without speaking into the microphone, carefully increase the DRIVE_BIAS POT until the current increases by 200 mA. Note the current.
- Keeping the PTT on the microphone pressed, now increase the PA_BIAS POT until the current increases by another 200 mA.
- Release the PTT.
These sBitx mods and fixes are from http://www.sbitx.net/
Want to learn more about sBitx?
