ARMD (ARMRADIO based Metal Detector) VLF IB PROJECT

[moodz]

Kickoff for ARMRADIO code based MD Project.

"Solutions through Contributions"

Nominal Aims

1. Develop a VLF MD based on ARMRADIO which uses STM32 ARM hardware and open source code.
2. Add front end processing to aid signal amplitude and phase recovery.
3. Develop an AIB Active Induction Balance system for coil balancing.
4. Use parts that are easy to obtain / source or have made for you ( it wont be a through hole PCB ! )
5. Document everything.

Status : IN DEVELOPMENT

Expect this to change with time.

[KingJL]

Kickoff for ARMRADIO code based MD Project.

"Solutions through Contributions"

Nominal Aims

1. Develop a VLF MD based on ARMRADIO which uses STM32 ARM hardware and open source code.
2. Add front end processing to aid signal amplitude and phase recovery.
3. Develop an AIB Active Induction Balance system for coil balancing.
4. Use parts that are easy to obtain / source or have made for you ( it wont be a through hole PCB ! )
5. Document everything.

Status : IN DEVELOPMENT

Expect this to change with time.

I think this could be a very interesting project!

[KingJL]

moodz
For TX what do you think about the alt2hbridge configured for bipolar half-sine operation driven from the ARM?

[Carl-NC]

I'm game. I did a lot of work on AIB at White's, it's not easy.

[moodz]

I reckon we can include the alt2bridge.

Been thinking how the project will track. I am going to suggest a tracking document (SDD - System Design Document ) that will be the historic record for the project where each update of the document will be the historic record and the latest update will be the current version.

The SDD will hold all the design / build / usage of hardware and software.

The project leads are the only ones that release an updated version. Milestone releases will be released as PDF and editable ( Microsoft Word ).... intermediate versions will be PDF.
The Milestone releases allow someone to take up the reigns if all the Project Leads drop out.

Suggestions and bug fixing via the forum ... maybe vote on some of them then update the SDD document.

Attached is the template ... its a bit intense ... should be more relaxed and readable when we get going.

[moodz]

So here is a "Milestone" release with some very trivial initial information. Feel free to comment.

[KingJL]

So here is a "Milestone" release with some very trivial initial information. Feel free to comment.

You may want to include the STM32F429IDISCOVERY (STM32F429I-DISC1 ... replaced the STM32F429I-DISC0)...

The STM32F429I-DISC0 is the board featured in original the I2PHD ARMRADIO article.

I have the STM32F429I-DISC1 and the STM32F746-DISC0 arriving early next week.

[ivconic]

As always, here I am to spoil the story a little!
I don't like projects like this from the start.
Because it's all the support that makes it easy to work on the project; mostly focused on the chosen platform.
Ok, everyone will rush in without a second thought because everyone has portability as an advantage first in mind.
Portability ... my a.$!
I went through the github descriptions in detail. Moving from one Nucleo platform to another; brings with it a whole bag of problems.
Starting with the most banal ones, such as pins that are "extracted" on one platform and not on another platform.
Either you have to review the existing library and do a lot of "surgery" on it... or pray to God that someone has already done it and checked it in practice...
or sit down and in a couple of weeks (optimistically) write a new library.
And to the more banal problems of choosing an LCD display, whether it can be obtained, whether there is a library for it and for that platform, etc.
The same problem applies to all similar peripherals.
"Lightness", "portability", "compatibility", have another side of the coin...
I haven't talked too much about these topics, but I've been doing this kind of thing intensively for a little less than 10 years.
Everything I write about I experienced in practice.
The project only succeeds if everything is rewritten for the chosen platform.
And that's a lot of work.
With Arduino is an exception, the job is very easy, because it has already formed a huge (probably the largest) support base in the world.
Someone has already done all the surrounding trivial work and you don't have to think about it. You just focus on the essence of the work.
For this to work; and we have only two examples that someone has already done this regarding the SDR issue; it is necessary to have identical conditions and identical material.
In this case we would all have to start with the same development platform.
And if you look at "VS" below; the first thing that "stings the eyes" is the consumption of the chosen platform.
As well as the price and ease of purchase.
Coincidentally, I have two ST Nucleo L496ZG-144. That's why I made a short comparison.
And again I'm tempted to repeat here the content of at least a dozen of my posts in the AMX thread.
Of course I won't. Whoever is interested should go there and read.
Exactly the same objections and remarks.
And this is all I had to say on the subject.
I will continue to follow the development of the situation here with lukewarm interest.
Sometimes I wonder; do the proponents of such ideas perhaps have some secret financial connections with the producers of the mentioned platforms?



STM32F746-Nucleo VS ST Nucleo L496ZG

