wiki.millerjs.org

User Tools

Site Tools

yaesufc-40control

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
yaesufc-40control [2026/07/18 05:15] – [Getting a Standalone Tune] adminyaesufc-40control [2026/07/18 05:32] (current) – [Photos & Media] admin
Line 137: Line 137:
  
   * **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 ====
  
Line 159: Line 155:
   * 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 ====
  
Line 187: Line 187:
  *  *
  * 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.
  *  *
Line 455: Line 455:
   * 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}}
  
yaesufc-40control.1784351747.txt.gz · Last modified: by admin
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki