STM32 Based PI Detector

[Carl-NC]

When I started this project nearly 2 years ago, I was torn between the PIC32MX, STM32 and the dsPIC. The PIC parts I liked because it would be possible to use the through hole parts. Some of the dsPIC line have a Programmable Trigger Generator (PTG peripheral) that would've allow the pulse and adc triggering to be done in the background by the peripheral. In the end, I went with the STM32.

NOTE - a revision will be made on the next board. The pulse will get driven by TIM1 rather than TIM2. The selected STM32 part allows TIM1 to trigger TIM15, TIM15 has a "repeat count" and can trigger the ADC circuitry, so the entire pulse and capture can be done in hardware with very precise timing. Right now, I have to trigger the ADC capture from an interrupt - which adds some jitter to the start of sampling.

You probably made the better choice. For the same money, ST has more memory, better peripherals, and lower power consumption. I still use PICs but mostly for simple book or forum projects since I know they are more widely used and understood than ST. ST isn't perfect, I wish they would expand some capabilities like ADC trigger sources or DMA channels. It can be a challenge to get everything mapped out. I generally trigger the ADC on a timer, use DMA to stuff the results, and the DMA interrupt triggers the RTOS to tell me "dinner's ready!" All in background. Since you're doing a string of conversions, using a second counter with repeat count is a good solution.

On the open source side, I have no experience with GitHub. You would probably get more feedback on STM32 programming there, but you would probably get more feedback on the metal detector specifics here. In any case, you are welcomed to post the project here and if it gets enough participation I can create a Project-specific forum for it.

[waltr]

Yes, with so many processors available it is hard to chose one to use.
All have advantages so its a trade-off on which features are best.

I can create a Project-specific forum for it.

That sounds like the best way for the hardware and some software discussions.

[Carl-NC]

Yes, with so many processors available it is hard to chose one to use.
All have advantages so its a trade-off on which features are best.

At White's we took a comprehensive look at 32-bit micros. PIC32, STM32, Freescale Kinetis, Cypress PSOC, NXP, Renesas, and TI. We chose STM owing to its superior timers which are critical in metal detector design and their otherwise strong peripherals. As I recall, Kinetis came in a close second. This was 10-12 years ago and things have changed somewhat, but I haven't seen anything yet that looks better. BTW, the biggest seller of micros is Renesas, but that's largely because they dominate the automotive market.

[waltr]

Yep, the PIC32's MX(50MHz) & MZ(200MHz) families have come a long way in 10 years.
Been playing with the PIC32MZ-EF recently. It has MISP32 DSP instructions plus a FPU so math it fast.
9 timers (100MHz inputs) to run peripherals such as OC (pulse outputs) and ADCs plus DMA.

The MX is more than enough for a PI detector. I'm working on a multi-freq VLF detector with the MZ due to lots more math is needed.

The STMs are very good, its just I never got around to trying one.

[Altra]

Stimey-mn keep posting your progress, will be interesting to follow.

During the lock down I purchased a STM32f4 Discovery board and a WaveShare open407v-d mother board, really cheap on ebay $30 for both(slightly used). I was planning to learn these processors. But once I dug in, the stm32 are very different than the Microchip processors. The set-up for the GPIO is complicated, you need to assign timers, pull-ups etc etc. even to blink an led. I did download CubeX which takes care of the configurations. It's on the shelf right now, maybe in the winter will take another look.

@ Waltr have a look at the pic32mk series. Lots of goodies! Unfortunately my compiler does not support this family yet or ever. (mikroelektronika)

https://www.microchip.com/design-cen...p-Data%20Sheet

[stimey_mn]

My issue with the MZ lines are - the packaging is so small I'm not looking forward to building a board. Had I been a bit braver, I'd have gone down the MZ route.

To be fair, I've never had a stencil made - and I've never tried the toaster oven method of SMT building.

The 32 LPFP packages on the lower end STM32 parts is about as fine a pitch as I'd care to go. The next rev will use SMT diodes, etc, but I'm aiming for 805 resistors, etc.

That said, I've worked with the PIC32 MX series, and they were quite easy to work with. There were times working through the STM32 that I pondered if I had made the wrong choice. (I don't care to rely on pre-packaged libraries, etc, the STM parts have a LOT of registers to get set correctly for everything to work properly. Once a person gets them working - they work great, but configuring them can be a bit of a bear, and the learning curve was higher than the PIC32's.)

