| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| yaesufc-40control [2026/07/18 04:59] – [Responses and the Ack/Ready Envelope] admin | yaesufc-40control [2026/07/18 05:32] (current) – [Photos & Media] admin |
|---|
| ===== The RF Front End ===== | ===== The RF Front End ===== |
| |
| [{{:yaesu:fc40:attenuator_schematic.png?600 |The FC-40's resistive bridge and attenuator front end, from the service manual schematic}}] | [{{:yaesu:fc40:fc40_rf_input.png?400 |The FC-40's resistive bridge and attenuator front end, from the service manual schematic}}] |
| |
| While studying the schematic I found two CPU-driven relays near the RF input, labelled **ATT_RL** and **CAL_RL**, feeding a network that made no sense to me at first - a cluster of enormous 20W resistors (a 180Ω across the top of a Pi, two 33Ω in the legs) dumping into a small resistive bridge and a sampling transformer, then a Schottky detector into a CPU pin labelled ''RET''. | While studying the schematic I found two signals coming from the CPU which distracted me, going to relays near the RF input, labelled **ATT_RL** and **CAL_RL**, feeding a network that made no sense to me at first - a cluster of enormous 20W resistors with heatsinks (a 180Ω across the top of a Pi, two 33Ω in the legs) dumping into a small resistive bridge and a sampling transformer, then a Schottky detector into another CPU pin labelled ''RET''. |
| |
| This is not the directional coupler / SWR bridge I'm used to seeing in tuners. It is an **instrument-grade resistive return-loss bridge sitting behind a ~12 dB protective pad.** The pieces: | This is not the directional coupler / SWR bridge I'm used to seeing in tuners. It looks like the sort of thing I'd see in a test insturment - a resistive return-loss bridge sitting behind a ~12 dB protective pad. The pieces: |
| |
| * The three ~47Ω resistors plus the antenna network form a **Wheatstone / return-loss bridge**. When the tuning matrix presents 50Ω, the bridge balances and the detector nulls. The CPU's job during a tune is simply to step L and C until the ''RET'' voltage hits minimum. | * The three ~47Ω resistors plus the antenna network form a Wheatstone / return-loss bridge. When the tuning matrix presents 50Ω, the bridge balances and the detector nulls. The CPU's job during a tune is simply to step L and C until the ''RET'' voltage hits minimum. |
| * The Schottky rectifies sampled RF to a DC level for the CPU's ADC; a clamp diode protects the pin. | * The Schottky rectifies sampled RF to a DC level for the CPU's ADC; a clamp diode protects the pin. |
| * The 12 dB pad means the radio sees any antenna mismatch through the pad **twice** (~24 dB round trip). Even a dead short or open at the bridge port looks like ~1.1:1 at the transmitter. **The tuner can safely measure and hunt into a completely unknown load without ever stressing the PA.** This is why the whole interface insists on a low tune-power carrier, and why the resistors are rated 20W (margin plus survival of an accidental high-power key) despite only dissipating a few watts at the intended ~10W tune level. | * The 12 dB pad means the radio sees any antenna mismatch through the pad **twice** (~24 dB round trip). Even a dead short or open at the bridge port looks like ~1.1:1 at the transmitter. The tuner can safely measure and hunt into a completely unknown load without ever stressing the PA. If you've ever watched your rig's SWR when a "normal" ATU hunts for a match, it usually is flapping around like crazy. With the FC-40, the radio always sees a perfect 1:1 until the match is found. It's a really slick design. |
| |
| The ATT/CAL relays give a three-state front end: straight-through (operate), through-pad-only (calibrate against a known reference), and pad-into-bridge (measure/tune). The ''CAL'' naming suggests the tuner takes a reference reading to compensate for the Schottky's nonlinearity before or during a hunt. | |
| |
| This front-end model turned out to be strongly predictive. When I later watched the RF on a spectrum analyzer, the signal dropped 30-50 dB **during** the hunt (pad in circuit, RF soaking into those resistors) and recovered to near-bypass level the instant a match completed (pad switched out, full power to the antenna). That recovery is direct confirmation that a successful match really delivers power to the wire rather than dumping it in the pad. | The ATT/CAL relays right by the RF input give a three-state front end: straight-through (operate), through-pad-only (calibrate against a known reference), and pad-into-bridge (measure/tune). The ''CAL'' naming likely suggests the tuner takes a reference reading to compensate for the Schottky's nonlinearity before or during a hunt, or some other variability in the hardware or environment. |
| |
| ===== Getting a Standalone Tune ===== | ===== Getting a Standalone Tune ===== |
| |
| The path to a working tune was not a straight line. A few key realizations, in order: | The path to a working tune was not a straight line. Here are a the key things I discovered while banging my head on the bench: |
| |
| - **The tuner is not autonomous.** Simply transmitting into a reset tuner does nothing - no relay activity, no messages. In bypass, the bridge detector is disconnected from the line, so the tuner is physically blind to SWR until something commands it into measurement mode. WA2FZW's "auto-tune on high SWR" behavior almost certainly belongs to the **radio** (which has its own SWR metering and issues the tune command), or to the MFJ clone's own added sensing - not to the genuine FC-40 acting alone. My Kenwood TS-590S has no idea it's supposed to say anything to the tuner, so nothing happened. | - **The FC-40 is not autonomous.** Simply transmitting into a reset tuner does nothing - no relay activity, no messages. In bypass, the bridge detector is disconnected from the line, so the tuner is physically blind to SWR until something commands it into measurement mode. What lead me astray on this topic was a comment WA2FZW made regarding his setup's "auto-tune on high SWR" behavior. This almost certainly is something that originates from his Yaesu radio (which has its own SWR metering and issues the tune command), or to the MFJ clone's own added sensing. Now, this said, there are a bunch of DIP switches in on the board. All but one (hard reset) are undocumented. Maybe a combination of these puts the tuner into an autonomous mode.... |
| - **Ordering is everything.** The carrier must be present **during** the ''F2'' measurement window. Sending ''F2'' and then keying is too late - the tuner has already aborted with ''B0''. The correct sequence is: key the carrier first, hold it, then send ''F2''. | - **Sequencing is everything.** The carrier must be present **during** the ''F2'' measurement window. Sending ''F2'' and then keying is too late - the tuner has already aborted with ''B0''. The correct sequence is: key the carrier first, hold it, send ''F2'', and wait for the cycle to complete. |
| - **Success latches natively.** When the tuner actually finds a match, it holds it across key cycles all on its own - no ''F0'' recall, no ''E0'' init handshake required. My earlier belief that matches "wouldn't persist" was an artifact of testing on bands my antenna simply could not match (they were failing, and I had ''A2'' mislabelled as success). | - **Success latches natively.** When the tuner actually finds a match, it holds it across key cycles all on its own - no ''F0'' recall, no ''E0'' init handshake required - this is something you would expect from an ATU, once it's tuned on a frequency it stays tuned until either the radio changes frequency, or the environment changes the antenna system. Early in my testing I keppt thinking that matches wouldn't persist after they were found, and that an additional command was needed to save them. This was an artifact of testing on bands my testing antenna system simply could not match AND the fact that since the radio sees the attenuator in the tuner as a perfect load, the radio reports 1:1 during the whole process, and it took me took long to make sense of this. |
| |
| The working procedure, with nothing but an Arduino, power, and a keyed carrier: | The working procedure, with nothing but an Arduino, power, and a keyed carrier: |
| |
| - Key the radio into a steady low-power CW carrier (5-10W). | - Key the radio into a steady low-power CW carrier. (Make sure the frequency is clear, first!) |
| - While transmitting, send ''FF F2 <freq>''. | - While transmitting, send ''FF F2 <freq>''. |
| - Watch the bus: ''A0'' (ack), relays hunt, ''A1'' (ready). If **no** ''A2''/''B0'' trails the ''A1'', the match succeeded and will hold. | - Watch the bus: ''A0'' (ack), relays hunt, ''A1'' (ready). If **no** ''A2''/''B0'' trails the ''A1'', the match succeeded and will hold. |
| - Unkey. | - Unkey. |
| |
| I have confirmed successful, latching matches on multiple bands this way, verified both by the radio's own 1:1 SWR reading on re-key and by an increase in delivered power on the spectrum analyzer. The tuner works as a standalone device. | I have confirmed successful matches on multiple bands this way, verified both by the radio's own 1:1 SWR reading, including at higher powers, and from attaching my NanoVNA to the tuner to sweep its match. The FC-40 works as a standalone device! (Mostly, you just need a brainslug microcontroller and a button or computer.) |
| | |
| <note>The 20-40m failures were not a fault - they were my end-fed wire being genuinely unmatchable on those bands, consistent with the impedance dips I'd seen on a VNA sweep at ~80m and ~10m. On 80m and 10m the tuner matched and latched cleanly.</note> | |
| |
| ==== Open Questions ==== | ==== Open Questions ==== |
| |
| * **F0 recall.** Whether ''F0 <freq>'' correctly recalls a previously stored match (without RF) is not yet confirmed - largely because my earlier recall tests were run against bands that had never produced a stored solution to begin with. This is now testable properly and is high on the list. | * **F0 recall.** Whether ''F0 <freq>'' correctly recalls a previously stored match (without RF) is not yet confirmed - largely because my earlier recall tests were run against bands that had never produced a stored solution to begin with. This is now testable properly and is high on the list. |
| * **The E0 init handshake.** We have never cleanly sent it with proper wake-gap framing. Whether it changes any behavior (memory persistence, a "radio-controlled" mode) is unknown. | * **The E0 init handshake.** I don't really know what this is doing. |
| * **The variant ack codes.** I have observed ''A4'', ''A8'', and ''E4'' in the opening (A0) slot on successful tunes, seemingly correlated with the starting SWR or search strategy. Several were captured under heavy RFI, however (see below), and ''A4''/''A8'' are only a single bit away from ''A0'', so some may be corrupted ''A0'' bytes rather than real sub-codes. Reproducing them on a clean line is the only way to know. | * **The variant ack codes.** I have observed ''A4'', ''A8'', and ''E4'' in the opening (A0) slot on successful tunes, seemingly correlated with the starting SWR or search strategy. Several were captured while experiencing RFI and may be untrustworthy, however (see below), and ''A4''/''A8'' are only a single bit away from ''A0'', so some may be corrupted ''A0'' bytes rather than real sub-codes. Reproducing them on a clean line is the only way to know. I need to do more testing with much better isolation. |
| |
| ===== RFI - A Cautionary Note ===== | ===== RFI - A Cautionary Note ===== |
| |
| Testing at the bench with the Arduino sitting within a foot of the tuner and a live 10m wire produced spectacular garbage on the receive line the moment a match completed and full power hit the antenna. The line would spew hundreds of bytes - ''FF'', ''F7'', ''77'', ''DF'' - in continuous ~3 ms bursts. | Testing at the bench with the Arduino sitting within a foot of the tuner and a live wire sometimes produced spectacular garbage on the receive line the moment a match completed and full power hit the antenna. The line would spew hundreds of bytes - ''FF'', ''F7'', ''77'', ''DF'' - in continuous ~3 ms bursts. |
| |
| These are not real data. Written in binary they are almost all 1-bits, the classic signature of RF glitching an idle-high UART line into framing errors. Tellingly, the spew only ever appears **after** the match completes - i.e. exactly when the protective pad drops out and full power reaches the wire - which is itself another confirmation of the front-end model, if an annoying one. | These are not real data. Written in binary they are almost all 1-bits, the classic signature of RF glitching an idle-high UART line into framing errors. Tellingly, the spew only ever appears //after// the match completes - i.e. exactly when the protective pad drops out and full power reaches the wire. |
| | |
| The mitigation plan for the next test session: put real distance between the tuner and the microcontroller (8-pin mini-DIN on a run of Cat6, using its twisted pairs, with the Arduino perhaps ten feet away), ferrite chokes on both the data cable and the USB cable, and a solid short ground bond. At 4800 baud there is enormous timing margin, so a longer cable costs us nothing. | |
| | |
| <note warning>Because a stray noise byte can decode as ''A2'' or ''B0'', the success/fail logic **cannot be trusted** until the RFI is dealt with. The current sketch is a diagnostic tool, not a reliable controller.</note> | |
| |
| | The mitigation plan for a future test session: put real distance between the tuner and the microcontroller (8-pin mini-DIN on a run of Cat6 probably, using its twisted pairs, with the Arduino perhaps ten feet away), more ferrite chokes on both the data cable and the USB cable, and maybe grounded metal shielding around the Arduino? At 4800 baud there is enormous timing margin, so a longer cable shouldn't impose any issues, and with 5v logic levels voltage drop shouldn't be a big concern either. |
| ===== The Test Sketch ===== | ===== The Test Sketch ===== |
| |
| Below is the current state of the testing firmware. It targets an **ATmega32U4** board (Leonardo/Micro/Pro Micro), chosen because its native USB gives us a hardware UART (''Serial1'') for the tuner that is fully independent of the USB console (''Serial''). The '328P-based Uno would force ''SoftwareSerial'', which is workable but inferior. | Below is the current state of the testing firmware. It targets an ATmega32U4 board with normal Arduino firmware (Leonardo/Micro/Pro Micro), chosen because its native USB gives us a hardware UART (''Serial1'') for the tuner that is fully independent of the USB console (''Serial''). It's also 5v tolerant, cheap, and I had one close at hand when I got started. Realistically, because the communuication is all happening over a UART, a FTDI or Prolific USB interface could be used, along with a python script or whatever. I've been sticking with Arduino because eventually I want my interface to be a box with a button and an LED or two, I don't want it to be entirely reliant on a computer.. unless I do.. (more on that later.) |
| ==== What it does ==== | ==== What it does ==== |
| |
| * Lets you send commands from the Arduino IDE Serial Monitor: wakeup, the full init sequence, individual ''E0''/''F0''/''F1''/''F2'' commands (with frequency in MHz, auto-converted to BCD), and arbitrary raw hex bytes. | * Lets you send commands from the Arduino IDE Serial Monitor: wakeup, the full init sequence, individual ''E0''/''F0''/''F1''/''F2'' commands (with frequency in MHz, auto-converted to BCD), and arbitrary raw hex bytes. |
| * Frames commands correctly, with the ~50 ms wake gap after ''0xFF''. | * Frames commands correctly, with the ~50 ms wake gap after ''0xFF''. |
| * Detects "success by silence" - if an ''A1'' arrives and ~250 ms pass with no trailing ''A2''/''B0'', it declares the tune matched, and drives status LEDs (D13 success, D12 fail). | * Detects "success by silence" - if an ''A1'' arrives and ~250 ms pass with no trailing ''A2''/''B0'', it declares the tune matched, and drives status LEDs (D13 success, D12 fail, though realistically these are kind of guesses). |
| * Collapses rapid RFI bursts into a single suppressed-count line so real, well-spaced bytes remain visible. | * Collapses rapid RFI bursts into a single suppressed-count line so real, well-spaced bytes remain visible - though this is kind of tricky because bad enough RFI will either crash the Arduino, or reset the USB interface. |
| * Loudly flags any unrecognized byte, so new response variants can't hide. | * Loudly flags any unrecognized byte, so new response variants can't hide. I'll update this page as I find more. |
| |
| ==== What it does NOT do (yet) ==== | ==== What it does NOT do (yet) ==== |
| |
| * **It is not a controller.** It cannot key your radio - you supply the carrier by hand (or with a separate PTT arrangement). The commanded sequence is issued by you, timed against the carrier you're holding. | * **It is not a controller.** It cannot key your radio - you supply the carrier by hand (or with a separate PTT arrangement). The commanded sequence is issued by you, timed against the carrier you're holding. I've just got a morse key next to my keyboard. |
| * **It does not trust its own success/fail output under RFI.** The noise filter improves readability but does not make the line reliable; a stray byte in a quiet gap can still mis-decode. | * **It does not trust its own success/fail output under RFI.** The noise filter improves readability but does not make the line reliable; a stray byte in a quiet gap can still mis-decode, and RFI can crash it out easily. |
| * **The response-code interpretation is provisional.** ''A2''=fail and ''B0''=no-carrier are well-supported; ''A4''/''A8''/''E4'' are guesses awaiting clean data. | * **The response-code interpretation is provisional.** ''A2''=fail and ''B0''=no-carrier are well-supported and have been consistent; ''A4''/''A8''/''E4'' are guesses and have been a lot harder to get consistently. |
| * **No memory / recall logic, no E0 handshake automation** beyond a bare ''init'' command for experimentation. | * **No memory / recall logic, no E0 handshake automation** beyond a bare ''init'' command for experimentation. I plan eventually test this, but I may just end up running this tuner as a "dumb" remote ATU where it regularly has to do a full cycle anyway. We'll see how things end up. |
| * It is a **bench diagnostic tool**, full stop. It is not fit for unattended or production use. | * It is a **bench diagnostic tool**, full stop. It is not fit for unattended or production use. |
| |
| | ==== Honesty Moment ==== |
| | I did use generative AI to help me with this sketch. I'm not super great at putting this kind of stuff together in a clean fashion. Between the work of those before me, and banging my head on the keyboard, I was able to get sequences that worked, and got the tuner doing what it needed to do. Once I got that far, I used Anthropic's opus to clean it up. |
| | |
| | If you don't like that, I understand, and you should be able to use the above descriptions and resources to write your own methods. |
| ==== Code ==== | ==== Code ==== |
| |
| * | * |
| * Acknowledgement: builds on the reverse-engineering of the Yaesu tuner | * Acknowledgement: builds on the reverse-engineering of the Yaesu tuner |
| * control protocol published by John Price (WA2FZW), and on the anonymous | * control protocol published by John Price (WA2FZW), and Albin Stigo's (SM6WJM) |
| * FC-30 reverse-engineering notes. Thanks for sharing openly. | * FC-30 reverse-engineering notes. Thanks for sharing openly. |
| * | * |
| * Investigate the MONITOR / PC port. | * Investigate the MONITOR / PC port. |
| |
| ===== Photos ===== | ===== Photos & Media ===== |
| | |
| | * {{ :yaesu:fc40:fc_40_antenna_tuner_manual_en_35bf.pdf}} |
| | * {{ :yaesu:fc40:fc-40_brochure.pdf}} |
| |
| {{gallery>:yaesu:fc40:photos}} | {{gallery>:yaesu:fc40}} |
| |
