VLF MD with digital signal processing : Bee-Buzz 1

[moodz]

Ok I can see I am upsetting you .. and I apologise for that. But there have been many projects started and not finished on this forum ( dont worry me included ... but I am easily distracted and procrastination so I have at least 60 or 70 projects . not all metaldetectors on the go ) The goals were set out in a very clear way and you asked for advice ... so I gave you some. Obviously not everyone thinks the same way but one thing is that if you research then you will find quite a few VLF detector projects and the one you propose is really not aspiring to any new "breakthrough" so its a YAVLF project ... Yet Another VLF project and since you already nominated the hardware before knowing the "system solution" ie if the system ( ie code ) that will eliminate most people on this forum as they will not have the hardware / development environment and so the commentary will be less informed than you as the project lead / director would like. Some would call this armchair commentary.
For instance I use LTSPICE to simulate analogue ccts before I build them in most cases ... and this saves time .. but also if you publish the simulation on forums like this then others can also run the simulation and comment more effectively as they can easily run the sim and provide more meaningful commentary.
So I was essentially trying to advise you that if you want a fully digital VLF detector then just develop the code ( signal flow solution ) that does that unconstrained by any hardware consideration THEN select the appropriate hardware that MATCHES the requirements set by your code. So that was my advice not trying to shut you down or anything. If you choose to go the other way its a free world.

PS ... the blue pill uses its VDD as the ADC reference voltage rather than a bandgap reference so its a poor choice for frontend ADC if noise is a concern.

[ivconic]

Without the risk of copying directly from the book and thereby infringing our friend's copyright... I will try to explain these two approaches to you using the example of radio applications.

Baseband Sampling:
1. Uses downconversion before sampling
2. Signal is mixed with a local oscillator to shift high frequencies down to baseband
3. Requires analog mixing components (mixers, filters, oscillators)
4. Lower sampling rate needed since you're only sampling the downconverted baseband signal
5. Typically used in traditional radio receivers

Direct Sampling:
1. Samples RF signal directly at high frequencies without downconversion
2. No analog mixing stage needed
3. Requires faster/higher performance ADCs
4. Higher sampling rates required (must meet Nyquist criteria for highest frequency) ... (When we talk about metal detectors, this criterion is stricter)
5. More modern approach used in Software Defined Radio (SDR)... (Ha! Gotcha Paul!)

Main Tradeoffs:
- Direct sampling offers simpler hardware design but requires more expensive, higher-speed ADCs
- Baseband sampling uses slower/cheaper ADCs but needs more analog components
- Direct sampling can capture wider bandwidth but generates more data to process
- Baseband sampling is more established but has more potential points of signal degradation

...

...The rule of thumb is go hard or go home...

Sounds harsh but it is true and take it as extremely friendly advice from Moodz.

[ivconic]

I really like the clear and unambiguous division on "baseband" and "direct" sampling.
First you have to decide on one of those two approaches.
It is obvious that you have chosen a platform for development, so it is recommended that you choose baseband sampling.
STM32 bluepill will give you much more with this choice.
You can find reasons and detailed explanations for this in the book.

[ivconic]

See post #113 again above.
The complete project along with my pictures of the built device.
I forgot to emphasize that that detector works pretty well WITH SLOW COIL SWINGING (ADC&DSP capabilities).
But I think what you would find very useful and welcome now Atul Asthana is the book ITMD3 which I am currently reading these days.
I just came to (the most interesting part for me) today, which is:

[Atul Asthana]

Try the nano_vlf as a starting point .... however it uses two processors for some reason that I dont know. But you should be able to see there is fair bit of work in this project to achieve what it does.

https://www.geotech1.com/forums/forum/technology/technical-books-papers-and-literature/418708-arduino-nano-vlf-metal-detector-project-published-january-2024

However if you are going to get into developmental DSP you will need more powerful hardware than a blue pill for development work because there will be insufficient processing overhead for debugging code etc.
The rule of thumb is go hard or go home.
Once you have understood what the signal chain looks like and you have coded a working system or simulation ... then and only then should you try to port it to the blue Pill which may or may not be capable
In commercial development the only reason to use less powerful chips is to save money ( for the manufacturer ) however engineers usually hate this reason because it just creates headaches.

moodz

can you analyse my design for all the points above?

I dont want to 'port' the nano vlf, thats not my idea of a direct sampling md. its some one elses idea, and nano vlf is working and its technically pointless to reengineer it to a diffetent platform. our philosophies are different and so are the aims.

from your comments, I understand that you are suggesting that I should shut down thid project, because the processor does not have sufficient processing power !

can you send me your basis of this assessment, and the calvulations there of?

I fully understand the process flow and the msthematics and logic of the design I've put forth.

so if you can, pick holes in this design / suggest improvements etc. instead of asking me to shut down the project or use the processor suggested by you !

from your statements, it seems that you arent happy with my design, processor and objectives. it may be a good idea for you to put forth your design, which I can then follow.

[moodz]

Try the nano_vlf as a starting point .... however it uses two processors for some reason that I dont know. But you should be able to see there is fair bit of work in this project to achieve what it does.

https://www.geotech1.com/forums/forum/technology/technical-books-papers-and-literature/418708-arduino-nano-vlf-metal-detector-project-published-january-2024

However if you are going to get into developmental DSP you will need more powerful hardware than a blue pill for development work because there will be insufficient processing overhead for debugging code etc.
The rule of thumb is go hard or go home.
Once you have understood what the signal chain looks like and you have coded a working system or simulation ... then and only then should you try to port it to the blue Pill which may or may not be capable
In commercial development the only reason to use less powerful chips is to save money ( for the manufacturer ) however engineers usually hate this reason because it just creates headaches.

moodz

[Atul Asthana]

I would agree .. we had some discussions on this forum years ago about the KISS principle and you really need to make it simple.
A simple way to get a POC "proof of concept going" is these possible pathways / options.

1. Take a simple project off the web ( ie exists already ) that ppl can build and play without visiting the bank manager or the wife. Like the example I gave. Then make it better.
OR
2. Take some generic modules ( eval boards and cpu boards ) and connect them together with some glue bits ( power supplies , tx circuit )
OR
3. Just use the soundcard in an old laptop / computer with a simple RX / TX and write/download the DSP code and try things out.

Instead you are choosing the most difficult path of designing a custom detector from scratch using random chips and DSP blobs AND you already said it wont be very high performance ????? ( waste of time )
Building the custom unit is the step AFTER the POC is done !!

As an example I have gone down choice 2. and with an ADC7760 eval board and an XILINX spartan eval board and some glue bits ( about $150 ) I getting PI ( 1 meter detect ranges + ground cancel ) performance from a single frequency detector with no front end amplifier,
Best of all I have not committed my eval modules to a "soldered" design ... I can reuse them ( and bits of the code ) on something else. There are no amps or filters on the frontend and I did not try to use nice sounding DSP blocks I just kept what worked and threw out everything that didnt.
moodz.

mmodz,

It will be a grest idea if you could help and restructure this project on the principles and processes, you've proposed.

a much simpler design, based on your choice of cpu and adc boarfs etc, could be a better option, and we could all learn this principle, save efforts and the hassle oif experimentstion.

I think, we will wait till we have a better, more cost effective and more robust proposal from you.

you can let us know the estimate of time for the propsal and for the POC .

regards and best wishes
atul

[Atul Asthana]

Sorry .... about those suggestions .. didnt know you worked for ST.

instead,
I will try and get st to work for me

[moodz]

Great,
I am following the KISS principle.

Sir, first, lets get the 'good enough', and then we will strive for the best.

I'd also switch to esp32, if an external adc becomes necessary.
lets once get this design going, I wont hesitate to use Axon or Raspberry PI or even x-86 sbcs if the design needs it.

Sorry .... about those suggestions .. didnt know you worked for ST.

[Atul Asthana]

I have it!
It's called Quant. Here is the archive, you have everything inside.
I made it and it works very nice.
The best part of the story is that you can use a wide variety of stock coils without having to build your own coils.

thanks ivconic.

[Atul Asthana]

A Conceptual Design for a Fully Digital VLF Metal Detector Using STM32F103C8T6

This paper outlines the concept of a fully digital Very Low Frequency (VLF) metal detector based on the STM32F103C8T6 microcontroller. The design prioritizes simplicity, low cost, and ease of construction for electronics hobbyists while leveraging the processing power of a 32-bit microcontroller running at 72 MHz. STM32F103C8T6 is about 20 times faster than popular 8 bit microcontrollers.


So above is the header from post #1 and it would seem then that cost and processor performance are a priority .. but not detector performance or new innovative solutions / techniques ?? I can tell you that from my experience on this board the later two are what people are looking for. Of course they want cheapness also and easy to construct and open source and they expect you to support them when they have problems. But overall they want to pay the organ grinder peanuts for a full orchestral symphony.

But just on processor performance ... the ESP32 blows the Blue pill out of the water on bang for buck ... it has WIFI too which can be linked to a smartphone app .. saving even more money on LCD s and controls !!
The development environment is easier on the ESP32 too.

Though in consideration the raspberry pi is way faster than either of these .... try demodulating 100 IQ streams simultaneously ... the RPi can do it with bags of room to spare.

Great,
I am following the KISS principle.

Sir, first, lets get the 'good enough', and then we will strive for the best.

I'd also switch to esp32, if an external adc becomes necessary.
lets once get this design going, I wont hesitate to use Axon or Raspberry PI or even x-86 sbcs if the design needs it.

[moodz]

A Conceptual Design for a Fully Digital VLF Metal Detector Using STM32F103C8T6

This paper outlines the concept of a fully digital Very Low Frequency (VLF) metal detector based on the STM32F103C8T6 microcontroller. The design prioritizes simplicity, low cost, and ease of construction for electronics hobbyists while leveraging the processing power of a 32-bit microcontroller running at 72 MHz. STM32F103C8T6 is about 20 times faster than popular 8 bit microcontrollers.


So above is the header from post #1 and it would seem then that cost and processor performance are a priority .. but not detector performance or new innovative solutions / techniques ?? I can tell you that from my experience on this board the later two are what people are looking for. Of course they want cheapness also and easy to construct and open source and they expect you to support them when they have problems. But overall they want to pay the organ grinder peanuts for a full orchestral symphony.

But just on processor performance ... the ESP32 blows the Blue pill out of the water on bang for buck ... it has WIFI too which can be linked to a smartphone app .. saving even more money on LCD s and controls !!
The development environment is easier on the ESP32 too.

Though in consideration the raspberry pi is way faster than either of these .... try demodulating 100 IQ streams simultaneously ... the RPi can do it with bags of room to spare.

[ivconic]

I have it!
It's called Quant. Here is the archive, you have everything inside.
I made it and it works very nice.
The best part of the story is that you can use a wide variety of stock coils without having to build your own coils.

[ivconic]

Such projects require commitment and engagement. Mostly everything revolves around the author, that is, the one who has an idea and knows what he wants.
I break down and change my mind every day, and for months now I've been trying to force myself to sit down and create a complete concept.
I don't even know what I want, I don't have focus, I don't have time and I'm overwhelmed with obligations.
And I'm not getting any younger during that time. During that time, young and much smarter people than me are already working on their tenth such project.
Github is full of works.
I have Nucleo 144 and ESP32 as two potential candidates. My latest research tells me that the Nucleo 144 is the better choice.
Now I need to find time, sit down and design the rest of the modules (Paul was 100% right here, the project needs to be broken into modules).
Once I get the modules, I draw the PCB, I have to send it to China for manufacturing. Because I am not capable of soldering those tiny components myself.
It's all a process. An ongoing process. And there is no certain outcome.
We have already tried to work together on projects several times and always the same problem has held things back. "Incompatibility" in opportunities, free time and resources.
That's why something like this is still an individual job.
As for the help; it is difficult to give concrete help because each of us should have the same set of hardware and software in front of him on the table.
And the worst part of the whole story is that they finally managed to infect me with the PI detector virus... so a couple of years ago I completely gave up on VLF I/B ideas!
The main culprits for this are Carl, Moodz and Tinkerer.
I think I have a very easy and interesting project somewhere on disk that could help you. I'll try to find it.
It already exists on the forum but I can't remember the name.
I remember building it and it worked quite nicely.

[Atul Asthana]

I would agree .. we had some discussions on this forum years ago about the KISS principle and you really need to make it simple.
A simple way to get a POC "proof of concept going" is these possible pathways / options.

1. .......
As an example I have gone down choice 2. and with an ADC7760 eval board and an XILINX spartan eval board and some glue bits ( about $150 ) I getting PI ( 1 meter detect ranges + ground cancel ) performance from a single frequency detector with no front end amplifier,
Best of all I have not committed my eval modules to a "soldered" design ... I can reuse them ( and bits of the code ) on something else. There are no amps or filters on the frontend and I did not try to use nice sounding DSP blocks I just kept what worked and threw out everything that didnt.
moodz.

Dear Moodz,

Thank you for your input. As I mentioned earlier, I am not up-to-date with electronics and signal processing, having not explored these areas deeply in the past 30 years. It’s clear that my design approach may be influenced by older ideas.

To provide clarity on the objective and some details of the design, may I kindly request you to revisit posts #1 and #68? The fundamental goal here is to create a low cost simple to create metal detector—regardless of whose idea or design it is. As Carl pointed out in his post #97, there are already several commercial direct sampling metal detectors, like ths design, with far superior performance, but these come at a significantly higher cost.

If you still feel that using a $2 Blue Pill board, $1 op-amps, and $5–$10 worth of additional mechanical hardware, along with open-source DSP libraries optimized for this constrained environment, is not a viable approach, I would greatly appreciate it if you could suggest an alternative design.

Consequently, could you please propose a solution that stays within the same budget and uses a similar number of components? I am more than willing to adapt and follow your recommendation.

Your insights, along with contributions from others, would help steer this project in the right direction and ensure the chosen approach remains both cost-effective and practical for a general hobbyist to implement.

Best regards,
Atul