Let's make a closely MXT like detector!

[KRinAZ]

Hi all,

I for one would like to see the STM32 family solution.
Look at the new N6 generation:
https://www.st.com/en/microcontrolle...n6-series.html

Huge horse power. Huge neural network inference horse power. Post-signal processing is possible with neural network (AI) solution.
This is sure overkill.

Choose a right one:
https://www.st.com/en/microcontrolle...rtex-mcus.html

Aziz

Exploring these links - and - there is a N6 Nucleo! The NUCLEO-N657X0-Q, in stock, a mere $58, would fit the bill of big horsepower big resources...but it's not time yet for specific micro choices...

[KRinAZ]

For prototypes you can most always find the CPU you want on some little board with 0.1 inch headers for everything. ( Alibaba :-). )
Before you choose your CPU ... one plan is to determine what the signal flow / main blocks are and how much grunt ( code wise )
is required to do the heavy lifting.

There is nothing worse than choosing your CPU and finding down the track you are missing that extra PWM, or DMA, or the interrupts wont fit into your DSP cycles.

Rule of thumb is go big or go home. If you find you oversized your CPU ... you can downsize it much more easily than upsizing it.

Nice block diagram, that could be the 60k foot view diagram for this project.

Between you and Carl and everyone haha I'll just throw a huge micro at this project - that is mostly just spinning nops - but who cares if there's no price or power penalty. Back in the day, good design required disciplined product selection without waste or excess, but back then there were very much both power and price penalties. Anyway big horsepower and resources it shall be...not ready for a specific micro selection yet though.

Will be continuing my discovery of the whole ST-M ecosystem in the background and will ocassionally bring up a specific micro or nucleo or dev kit for this project.

I think, in the background for starters, I'm going to get a cheap Nucleo F or H and setup the ST CUBE system, and redo some projects on the Nucleo - just to get used to the STM tools.

If I find there are socketable STM32s - can also see myself making a socketed nucleo board in KiCAD where I can plug in a range of STM32's and experiment.

[Carl-NC]

Look at the new N6 generation:

Unfortunately all BGA and all use external flash. Tougher for the hobby crowd.
For me:

• H7: High horsepower/graphics
• U5/C5: Medium horsepower
• L0/G0/C0: Low cost/low power

[Aziz]

Hi all,

I for one would like to see the STM32 family solution.
Look at the new N6 generation:

https://www.st.com/en/microcontrollers-microprocessors/stm32n6-series.html

Huge horse power. Huge neural network inference horse power. Post-signal processing is possible with neural network (AI) solution.
This is sure overkill.

Choose a right one:

https://www.st.com/en/microcontrollers-microprocessors/stm32-32-bit-arm-cortex-mcus.html

Aziz

[moodz]

For prototypes you can most always find the CPU you want on some little board with 0.1 inch headers for everything. ( Alibaba :-). )
Before you choose your CPU ... one plan is to determine what the signal flow / main blocks are and how much grunt ( code wise )
is required to do the heavy lifting.

There is nothing worse than choosing your CPU and finding down the track you are missing that extra PWM, or DMA, or the interrupts wont fit into your DSP cycles.

Rule of thumb is go big or go home. If you find you oversized your CPU ... you can downsize it much more easily than upsizing it.

[KRinAZ]

I've officially fallen down the ST Micro rabbit hole...blue pill, black pill boards, just discovered a whole additional section of ST Micro's web site with the WB family of Nucleo's...looking amongst them for Bluetooth audio support.

I've also found lots of articles on how to diy a STM32 PCB - is that what you folks who run bare STM's do - design your own PCB for each project? Forgive me for asking but I come from the through-hole DIP and breadboard world...have done my share of wire wrap...

[KRinAZ]

Interesting... I have several of those clone dongles but haven't used one in years.



If you are wanting to design a detector that mimics MXT performance, then using an MXT coil at the MXT frequency eliminates 2 variables when performance is falling short. Furthermore, I would duplicate the MXT's TX circuitry. Once you have firmware running that achieves performance, then you can entertain other changes like coils or frequencies. As you point out, there are still a lot of MXT/DFX/V3 coils out there, even with aftermarket vendors. A problem with the MXT coil is that the L_RX = 15.7uH which is quite high and doesn't work well beyond 15kHz. It took quite the effort to make it work on the V3 (@22.5kHz).



