Android Phone Based Metal Detector - FCMD

[moodz]

This project was partly driven by historical discussions ( this board and others ) on the possibility of utilising the processing capability of smartphones to implement a metal detector but also partly by the advent of agentic AI and so called "vibe coding" where we give an AI its own development environment ( console, compile, execute and debug ) where the "human" only describes the project requirements in the same manner as a team lead might instruct a development team ( ie in plain language ).

So to begin with let me start at the end. Here is the instruction to the AI to generate the FCMD eBook which is about android based detectors :

"I want a book on the subject of android based metal detectors covering this project as a foundation example but also introducing the basic concepts for uninformed readers upto
complex topics for expert readers. The ebook would have a title, table of contents / index, chapters and references / bibliography."

...and attached is the book written in around 5 minutes.

I have not reviewed it closely and AI's are known to make mistakes .... so you guys are the proof readers.

[moodz]

All the source code is here at github.

https://github.com/haxidermist/FCMD

[moodz]

All the documentation is here :

https://haxidermist.github.io/FCMD/

[moodz]

Before anyone says it .. a consideration with this project is that the TX power is limited to the output audio power ... an audio amplifier will fix that !

[Altra]

This project was partly driven by historical discussions ( this board and others ) on the possibility of utilising the processing capability of smartphones to implement a metal detector but also partly by the advent of agentic AI and so called "vibe coding" where we give an AI its own development environment ( console, compile, execute and debug ) where the "human" only describes the project requirements in the same manner as a team lead might instruct a development team ( ie in plain language ).

So to begin with let me start at the end. Here is the instruction to the AI to generate the FCMD eBook which is about android based detectors :

"I want a book on the subject of android based metal detectors covering this project as a foundation example but also introducing the basic concepts for uninformed readers upto
complex topics for expert readers. The ebook would have a title, table of contents / index, chapters and references / bibliography."

...and attached is the book written in around 5 minutes.

I have not reviewed it closely and AI's are known to make mistakes .... so you guys are the proof readers.

Incredible work moodz!

I have a question regarding the equations in 8.2. Is t = 1/fs ? Is this mixer basically a single bin DFT?

Thanks

[ivconic]

[ivconic]

VDI partially covers the progress bar, I probably made a mistake somewhere?
...
KUDOZ Paul! Nice work!

[moodz]

Incredible work moodz!

I have a question regarding the equations in 8.2. Is t = 1/fs ? Is this mixer basically a single bin DFT?

Thanks

I will let the "dev team" answer your question - they are more eloquent than I am :

● Great questions! Let me answer both based on section 8.2 of the ebook:

1. Is t = 1/fs?

Not exactly. In the continuous-time equations, t represents continuous time in seconds. However, in the discrete implementation, samples occur at intervals of Δt = 1/fs.

Looking at the implementation in IQDemodulator.kt:918:
private val phaseIncrement = 2.0 * PI * frequency / sampleRate

For each sample n, the time is t_n = n/fs, so the phase becomes:
phase(n) = 2π * f * (n/fs) = (2π * f / fs) * n

This is why phaseIncrement is calculated as 2π * f / fs - it's the phase change per sample, where each sample represents a time step of 1/fs.

2. Is this mixer basically a single bin DFT?

Yes, exactly! This is functionally equivalent to computing a single frequency bin of the Discrete Fourier Transform.

The DFT for frequency bin k is:
X[k] = Σ x[n] * e^(-j*2πkn/N) = Σ x[n] * (cos(2πkn/N) - j*sin(2πkn/N))

Breaking into real and imaginary parts:
- Real part: Σ x[n] * cos(2πkn/N) → This is the I component
- Imaginary part: Σ x[n] * sin(2πkn/N) → This is the Q component

The key differences from a standard DFT:

1. Filtering approach: Instead of summing over a fixed window (N samples), it uses a single-pole IIR low-pass filter (α=0.01) that acts as an exponentially-weighted moving average
2. Continuous operation: Runs sample-by-sample in real-time rather than on blocks
3. Computational efficiency: Maintains a running phase rather than recalculating trig functions

As explained in section 8.2.1, after low-pass filtering, you extract:
- Amplitude: √(I² + Q²) * 2 (the ×2 compensates for the factor of 1/2 from mixing)
- Phase: atan2(Q, I)

So yes, it's a streaming, single-bin DFT optimized for real-time metal detection!

[moodz]

VDI partially covers the progress bar, I probably made a mistake somewhere?
...
KUDOZ Paul! Nice work!

AI could stand for amplified intelligence : it takes plain language ideas and turns them into systems ... if you ask the right questions. So thanks to Claude for doing the heavy lifting in this case.

The downside of developing from the CLI is that the AI cant "see" the screen to provide feedback as it can with the code ... this ability is coming and some AIs already can do it.

Note the "progress bar" is the conductivity indicator : you didnt do anything wrong its a scaling issue for different screen resolutions. ( you have found bug no 1 )

Thanks Ivica.

[moodz]

Told the dev team to fix the overlap issue. The control panel now autohides. No need to look at it when detecting. If you touch the screen it reappears then hides again in 3 seconds if you dont change anything. Main display just shows conductivity, VDI, confidence, target icon and depth.

github source updated.

Key Features Committed:
1. Depth display - Shows depth estimate with color-coded indicators
2. Smart auto-hide controls - Panel auto-hides after 3 seconds of inactivity
3. Timeout management - Resets on user interaction, holds during GB pumping
4. Responsive design - Scales properly across all device sizes
5. UI refinements - Removed debug popups, overlay control panel, fade animations

[ivconic]

[ivconic]

Trying to port it... some functionalities are subject to add soon:

[ivconic]

Speaking of UI... you'll probably disagree Paul, but a twisted mind like me has the idea to adapt the UI to the XP Deus look!



Part of the functionality to move to ESP32 and make the coil "wireless"!
I don't know if I will succeed, there are too many obligations and too little time, the winter days are short, there is too much on my shoulders.
But... a port to Python opens up possibilities for further development and experimentation on multiple platforms.
I personally don't like Python, I consider it a bad and weak derivative of C++ language.
But it is the fastest and easiest for jobs when you don't have a lot of time.
I have a couple of older smartphones that have a CTIA (AHJ) jack and it won't be a problem to try your original code.
All that remains is to assemble the small TX drive. I have some stock coils, worth testing them.

[ivconic]

"...All that remains is to assemble the small TX drive..."

Dang!
Sleeping Beauty occupied my workspace, if I tried anything; I will get very sharp claws!



That's why I put off making the TX drive and decided to test the APK on some oldies I still have!
Never throw away old devices!
This Samsung Galaxy Tab 3 was once used by Jesus... and now by me!
I installed LineageOS to extend its life.


And it's really crazy interesting to test a new apk on a very old device.
And ... it WORKS!

My congratulations to the author!
This is immediate proof of excellent programming (I had no doubts)!
The next device to test is the CAT S60... but the battery is dead so I'll do that later.

[ivconic]

Because of this:



I am now forced to do this: