Skip to content
View in the app

A better way to browse. Learn more.

Ham Radio Base -Powered By Ham CQ DX

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.
Solar
SFI 125
SN 85
A 7
K 2 Quiet
X-Ray C1.9
Wind 445.8 km/s
Aurora 2
Updated 00:30 UTC HamQSL · N0NBH
Day 80/40m Fair 30/20m Good 17/15m Good 12/10m Fair
Night 80/40m Good 30/20m Good 17/15m Good 12/10m Poor

Callsign Lookup
_
Vanity Call Signs Available
Enter filters above and click Search.
ⓘ Callsign lookups are in real time via the FCC database. Vanity callsign availability is refreshed daily at 6:00 AM CST. The vanity search may be unavailable for a few minutes during this update.
Live DX spots
Live DX Spots — 70cm via PSKReporter · scroll or pinch to zoom
Band
Mode
Time
Loading map data…
MHz DX Spotter Info
Recent spots
Select a band above to load spots
Ready — select a band to fetch live spots

Divide and Conquer

Imagine a superheterodyne receiver with eight stages between the antenna jack and the speaker: RF amplifier, mixer, IF filter, IF amplifier, detector, audio preamp, audio power amplifier, and speaker. The receiver produces no audio at all. Testing each stage one at a time, starting from the antenna and working toward the speaker, could take up to eight measurements before you find the fault — and if the fault happens to be in the very last stage, you will have made seven unnecessary measurements before reaching it.

There is a faster way, and it is one of the oldest and most powerful ideas in problem-solving generally, not just electronics: divide and conquer, also called the half-split technique. Instead of testing stage by stage from one end, you test near the middle of the chain. That single measurement tells you which half of the chain contains the fault, eliminating the other half entirely — instantly cutting the search space in half with one test. You then repeat the process within the remaining half, again and again, until only one stage remains. This lesson explains exactly how and when to apply it.

Key idea: A test in the middle of a suspect signal chain is worth roughly as much information as testing every stage on one side of it. Divide and conquer exploits this to find a fault among N stages in approximately log2(N) tests instead of up to N tests.
Block diagram of an eight-stage superheterodyne receive chain from antenna to speaker with a binary search tree overlay showing how three half-split tests isolate a fault to one stage

Half-split testing isolates a fault among eight receiver stages in three tests instead of up to eight.

View Larger

The Half-Split Concept

Divide and conquer is borrowed directly from computer science, where it describes any algorithm that solves a problem by splitting it into smaller sub-problems, solving each, and combining the results. The classic example is a binary search through a sorted list: to find a name in a phone book, you do not start at "Aaronson" and read every entry — you open to the middle, see which half the name must be in, and repeat. Troubleshooting a multi-stage circuit is structurally the same problem: the "sorted list" is the signal path from input to output, and the "search" is for the single stage where a healthy signal becomes an unhealthy one.

In a working circuit, a signal (audio, RF, DC voltage, a digital data stream) enters at one end and is supposed to emerge, transformed in a known way, at the other end. When something fails, the signal is correct up to some point in the chain and incorrect (absent, distorted, or out of specification) from that point onward. Every stage before the fault is, by definition, working correctly with respect to its input — the fault has not affected it yet. Every stage from the fault onward is affected, either directly (it is the faulty stage) or indirectly (it is being fed a bad signal by something upstream). This is exactly the structure that makes half-split testing valid: the chain is divided into a "good" region and a "bad" region by a single boundary, and your job is to locate that boundary.

Why It Is Faster Than Stage-by-Stage Testing

The mathematics behind the speed advantage is straightforward. If you test stage by stage starting from one end, finding a fault in stage k out of N total stages takes k tests. On average, across all possible fault locations, that works out to roughly N/2 tests, and in the worst case (fault in the last stage) it takes N tests. Half-split testing, by contrast, always takes approximately log2(N) tests, rounded up, regardless of where the fault is. The table below makes the difference concrete.

Number of Stages (N)Stage-by-Stage Worst CaseHalf-Split Worst Case
44 tests2 tests
88 tests3 tests
1616 tests4 tests
3232 tests5 tests
6464 tests6 tests

The gap widens dramatically as the number of stages grows, which is exactly why this technique matters most for long, complex chains — a modern HF transceiver's receive path, when you count every gain and filter stage from the antenna connector through to the audio output, frequently exceeds a dozen functional blocks. Doubling the number of stages costs stage-by-stage testing twice as many tests in the worst case, but costs half-split testing only one additional test. This is the same reason a well-organized library can locate any of a million books almost as fast as one of a thousand, while a disorganized pile of a million books is effectively unsearchable.

How to Pick the Split Point

"Half" does not have to mean the geometric middle of the schematic. The goal of each test is to maximize the information gained per unit of effort, and three practical factors should influence exactly where you choose to test, in this order of priority:

1. Accessibility. A test point you can reach with a probe without removing covers, lifting components, or breaking a sealed module is far more valuable per minute spent than a theoretically perfect midpoint buried under three boards. If the literal midpoint is hard to reach but a test point one stage away is easy, test the easy one — you lose only a small amount of search efficiency and gain a large amount of speed.

2. Signal type you can actually measure. Some domains are far easier to check than others. Audio can be checked by ear directly with a pair of headphones clipped onto a test point — no instrument required. DC voltages are trivial with a meter. RF, by contrast, usually requires either an oscilloscope (see M21G) or at minimum an RF probe. Where the signal chain crosses from one domain to another — for instance, RF before the detector, audio after it — that crossing point is often an excellent natural split point because it is easy to test with simple equipment on both sides.

3. Combine with most-likely-cause-first. If you have any prior reason (from M21A) to suspect one half of the chain more than the other — for example, a recent modification was made to the first half, or a particular family of components is known to be fragile — it can be more efficient to deliberately split closer to that suspect region on the first test, sacrificing a small amount of pure binary-search efficiency for a higher chance of an early, decisive result.

Worked Example: Dead Receive Audio

Symptom: An HF transceiver receives no audio at all on any band. The S-meter shows normal-looking noise/signal activity, suggesting the front end is doing something, but the speaker and headphone output are completely silent.

The chain (8 stages): (1) Antenna input / RF amp → (2) Mixer → (3) IF filter → (4) IF amplifier → (5) Detector → (6) Audio preamp → (7) Audio power amplifier → (8) Speaker.

Test 1 (split at stage 4/5 boundary — the detector input): Using an oscilloscope at the IF amplifier output (just before the detector), a healthy IF signal is present. Conclusion: stages 1 through 4 are confirmed working. The fault is in stage 5, 6, 7, or 8.

Test 2 (split the remaining four stages at the audio preamp output): Using a simple audio probe (or headphones) at the audio preamp output, no audio is present, even with a strong, known-good IF signal feeding the detector. Conclusion: the fault is in stage 5 (detector) or stage 6 (audio preamp). Stages 7 and 8 are eliminated.

Test 3 (split the remaining two stages at the detector output): Probing directly at the detector's output (the input to the audio preamp) reveals a healthy, correctly demodulated audio signal. Conclusion: the detector is working. The fault must be in stage 6 — the audio preamp.