ST has a broad portfolio of wireless MCUs, many of them dual core with a pretty hefty main processor. You could easily put the whole metal detector on one chip. This has already been done with the ESP32 but (IMO) the STM is still the better path.



The MXT was written in assembly language and barely fit in the 16C76's 14k memory space. The MXT Pro required more memory which is why we jumped to a new chip. When you write the code in C, it will invariably take more memory than hand-optimized assembly. Probably you could fit a C-version of the MXT in 32k with little problem, but why limit yourself? Memory is now dirt cheap, and a micro with 512k-1M barely costs any more and you don't have to worry about how you write code. Also, more flash == more RAM so you can play with way-too-big arrays. Same thing with processor speed -- yes, you could get it to work at 8MHz but... why? Speed is also dirt cheap.

Although I have used PIC16/PIC18/DSPIC in the past I am pretty much exclusively using ST micros now. This was a choice we (me and a co-worker) made years ago at White's after evaluating pretty much all the leading micros at the time. STMs had clearly better timers and other peripherals were as good or better. It was a good choice as ST has largely been outrunning their competitors ever since. I've used L0, L4, G0, H7, and U5 families. Currently using the U5. Yes, the H7 has massive horsepower but if you are driving a graphics display the extra horsepower is good to have.

All that said, there is also the comfort factor to consider. That is, what micros and tools you already know well.

Great advice on the first point - I'll just focus on making a detector as MXT like as possible. I'm finding those Eclipse and compatible coils are getting more scarce. I've also read a bunch of quite bad experiences with the Detech coils, glad I don't have any. I may take a shot at a hand build of a 4x6 or 6x10 DD that meets or exceeds the Eclipse coils - if so I'll make a separate thread...that would of course be after I read the Coils section of your ITMD3 that I'm waiting on...

And...wow the world of micros has changed in a hurry - I spent the day today getting up to speed on the STM32 Families and Series within the Families, and then better understood the differences between the 9 current production Nucleos. Finally at the end of all that I searched for prices and had quite a laugh. I expected them to cost more and there to be a big price difference from lower to higher performance. I found the lowest end Nucleo was around $12 and the highest end Nucleo was...you guessed it!...around $12. So, now I see what you mean - we now get crazy amounts of processing power and peripherals and all for very little $ and it's silly to buy the low end when the high end is so cheap. And these things are far less $ than the much less capable Arduino Nano (I love the Arduinos but you gotta admit you get a lot more from any of the Nucleo's per dollar). I can see myself also just using ST Micros going forward.

So, it's quite possible I'll want to run a chip that isn't on a Nucleo - especially if I find a STM32 (or higher) with built in Bluetooth and OLED driver. How does the hobbyist implement bare micros? Is there a socketed breadbord that you can plug processors into so you don't have to solder the micro in place? Something like a Nucleo with a socket instead of a soldered micro? My SMD soldering skills aren't yet up to soldering and unsoldering micros...at least without destroying things haha...

EDIT - ok there are more than 9 current production Nucleo's, and probably STM32 Families I haven't discovered yet...

[Carl-NC]

I noticed the later versions of the STM32 software give a warning message about using cloned stlink dongles ( aka chinese ) and would not program the chip ...

Interesting... I have several of those clone dongles but haven't used one in years.

OK so now I'm going to maybe open a huge writhing can of worms in asking all interested - stick with 13.8khz TX RX (as the single frequency)? Seems to work beautifully in the MXT and I'm happy with it.

If you are wanting to design a detector that mimics MXT performance, then using an MXT coil at the MXT frequency eliminates 2 variables when performance is falling short. Furthermore, I would duplicate the MXT's TX circuitry. Once you have firmware running that achieves performance, then you can entertain other changes like coils or frequencies. As you point out, there are still a lot of MXT/DFX/V3 coils out there, even with aftermarket vendors. A problem with the MXT coil is that the L_RX = 15.7uH which is quite high and doesn't work well beyond 15kHz. It took quite the effort to make it work on the V3 (@22.5kHz).

So now to look at Bluetooth modules for the STM32...