STM32F746 32-bit ARM Cortex-M7 clock speed of up to 216 MHz.
STM32L496ZG 32-bit ARM Cortex-M4 clock speed of up to 180 MHz.

STM32F746NG 2 MB of flash memory and 128 KB of RAM.
STM32L496ZG 512 KB of flash memory and 192 KB of RAM.

Both boards have a variety of peripherals, including:
-GPIO
-UART
-I2C
-SPI
-CAN
-PWM
-ADC
-DAC
-RTC
-USB

STM32F746-Nucleo has additional peripherals that are not available on the ST Nucleo L496ZG, including:
-Ethernet
-QSPI
-SDIO
-FSMC
-USB OTG FS

Power consumption:

STM32F746-Nucleo's power consumption:
Run mode: In run mode with the processor clocked at 216 MHz and all peripherals enabled, the board can consume around 200 mA.
Stop mode: In stop mode, with the processor clock stopped and most peripherals disabled, the board can consume around 5 µA.
Standby mode: In standby mode, with the processor clock stopped but some peripherals enabled, the board can consume around 1 mA.

ST Nucleo L496ZG power consumption:
Run mode: At its highest clock speed of 180 MHz with all peripherals enabled, the typical current consumption is around 50 mA to 70 mA.
Stop mode: In stop mode, with the processor clock stopped and most peripherals disabled, the board can consume around 5 µA.
Standby mode: In standby mode, with the processor clock stopped but some peripherals enabled, the board can consume around between 1 µA and 10 µA.

[ivconic]

Under ideal conditions, here's how the whole project would go...
The final goal is therefore a metal detector.
You choose a development platform.
You provide all the peripherals that are needed.
You provide all the software support needed for the project (libs at first place).
You sit and work on a project.
The problem with detectors is that the quality of work and the functions of the detector mostly rely on the "external sensor", in this case it is the coil.
So we work in the EM field domain.
This kind of work on the development platform requires a lot of attention to the various present "disturbances" that will happen around the "sensor" during development.
Wired development platform with various DIY accessories... wires everywhere... protoboards, breadboards... noises, interference... assumptions that "this is because of this... that is because of that..."
A metal detector is too delicate a project for that kind of work.
Even worse when we introduce ADC sampling into the story... 30% of the samples will be immediately ready for the trash can, due to such working conditions.
Anyone writing code or pieces of code will have a unique situation specific only to the current conditions in which he is working.
In the DIY world, that usually doesn't have a bright fate and doesn't end well.
That is why I have mentioned several times that I prefer to leave such jobs to professionals. Because professionals do not work in DIY conditions.
The idea is to get the job done with as few trivial obstacles and hassles as possible and that most of the work deals only with solutions to the idea.
That's why I always choose development platforms that have great support.
In this case, the choice is very small.
Nucleo platforms really offer a lot. But support for them is still in its infancy. Open source support, of course.
That's why I advocated an analog approach on the "Competition" thread.
Possibly with the addition of "digital" only in a dose that will not bring with it a bunch of the mentioned problems.
This is not just about "entropy", but about reality. Real problems exist when trying to do a "professional" job with a DIY approach.

[ivconic]

Ok, everything I've written here so far has been "counter-constructive".
It would be fair to write something constructive now.
Instead of choosing between different development platforms, which already exist on the market...
Why don't we design a special development platform for metal detector ideas ourselves?
A universal platform, possibly modular, on which various ideas around metal detectors can be developed.
We can leave the manufacturing of that platform to services such as JLPcb.
What is the advantage?
Everything is already on one pcb.
The essential part of the digital part of the detector is therefore on one PCB.
JLPcb did the assembly for us, flawlessly.
On that pcb there should be a processor, with derived ports for communication with the outside world.
All the voltage regulators that are needed. All hardware filters that are required.
And several variants of ports for writing code into the processor.
It wouldn't be bad if there was a standard USB with or without the addition of an integral circuit for conversion and communication
(it will first of all depend on the selected processor, because some already have that in them)
We design the pcb ourselves, all of us together, everyone contributes with their knowledge and suggestions.
Let's leave only the possibility for 3 more additional modules on a separate pcbs (it is not necessary that all 3 are mandatory in every project that will be done on such a platform).
RX (with or without dedicated ADC circuit), TX (with or without special drivers) and audio driver and output.
On the main pcb, there should be array pins for LCD and keyboard.
And in the end what do we have?
We have a main pcb which is specially adapted for metal detector.
And an addition of 3 small pcbs that are attached to the main one with the help of an array pin connector.
LCD, OLED, TFT, more or less we have them all with derived standard ports.
I2C is preferred. Because it is the most widespread. And the speed is sufficient for data as needed for a typical metal detector display.
SPI is the next one that gets the job done around the display equally well and easily, with the advantage that it's faster.
Parallel connections, special purpose ports... this should be avoided because it will reduce the choice of displays and also affect the cost of materials.
And when we finally have "on paper" everything is finished. We submit gerbers to JLPcb.
In the end the result is; We ALL have the same development platform specially designed for metal detector projects.

