Metal Detector Design Series Part II – User Interface Concept

Metal Detector Design Series Part II – User Interface Concept

In Part I – Concept and Rough Sketch, we identified some potential improvement points concerning current metal detector technology, and roughly outlined and sketched a concept for a new detector design.

Thanks to all of you that provided constructive feedback, especially those that sent detailed emails with your input.   We spent time on the phone yesterday with Chuck Finley (not real name), a retired detecting industry engineer and D365 contributor.  (He  hasn’t written an article yet – Thanks Chuck!)   Chuck had read Part I, but it took a lot of discussion before Chuck really started talking.   He gave us some great input and pointed out some key challenges.

One thing that Chuck told us:

“The most radical element of this design is the user interface and  “detector intelligence”  that you are proposing, not the use of a smart phone.  Implementing the proposed user interface is not predicated on the integration of a smartphone.   While use of a smartphone may ultimately have advantages in terms of reducing unit cost and flexibility,  the design could also be implemented by simply  upgrading an existing detector’s onboard computer and display technology to the technology standards equivalent to those found in a smartphone and other cutting edge devices.”

In other words, since we are focusing on upgrading the user interface and intelligence of a metal detector in order to address the aforementioned issues, we are over-complicating the design by focusing on the smart phone.  We can come back to that later, and look at variants of the physical design with and without the smartphone.

So let’s start with the User Interface.  What would we like the iMD to do for us?  We’ll figure that out and then work backwards on designing it to do so.

First we’ll focus on the visual display.   We’ll discuss what might be heard in the headphones later in the series.

Basic Readings

Audio aside, when I am detecting, visually I am looking at 2 things on the display:
– The readings (numbers, bars and cursors).   Maybe I’m just waiting to see a number over 25, for example.
– The depth estimation.  I’m very impressed that certain detectors can even do this at all.  The estimation generally isn’t precise, at least not until you pinpoint.  Most detectors just tell you something like Shallow 0-4″, “Medium 4-6″ or Deep >6”   and you get a better resolution when in pinpoint mode.   I’m typically  looking for medium and deep targets in most instances because that is where the old stuff is.  If I am coin shooting, for example, I might dig shallow targets that predict a penny or greater.   For deeper targets, I might dig anything that registers a nickel or greater.  My tolerance is greater because, right or not, I am equating depth with age.   (This is just an example – my tactics vary based on the nature of the site, my current disposition and other factors during a specific hunt.)

So let’s start with the good old faithful reading and depth:

iMD 1 -Reading Depth

The reading is a number on the dial gauge  in the center.  The light on the dial (blue) represents the reading from 0-100: in this case 45.   More on the lighted indicator later.    The depth is represented on a simple bar gauge to the right.   Granted nothing is very exciting or novel about that.  So let’s add something new and interesting.

The Scroll

Most detectors have the old “nail” “nickel” “gold” “bottle cap” “penny” “dime” “quarter” designations.  Either they are printed on the detector, or the numbers are firmly implanted in your memory.  On the e-Trac I’m looking for 12-36 through 12-47 for most coins.   We have too many possible targets, even the common ones, to keep up with all of them in our minds.  I can’t think of what a $20 gold piece would come up as right now without looking it up.    So let’s put a whole bunch of them on our display.  We’ll make this possible by using a scrolling control, and for fun we’ll call it “The Scroll”.  

iMD 2 - The Scroll

The items on the scroll will be defaults, but individual items can be added or removed by the detector’s user.  Perhaps they could be updated via the internet as well and have sets for different countries..    The items on the Scroll would also be modified by the computer as it learns, as we will see in Part III.


When something on that screen interests me, the next thing I am looking for is signal repeatability.    This is easy for a dime at 4 inches in clear ground, but our design must account for a variety of scenarios including deep targets and multiple targets in the ground.

In order for the computer to assist us on signal repeatability.  It requires at least two pieces of information:
– It needs to be aware that we are focusing on a specific reading, sound or combination of such;
– It needs to know which signal/s are of interest;

A Detecting Event
At this point I am going to propose the introduction of a concept that, at least for now, we’ll call an “event”.  An event is when you are detecting and stop walking to swing the detector over and around a point on the ground and focus on a signal and/or sound you heard.   An event begins when you stop to focus on something, and ends when you move on – without regard to whether you dug anything.  Let’s not confuse an event with a “target” because, as happens quite often, maybe it was nothing and you move on.  Maybe you just bumped your coil.

Types of Events
For our user interface program, we’ll need at least two types of Events:

Automatic Event:   An automatic event is one that is even obvious to the metal detector.    For example, it just caught a perfect dime number three times in a row within 4 seconds.   Exactly how the detector triggers an automatic event would be configured in the detector’s settings, and the default would require some testing. But whatever it is, an automatic event would throw the detector into “Event Mode”.

User Designated Event:  You’ve caught something of interest.  Maybe just a certain sound or flash of a number that might hint at a desirable target.  You press a button or trigger to activate an event mode.

Event Mode
Event mode is like pinpointing mode on steroids.    In event mode, the detector assumes you are paused and swinging back and forth over the same area, even if it is at different angles.

We’ll have our reading indicator turn from red, through yellow, and finally to green to designate poor to good signal repeatability.  We’ll also have the depth indicator do the same for confidence in the general depth.  On the left, the Scroll will settle on an object or range of objects with good repeatability.

iMD 3 - Event

At this point we decide whether or not to dig the target.  And that is where the iMDs capabilities really start to kick in.

(To Be Continued in Part III)

Final Thoughts
We’ve got a new user interface and a lot more targets on the screen.  The iMD design also incorporate events and target repeatability.  But that’s just part of the user interface.

In part III, we’ll discuss Detector Intelligence and continue complete the basic visual interface, focusing on how the detector will collect feedback from you at the end of an event and use this information to learn and provide recommendations to you.  We’ll also talk about the concept of Inclusion – the opposite of discrimination – and why it is critical to the iMD design concept.

Thanks for reading.

Please discuss this article below!!!  We want to hear from you.  If you like this article, please reward us by liking D365 or this article on Facebook or Twitter.   Thanks!

Photo Credits
Detecting365.  Please feel free to use, but credit and link the photo back to us.



There are 3 comments for this article
  1. Mike Ray at 9:35 pm

    I like your ideas. I also think there should be a record mode. That way when you find a interesting target, hit the record button and it records the readings you are seeing up until pinpoint. So that way if you find a piece of treasure you can go back and look at the readings your detector was giving you before you chose to dig.

  2. Stan at 8:50 pm

    There should be a cloud master data base that synchronizes with every unit that is part of the world wide network. For example. After User1 has identified the targets they dug during a hunt via user interface, they upload their targets id data to the master data base, so when user2 prepares to hunt, they first download the latest target data base from the cloud data base..

Discuss This Article