Yep, the PIC32's MX(50MHz) & MZ(200MHz) families have come a long way in 10 years.
Been playing with the PIC32MZ-EF recently. It has MISP32 DSP instructions plus a FPU so math it fast.
9 timers (100MHz inputs) to run peripherals such as OC (pulse outputs) and ADCs plus DMA.

The MX is more than enough for a PI detector. I'm working on a multi-freq VLF detector with the MZ due to lots more math is needed.

The STMs are very good, its just I never got around to trying one.

[waltr]

@ Waltr have a look at the pic32mk series. Lots of goodies! Unfortunately my compiler does not support this family yet or ever. (mikroelektronika)

Just downloaded the MK data sheet and Errata (Very Important to look at).
Errata may have items to cause issues but may be ok.
Yes, nice features and runs at 120MHz.

Check the MPLAB X IDE and free XC compliers (gcc based).
These do very well.

My issue with the MZ lines are - the packaging is so small I'm not looking forward to building a board.

Understand that. TQFP is pretty small pitch but I have been able to hand solder these.
I should look into getting a plastic stencil and solder paste to do reflow soldering.

The MX has a 28 pin Dip available with very close pinout to the older 28pin 16F & 18F pics.

[profesor]

P channel mosfet is very noisy. I tried. ADC resolution is important but more important is the sampling rate. "
The first attempt with a simple pic like PIC18F452 was very bad.
externally I connected an 8 bit 1Gs / s ADC. the result worked much better.

[stimey_mn]

Based on Version 1 schematic and circuit experimentation:

1) Direct coil amps monitoring is NOT sufficient for detection. The threshold of the Eddy Currents across the 0.75 (or lower) current sense resistor don't result in enough volts to be useful, and amplifying them to the point of useful requires a VERY high Gain-BW opamp.

2) I hacked the original circuit to provide a diode voltage level sensor across a resistor. Using the P-Mos allows the diode circuits to be ground referenced, greatly simplifying the opamp circuit, etc.

The attached schematic is what I'm looking to order PCB's for in the next week or so.

RIGHT NOW - my analog circuit is looking at a diode detector referenced to ground with a gain of 2. Using that circuit (and almost all the other circuitry is nearly identical to the schematic) I'm picking off my wire stripper at a distance of about 10" and my wedding ring at a distance of about 1" using a 275 mm coil.

I found the HV charge pump circuit was causing noise issues - so I silenced that (in software) around the pulse and ADC sampling times. I found I can trigger 100 ADC readings via the hardware trigger that triggers the coil pulse, so I have VERY reapeatable timing in relation of the coil pulse and ADC sampling windows. i've up'd the MCU speed to 80 MHz, so I am sampling at 5.33 MSPS on the ADC.

I build a monocoil per bbsailor's monocoil PDF. I am currently using the IRF9510 P-channel MOSFET - it has reduced the output capacitance so much that I have ringing around the MOSFET release time (the previous MOSFET did not have any ringing - but was notably VERY slow and had MUCH higher output capacitance [360 pF vs 80-ish pF on the 9510]).

I have ample ADC resolution that AFTER the saturation of the diode detectors, I get about 20 samples in the "of interest" timeframe (when we should be detecting - across the diodes - the coil discharge voltage.) I take the ADC values, adjust them so they are converging to 0, and essentially represent coil current. The ADC values are run through programming that are equivelant to running then into Excel, creating a Trendline and basing the trendline on the exponential decay. This adjusts for any timing issues and bases the results purely on the decay curve.

