Homebrew sBitx - Fault Tree Analysis

 

KK4DAS sBitx Low Pass Filter Board

My friend Pete, N6QW recently mentioned the problem I was having with the low pass filter board in his excellent blog post describing the enginerring process of fault tree analysis, a systematic approach to understanding and resolving failures of complex systems.  This post will describe the observed problem with my LPF board and walk through some of the steps I am taking to resolve it.

First, some context.  The LPF board consists of four low pass filters covering the HF bands from 80 meters to 10 meters.  My board uses relay switching to select the correct filter for the band I am  operating on.  The relays are are fed +12V on transmit and each relay is switched with an NPN transistor.  The transistors are are turned on by a GPIO signal from the Raspberry Pi, there is a seperate GPIO line for each relay and only one line is "high" at a time.

Here is the typical circuit for controlling a relay from a GPIO line...

GPIO Controlled Relay Switch

In addition to the four LPF relays there is one more relay with the idential circuit that is the Tx/Rx relay which enables the +12Tx bus to provide power to the transmit chain.  I built and tested the LPF board on the bench and it was working perfectly, one relay at a time coming on, one filter at a time in theTx line, but when I put it in the rig things immediately went haywire. As soon as I would transmit on any band all of the relays would start chattering, machine gun style.   I checked-in with sBitx designer Farhan, VU2ESE and he recommended adding a .1uF cap to each contrrol line to keep RF off the control lines - I hadn't done that so I added the cap (Q2 in the schematic) and that immediately calmed things down ... mostly.

That episode focused my attention on the relays and I observed something I had seen once or twice before but not given much thought to - sometimes the Tx/Rx relay would switch spontaneously, I noticed it particulalry during rig power-up but I had attributed it mostly to the floating state of the GPIO pins during initialization.  Pete suggested the problem could be subthreshold conduction, the transistor conducting when a weak (below turn on voltage) signal is present on the GPIO lines.  I measured the GPIO lines and found that in the logic "off" state they still had about 600mV on each line. That's fine for digital logic but pretty close to turn on voltage for an NPN switch.   R1 was orignally 220 ohms and Pete suggested bumping it up to 2.2K and using a TIP switching transistor in place of the the 2N3904.  A member of our Maker's group suggested adding a pull down resistor to the base of the transistor. The Pi has internal pull-downs but the thought was and external resistor might pull the line closer to 0.  The external pull-down didn't help so I took Pete's advice and that solved the spontaneous transmit switching problem.

With the spontaneous transmit problem now resolved, and with hyper-awareness to the relays I noticed that there was a faint whirring noise coming from the relay board that occured during transmit - particulalry on FT8 or CW.  I also noticed that sometimes power output was significantly below what I expected.  The whirring noise almost sounded like a fan - but there is no fan on the board.  I hypothesized that it could be the relays fluttering.  One of the keys to solving a problem in a complex system is to to be able to discern where the problem is occuring.  To help me literally "see" if the relays were turning on when they were not supposed to I added an LED to each relay.   Here is the result:

So that was a clear indication that the transistors were conduction during Tx in the presence of strong RF.  I thought that perhaps the relatively high "off" voltage on the GPIO lines combined with the RF floating around the rig might cause the transistors to partially turn on.  Sometimes they would turn-on strong enough to switch the relays and sometimes not.  I thought that maybe if I added a voltage divider to the base of the transistor that would knock down the voltage enough to make the problem disappear.  Unfortunately, as is often the case when working on a homebrew rig, one problem leads to another and I had a side trip to solve a couple of other problems.  The main one was that the main Tx/Rx relay starting sticking in Tx.  I could tap it with a pencil to get it to shut off.  The relay was problably weakened during my early testing when it was machine gun chattering on Tx.  Here is a short video describing the next steps:

So back to fault tree analysis - what do I know now?  First the problem is related to RF and it varies with drive level.  So, per Pete's advice - lets see if its on the DC line or the control lines or just RF floating around the booard.  I disconnected the off-band GPIOS and the LEDs still blinked.  I put the relays on a separate power supply, and the LEDs still blinked.  Remembering that changing the 2N3904 to a TIP-110 has helped solve the Tx/Rx switching problem I decided to swap one of the 2N3904s for a TIP-110 on the LPF board.  That helped a lot. Here's the video demonstration of all of the above:

So here is where things stand.  I have replaced all the 2N3904s with TIP-110s and the LEDs no longner flicker on 80, 40, and 20 meters, but as frequency increases the LEDs start flickering again - and they are strongest on 10 meters.  The higher the frequency the more RFI.  If I lower the drive to about 10 watts it goes away on all bands. 

So to summarize the changes since I started.  I added RF bypass caps to the control lines.  I added a voltage divider to the base of the transistors, and increased the current limiting resistor from 220 ohms to 10K, and I swapped all the 2N3904s for TIP-110 switching transistors. Here is what the relay circuits look like now:

At this point, even though the LEDs flicker a bit on higher power and higher frequencies, I don't believe any of the relays are switching on, so if I remove the LEDs, which I only added for visibility, the problem may be "out of sight, out of mind."

I'd still like to solve the problem - because even if I can't see it, I'll still know its there.  Leave comments below if you have any suggestions.

73 from Great Falls,

Dean

KK4DAS