Back to the roots at 50: Introducing Spectral-G4 (AI meets VLF)

[Taktyk]

Hi all,

I had to build myself some software that makes it easier to tune my detector squinting at
raw numbers on a tiny LCD while chasing ground balance and discrimination just wasn't cutting
it. So I put together a small PC "bench lab" that talks to the detector over USB and shows what
the DSP is actually doing, live.
It connects to the detector MCU over USB-CDC / serial, streams the signal frames, and
visualizes them:
- XY hodograph — the I/Q vector trail (per harmonic) for ground-balance and target
discrimination tuning: signed ±180° protractor, live phase readout, persistence trail.
- Virtual oscilloscope — demodulated I/Q (or raw RX) in the time domain, with a sweep
trigger and automatic Vpp / RMS / mean / frequency measurements.
- Live FFT — Hann-windowed spectrum for spotting EMI and picking clean working frequencies.
- DSP recorder — a multi-channel strip chart of the detection chain over time: audio
(signal strength), threshold, ground (after correction), and I/Q after the active mode's
filters (DEEP / DISC / PROS each use different filters). Tap the coil and you can watch the
filter's impulse response.
It's profile-driven — a small JSON contract describes the telemetry framing — so it isn't tied
to one machine. Right now I'm running it with a single-frequency VLF (ATxmega) and building it
toward a multi-frequency STM32 design.
Backend is Python (FastAPI) streaming over WebSocket; the dashboard is Next.js / React with
uPlot charts. It's open source and very much a work in progress:

https://github.com/takzen/metal-detector-studio

— Christopher

[Sergey_P]

Hi Taktyk
Are measures taken to eliminate the occurrence of self-resonant frequency of the transmitting coil caused by parasitic structural capacitance of the coil?

[Taktyk]

Hi Taktyk
Are measures taken to eliminate the occurrence of self-resonant frequency of the transmitting coil caused by parasitic structural capacitance of the coil?

No. The coil is not tuned to resonance. The design relies on keeping the self-resonant frequency well outside the operating bandwidth and measuring the actual phase/amplitude response digitally.

[Taktyk]

Quick update — the project has come a long way since the first post, and I've just tagged a
v0.7.0 beta, so here's a rundown of what's new.

Most of the work went into the analysis tools. The live FFT now has a waterfall/spectrogram view
and selectable windows (Hann, Hamming, Blackman, flat-top, rectangular) with averaging, max-hold
and 50 Hz mains markers, which makes hunting for clean frequencies and tracking down interference
much easier. The oscilloscope got a proper sweep trigger (auto / normal / single-shot) with a
draggable level and automatic Vpp / RMS / mean / frequency readouts. The DSP recorder now puts
each signal on its own lane with its own scale, shows the I/Q after the active mode's filters, and
can be frozen so you can study a coil tap.

The new feature I'm happiest with is a filter lab — it shows the impulse and frequency response of
the actual DSP filters running in the firmware (the EMA trackers, the biquad low-pass, the SAT /
threshold filters), with the real coefficients and metrics like the −3 dB point, settling time and
overshoot. It can also flip a tracker between its low-pass and high-pass form and show the effective
passband of the motion channel. It's been really handy for understanding and tuning the chain
before flashing anything.

On the hardware side, I documented the serial protocol and added a minimal STM32 example, plus a
fillable device-profile template and a validator, so connecting your own build is now
straightforward — at minimum the firmware just sends "X:<i> Y:<q>" lines over USB-CDC, and a small
JSON profile describes the rest. There's a written user manual now too.

Smaller things: the UI remembers your settings between sessions, there are keyboard shortcuts for
the tabs and common actions, per-chart fullscreen, and PNG export. There's also an optional MCP
server that exposes the live telemetry to AI assistants.

A few screenshots of the current dashboard below. Repo:

https://github.com/takzen/metal-detector-studio

As always, feedback and ideas welcome.

[Taktyk]

Another update. I've just tagged a v0.8.0 beta. The headline this time is a new ADC scope: a
tab for looking at the raw converter in the detector instead of the cooked DSP output.

A bit of background on why I wanted it. My VLF front-end digitizes the demodulated channel with
an AD7691 (18-bit SAR), a REF3240 4.096 V reference and an ADA4941 driver, and in normal
operation the MCU runs a synchronous demod plus a 16-sample boxcar and then decimates — so all I
ever get to see is the averaged number. I wanted to look at the converter itself: what the real
noise floor is, and what is actually limiting ENOB. So I added a service screen on the detector
that streams a contiguous block of single-channel raw ADC samples over USB-CDC (256 samples at
~22 kSPS, with no demod, no boxcar and no truncation), gated by an on-device toggle so it stays
silent in normal use. The PC side windows the block, runs an FFT and reports the noise floor,
SNR, ENOB and a narrowband SNR over a band you pick, with the FFT processing gain accounted for.
The readouts are copyable and each has a short "what does this mean" note.

Also in this release: the hodograph now computes its own I/Q delta on the PC against a
studio-side zero (so it no longer depends on the device's reference), there is a SwingTune mode
that reproduces the firmware's swing-peak median-phase automat for ground balance, and you can
set a factory ground-balance line on the plot.

As always, feedback and ideas welcome.

[dekamon]

Hi everyone,

I am planning to modify the classic Delta Pulse (Pulse Induction) metal detector circuit. My goal is to completely eliminate the analog timing stage—specifically replacing the LM556 and CD4538 ICs—and instead use an STM32F103 microcontroller to handle all the timing.

I want to control the TR2, TR4, and TR5 control pins of the CD4066 analog switch directly via the STM32 firmware.

I want to ask Claude AI to write the STM32 code (using STM32CubeHAL) for this project. How should I structure my prompt so that the AI understands the exact timing requirements of a PI detector and generates a precise, reliable code?

Specifically, the code needs to handle:

1. TX Pulse Generation: Adjustable frequency (100Hz–150Hz) and adjustable pulse width (100µs–250µs).
2. Delay/Offset Time: A precise, adjustable microsecond delay after the TX falling edge to let the coil ringing subside.
3. Sampling Gates: Sequential or precise control pulses for the CD4066 switch pins (TR2, TR4, TR5) with microsecond accuracy using hardware timers to avoid jitter.

If anyone has a well-optimized Claude prompt template for this kind of hardware timing task, or any advice on implementing this with STM32 timers/ISRs, I would greatly appreciate your help!

Thanks in advance.

[Taktyk]

Hi everyone,

I am planning to modify the classic Delta Pulse (Pulse Induction) metal detector circuit. My goal is to completely eliminate the analog timing stage—specifically replacing the LM556 and CD4538 ICs—and instead use an STM32F103 microcontroller to handle all the timing.

I want to control the TR2, TR4, and TR5 control pins of the CD4066 analog switch directly via the STM32 firmware.

I want to ask Claude AI to write the STM32 code (using STM32CubeHAL) for this project. How should I structure my prompt so that the AI understands the exact timing requirements of a PI detector and generates a precise, reliable code?

Specifically, the code needs to handle:

1. TX Pulse Generation: Adjustable frequency (100Hz–150Hz) and adjustable pulse width (100µs–250µs).
2. Delay/Offset Time: A precise, adjustable microsecond delay after the TX falling edge to let the coil ringing subside.
3. Sampling Gates: Sequential or precise control pulses for the CD4066 switch pins (TR2, TR4, TR5) with microsecond accuracy using hardware timers to avoid jitter.

If anyone has a well-optimized Claude prompt template for this kind of hardware timing task, or any advice on implementing this with STM32 timers/ISRs, I would greatly appreciate your help!

Thanks in advance.

In practice, a workflow like this works very well:

1. Create a new project in STM32CubeMX or STM32CubeIDE.
2. Select the target MCU (for example, STM32F103C8T6).
3. Save the project and the .ioc file.
4. Open the entire project folder in VS Code with Claude Code, Codex Agent, Cursor, or a similar AI coding assistant.
5. Provide the agent with the .ioc file, timing diagrams, and hardware requirements (GPIO assignments, timers, DMA, pulse widths, sampling windows, etc.).
6. Ask it to:

• configure the timers in the .ioc file,
• configure GPIOs,
• configure DMA if required,
• generate HAL/LL initialization code,
• implement the timing and control logic.

The agent can analyze the project, modify the .ioc file, update the source code, and often complete 80–90% of the STM32 configuration and firmware development work.

For more demanding projects such as a Pulse Induction metal detector with microsecond-level timing requirements, you will still need to verify timer settings and signal timing with an oscilloscope. However, modern AI agents can significantly reduce development time and handle much of the repetitive STM32 setup and coding work.

Good luck with the project!

[dekamon]

In practice, a workflow like this works very well:

1. Create a new project in STM32CubeMX or STM32CubeIDE.
2. Select the target MCU (for example, STM32F103C8T6).
3. Save the project and the .ioc file.
4. Open the entire project folder in VS Code with Claude Code, Codex Agent, Cursor, or a similar AI coding assistant.
5. Provide the agent with the .ioc file, timing diagrams, and hardware requirements (GPIO assignments, timers, DMA, pulse widths, sampling windows, etc.).
6. Ask it to:

• configure the timers in the .ioc file,
• configure GPIOs,
• configure DMA if required,
• generate HAL/LL initialization code,
• implement the timing and control logic.

The agent can analyze the project, modify the .ioc file, update the source code, and often complete 80–90% of the STM32 configuration and firmware development work.

For more demanding projects such as a Pulse Induction metal detector with microsecond-level timing requirements, you will still need to verify timer settings and signal timing with an oscilloscope. However, modern AI agents can significantly reduce development time and handle much of the repetitive STM32 setup and coding work.

Good luck with the project!

"Thanks for the amazing advice! I will try this exact workflow using Cursor/Claude with the .ioc file."

[Taktyk]

Another quick one - just tagged a v0.9.0 beta. The studio now drives my multi-frequency build
on its Spectral-G4 profile (three simultaneous harmonics), so the shots finally show real
3-frequency I/Q instead of a single channel.

Most of it is in the analysis tabs. The filter lab now shows an input → output → spectrum triad
(a triangle test pulse, the filter's response to it, and the frequency response), with a
per-stage toggle to inspect each biquad of a cascade or the whole chain, X/Y zoom, and an
absolute-dB axis so filters with gain show their real level - plus a small "sandbox" that
previews experimental biquad cascades straight from the firmware source. The live FFT gained a
complex two-sided mode: it runs the FFT on I + jQ instead of I and Q separately, so it keeps the
side of the carrier (a tone above zero-beat shows at +f, below at −f) and reveals quadrature
imbalance as a mirror image.

There's a new tab too - an I/Q phase / axis auto-calibration sandbox. You air-balance on the
no-metal probe vector to measure the unknown axis rotation, rotate it out, and read the
corrected phase. On an analog-demod detector the axis is already ~0, so there it's mostly a
viewer; the real use is a digital-demod build.