Android Phone Based Metal Detector - FCMD

[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 )

[Aziz]

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

[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.

[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.

[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.

[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]

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.

[moodz]

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

[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]

The big challenge for my work is to cancel conductive ground ( like salt ) AND ferrite simultaneously ....

Here is a video of the results ...

https://youtu.be/CxXo76ON9_Y

[moodz]

...I agree. If I am a bit more charitable .. VDI does have its use cases. If you are searching a well searched place like a beach then you are only interested in the stuff that was dropped in the last day or so, the good targets will all be nearer the surface ( ie close to the coil ) and you will have good VDI readings.
However my research at the moment is concentrated on deep targets and cancelling the ground / salt. I also want to eliminate all the tiny nuisance targets like lead shot and slivers of rust from decayed cans and wire. Although lead shot is similiar to small gold.

[Carl-NC]

4. Notch out things we dont want like rusty iron, foils, hotrocks etc ( ability to do task 1,2 and 3 ) without chasing crap.

Rusty iron can easily mask a good target, and I've dug small jewelry that ID'd as foil. So if you want to eliminate the possibility of missing a good target, you use AM mode and dig absolutely every signal. But -- depending on the amount of trash, the hardness of the ground, or the time available to hunt -- this may not be practical. Maybe today you want to cherry-pick silver coins, in which case discrimination and VDI become useful tools. There is no "absolutely right," it depends on the situation.

[JoyJo]

That's all: homemade detectors have such a procedure: ferrite calibration. With the help of this calibration, the phase parameters of the detector are brought to the desired state: the vdi scale is calibrated. To do this, you should always have a piece of ferrite with you. It's not convenient. The whole question is to make this calibration automatic, without human and ferrite participation.

[JoyJo]

I am not sure why VDI should be the focus.
The priority in detection tasks is as follows :

1. Target sensitivity ( ability to detect targets small and big, deep and shallow )
2. Ground balance / removal ( ability to do task 1 with minimal ground effect )
3. Salt balance ( ability to do task 1 and 2 ) in salty conditions not just at the beach but where soils are conductive
4. Notch out things we dont want like rusty iron, foils, hotrocks etc ( ability to do task 1,2 and 3 ) without chasing crap.
5. If you can do tasks 1 - 4 ... you dont need VDI because there is only good targets left.

Pro searchers do task 1 to 4 as a combination of experience and learning their machine really well.
VDI is like a slot machine the pro searcher looks at the target after they have dug it up and says to themselves "waddya know ... the VDI said this gold sovreign was a ring pull ... LOL"

anyway the bottom line is that in engineering a good detector .. VDI accuracy is way down the list in priority from an engineering viewpoint.

You are absolutely right. Vdi is not of priority importance. But if, from possible factors, it can go beyond 0-180 degrees (or some types of targets will go beyond the scale), then they simply will not be voiced. And they won't be found.

[moodz]

... here is a short clip demonstrating Instant Ground Balance which seems like it might be a good thing.

https://youtu.be/pzm3iB40Adc

...and here is the salt response https://youtu.be/4JJUaO6ZHIk?si=HmHHzrQfoB62_ZM5