ST has a broad portfolio of wireless MCUs, many of them dual core with a pretty hefty main processor. You could easily put the whole metal detector on one chip. This has already been done with the ESP32 but (IMO) the STM is still the better path.

A thought - if the 8 bit PIC running 8mhz was enough processor and resources to run the MXT it seems like even the slowest STM32 would be overkill - so is a H series really needed? Would the L low power / the least powerful be enough if there is one with the needed peripherals? It seems like all the STM32 variants have more flash and memory than will be needed, at least to my - still learning the STM32 lineup - mind.

The MXT was written in assembly language and barely fit in the 16C76's 14k memory space. The MXT Pro required more memory which is why we jumped to a new chip. When you write the code in C, it will invariably take more memory than hand-optimized assembly. Probably you could fit a C-version of the MXT in 32k with little problem, but why limit yourself? Memory is now dirt cheap, and a micro with 512k-1M barely costs any more and you don't have to worry about how you write code. Also, more flash == more RAM so you can play with way-too-big arrays. Same thing with processor speed -- yes, you could get it to work at 8MHz but... why? Speed is also dirt cheap.

Although I have used PIC16/PIC18/DSPIC in the past I am pretty much exclusively using ST micros now. This was a choice we (me and a co-worker) made years ago at White's after evaluating pretty much all the leading micros at the time. STMs had clearly better timers and other peripherals were as good or better. It was a good choice as ST has largely been outrunning their competitors ever since. I've used L0, L4, G0, H7, and U5 families. Currently using the U5. Yes, the H7 has massive horsepower but if you are driving a graphics display the extra horsepower is good to have.

All that said, there is also the comfort factor to consider. That is, what micros and tools you already know well.

[KRinAZ]

In post #42 I asked about search coil frequencies, now another possibly thorny question - coil types - to my knowledge most favor the DD coils over concentric on the MXT, saying better ground handling, target separation, and detection depth. The same would likely apply to this project and I propose the development and testing be done with White's Eclipse DD coils, and if anyone has other brand DD coils to test with that would be a bonus. Thoughts?

[KRinAZ]

open the attachment in a webrowser for a comparative view.

I am trying out the ESP32 on a VLF at the moment .. but that is with an external demod and ADC. If you go internal demod with a straight conversion ADC ( ext or internal ) then the STM32 wins handsdown.

Wow!, now that's a comprehensive evaluation, invaluable, thanks. So it seems clear the STM32 wins. On the RPi I was actually thinking about the newer RPi Pico WH with Bluetooth, but looking at it I don't think it has the peripheral support needed, and probably is less suited than the RPi5 in the chart.

So now to look at Bluetooth modules for the STM32...I'm thinking a hat for the Nucleo would be an easy solution, I found
1) Bluetooth Low Energy expansion board based on the BLUENRG-M2SP module for STM32 Nucleo, supports audio?
2) Maybe the same thing? STM32WBA55G-DK AND STM32WBA65I-DK with audio stream support - this appears to be just what's needed
2) Infineon WiFi+Bluetooth for Nucleo by Murata, I don't see a need for WiFi in this project though

There may be other Bluetooth solutions to consider such as I2C connected Bluetooth modules...


EDIT - I see those DK's - development kits - are $86 each, a nice solution but a Nucleo and separate Bluetooth will be much less $$$
Also it appears the STM32H based Nucleos are discontinued, the STM32F, STM32G, and STM32L based Nucleos are current production according to the STM site. I'm just beginning to get educated on the differences and a good selection for this project...

A thought - if the 8 bit PIC running 8mhz was enough processor and resources to run the MXT it seems like even the slowest STM32 would be overkill - so is a H series really needed? Would the L low power / the least powerful be enough if there is one with the needed peripherals? It seems like all the STM32 variants have more flash and memory than will be needed, at least to my - still learning the STM32 lineup - mind.

I guess I need to make a chart of the specific resources the MXT uses of the PIC, then compare to the STM32 variants resources...to be continued...

[moodz]

Thx, very good to know...& yes just this evening I read about the bootloader and the boot button and all on the Nucleo's, quite handy! ... a little like an Arduino, super easy.

I'm interested to hear thoughts on whether the ESP32 or Raspberry Pi Pico WH (the one that's just a shield/hat) could take the place of the Nucleo and be the processor...

open the attachment in a webrowser for a comparative view.