Result: Three tests isolated the fault to a single stage out of eight. Stage-by-stage testing from the antenna end could have taken as many as eight tests to reach the same conclusion if the fault had been in the audio power amplifier or speaker — and even in this case, where the fault happened to be roughly mid-chain, stage-by-stage testing from either end would have taken five or six tests. Inspection of the audio preamp stage then proceeds using the substitution and signal-tracing techniques covered in M21D and M21E — a coupling capacitor in the preamp stage was found to be open, blocking the audio signal entirely while passing DC bias normally (which is why a simple in-circuit voltage check at the transistor's bias points would not have revealed the fault — only the AC signal path was broken).

Applying Half-Split to Power Supply Chains

Half-split is not limited to signal chains — it applies equally well to any sequence of stages where a value should change, in a known way, from input to output. A linear power supply with multiple regulation stages (rectifier → filter capacitor → pass transistor regulator → output) is a chain of exactly this kind, and a fault that causes "no output voltage" can be split the same way: measure the DC voltage at the filter capacitor first. If correct, rectification and bulk filtering are fine and the fault is in the regulator stage. If incorrect, the fault is upstream, in the transformer or rectifier. This is the same logic applied to DC rather than AC or RF, and it works for exactly the same reason: each stage's output is the next stage's input, and a clean boundary exists between the working region and the faulty region.

Limitations: When Half-Split Does Not Work

Half-split testing relies on one important assumption: that there is a single fault, and that the chain is a single, well-defined sequence from input to output. Three situations break this assumption and require a different approach.

Multiple simultaneous faults. If two independent stages have both failed, a half-split test can produce a confusing or contradictory result — for example, splitting near the middle might show the signal is already bad earlier than expected because of a second, unrelated fault upstream, leading you to chase the wrong half. When results seem inconsistent across repeated tests, consider the possibility of more than one fault, especially after an event likely to damage multiple components at once (a lightning strike, a reversed-polarity power connection, or an RF overdrive event).

Branching or non-linear topology. Many real circuits are not a simple single-file chain — a microcontroller's output might feed three different subsystems, or an AGC (automatic gain control) loop might feed a control voltage backward from a later stage to an earlier one. Half-split assumes a clean forward path; if the topology branches or loops, you must first identify the relevant linear path for the specific symptom you are chasing, and may need to treat each branch as its own chain.

Intermittent faults. A connection that fails only when warm, or a fault that depends on vibration or orientation, can give a "working" result during a half-split test purely by chance, even when probed at the actual faulty stage. Intermittent faults generally require repeated testing, controlled stress (gentle flexing, localized heating or cooling, or tapping suspect components — sometimes called the "wiggle test") alongside half-split logic, rather than a single clean pass through the technique.

⚖ Experiment: Half-Split a Faulty LED Chain

This experiment builds a simple "chain" of six stages you can fault and search using half-split logic, reinforcing the binary-search mindset on hardware you can see and touch.

You will need:
  • Six LEDs and six 470 Ω series resistors
  • A 9 V battery (or a bench supply set to a safe voltage for a six-LED series string, noting that six red LEDs in series typically need 12-14 V minimum — alternatively, build six independent LED+resistor branches in parallel across one 9 V supply, each representing one "stage" to test)
  • A breadboard and jumper wires
  • A digital multimeter
  • A helper to introduce one fault without telling you which branch
  1. Build six independent LED-plus-resistor branches in parallel across the 9 V supply, numbered 1 through 6. Confirm all six light normally.
  2. Have your helper disconnect or reverse exactly one LED in one branch while you are not watching.
  3. Rather than checking branch 1, then 2, then 3 in order, apply half-split: check branch 3 or 4 (the middle of the range) first. If it is lit, the fault is somewhere in branches 4-6 (or 1-3, depending which you tested and which half is unconfirmed); if dark, you have found it immediately, or narrowed to a smaller remaining range.
  4. Continue splitting the remaining range of suspect branches in half with each test until exactly one branch is identified.
  5. Verify by visual inspection and a continuity/voltage check that the identified branch is the one with the introduced fault.
What you should see:

With six branches, half-split testing finds the fault in at most three tests (log2(6) rounded up), compared with up to six tests checking branch 1, 2, 3... in order. Repeat the experiment a few times with different fault locations and count your tests each time — you should consistently use fewer tests with half-split than with sequential checking, and the advantage grows if you scale the experiment up to ten or twelve branches.

Frequently Asked Questions

Do I have to split exactly in the middle every time?

No. The geometric middle is the theoretically optimal split point only when every test is equally easy to perform. In practice, accessibility and ease of measurement should often take priority over a perfectly even split. Testing a slightly uneven split that is much faster to perform is usually a better trade than insisting on the mathematically perfect midpoint.

Can I use half-split testing on a circuit I don't have a schematic for?

Yes, as long as you can identify a reasonable sequence of accessible test points along the signal path, even without exact component-level knowledge. Block-level knowledge of a typical superheterodyne receiver or linear power supply is often enough to pick sensible split points without a schematic, though a schematic makes the choice faster and more precise.

What if the half-split test gives an ambiguous or borderline result?

Treat an ambiguous result as inconclusive rather than guessing which half it implies. Either repeat the measurement under more controlled conditions, compare it against a known-good reference reading at the same point, or pick a different, more clearly interpretable test point nearby. Acting on an ambiguous result risks searching the wrong half entirely, which costs more time than a careful re-test.

Why might half-split testing point to the wrong half?

This almost always indicates either more than one fault is present, the circuit has branches or feedback paths that violate the simple linear-chain assumption, or the fault is intermittent and happened not to show during that particular test. If a half-split search seems to be going in circles, stop and reconsider whether one of these three situations applies.

Test Your Knowledge

Answer the questions below to check your understanding. Every answer can be found in the lesson above.

Loading questions...

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.