VLF MD with digital signal processing : Bee-Buzz 1

[Detectorist#1]

Is it this current is draw from Tx circuit or from total detector with processor and all other electronics?

[Marchel]

Hi Marchel,

What is the necessary output power of a VLF detector is interesting question for me. Too low power ( in case of using of USB sound card) maybe will be not OK. I'm sure, Carl knows the right answer.

It depends more or less on the TX winding and frequency. I use an XP Deus X35 coil and the total electronics draw is about 40mA. Other detectors I have seen draw something between 80-120mA from the battery.

[Detectorist#1]

Hi Marchel,

What is the necessary output power of a VLF detector is interesting question for me. Too low power ( in case of using of USB sound card) maybe will be not OK. I'm sure, Carl knows the right answer.

[Marchel]

Hi all,

the fastest way of implementing a fully digital direct sampling VLF is using the PC (Tablet) and an external USB sound card. At least, you can make the proof-of-concept easy and fast.
You have:
- an operating system (multi-core)
- GUI-API
- drivers (only API interfacing the signal data)
- display, keyboard, touchpad, Wi-Fi, blue-thooth, etc.
- lots of DSP-code written in C/C++ (open source)
- debugger (within Visual Studio for instance)
- no external HW required (no soldering iron) -> you can twist the input/output cables with a resonant capacitor and the coils if you like
- possibility to start immediately with coding

Think of it. This is a good advise.
Aziz

Yes, it's a simple solution, but the results will be very poor because without input preamplifiers and output mosfets on the TX it probably won't work. And the second thing is that the device would be difficult to carry outside and do ground tests with. I want my prototype PCB to contain 2 TX outputs for a sinusoidal signal and also for a square wave signal so that both types of coils can be connected there.

[Aziz]

Hi all,

the fastest way of implementing a fully digital direct sampling VLF is using the PC (Tablet) and an external USB sound card. At least, you can make the proof-of-concept easy and fast.
You have:
- an operating system (multi-core)
- GUI-API
- drivers (only API interfacing the signal data)
- display, keyboard, touchpad, Wi-Fi, blue-thooth, etc.
- lots of DSP-code written in C/C++ (open source)
- debugger (within Visual Studio for instance)
- no external HW required (no soldering iron) -> you can twist the input/output cables with a resonant capacitor and the coils if you like
- possibility to start immediately with coding

Think of it. This is a good advise.
Aziz

[Atul Asthana]

I’ve been trying to learn from both analog and newer digital designs, but without detailed design descriptions, it's challenging to understand the rationale behind specific components or methodologies. Guesswork isn't helpful, as it often doesn't align with subsequent stages.

One key aspect is the noise floor, particularly since most metal detectors use front-end opamps that are sometimes only slightly better than standard ones, making it difficult to quantify this parameter to sufficient accuracy. My attempts to create a mathematical model to understand the underlying logic have been unsuccessful due to these ambiguities.

I'm aiming for a noise floor of e.g. 1 microvolt, which requires careful consideration of the analog input filters. Would a two-pole filter suffice, or should I add another set of opamps to create a four-pole filter?

Additionally, what type of filter would be most effective? Should notch filters be placed in the analog path, or is it better to implement them digitally? Do I even need notch filters in the first place?

In terms of signal processing, what methodology should be employed after the initial detection (e.g., post-Goertzel algorithm)? What corner frequencies would be ideal for the filters to differentiate ambient from target responses?

Furthermore, what is the most appropriate way to calculate VDI (Visual Discrimination Indicator)?

What additional features could be incorporated to enhance the signal processing and use features, making the metal detector more effective and user-friendly?

[moodz]

Try Octave it's prob closer in capability.

[dbanner]

PS I have not used MATLAB for years ... its come a long way.

moodz

Can Scilab do much of the same as Matlab? How does it compare? Ever used it, anyone? It is free and open source.

[dbanner]

I want to go have a look at the front end architecture of the stuff that's out there.

[dbanner]

Next week I should be able to draw the first PCB for a prototype metal detector based on this hardware https://vi.aliexpress.com/item/10050...Cquery_from%3A so let me know if I should start working on it or this thread will disappear, which would be a great shame because I would like it to be an example for everyone who wants to start building a metal detector with direct sampling.

Maybe start a new thread, I will follow closely. I am especially interested in the development of such a direct sampling VLF. Let's see how far it can be developed that would put the performance as close to the commercial stuff that's out there.
Aim for MF as a destination.

[Repwoc]

I can't help but feel like you're expecting the entire project—lock, stock, and barrel—tested and working, be handed to you on a silver platter, and on top of that, you are demanding that it fits neatly into your schedule!

Sir, the world doesn’t quite work that way any more.

The irony is palpable.

[Marchel]

Next week I should be able to draw the first PCB for a prototype metal detector based on this hardware https://vi.aliexpress.com/item/10050...Cquery_from%3A so let me know if I should start working on it or this thread will disappear, which would be a great shame because I would like it to be an example for everyone who wants to start building a metal detector with direct sampling.

[Marchel]

Not arguing ... but your logic does not make sense. I mean somehow you have turned it around and its our fault now ? If you had been straight up with the proposal and as you admit you are not so well informed in this area of expertise ( aka metal detectors ). Also as a somewhat uninformed person on this matter you somehow go missile lock on the blue pill as the target solution. Hate to harp on but the ESP32 is streets ahead of the blue pil because it has wifi and bluetooth which means your user interface hardware is much easier ( leaving processor speed aside ) and though some bang on about the non linearity of the ADC ... the facts are it does not matter for VLF because the non linearity is a constant distortion ... we are not measuring voltages we are doing frequency domain sampling. The wifi and bluetooth along with arduino development makes it a piece of cake develop a detector.

Also some basic web research skills would help too .... here is a VLF detector project for the ESP32 with an APP for your phone ( every kid seems to have one nowadays ) its ready to go !!!
lf you really have to why dont you port it to the blue pill ?

https://github.com/folny/ESP32_Metal...ster/README.md

best regards.

PS you can get a ESP32 for the same cost or cheaper than a blue pill.

ESP32 Metal Detector is probably my first project that I started working on, but then I stopped working on it because the hardware was complex and I started working on direct sampling detectors and switched to STM32.

[Atul Asthana]

Not arguing ... but your logic does not make sense. I mean somehow you have turned it around and its our fault now ? If you had been straight up with the proposal and as you admit you are not so well informed in this area of expertise ( aka metal detectors ). Also as a somewhat uninformed person on this matter you somehow go missile lock on the blue pill as the target solution. Hate to harp on but the ESP32 is streets ahead of the blue pil because it has wifi and bluetooth which means your user interface hardware is much easier ( leaving processor speed aside ) and though some bang on about the non linearity of the ADC ... the facts are it does not matter for VLF because the non linearity is a constant distortion ... we are not measuring voltages we are doing frequency domain sampling. The wifi and bluetooth along with arduino development makes it a piece of cake develop a detector.

Also some basic web research skills would help too .... here is a VLF detector project for the ESP32 with an APP for your phone ( every kid seems to have one nowadays ) its ready to go !!!
lf you really have to why dont you port it to the blue pill ?

https://github.com/folny/ESP32_Metal...ster/README.md

best regards.

PS you can get a ESP32 for the same cost or cheaper than a blue pill.

The objectives of this project were clearly outlined in the initial paper, and as the designer, I’d appreciate the freedom to choose my resources based on my preferences. Of course, you are equally free to select your own resources for your version of the project.

It seems there might be some misunderstanding here:

1. The issue isn’t the project itself, pointing faults at you, but the continuous and unprovoked retort and demands expecting me to align with your timeline and preferences.
2. My decision to avoid the ESP32 wasn’t based on dismissing its capabilities but on using what’s accessible to me and not sourced from China.
3. It’s not strictly about the Blue Pill either—any processor capable of doing the job is fair game. If needed, I can even use an N100 SBC.
4. This is a maker-level project, not a user-level one so copying or porting is not the objective.
5. And no, I haven’t joined ST Micro, contrary to your previous retorts.
6. I don't quite understand your insistence on porting an existing project to the Blue Pill. Are you suggesting that building a project from the ground up isn't worthwhile, and that we should only follow a single, predetermined approach?

I appreciate the enthusiasm for the ESP32 and understand its advantages, such as Wi-Fi and Bluetooth, which can make interface development easier. However, my choice of the Blue Pill was guided by what was accessible and suitable for the project's scope at the time. While the ESP32 offers great features, my focus was on simplicity and availability.

The goal of this project is to foster creativity and innovation. If someone prefers to use the ESP32 and develop along those lines, that's fantastic. The beauty of an open, collaborative project is that multiple approaches can coexist, enriching the overall effort.

[Atul Asthana]

Some are, some are not. Throughout this thread it's sounded as if this is a project you intended to do (both hardware and software) and wanted feedback on the intended direction. Then, suddenly, you asked if anyone can write the code for you. I don't think anyone saw that coming. Maybe next time make it clear your intentions.

Most people here already have projects on-going. I have several. And, from the feedback, I think many people would do this project differently, both with hardware & software. Maybe this thread will help spark interest in someone making a direct-sampling VLF, but it may be completely different than your proposal. Maybe you could take one of your STM Blue Pills and start writing code for the TX PWM, get that working first. I think that alone will be somewhat difficult.

I currently don't have the time for extensive coding, though the task scheduler and other aspects aren't too challenging.

Everyone should approach this project in their own way, as it's a hobby project for experimentation, redesign, and research—not a professional-grade metal detector. Its purpose is to help students delve into electronics and mathematics, rather than just assembling parts and loading software without understanding.

This is a maker-level project, demanding thoughtful engagement and technological exploration, while also offering hands-on, practical experience in the field.