VLF MD with digital signal processing : Bee-Buzz 1

[Carl-NC]

I am also looking for review and suggestions on improving the signal procesding part, since the md is all software, I am pretty sure thst there must be easier / more rational / better ways to process the signal or to manage the admin tasks so thst initial softeare development errors can be reduced.

A first design is always difficult, after that it gets easier. When I developed the security walk-through detector for FTP, I wrote the code (both DSP and a massive menu-driven user interface) a particular way. Eventually, as I tried to add new features, I decided I had made bad choices so I started completely over. Now what I have is "robust and feature rich" and much easier to manage. Expect to write the code twice. The first time, do it the way you think it should be done. The second time, do it right.

Currently I write all my code in C++ because modularizing everything in objects makes it more readable and easier to maintain. You have to be careful not to overuse C++ features because it can rapidly expand memory usage. I also use RTOS because a metal detector is fundamentally a real-time embedded system. With RTOS, you can further modularize tasks; typically I run only two tasks: a UI task and a DSP task. If you write your own task manager, you have to manually juggle everything going on and that gets harder as you add more complexity, like a display, a keypad, audio, wireless, etc. RTOS makes all this much simpler, which is why I brought it up earlier.

I suggest you define everything you want the software to do. Split it in to DSP and UI functions. Ferinstance, how will you read the ADC and what will you do with the data, and how often? What signals will you need and how will you create them? How much RAM will be needed? On the UI side, will you have pots and/or a keypad? Display? How often do you want to update the audio, and how will it be generated? All this & more.

[Atul Asthana]

I am also looking for review and suggestions on improving the signal procesding part, since the md is all software, I am pretty sure thst there must be easier / more rational / better ways to process the signal or to manage the admin tasks so thst initial softeare development errors can be reduced.

[Atul Asthana]

In the past I've advocated that folks define the goal of a project before selecting the chips to use. In this case, you've pretty clearly stated this is an exploration project. As such, I don't know why the 32F103 won't work; it's plenty fast, probably has enough flash and RAM, and certainly enough timers for direct sampling. And does single-cycle mult/div. Where do you think it falls short?

I think that the computational load, specially the signal processing part, is too heavy for the processor to leave much resources for administrative and user interaction management.

[Atul Asthana]

To logically follow up on Carl's post; no reason to switch platforms, STM32 will do a fair job.
But with the addition of a good external ADC circuit you will get much more.
The whole point of my scribomania is only in the proposal to add a good ADC in front of the processor.

noted.
I need to rework on the amp and adc.

I am wondering if my signal processing and power control approach needs adjustments or rehashing?

[ivconic]

I get this feeling that an stm32f103c8t6 @ 72 MHz is not sufficient. A more powerful processor with fpu/dsp should be used !

and of course with a very low noise amp and atleast a 16 bit adcat 100ksps or above.

To logically follow up on Carl's post; no reason to switch platforms, STM32 will do a fair job.
But with the addition of a good external ADC circuit you will get much more.
The whole point of my scribomania is only in the proposal to add a good ADC in front of the processor.

[ivconic]

[ATTACH]n431987[/ATTACH] --------> https://openl.io

Very good!
Lot of interesting observations!
Thanks for posting!
For those who can't manage to translate it easy:

[Carl-NC]

In the past I've advocated that folks define the goal of a project before selecting the chips to use. In this case, you've pretty clearly stated this is an exploration project. As such, I don't know why the 32F103 won't work; it's plenty fast, probably has enough flash and RAM, and certainly enough timers for direct sampling. And does single-cycle mult/div. Where do you think it falls short?

[Atul Asthana]

I get this feeling that an stm32f103c8t6 @ 72 MHz is not sufficient. A more powerful processor with fpu/dsp should be used !

and of course with a very low noise amp and atleast a 16 bit adcat 100ksps or above.

[pustareka]

КНИГА.pdf --------> https://openl.io

[Atul Asthana]