[ivconic]

If this is accepted; I could add more arguments and suggestions.
When I plan such work, so JLPcb to do a full assembly for me; the first reference I use is their personal database of components and materials. They are the best in the world!
Here is the link: https://jlcpcb.com/parts
Ok, let's see how it goes in practice...
So let's say we chose the STM32F103C8T6 processor (not coincidentally, it's everywhere, even on the "blue pill", the open source support for it is HUGE and the Arduino IDE has support for it).
... Let's see if it is in the JLPcb database and what is the price.
Yuppie! It is available and the price is $1.4!
By JLCPCB Part C8734. Package is LQFP-48_7x7.
We have chosen the "heart" of the system and now we repeat the same with hierarchically lower components.
Once we were sure JLPcb had them in stock, listed all their unique JLPcb serial numbers (important later); now we have a complete BOM for our project.
We draw the pcb. In the description of each component, we add the JLPcb id number (later important for BOM and CPL documents, picknplace documents)
We send everything to JLPcb, they fabricate it and send us the finished "modules" within 10-15 days.
And then only the essential and "smart" part of the work on the project starts.
...
Specifically, the STM32F746 chip is selected here, let's see its situation!
JLPcb has it in two variants:
1) STM32F746NGH6... package TFBGA-216! Problem! Much harder to draw two layer pcb for it, the price is $12.3
2) STM32F746BGT6... package LQFP-208 /28x28/ Not problem! Easier to draw two layer pcb for it, the price is $29

Take the STM32F746BGT6 and draw a pcb for it. Add everything mentioned, voltage regulators, hardware filters, ports with array pins...
The design of the pcb can be customized in advance for a device such as a metal detector.
We send everything to JLPcb, they fabricate it and send us the finished "modules" within 10-15 days.
And then only the essential and "smart" part of the work on the project starts.
Why 2-layer pcb and not multi-layer?
Because this is still a hobby DIY project. It is much easier to draw and work with 2-layer pcb.

[Carl-NC]

Ivica, I suggest you take your 4 posts above and start a new project of your own. Then you get to define what the project is, and how it is run. I will gladly participate.

[ivconic]

I might do that as well.
Maybe my choice of the "platform" you will not like though.

[Carl-NC]

It doesn't matter, it would be your project, not mine.

[moodz]

I think you are describing a bottom up design Ivica. You are the guy who comes to the design meeting in solution mode. This would be where the hardware fine details and parts are selected before we get to the schematic then from the schematic create a block diagram and then to the finished detector user manual. This is a valid approach but not always good when you dont have all the problems to be solved.

Whereas I would approach in top down methodology with a description of the required functionality ( proposed features ) then move to a block diagram of the required functionality. Going then to a design of each block with prototyping. Then selecting appropriate parts to deliver each block. Then drawing schematic. Then PCBs housings etc. Construction. etc. This is also a valid approach but not always good where you might spend time reinventing the wheel.

However with the VLF IB detector there may be ( there are ) more inovations to be discovered ( ie not reinventing the wheel ) So in part new things will come and we must start at the top to describe these new things as starting at the bottom might lock us into a pathways that only deliver what we know already and cant deliver the new ideas.
For instance choosing the ARMRADIO base code saves alot of work and we know it works on the ARM. ( It can be ported to other MCUs no problem ) .. so we avoid reinventing the wheel here. ( and is has some nice algorithms )

No one AFAIK has a vested interest in using the discovery boards ... they are mainly convenient because they save some time / are reasonably priced / have some sort of toolchain and they are in production and available. I would not say that the STM32 developement environment is totally without risk ( I find that what works ... works really well and anything that doesnt is quite hard to find out how to do it as the platform is complex and the support code is incompatible across releases without alot of headbanging.)

Finally once the code works on a the development platform with support modules THEN we map the key elements into a custom design and board if necessary.

I have on my workbench a few products based on STM32 disco boards. eg MINI1300 network analyzer. HACKRF portapack. They are both very competent instruments / selfcontained and the integration would put most MD hardware designs to shame. ( and they run for hours off single internal 3.7 lithium cell )


moodz

[ivconic]

I asked Carl to remove those 4 posts as they are clearly out of place.
And it is because of my poor understanding of your idea.
I am sorry for that. Will not be repeated.