Constraint Propagation (Naked Singles)

Before venturing into search trees, the solver propagates known values across peer units. If a cell has only one valid candidate remaining given its row, column, and box constraints, that value is assigned immediately. This pruning cascades, often solving easy and moderate puzzles without taking a single speculative branch.

Heuristic Variable Selection (Minimum Remaining Values)

When deterministic deduction reaches quiescence and speculative branching is necessary, choosing the right cell to guess determines search performance:

• A naive search picks the first open cell index, leading to deep, thrashing subtrees.
• Instead, the solver employs the Minimum Remaining Values (MRV) heuristic (or most constrained variable): it chooses the unassigned cell with the fewest legal candidate choices. If a cell has only two possible options, branching on it cuts the branching factor to 2, failing fast if a branch is invalid.

Recursive Backtracking Search

The backtracking engine is built on pure functional recursion. Rather than mutating global grid state and manually rolling back changes upon encountering an invalid configuration, the function accepts the current board state and returns either a solved board or NIL:

(defun solve (board)
  "Recursively solve the Sudoku BOARD using constraint-driven backtracking."
  (let ((clean-board (propagate-constraints board)))
    (cond
      ((null clean-board) nil)                ;; Conflict encountered; backtrack
      ((solved-p clean-board) clean-board)    ;; Complete and valid configuration
      (t
       ;; Pick cell with fewest candidates (MRV heuristic)
       (let* ((cell (find-most-constrained-cell clean-board))
              (candidates (get-legal-candidates clean-board cell)))
         (some (lambda (val)
                 (solve (assign clean-board cell val)))
               candidates))))))

The combination of some with higher-order functions provides a declarative backtracking loop: it attempts candidates sequentially and halts on the first non-NIL solution returned down the call stack.

1. LISP is great for exploring “classical AI”.

When Lisp earned its reputation as the foundation of AI at MIT, Stanford, and Xerox PARC in the 1970s and 1980s, “Artificial Intelligence” meant Symbolic AI (Good Old-Fashioned AI / GOFAI): * Formal logic deduction and rule engines * Expert systems and semantic networks * Graph search and constraint satisfaction (exactly like Sudoku)

For these domains, Lisp has no equal. Its homoiconicity (code-as-data), powerful macro system, dynamic typing, and interactive image-based REPL allowed early researchers to invent domain-specific languages (DSLs) and manipulate ASTs effortlessly. If AI is defined as manipulating logic symbols and reasoning trees, Lisp earned the title honestly.

Modern AI, however, underwent a seismic shift toward Connectionist AI: * Deep neural networks, continuous tensor representations, and automatic differentiation * Highly parallel matrix math executing across thousands of SIMD/SIMT GPU cores * Massive statistical optimization (SGD, Adam) rather than discrete graph traversal

Python didn’t conquer modern machine learning because it is conceptually superior to Lisp; it won because it became the premier high-level glue language wrapping highly optimized C++, CUDA, and BLAS/LAPACK runtimes (PyTorch, TensorFlow, JAX). Lisp’s elegant linked lists and pointer chasing are fundamentally misaligned with contiguous memory layouts, vectorized cache lines, and hardware tensor cores.

2. Lisp is the Progenitor of most modern languages

While Common Lisp may no longer dominate industrial AI headlines, almost every breakthrough feature modern languages celebrate was born in the Lisp ecosystem: * Garbage Collection: Invented by John McCarthy specifically to manage dynamic tree allocations in Lisp. * Dynamic Typing & First-Class Functions: Pioneered decades before JavaScript or Python made them mainstream. * Interactive Development: The interactive feedback loop popularized by Jupyter Notebooks is essentially a rudimentary, browser-bound approximation of a true Lisp REPL (like SLIME or SLY). * Metaprogramming: Few modern languages match the safety and expressive power of Common Lisp’s macro system (defmacro), which operates on raw S-expressions rather than fragile token streams or complex compiler plugins.

The Verdict

