Android Phone Based Metal Detector - FCMD

[moodz]

I developed a metal detector development board for these STM32 boards. Here are the latest documents, I have the latest board made at home but I haven't had time to test it yet so I don't know if there are any bugs on the board.

Good work...what is your transmit scheme.

[Aziz]

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

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

This is great magic.

[ivconic]

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

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

I am developing a new business strategy that will work in the spirit: WeDontAct-WeStayPut!

[Marchel]

I developed a metal detector development board for these STM32 boards. Here are the latest documents, I have the latest board made at home but I haven't had time to test it yet so I don't know if there are any bugs on the board.

[moodz]

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!

Thanks Aziz ...

You dont have to be limited .. these boards are very cheap and all tools are free / open source.

[moodz]

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

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

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

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

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

[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

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

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.