great,
good information.
the more we discuss and share knowledge, the better it is.
more knowledge never hurts.

I will read up, assimilate the suggestions and recreate this design in some time.

[ivconic]

Unlike Carl, I try to talk you out of such ideas and direct you to a choice with a brighter future!
The difference between me and Carl (apart from the amount of knowledge on his side) is that Carl is
a highly cultured and nice man, while I am a rudimentary savage who usually says what he thinks right away!



I wouldn't interfere in this topic and get on your nerves... I'm not doing it out of bad intentions!
I was already attracted by the idea of giving new life to today's "obsolete" bluepill modules.
I have them, they are unused and I would like them to be given some meaningful purpose.
I would be happy to participate in such a project.
I would just suggest a better way. Let the "processor" be blue pill, great!

Let's consider the widely distributed and accessible bluepill module (I think this is a great idea because literally all forum members will be able to get involved in the project).

For ultra-sensitive detection, the ADC must have high resolution, low noise, and compatibility with the STM32.
Here are some candidates:

1) ADS8860 (Texas Instruments):
Resolution: 16-bit.
Sampling Rate: Up to 1 MSPS.
Interface: SPI (compatible with STM32).
Ultra-low noise with high input impedance.

2) ADS127L01 (Texas Instruments):
Resolution: 24-bit.
Sampling Rate: Up to 512 kSPS.
Interface: SPI.
Low-noise, wide dynamic range, and excellent for DSP applications.

3) AD7768-1 (Analog Devices):
Resolution: 24-bit.
Sampling Rate: Up to 256 kSPS.
Interface: SPI.
Highly accurate sigma-delta ADC with low power consumption.

As for RX frontend:

1) OPA1611 (Texas Instruments):
Ultra-low noise: 1.1 nV/√Hz.
High gain bandwidth: 40 MHz.
Ideal for precise low-noise amplification.

2) LT1028 (Analog Devices):
Noise: 0.9 nV/√Hz.
Suitable for low-frequency precision circuits.

3) AD8429 (Analog Devices):
Instrumentation amplifier.
Noise: 1 nV/√Hz.
High CMRR, excellent for differential signal amplification from RX coils.

Use a combination of active low-pass and band-pass filters with precision capacitors and resistors (1% tolerance) to eliminate unwanted noise and harmonics.
...
Use STM32 SPI peripherals to read ADC data. Configure DMA for high-speed continuous data acquisition.
Use ultra-low noise linear regulators for the ADC and RX frontend.
Keep analog and digital sections isolated.
Use a solid ground plane and proper decoupling capacitors (100 nF close to pins).
...
I wouldn't suddenly "out of nowhere" start pouring out so many suggestions... but it's an incredible coincidence that these very days I'm thinking of raising my works to a higher level myself... of course with the material I already have or can easily get.
With a small difference that I have already decided on ESP32 and not bluepill.
But take this with a grain of salt, it's always on a very long stick with me...long shot as the Americans say.
I started to come up with a scenario. These days I'm very slow to put together a concept. It will be a very long process. Due to certain private difficulties I am prevented from working faster.
But my idea is not limited to use in metal detectors. I'm coming up with a concept that will be modular and universal. I hope that one day it will appear on Aliexpress as an independent product.
So these are the real reasons why I suddenly came here full of "advice" and "opinions"! A mere coincidence!
I'm sorry if I'm a bother... I won't interfere too much from now on. But I will follow the development very carefully.

P.S.
The sentences above are just Copy&Paste from my much larger MS Word document that I have been putting together for days.
Because without a clear "scenario" this kind of work cannot even be successfully started... let alone finished!

[ivconic]