Is Common Lisp the “Language of AI” today? Practically speaking, no. If you are training multi-billion parameter transformer models, fine-tuning diffusion networks, or writing high-throughput tensor operations, Python and C++/CUDA remain the undisputed industry standard.

However, as an educational tool and an intellectual foundation, learning Lisp changes how you think about computation forever. I believe this was the core message of most materials we were exposed to during the course, zeal and mysticism aside (though it makes for very entertaining YouTube content). Writing cl-sudoku in Common Lisp demonstrated that complex problem domains can be expressed declaratively, recursively, and with startling conciseness. Understanding Lisp demystifies interpreters, abstract syntax trees, and symbolic reasoning—giving an engineer a profound appreciation for what modern frameworks abstract away.

1. Toroid Winding & Enamel Stripping

RF inductors and impedance transformers require hand-winding enameled magnet wire around tiny ferrite/iron-powder toroid cores (such as T37-6 cores).

• Turns Accuracy: Inductance scales quadratically with turns (). A single missing or extra turn shifts the cutoff frequency of the multi-pole Chebyshev low-pass filter right into the passband. Ironically, the above thumbnail shows a major blunder - not spacing the windings evenly. For unknown reasons, this caused the output power to be far lower than 5W, which of course required desoldering and - in one case - rewinding with scrap wire.
• Thermal Stripping: The polyurethane enamel coating must be burned away or tinned cleanly before soldering into the high-density PCB. Every lead required continuity verification using a multimeter to ensure enamel remnants didn’t insulate the solder joint. A Klein multimeter with beep continuity test was invaluable here, as it takes a lot more heat than one may think to melt off the coating.

2. Micro-Soldering in High-Density Layouts

Because through-hole pads sit mere fractions of a millimeter away from neighboring traces and pre-populated SMT components:

• I resolved to use a jeweler’s loupe / optical magnification and ample lighting from a headlamp to inspect solder wetting, fillet geometry, and clearance on every joint. Happily, I had no major issues here, though the BNC connector was very difficult to secure with solder because it acted as a giant heat sink, preventing the solder from laying nicely and securing the mounting pegs to the PCB board.
• Maintained strict thermal control: applying targeted paste flux with a fine conical tip, dwelling for under two seconds to prevent lifting pads or heat-soaking sensitive transistors.
• Utilized precision flush-cutters to clip component leads sub-millimeter to prevent shorts against the metal casing.

3. RF Bench Safety & Load Termination

Unlike audio amplifiers, an RF transmitter cannot be tested open-circuit without instantly destroying the final output transistors (BS170 MOSFETs) due to reflected power and voltage standing waves (high VSWR). * Prepared a calibrated 50-ohm dummy load capable of dissipating 5W continuous RF power. * Validated receiver alignment, sideband suppression, and sidetone pitch prior to any antenna connection.

Impedance Transformation & Transformer Physics

An end-fed half-wave radiator driven at resonance presents an extremely high feedpoint impedance, which the ARRL handbook reports to be between and . This is due to the voltage antinode (and current node) at the wire’s termination:

To match this high-impedance feed to the standard unbalanced output of the QCX-mini’s BNC connector without a bulky antenna tuner, I hand-wound a 49:1 Unun (Unbalanced-to-Unbalanced) transformer:

• Toroid Selection: Built on a high-permeability Fair-Rite FT140-43 ferrite toroid core to maintain low insertion loss across the 14 MHz band while avoiding core saturation.
• Winding Geometry: Wound using an autotransformer configuration with an isolated primary coupling loop: 2 primary turns tapped into a 14-turn secondary (, ).
• Impedance Ratio: Because transformation scales with the square of the turns ratio:
• High-Voltage Compensation Capacitor: Placed a / silver-mica capacitor in parallel across the input to tune out leakage inductance introduced by the bifilar primary coupling at 14 MHz.

Tuning & Vector Network Analysis

Tuning an EFHW requires meticulous length trimming to position the minimum Voltage Standing Wave Ratio (VSWR) directly inside the CW sub-band (14.000–14.070 MHz):