The ONLY issue I am having - at "idle" the results of the trendline (or programming equivelant) have "jitter" at "idle". When I put a pliers in the center of the coil, my readings are relatively rock solid. However, at idle, I'm seeing "jitter" in the neighborhood of +/- 20%. This jitter prevents me from detecting things at further range. I'm suspecting it may be environmental (there is PWM solar charger and window AC unit within 10' of my PCB.) Other than that, does anyone have any ideas on removing this "jitter".

I'm very excited to see the steadiness of the ADC readings, the steadiness of the coil, diode detectors, coil timing, HV PWM voltage generation, etc o'scope observations.

Once I have the new PCB's proved out, I'll push everything to KiCad and push out on github as open hardware/open source software.
Schematic_PI-Detector-V2_2020-07-11_23-30-47.pdf

[Taktyk]

I would add here an 18-bit SAR with SINAD >100dB. DSP processing + oversampling (16x) will achieve a resolution of 20 bits. The dynamic range will be increased to 125dB.

TAKTYK

[waltr]

The ONLY issue I am having - at "idle" the results of the trendline (or programming equivelant) have "jitter" at "idle". When I put a pliers in the center of the coil, my readings are relatively rock solid. However, at idle, I'm seeing "jitter" in the neighborhood of +/- 20%. This jitter prevents me from detecting things at further range. I'm suspecting it may be environmental (there is PWM solar charger and window AC unit within 10' of my PCB.) Other than that, does anyone have any ideas on removing this "jitter".

Not sure what this 'jitter' looks like. Can you post some pictures to show this?
Local EMI may be the cause. We all have had issues with detectors in our workshops.

Would adding multiple TX/RX cycles help?
If you are running even a 1msec TX/RX cycle then you can add 8-16 cycles and still have what feels like 'real time' response.

[stimey_mn]

Out on a weekend trip for work this weekend, I'll post scope shots and provide sampling data this evening.

The ADC readings are normalized to decay to 0. I then take the samples AFTER the diodes have stopped effecting the voltage reading and use those readings to calculate a line fit providing an exponential function in return (i.e. model the ADC readings into a formula akin to y=A*exp(B*x) - which is the formula for the voltage decay of an LR series circuit. The B component is used to determine how far from "standard" the decay is - and whether there is something of interest in the field.

The B value from one pulse to the next is where I'm seeing the jitter. If I put my wire stripper in close proximity, the B value becomes considerably more solid, it's when the field is empty that I'm getting the variations.

Not sure what this 'jitter' looks like. Can you post some pictures to show this?
Local EMI may be the cause. We all have had issues with detectors in our workshops.

Would adding multiple TX/RX cycles help?
If you are running even a 1msec TX/RX cycle then you can add 8-16 cycles and still have what feels like 'real time' response.

[waltr]

Out on a weekend trip for work this weekend, I'll post scope shots and provide sampling data this evening.

The ADC readings are normalized to decay to 0. I then take the samples AFTER the diodes have stopped effecting the voltage reading and use those readings to calculate a line fit providing an exponential function in return (i.e. model the ADC readings into a formula akin to y=A*exp(B*x) - which is the formula for the voltage decay of an LR series circuit. The B component is used to determine how far from "standard" the decay is - and whether there is something of interest in the field.

The B value from one pulse to the next is where I'm seeing the jitter. If I put my wire stripper in close proximity, the B value becomes considerably more solid, it's when the field is empty that I'm getting the variations.

Ok, now I understand.
I have done the same with a PIC32MX. Simple Ln to linear then curve fit.
I seem to remember having some jitter of the 'B' value without a target but steady with a target.

Just talking this through for ideas:
Without a target the expo decay curve is rather fast (ideally only the coil RL decay). But there are diodes, damping R, op-amp overload, etc so maybe not ideal RL decay. Also, local noise from EMI.

Looking at my notes (excel with data & graphs) and a plot of RX curves do not produce a straight line when plotted Log/Lin until sample #20, 40usec after TX off with a bunch wound coil. This coil is slightly under damped so has a slight 'over shoot' without a target. Data is the ADC values output on a UART to the PC and captured, then plotted in Excel.

Looking at captured data I see the No Target curves get quite noisy due to signal decaying to very small value. This in itself will give the Exp curve fitting procedure issues, therefore the TC value jitters. Adding multiple cycles help decrease this noise.

What does the data you use the calculate the TC look like?
If there is non-coherent EMI (AC mains, etc) getting into the coil then when coil signal is very low I would expect TC value jitter.

[Altra]

Some of you might be interested these WM8775 24bit adc 98ksps, the price is right. I picked some up, but have not tried them yet. Minelab equinox is using a similar adc the PCM1861 192ksps. They can be interfaced using spi mode "I2S", which pic32, dspic's most likley stm32 have special registers which optimize data through put.



https://www.ebay.com/itm/10PCS-Wolfs...53.m2749.l2649

Adaptor
https://www.ebay.com/itm/10Pcs-SOP28...kAAOSwHUhaLkH-

[Winston2021]

It's a real shame when such promising projects like this one appear to fade away although I've done the same with plenty of my own projects.