Android Phone Based Metal Detector - FCMD

[JoyJo]

I still can't understand why branded devices don't have such calibrations. The only thing is that all search coils have the same parameters and are manufactured with the same imbalances in factories and in the same technology? Only in this?

[moodz]

Added an iron ID channel for those pesky surface iron bits https://www.youtube.com/shorts/gcnKkPmBtng

[Carl-NC]

I still can't understand why branded devices don't have such calibrations. The only thing is that all search coils have the same parameters and are manufactured with the same imbalances in factories and in the same technology? Only in this?

Detectors are calibrated at the factory with the stock coil using a ferrite. This should make all detectors have the same VDI response. Beyond that, there are 2 sources of error that could affect the VDI.

First is temperature which changes the resistance of the TX coil (copper R is +3900ppm/°C) which alters the voltage-current phase relationship (in ITMD3, this is discussed in 8.11). One way to fix this is by placing an NTC resistor in series with the coil; this will add to the absolute phase error (easy to remove) but stabilize the temperature change. Another way is to reference the demods off the coil current instead of the coil voltage. Then resistance doesn't matter.

Second error comes from swapping coils, where an accessory coil could have a different TX phase shift than the stock coil. If you reference the demods off the coil current then this won't matter. If you reference the demods off the coil voltage then what you want to do in ensure the TX L/R time constant is within a certain specification. For a 2X bigger coil you (first order) cut the turns by sqrt(2) to maintain inductance and you increase the wire gauge by sqrt(2) to maintain resistance. But number of turns and wire gauge availability have coarse step sizes that may limit how close you can get, so some resistance padding may be needed.

What should not matter is the null imbalance of the coil. That is, if the coil null shifts over temperature or an accessory coil is nulled to a different level, that should not affect the VDI because the phase of the null should always be 0°. It will seem to affect the phase of the RX signal as seen at the preamp, but this effect is removed by the demods and motion filters.

[JoyJo]

Is it realistic to come up with an algorithm that would produce "digital ferrite calibration" based on the measurement of the current phase (dependence of the current phase on the frequency)? Or is it from the field of fantasy? Or is it possible to perform a calibration once, "remember it in the algorithm", and then make an adjustment or adjustment on the basis of the actually measured phase (in the process of operation)?

[Carl-NC]

To do it right (or at least in a useful manner) you need a way to switch in a ferrite-equivalent load inside the coil. Since ferrite is close to 0°, I can't think of a way to do that. Again, the best way to eliminate the coil phase error is to use the TX current as the phase reference. You still need to deal with other phase errors (preamp, demod clocking, ADC, etc) but they are manageable through good design practices. Then a one-time ferrite calibration should just about do it.

[moodz]

... I've added the code to enable the bluetooth serial interface and a small android app to run the detector in field tests.
The USB interface is still active but the bluetooth removes the tether.

The android app provides all the main controls SAT / FIXED, INSTA GROUND, QUICK TRAK, K adjust ( GB adjust ), Audio Volume, Target Threshold.
Theres a moving graph to show target responses / levels etc.
I will add the iron channel later .. I am still testing the code.

Now I just have to move the bluetooth module outside the electronics enclosure because it is causing low level interferance at the ADC inputs.

[moodz]

Coding is just like science fiction now ... below is a 2 minute dialogue between me and the AI to find a some low level noise in the target signal ...
This would have taken me hours to do ( if ever ) manually but 2 minutes for the AI to identify and correct in one try including flashing the hardware and testing

I asked this simple question below ...

Me : there is low level 5 hz modulation on the target signal ... could be interferance or coming from the code ?

Let me check the firmware code for anything that could cause 5Hz modulation.

Read main.c (lines 501-650)
Read main.c (lines 646-745)

Grep "integrator_reset_count" (in /Users/moodz/AI/H750SF/Core/Src/main.c)
3 lines of output
I see a potential issue. The Bluetooth status transmission at line 560 is blocking:
HAL_UART_Transmit(&huart4, bt_tx_buffer, bt_len, 10);


This blocks the DMA callback for up to 10ms every 100ms (at 10Hz), which could create timing jitter that manifests as 5Hz modulation (10Hz / 2 = 5Hz beat pattern).

Let me check if the DMA TX was previously set up but not being used:


Grep "bt_tx_busy|HAL_UART_Transmit_DMA.*huart4" (in /Users/moodz/AI/H750SF/Core/Src/main.c)
2 lines of output

Found it. The code has bt_tx_busy for DMA but is using blocking HAL_UART_Transmit instead. Let me fix this to use non-blocking DMA transmission:

Read main.c (lines 549-56
Edit main.c
Added 2 lines


Let me verify the UART4 TX DMA is configured:


Grep "hdma_uart4_tx|UART4.*TX.*DMA" (in /Users/moodz/AI/H750SF/Core/Src)
16 lines of output
Good, UART4 TX DMA is configured. Let me build and flash:

Bash Build firmware with non-blocking BT TX
IN./build.sh 2>&1

OUT===== Building H750SF Firmware =====

Compiling C sources...
stm32h7xx_hal_adc_ex.c [OK]
stm32h7xx_hal_mdma.c [OK]
stm32h7xx_hal_flash.c [OK]
stm32h7xx_hal_flash_ex.c [OK]
stm32h7xx_hal_gpio.c [OK]
stm32h7xx_hal_pwr.c [OK]
stm32h7xx_hal.c [OK]
stm32h7xx_hal_dma.c [OK]
stm32h7xx_hal_dac.c [OK]
stm32h7xx_hal_adc.c [OK]
stm32h7xx_ll_usb.c [OK]
stm32h7xx_hal_uart.c [OK]
stm32h7xx_hal_i2c.c [OK]
stm32h7xx_hal_dac_ex.c [OK]
stm32h7xx_hal_pwr_ex.c [OK]
stm32h7xx_hal_dma_ex.c [OK]
stm32h7xx_hal_cortex.c [OK]
stm32h7xx_hal_rcc.c [OK]
stm32h7xx_hal_rcc_ex.c [OK]
stm32h7xx_hal_hsem.c [OK]
stm32h7xx_hal_tim.c [OK]
stm32h7xx_hal_uart_ex.c [OK]
stm32h7xx_hal_tim_ex.c [OK]
stm32h7xx_hal_pcd_ex.c [OK]
stm32h7xx_hal_i2c_ex.c [OK]
stm32h7xx_hal_pcd.c [OK]
stm32h7xx_hal_exti.c [OK]
stm32h7xx_hal_msp.c [OK]
syscalls.c [OK]
system_stm32h7xx.c [OK]
main.c [OK]
sysmem.c [OK]
stm32h7xx_it.c [OK]
usbd_ctlreq.c [OK]
usbd_core.c [OK]
usbd_ioreq.c [OK]
usbd_cdc.c [OK]
usbd_cdc_if.c [OK]
usb_device.c [OK]
usbd_desc.c [OK]
usbd_conf.c [OK]

Compiling startup...
startup_stm32h750vbtx.s [OK]

Linking...
H750SF.elf [OK]

Generating binary...

===== Build Successful =====

text data bss dec hex filename
64168 768 12632 77568 12f00 /tmp/h750sf_build/H750SF.elf

Output files:
-rwxr-xr-x@ 1 moodz wheel 64948 Jan 23 21:09 /tmp/h750sf_build/H750SF.bin
-rwxr-xr-x@ 1 moodz wheel 114208 Jan 23 21:09 /tmp/h750sf_build/H750SF.elf
-rw-r--r--@ 1 moodz wheel 182729 Jan 23 21:09 /tmp/h750sf_build/H750SF.hex
-rw-r--r--@ 1 moodz wheel 361708 Jan 23 21:09 /tmp/h750sf_build/H750SF.map
Bash Flash firmware
IN./flash.sh 2>&1

The fix I made: Changed the Bluetooth TX from blocking HAL_UART_Transmit() with 10ms timeout to non-blocking HAL_UART_Transmit_DMA(). The blocking call was disrupting the 50Hz signal processing timing inside the DMA callback, likely causing the 5Hz beat pattern (10Hz transmit rate / 2 = 5Hz).

Bash Flash firmware
IN./flash.sh 2>&1

OUTFlashing /tmp/h750sf_build/H750SF.bin...

Software reset is performed
[39;49m[0m[39;49m[0mFlash successful!
Flashed. The Bluetooth TX is now non-blocking DMA. Test if the 5Hz modulation is gone.

Me: the audio sounds clean

The non-blocking DMA TX fixed it. The blocking UART call was disrupting the 50Hz signal processing loop, causing the 5Hz beat pattern.

[Aziz]

WTF!, I can't believe it. Maybe almost all software engineers will be fired soon. Except those doing AI. This is frightening.

[moodz]

WTF!, I can't believe it. Maybe almost all software engineers will be fired soon. Except those doing AI. This is frightening.

Anyone not using AI has already been run over by the bus which stopped, reversed and ran them over again whilst spinning the wheels. ( they just dont know it yet )

[moodz]

Here is the final performance spec for the field test unit. This pretty much agrees with the experimental results in the lab regarding sensitivity and noise.
I would expect the noise ( EMI mainly ) to be less in the field.
It also demonstrates that the 16 bit ADC is a good choice ... a 24 bit ADC does not bring significant benefit as it only shifts the noise dominance from the ADC to the frontend.
( remembering that the 16 bit ADC samples much faster than the the 24 bit ADC )

[moodz]

...not quite what I imagined on post #1 .. but here is the android phone based ( connected ) detector ready for field tests !

https://youtu.be/Q2FyQp9yhN4

[Aziz]

Hi Paul,

your final ENOB of 21 bits on a fast 16-bit ADC is quite good. It is even better than most slow 24-bit ADC's can arrive.
Well, I don't get the same level of performance on my 192 kHz/24 bit sound card. I'm limitted to relative low frequency responses, which limits the total detector sensitivity.

I'm really impressed of your KISS and cheap project. Well done!

[Aziz]

...not quite what I imagined on post #1 .. but here is the android phone based ( connected ) detector ready for field tests !

https://youtu.be/Q2FyQp9yhN4

"SF Detector"
Science-Fiction Detector?

[ivconic]

If I were the CEO and Paul my chief development engineer; This is what our daily briefing would look like:
(I hate losing my hair)

[moodz]

Here is an engineering presentation on a new detector to management.

https://www.youtube.com/shorts/L2-krroaLqQ