1. Pruning the Radiator: Began with roughly 36 feet of 22 AWG insulated stranded copper wire suspended in a sloper configuration.
2. VNA Sweeps: Used a calibrated NanoVNA to sweep the reflection coefficient () and return loss from 13.5 MHz to 14.5 MHz.
3. Resonance Trimming: Folded back the wire in 1-inch increments until the resonant dip achieved an (VSWR ) centered at 14.060 MHz (the international QRP CW calling frequency).

This self-contained, resonant antenna requires no tuner and minimal counterpoise, providing a high-efficiency field radiator capable of working stations across North America on just 5 watts of RF power.

What I Couldn’t Resolve on My Own

Two questions came up during this build that I could work around in practice but never fully resolve in theory:

• Core and wire sizing. I settled on the FT140-43 core and 22 AWG wire based on what other builders’ writeups used, not from a calculation I could reproduce myself. I don’t yet know how to size a toroid core or wire gauge for a given power level from first principles—accounting for core saturation and heating at 5W of continuous RF, and how RF-specific effects like skin effect factor into an appropriate wire gauge—versus simply copying a known-good recipe.
• The counterpoise question. I found genuinely conflicting guidance in the amateur radio community about whether an EFHW like this needs a counterpoise (and if so, how long) or whether the feedline shield alone is sufficient. I still don’t have a confident, first-principles answer to that question.

The Timing Problem

Under the standard PARIS benchmark, ideal Morse transmission follows strict proportional relationships based on a unit duration ():

• Dit ():
• Dah ():
• Intra-character space:
• Inter-character space:
• Inter-word space:

In practice, physical keys, manual paddles, and atmospheric propagation introduce non-linear variations:

1. Weighting Bias: Many operators transmit “heavy” or “light” code, skewing the mathematical dit-to-dah ratio.
2. Farnsworth Timing: Spacing between words or characters often expands while individual element speeds remain fast, confounding simple threshold filters.
3. Contact Bounce & Chirp: Mechanical switches produce spurious microsecond pulses that must be distinguished from genuine dits.

Cleaning & Feature Engineering

To process these irregular streams, the cleaning step converts raw high/low durations into normalized element arrays:

• Outlier Truncation: Drops transients under caused by contact chatter or audio interface clipping.
• Bimodal Duration Clustering: Rather than hardcoding millisecond thresholds, the pipeline fits bimodal distributions to separate dits from dahs dynamically, adapting as the effective transmission speed (WPM) drifts across a session.
• Ratio Tracking: Computes rolling moving averages of the element ratio () to identify operator fatigue and mechanical key misalignments over time.

System Overview

Transforming a hobbyist chassis into a stable Linux-driven mobile platform required thougtful planning around mechanical constraints, wiring, and electrical isolation:

• Procurement & Physical Layout: Selected and sourced the Raspberry Pi, PCA9685 16-channel 12-bit PWM HAT, and continuous rotation servos, laying out the chassis geometry to keep the center of gravity low and stable.
• Soldering & Board Prep: Populated and soldered the multi-pin header arrays on the PWM HAT and custom power leads, ensuring reliable mechanical joints that would reliably deliver signal between the Raspberry Pi board and HAT.
• Custom 3D-Printed Mounts: Procured and printed (additive manufacturing) custom mounting brackets and standoffs to secure the Raspberry Pi, camera module, and battery bank to the aluminum Boe-Bot chassis without shorting against the metal frame.
• Power Budgeting & Electrical Isolation: High-torque servos draw significant stall current and inject inductive electrical noise onto supply rails. To prevent voltage sags from browning out the Raspberry Pi during sudden motor acceleration, I designed around an appropriate power topology with isolated rails:
  • An onboard high-current 5V USB battery bank dedicated to the Raspberry Pi logic.
  • An isolated, filtered 5–6V battery supply feeding the high-draw servo power rail on the HAT.

How Continuous Servos Work

