DSPECT ... A development tool for metal detectors ( and other stuff )

[moodz]

I went coding wild .... added the LCR , BODE and NAD modes ( noise and distortion) .... Only for sound card though.

Version 2.2 is attached below for your enjoyment ( or not ).

[moodz]

Hi Paul,

nice App.

For real-time metal detecting approx. 100 times / s measurement is ok. Even 50 times/s is ok (slow motion version).
Instead of Lock-in amp demodulation, Goertzel will do it slightly faster.

With an ultra-low-noise amplifier, the USB sound card version will do a good job.
Aziz

Claude agrees with you but this is what he said :

For the sound card, keep the lock-in as it is. Goertzel would give the same answer, and the current version is the better-behaved of the two.

What we have is already a DFT bin at the TX frequency, the same quantity Goertzel computes, but with two advantages:

Hann weighting. Off-frequency signals leak far less. You saw it in the test: with plain averaging the extra 1 kHz and 5 kHz tones made the reading wander by about ±0.7°. With Hann it was steady to 0.0001°. A plain Goertzel is a rectangular window, so it behaves like the first version.
Any frequency, any block length. Since the exact-frequency TX change, the TX is a fractional phase accumulator, so a block rarely holds a whole number of cycles. A rectangular Goertzel needs whole cycles to stay clean; Hann doesn’t care.
Goertzel’s one advantage is speed, about 1 multiply per sample instead of about 4. That doesn’t matter here: at 192 kHz on two inputs the lock-in costs a few million operations per second, which JavaScript handles without noticing.

The numerics also favour the direct form. Each sample is multiplied by an exact cos/sin of its known TX phase, so there’s no recursion to accumulate rounding error over long, low-frequency blocks. In JavaScript’s double precision that isn’t a real risk either way.

Goertzel only makes sense where every multiply counts: in the FPGA, on the ESP32, or for a bank of many frequencies at once. For one TX frequency in the browser, the current lock-in is the right choice.

[Aziz]

Claude agrees with you but this is what he said :

For the sound card, keep the lock-in as it is. Goertzel would give the same answer, and the current version is the better-behaved of the two.

What we have is already a DFT bin at the TX frequency, the same quantity Goertzel computes, but with two advantages:

Hann weighting. Off-frequency signals leak far less. You saw it in the test: with plain averaging the extra 1 kHz and 5 kHz tones made the reading wander by about ±0.7°. With Hann it was steady to 0.0001°. A plain Goertzel is a rectangular window, so it behaves like the first version.
Any frequency, any block length. Since the exact-frequency TX change, the TX is a fractional phase accumulator, so a block rarely holds a whole number of cycles. A rectangular Goertzel needs whole cycles to stay clean; Hann doesn’t care.
Goertzel’s one advantage is speed, about 1 multiply per sample instead of about 4. That doesn’t matter here: at 192 kHz on two inputs the lock-in costs a few million operations per second, which JavaScript handles without noticing.

The numerics also favour the direct form. Each sample is multiplied by an exact cos/sin of its known TX phase, so there’s no recursion to accumulate rounding error over long, low-frequency blocks. In JavaScript’s double precision that isn’t a real risk either way.

Goertzel only makes sense where every multiply counts: in the FPGA, on the ESP32, or for a bank of many frequencies at once. For one TX frequency in the browser, the current lock-in is the right choice.

Yep, Gemini AI says the same.
Lock-in amp with Hann windowing is the way to go.

[Aziz]

This is the Gemini AI Goertzel vs. Lock-in comparison (see PDF).

Even the Goertzel with Hann windowing, numerical instability on large sample block sizes remains.
I have a block size of 1920 samples. I will face with the numerical instability.

[KingJL]

... The line above the slider is the bug: it recalculates N from the slider’s rounded position instead of showing the real value. TONE F and SPAN have the same rounding in that line.

I’ll fix both:

...
The corrected file is attached...

No attached file... only the .png image.

[moodz]

No attached file... only the .png image.

My bad ...post #16 has v 2.2 latest. I fixed and added more stuff.

[Aziz]

Hi Paul,

is your AI coding the WebApp Audio application in Typescript or Javascript?
It is also using AudioWorklet for time critical audio functions.

One also could use WebAssembly technology to code in C, C++ or any other programming language for the pure DSP part.
Anyway, this is very interesting to run the whole App in a common modern browser (platform independent).
Nice. Very nice.
Aziz

[moodz]

Hi Paul,

is your AI coding the WebApp Audio application in Typescript or Javascript?
It is also using AudioWorklet for time critical audio functions.

One also could use WebAssembly technology to code in C, C++ or any other programming language for the pure DSP part.
Anyway, this is very interesting to run the whole App in a common modern browser (platform independent).
Nice. Very nice.
Aziz

This is the revelation .. there is no need for fancy coding ... javascript has come a long way in recent years especially in active browsers like Chrome and Edge.
Ferinstance with plain javascript the spectrum scope does around 320 traces per second ... thats way faster than your eye can register. ( on a single core of a 3 Ghz AMD processor ).
... and you have to consider that it has to do the graphics on top of the DSP.