I am trying out the ESP32 on a VLF at the moment .. but that is with an external demod and ADC. If you go internal demod with a straight conversion ADC ( ext or internal ) then the STM32 wins handsdown.

[KRinAZ]

OK so now I'm going to maybe open a huge writhing can of worms in asking all interested - stick with 13.8khz TX RX (as the single frequency)? Seems to work beautifully in the MXT and I'm happy with it.

I'd also be happy with skewing the freq higher to benefit Prospecting mode, but that would no doubt be to the detriment of the Relic and C&J modes, also that would complicate the availability of commercially made coils. I know Detech has nice DD coils for 13.8khz in addition to whatever White's Eclipse coils are still out there.

But thought I'd ask. If anyone suggests a different freq pls also give the pros and cons.

[KRinAZ]

I noticed the later versions of the STM32 software give a warning message about using cloned stlink dongles ( aka chinese ) and would not program the chip ... so I used to use the stlink that comes with most stm32 demo boards like carl said.
Although alot of the stm32 chips have a factory bootloader ... you just press reset then press boot button and release reset then the boot button and it puts the chip in fw download mode ... so no programmer needed at all. Its more convenient than a programmer.

Thx, very good to know...& yes just this evening I read about the bootloader and the boot button and all on the Nucleo's, quite handy! ... a little like an Arduino, super easy.

I'm interested to hear thoughts on whether the ESP32 or Raspberry Pi Pico WH (the one that's just a shield/hat) could take the place of the Nucleo and be the processor...

[KRinAZ]

Get STM32CubeIDE for programming. Get STM32CubeMX for assigning pins and generating start-up code. Both free. Chinese clone ST-Link programmers can be found on eBay for $3. Or, buy an STM32-Nucleo board withe micro you want to use and it comes with an ST-Link programmer that also works independently. That's what I use.

The MXT runs at 13.8kHz in all modes. The GMT runs at 48kHz. Yes, you could design a system to use radically different frequencies for different modes; say, Relic = 2kHz, Coin = 13kHz, and Gold = 48kHz. But the MXT (and GMT) uses a boosted resonance transmitter (L4, C18, C20, and the TX coil) that can only run at one frequency, so you'll need to do something different.

Ok sounds good on the STM32 development platform, the STM software is the way to go then. I like the idea of the Nucleo board, didn't know they can be a programmer as well, nice.

While searching for Bluetooth solutions I came across the ESP32 and the Raspberry Pi Pico WH. They each appear to have pretty capable dual core processors. I'm wondering if they could be the microprocessor instead of just a shield for the Nucleo. I'm kinda thinking out loud here as I haven't gone over their datasheets for their I/O ports, A/D capabilities, and such. I'm thinking if they are not a suitable standalone micorprocessor then the ESP32 on a Nucleo could be a nice core to build around. Have to spend some time determining which Nucleo would be best... To me Bluetooth is important - I pretty much always detect with headphones, and am so done with the headphone cord! Actually earbuds would be far better than over ear IMO.

Thx for your input on the TX RX freqs. For now just single frequency. Once the project is mature perhaps multi-freq can be explored as a mod. As you said...start simple..

[moodz]

Get STM32CubeIDE for programming. Get STM32CubeMX for assigning pins and generating start-up code. Both free. Chinese clone ST-Link programmers can be found on eBay for $3. Or, buy an STM32-Nucleo board with the micro you want to use and it comes with an ST-Link programmer that also works independently. That's what I use.

The MXT runs at 13.8kHz in all modes. The GMT runs at 48kHz. Yes, you could design a system to use radically different frequencies for different modes; say, Relic = 2kHz, Coin = 13kHz, and Gold = 48kHz. But the MXT (and GMT) uses a boosted resonance transmitter (L4, C18, C20, and the TX coil) that can only run at one frequency, so you'll need to do something different.

I noticed the later versions of the STM32 software give a warning message about using cloned stlink dongles ( aka chinese ) and would not program the chip ... so I used to use the stlink that comes with most stm32 demo boards like carl said.
Although alot of the stm32 chips have a factory bootloader ... you just press reset then press boot button and release reset then the boot button and it puts the chip in fw download mode ... so no programmer needed at all. Its more convenient than a programmer.