Standard hobby servos use internal potentiometers for closed-loop angular positioning ( to ). Continuous rotation servos remove the mechanical stops and disconnect the potentiometer, turning pulse width into rotational velocity and direction:

• Neutral / Stop (): Signals the internal H-bridge to stop motor rotation.
• Clockwise (): Full rotational speed in one direction.
• Counter-Clockwise (): Full rotational speed in the opposite direction.

Because potentiometers drift slightly between individual units, software calibration was required to define a consistent “deadband” window around neutral—ensuring the chassis doesn’t crawl across the floor while idling.

Interfacing with the Servo HAT in C++

Driving pulse-width modulation directly off standard Linux GPIO pins often results in timing jitter due to OS process scheduling. To ensure clean signals, the servos and camera pan mount are offloaded to an auxiliary PCA9685 16-channel PWM driver HAT connected via I²C. During the project, debugging and testing was conducted over WiFi on my home network to the Pi via an SSH terminal. Past experience in CLI-driven Linux was invaluable at this stage of the project. Local development was done on my laptop and successive tests shipped to the bot via rsync.

Pulling in System Headers

Rather than pulling in bloated third-party libraries, the C++ driver I wrote for the bot interacts directly with Linux kernel I²C character devices:

• Used <linux/i2c-dev.h>, <sys/ioctl.h>, and standard POSIX-compatible file calls (open, write, close).
• Initialized the I²C bus on /dev/i2c-1 and set the target slave address.
• Configured the internal oscillator prescaler for a standard 50 Hz PWM frequency ( period) and wrote 12-bit channel counter values.

void RobotChassis::driveForward() {
    setServoPulse(LEFT_SERVO_PIN, 1300);   // Left wheel forward
    setServoPulse(RIGHT_SERVO_PIN, 1700);  // Right wheel mirrored
}

void RobotChassis::pivotLeft() {
    setServoPulse(LEFT_SERVO_PIN, 1700);   // Left wheel reverse
    setServoPulse(RIGHT_SERVO_PIN, 1700);  // Right wheel forward
}

void RobotChassis::halt() {
    setServoPulse(LEFT_SERVO_PIN, CALIBRATED_STOP);
    setServoPulse(RIGHT_SERVO_PIN, CALIBRATED_STOP);
}

Wrapping this inside a clean C++ driver class provided RAII (Resource Acquisition Is Initialization) resource cleanup on shutdown and prevented runaway motors if an upstream process crashed. The importance of writing safe and stable software when working with robotics became very clear here. In larger industrial projects, a runaway process could have catastrophic consequences. I gained an awareness of RTOS systems and custom compilers that can be mathematically proven to prohibit accidentally writing non-terminating loops, a routine performing infinite recursion, etc.

GitHub::Chassis Driver Repository

Driver Demo

Here is a quick run of the driver test sequence in my home lab. The script validates forward/reverse drive, rotational pivots, and camera pan articulation:

AudioCW Interface Demo

The interface handles text-to-tone serialization, configurable Words-Per-Minute (WPM) symbol timing, and sidetone pitch adjustment (typically 700 Hz) with live visual feedback:

GitHub::Transceiver Repository

Vision for this project:

Like many projects, it’s hard to gauge completion. This turned out to be a very educational and interesting project with tons of potential. Transmitting audio for digital communication and/or remote sensing with either audible or sub-audible tones is used across many industries and areas of science/development. Similarly, signal processing is especially relevant in speech-to-text AI workflows (see ChatGPT Live, and others); DSP allows voice to be efficiently filtered out from background noise, which translates to less heavy processing by LLMs when receiving user input.

Any and all of these areas remain relevant to this project, which continues to serve as a “toy example” to learn more about these areas in a stripped down environment. I continue to find that tailored, digestible, hands-on projects such as this make for an interesting vehicle for learning core fundamentals about what I consider to be very complex topics. Once I’ve sufficiently mastered these topics, I’d very much like to contribute end-to-end hardware projects and code for future learners in this same style.