If I could sum up everything I've learned from Carl, Tinkerer, Moodz, Skippy, Altra... previously on the mentioned PI topic... it would be summarized like this:
the minimum speed and resolution of the ADC for an ultra-sensitive direct sampling metal detector depend on several factors, including the operating frequency, the desired sensitivity, and the type of signal processing being performed.
To accurately digitize the signal, the Nyquist theorem requires the ADC sampling rate to be at least 2x the highest signal frequency.
A practical guideline is to use a sampling rate 4-10x the signal frequency to account for harmonics and enable better filtering.
As for the dynamic range; the ADC must capture both small signal variations and large background signals without saturation or loss of detail.
For metal detection, small signals (due to weak inductive changes) require high resolution, typically 16-bit to 24-bit ADCs.
For low-frequency operation (1-10 kHz), a sampling rate of 50 kSPS to 100 kSPS is sufficient.
For higher-frequency operation (over 10kHz... say up to 40kHz), a sampling rate of 500 kSPS to 1 MSPS is recommended.
16-bit resolution is sufficient for most applications, offering a dynamic range of ~96 dB.
24-bit resolution better for ultra-sensitive detectors, providing ~144 dB dynamic range, essential for resolving sub-threshold signals.
A 24-bit ADC might be overkill for most metal detector applications, depending on the design goals and the nature of the signals you are trying to detect.
The smallest detectable signal depends on noise level of the front-end amplifier and ADC. (environmental noise EMI, ground mineralization).
For most practical designs; well-designed 16-bit system can detect signals as small as a few microvolts when paired with a low-noise amplifier.
A 24-bit system will provide better performance, but the improvement depends on whether the overall system noise is below the ADC’s resolution.
So... using an internal ADC in the processor (any of the ones mentioned) will not lead to satisfactory results. That has already been tried. Many times before on the forum.
I see that you have been a member of the forum since 2005. So you are not "from yesterday". I assume that you missed reading a bunch of papers that have been posted on the forum for a long time.
That's why I suggest you start from here (you'll save yourself a lot of time and probably nerves): https://www.geotech1.com/forums/foru...ctive-projects

[Carl-NC]

• Your signal has a dynamic range of only 70 dB.

I think 70dB is quite low. The preamp signal dynamic range is probably more like 100dB. The max signal (at overload) is 3vpp (defined by the max range of the ADC) and 100dB down from this is 30uvpp. Typical preamp gains in a VLF are 20-50 -- let's call it 30 to make the math easy -- so the minimum signal at the RX coil will be 1uvpp, or 350nv rms. Even with a not-so-great opamp, the input-referred noise of the preamp is likely to be under 100nv rms (assuming a 50Hz NBW) so this is very reasonable. An 18b ADC would work well here, but these tend to be very expensive SAR converters. The 24b CODECs use a much cheaper sigma-delta ADC which never achieves 24 ENOBs but usually 18-20 ENOBs, which is perfect for this application. And they're cheap. That's why all the detector companies are using them.

The question with the above analysis is, with a preamp gain of 30, will anything ever create a 3vpp signal at the ADC? The answer is 'yes'; a strong target or very strong ground can do it. How strong depends on the TX field strength and the area-turns of the RX coil. It is a "whole design" concept, and you have to figure out where you want your overload point to be and design the coils, TX, and preamp for this. Personally, I consider a US quarter at 2 inches to be a reasonable overload point. Even then, I've seen ground stronger than that, though it's rare. Once you have determined your overload point, then select the ADC and design the preamp to achieve a minimum resolvable signal level.

I'm sure it sounds like I'm trying to talk you out of the 12b approach but I'm not, I think it's the right starting point. I'm just trying to present a clearer picture of what to expect and, eventually, how to deal with it.

[ivconic]

In the meantime if you decide to do something with the blue pill or ESP32... welcome.

[Atul Asthana]

I think I understand the reasoning behind some of your views.
Keep in mind that 40 years ago you didn't have super low power opamps with super good S/N ratio available.
Today the situation is different.
Nowadays you can do much more with 24bit if you have a high end opamp frontend with incredible speed and S/N in front of it.
You can literally "hear" signals below the noise level.

Great,
Next design, will try out.