Tweet
Originally posted by moodz
View Post
-
I agree, from the info this thread has produced I would be 100% confident in repairing a MXT or a GMT. Wish I still had that GMT that died, I could now resurrect it...sigh...I got rid of it over 10 years ago...sigh... -
Well there has recently been an amazing series of developments on this project!
Regarding the copyright discussions - and just to make the point - I didn't intend this project to copy the original MXT firmware or hardware verbatim - but to understand it well enough to be the springboard to build a MXT like detector that functions as well as the MXT, and similar to the MXT, as a prototype base platform detector, then (and only then) when fully functional - to:
Mod the hell out of it and make it our own! (I have specific mods in mind, as I know you all do also, but will not even mention them for now - as they will come AFTER a fully functional base is running). Worth sayng again - first and obviously difficult goal - is to get a closely MXT like detector working in the field...
The reason for being so focused on the original MXT firmware is because it does a number of things very well and very efficiently:
1) Ground tracking - truly superb ground tracking - I live in an area of Arizona that has iron ground problems that rival the Aussie's bad ground - there is a nearby hill with so much iron that a magnet will stick to it - and it's not even iron ore...so for me the MXT handles the extreme bad ground that I have to deal with very very well.
2) The ability to modify and optimize the ground tracking and target response algorithms based on the VSat and Gain controls and their "hyper" modes - note - this is something the AI models will need to include in their analysis and modeling.
3) The Iron Grunt audio (in Prospecting mode) is (in my experience) very accurate at identifying iron targets - separate from the super hot iron ground - and separate from low conductivity targets. This is not discrimination, a target signal is still produced and one has the choice to dig the target if desired (vs discrimination where no target response is present). This is for me a must have fully functional feature as I hunt areas littered with iron trash (not relics).
4) What is called in Jeff Foster's book on the MXT - Threshold Silencing Resistance - the ability of the MXT (and GMT) to detect a small gold nugget even when very close to a "cold rock". On many detectors a "cold rock" will cause a suppression of a very close (in proximity) target response, but not on the GMT, MXT, or for that matter the Tesoro Lobo SuperTRAQ.
5) Displaying very useful and accurate relative ground mineralization numbers.
6) Calc'ing and displaying highly accurate and useful VDI numbers - with - percent of confidence - in the calc'd VDI number.
These are all absolutely inherent in a detector with the unique abilities and features of the MXT and will be in the mix of determining the success - in the field - of this project's base prototype.
I can't think of another detector that works like the MXT/GMT and the clues are in the firmware. Understanding how the MXT firmware works will be the springboard for code that works in a similar way in the STM32...
This is obvious but - when analyzing the firmware - in the HEX file (and disassembly) - there is no distinction between what would have been the included libraries and the actual source code written. That of course makes the disassembled code much more difficult to analyze, understand, compartmentalize. You guys (and AI) have done a superb job so far of breaking down the code into functions. Perhaps it would be useful to try to identify what code would actually be part of a standard library, separate it out, and then be left with the code that would have been actual source code (assembly of course) to focus on. No point in trying to understand the library files, their function is obvious. If it would help I do have all the library files (via MPLab) that would have been linked in the original assembly code. I don't know which specific library files were linked in the source code but if someone has ideas on which ones or wants any library files I can supply them.Last edited by KRinAZ; 06-01-2026, 07:28 AM.Comment
-
By the way, this is the original HEX file, don't remember if it was uploaded elsewhere in these posts...Comment
-
Honestly, having fully reconstructed and analyzed the firmware, I can clearly see the limitations imposed by the old hardware platform. There is really no point in trying to reuse everything exactly as it is.
Modern microcontrollers with hardware DSP (like the STM32 G or H series) offer completely new possibilities that simply didn't exist back then. Looking at the original code today, it should be treated more as a fascinating engineering curiosity. The original algorithms are definitely very clever, but many of them are just highly optimized workarounds for a slow CPU.
Instead of forcing a 1:1 port, the real value lies in understanding those clever concepts and implementing them from scratch using modern DSP capabilities. If a private thread is created to discuss this kind of modern approach using the original logic purely as an inspiration/ I’d be happy to share my insights from the semantic code.
Comment
-
Hello KRinAZ
Thanks for the HEX file.
I've been following the topic since the beginning.
This is the first time I've seen this file.
Comment
-
To be frank, if we want to turn this into a real collaborative effort, it requires setting up a dedicated repository where the MXT firmware can serve as a sensible reference for analysis and learning. But how do you actually envision that happening in this environment?
How much useless effort must we waste trying to translate every detail into obscure pseudocode, just because some couch lawyer will inevitably pop up to threaten us with legal consequences and accuse us of creating 'derivative works'? You simply cannot work effectively under that kind of constant paranoia.
On one hand, isn't a forum like this meant for learning and sharing knowledge? We are all adults here. We know the MXT was and still is an incredibly fascinating project. It is absolutely worth digging under its hood, if only out of sheer appreciation for its design.
For me, it is also about sentiment. The work and genius of the late Dave Johnson have always captivated my attention. Maybe it is time to rise above these endless, petty legal debates and honor his memory with a joint, open-source project? He was a true pioneer of our hobby, and I'm sure he would have wanted us to build upon his pathways and push the technology forward.
What do you all think?
Comment
-
What I think is there's no need for backhand insults ... in engineering there's risk analysis and there are opinions some people differ so be it.Comment
-
If you had actually understood the MXT software, you would know that there is absolutely no point in porting it to a new platform. Everything in it is highly optimized specifically for an 8-bit PIC microcontroller, because back then, there simply was no other choice.Originally posted by moodz View Post
And everything in that code can be done much better now something that was structurally impossible in the '90s.
You simply got way ahead of yourself with these legal accusations and never paused to think that someone might actually dig in and realize there is no 'magic' in this software. But instead, you chose to make this whole rant. The reality is, everything in the MXT code is up for improvement today.
Comment
-
My 2 cents for what it's worth -
I don't see a copyright problem with code inspired by other code - the tech world is filled to bursting with it, it is the basis of AI LLM's, right?
So again, the mission is to first create a very MXT like detector using as much as possible the existing electronics, only replacing electronic components where necessary - yes it is old technology, but it (the MXT) works better than a lot of what is "current technology", right? Isn't that why the interest in the MXT?
IMO we have to get the base "very MXT like" project working first, proven in the field, then we can mod it right up to current technology, testing each small mod along the way to verify functionality is maintained and/or enhanced. Then I'm sure the more ambitious mods will take many branches...
But if we make something that isn't the "very MXT like" base - and it does not perform - was it the mod or just that we don't have a working base yet?
And if we shift to make something utilizing modern technology - and setting aside the tech in the MXT (old as it is) - what we are doing really is just designing a new detector. That is not what this particular thread is all about.
Why is that not what this thread is all about? - because what it is about is making modern improvements to the MXT as outlined in Post #1, and heeding Carl's suggestion in Post #2.Comment
-
-
More BHI ....just to set the record straight. . YOU are the one who was reverse engineering the code and porting it not me. Get your facts straightOriginally posted by Taktyk View Post
that's my last word ...
Comment
-
So, from my little corner in Dante's hell (right moodz?
) here's what I think - going forward:
I know everyone really wants to not use a PIC micro, myself included (but only just), but there is one argument to be made for initially deploying a PIC16F76 - and that is because C code for the PIC16F is the closest / easier to produce C code (inspired by our disassembled code) that could be compiled and run in a MXT board - again I said initially, to test and verify we have good tested C code. If C code were produced that would compile and run in a MXT just as the original - then we would have a fully functional code base, tested, and ready to port to a STM32. My understanding is we currently do not have that yet.
The code is obviously both; where most of the operational magic is, and hard to produce even with the aid of AI. From where we are now - it seems to me to be easier to create code for a PIC16F than for the STM32 - as currently we have no way to test the code for a STM32 in actual hardware. Then as soon as that (C code for PIC16F) is accomplished the focus moves to; adapting the code base to run in the STM32, and producing the STM32 based version of a MXT board.
I have a number of things going on currently, so maybe I'm not moving so fast - but still I am currently chipping away at; producing a schematic of a STM32 based version of the MXT schematic, and understanding the specific differences between PIC16C and PIC16F in order to modify the disassembled PIC16C code to run in a PIC16F.
So what I propose as next steps:
1) Produce functional equivalent C code to compile and run - in a PIC16F76 - on a MXT board.
2) Test said code in MXT board and work out any bugs
3) Produce a STM32 centered schematic and pcb of the MXT
4) Have tons of eyes on said schematic and pcb to spot any flaws
5) Send the consensus approved gerber off to produce several pcb's
6) Port the PIC16F C code to the STM32
6) Have several folks run our pcb with our code in actual (modified for our use, more on that soon) MXT bodies and field test
7) Debug as needed
And enough with the copyright stuff, personally I don't give a hoot...let's move forward...onward thru the fog...
Thoughts? Disagreements? Agreements?Comment
-
Analysis of Selected White's MXT Firmware Subsystems
Based on Reverse-Engineered Pseudocode
Part 1: Digital Filtering Architecture
Introduction
The White's MXT is one of the most influential VLF metal detectors ever produced. Despite its age, the detector earned a reputation for excellent ground handling, stable target identification, and reliable performance in highly mineralized soils.
While much has been written about the MXT from a user perspective, relatively little information exists regarding its internal digital signal-processing architecture. This article presents a technical analysis of the MXT filtering system based on reverse-engineered pseudocode derived from the original firmware.
The objective of this study is not to reproduce the original firmware, but rather to understand the design decisions behind its digital signal-processing chain and identify which concepts remain relevant for modern detector designs.
Historical Context
The MXT was designed around a Microchip PIC16-series microcontroller. At the time of its development, processing power, memory capacity, and arithmetic capabilities were severely limited compared to modern embedded systems.
As a result, the MXT firmware was engineered around several constraints:- Minimal RAM usage.
- Minimal program memory consumption.
- No hardware DSP engine.
- No multiply-accumulate unit.
- Predominantly fixed-point arithmetic.
- Preference for shift operations instead of multiplications.
These constraints strongly influenced the architecture of the digital filtering system.
Overview of the Signal Processing Chain
Analysis of the firmware reveals the following high-level processing structure:
X/Y Demodulated Channels
↓
Baseline Tracking
↓
Delta Extraction
↓
EMA Filter Stage 1
↓
EMA Filter Stage 2
↓
Phase Filter Pair
↓
Edge Detection
↓
Ground Tracking
↓
Audio / VDI Processing
An important observation is that the MXT does not perform ground compensation immediately after demodulation. Instead, several filtering stages are applied before the Ground Tracking subsystem becomes involved.
This differs from many modern architectures, where ground subtraction is often performed near the beginning of the processing chain.
Baseline Tracking
The first stage maintains a slowly changing reference signal, referred to here as the baseline.
Its purpose is not target detection but long-term signal stabilization.
The implementation resembles a simple first-order recursive filter:
baseline ← baseline + α(x − baseline)
where α is implemented using power-of-two scaling rather than explicit multiplication.
The resulting baseline follows slow environmental changes while rejecting short-duration target responses.
Conceptually, this stage acts as a long-term reference model for subsequent processing.
Delta Extraction
Once the baseline has been established, the firmware computes the difference between the current signal and the baseline estimate.
delta = signal − baseline
This operation removes a significant portion of the slowly varying background component and emphasizes transient responses generated by metallic targets.
The resulting delta signal forms the input to the next filtering stages.
Cascaded EMA Filtering
The most notable characteristic of the MXT filtering architecture is the extensive use of cascaded exponential moving average (EMA) filters.
A typical stage is implemented as:
state ← state + (input − state)/8
which corresponds to:
α = 1/8
in a conventional EMA representation.
Several such stages appear sequentially throughout the signal path.
From a modern DSP perspective this may appear simplistic, but within the constraints of the original hardware it provided several advantages:- No multiplication required.
- Minimal memory usage.
- Numerical stability.
- Predictable execution time.
The cost of this approach is increased signal latency and longer impulse responses compared to more advanced filter structures.
Phase Filter Pair
One of the most interesting sections of the firmware is the phase filtering stage.
Its structure can be simplified as:
EMA1
↓
EMA2
↓
EMA1 − EMA2
The subtraction of two low-pass filtered signals effectively produces a band-pass response.
This technique is widely used in low-cost embedded systems because it provides useful frequency selectivity while requiring only additions, subtractions, and bit shifts.
Mathematically, the structure behaves similarly to a first-order high-pass filter followed by additional smoothing.
The result is a signal that emphasizes changing target responses while suppressing slow background variations.
Edge Detection
Following band-pass filtering, the firmware analyzes signal transitions rather than relying solely on signal amplitude.
The code monitors:- Sign changes.
- Zero crossings.
- Transition timing.
- Signal polarity.
These events are converted into internal flags that are later consumed by higher-level subsystems.
This indicates that the MXT relies not only on signal magnitude but also on temporal characteristics of the filtered response.
Design Philosophy
The filtering architecture demonstrates a clear design philosophy.
Rather than implementing mathematically sophisticated filters, the designers chose a sequence of computationally inexpensive building blocks:- First-order recursive filters.
- Difference operations.
- State capture mechanisms.
- Event-based decision logic.
The complexity of the detector does not arise from any individual filter but from the interaction between multiple simple stages.
This approach was particularly well suited to the hardware limitations of the period.
Engineering Assessment
From a contemporary perspective, the MXT filtering architecture appears conservative.
Modern microcontrollers can easily support:- FIR filters.
- Higher-order IIR filters.
- Biquad sections.
- Adaptive filtering.
- Floating-point processing.
Consequently, many of the original MXT filter stages could be replaced by more efficient or more selective DSP structures.
However, such a conclusion would miss an important point.
The MXT was not designed to maximize theoretical DSP performance. It was designed to achieve reliable detector behavior within extremely limited computational resources.
Viewed from that perspective, the architecture is remarkably efficient.
Conclusions
The analysis reveals that the MXT digital filtering system is built almost entirely from cascaded first-order EMA filters and simple difference operations.
No advanced DSP structures are present. Instead, the firmware relies on carefully tuned recursive filters implemented using fixed-point arithmetic and bit-shift operations.
The filtering stages themselves are relatively straightforward and primarily serve to prepare signals for later processing.
The true sophistication of the MXT appears to lie elsewhere—particularly within the Ground Tracking subsystem, which will be examined in the next article of this series.
Next Article
Part 2: Ground Tracking Architecture
The next article will investigate how the MXT models ground conditions, captures baseline information, performs extrapolation, and maintains stable operation in changing soil environments.
Comment
-
Analysis of Selected White's MXT Firmware Subsystems
Based on Reverse-Engineered Pseudocode
Part 2: Ground Tracking Architecture
Introduction
In the previous article, we examined the digital filtering architecture of the White's MXT and found that the signal-processing chain is built primarily from cascaded first-order EMA filters and simple difference operations.
While those filtering stages are important, they are not what made the MXT famous among detector users.
The detector's reputation was largely built on its ability to maintain stable operation in difficult ground conditions while preserving target response and identification accuracy. This capability originates from the Ground Tracking subsystem.
This article analyzes the architecture of the MXT Ground Tracking system based on reverse-engineered pseudocode and attempts to identify the design principles behind its operation.
The Ground Problem
All VLF metal detectors must solve the same fundamental problem.
The receive signal contains contributions from:
Target Response
+
Ground Response
+
Environmental Noise
In highly mineralized soils, the ground response can be significantly larger than the signal generated by a coin or relic.
A detector that simply amplifies the received signal will either become unstable or lose sensitivity.
The purpose of Ground Tracking is therefore to estimate and remove the ground component while preserving target information.
Classical Ground Balance
Many detectors implement ground compensation using a slowly adapting low-pass filter:
ground ← ground + α(signal − ground)
where the estimated ground value gradually follows long-term changes in soil conditions.
Although simple and effective, this approach presents a compromise.
If adaptation is too slow:- Ground changes are not tracked efficiently.
If adaptation is too fast:- Target signals may be incorporated into the ground estimate and effectively disappear.
This trade-off is one of the central challenges of detector design.
MXT's Different Approach
Analysis of the firmware suggests that the MXT does not rely exclusively on a continuously adapting ground estimate.
Instead, it appears to combine:- Signal observation.
- Event detection.
- State capture.
- Offset estimation.
- Predictive correction.
In other words, the system behaves more like a state-driven estimator than a simple tracking filter.
Ground Tracking Subsystem Overview
The reverse-engineered firmware reveals four particularly important functions:
capture_threshold_baseline()
capture_offset_baseline()
apply_baseline_extrapolation()
tick_ground_counter()
Together these functions form the core of the Ground Tracking system.
Rather than continuously modifying the ground estimate every sample, the firmware periodically captures and evaluates internal states before deciding how the ground model should be updated.
Baseline Capture
The first significant mechanism is baseline capture.
During specific operating conditions, the detector stores internal filter states representing the current ground environment.
Conceptually:
Current Ground State
↓
Snapshot
↓
Stored Reference
This snapshot serves as a reference point for future corrections.
Instead of relying solely on a moving average, the detector preserves historical information about previously observed ground conditions.
Threshold-Based State Capture
The function:
capture_threshold_baseline()
appears to monitor specific signal conditions and record baseline values when predefined criteria are met.
Although the exact trigger conditions require further study, the mechanism resembles event-driven sampling rather than continuous adaptation.
This design choice is important because it allows the detector to capture stable ground information without constantly reacting to transient target signals.
Offset Capture
A second mechanism stores offset information associated with the current ground estimate.
Conceptually:
Ground Estimate
↓
Offset Calculation
↓
Stored Offset
This offset acts as an additional correction term that can later be applied during ground model reconstruction.
The existence of dedicated offset storage suggests that the MXT internally separates baseline estimation from correction compensation.
Ground State Extrapolation
One of the most interesting discoveries within the firmware is the extrapolation stage.
The function:
apply_baseline_extrapolation()
combines previously stored information to generate a predicted ground value.
The operation resembles:
predicted =
snapshot
− offset
+ bias
and in some operating modes:
predicted =
snapshot
− 2 × offset
+ bias
Although the exact interpretation of each variable requires further investigation, the structure itself is significant.
This is not merely filtering.
The firmware is actively attempting to predict the expected ground state from previously captured information.
Predictive Ground Compensation
Traditional adaptive filters estimate ground conditions from recent samples.
The MXT appears to supplement this process with prediction.
Conceptually:
Past Ground State
+
Current Offset
+
Current Bias
↓
Predicted Ground State
This strategy may explain why the MXT often feels unusually stable when moving between regions of differing mineralization.
Rather than waiting for a filter to settle, the detector attempts to anticipate the required correction.
Ground Tracking State Machine
The function:
tick_ground_counter()
appears to implement a state-management system controlling the tracking process.
Responsibilities likely include:- Timing updates.
- Managing tracking intervals.
- Determining when new baselines should be captured.
- Deciding when extrapolation should occur.
- Preventing excessive correction activity.
This indicates that Ground Tracking in the MXT is governed by explicit control logic rather than a continuously running filter alone.
Why This Matters
The architecture suggests that the MXT designers recognized a key limitation of purely adaptive filtering.
A conventional tracking filter must constantly balance:
Fast Tracking
vs
Target Preservation
The MXT attempts to reduce this conflict by introducing state capture and prediction.
Rather than blindly adapting at every sample, the detector selectively updates its internal model and uses previously captured information to guide future corrections.
This approach potentially allows:- Faster adaptation to changing ground.
- Improved target preservation.
- Reduced instability.
- More consistent detector behavior.
Engineering Assessment
From an engineering perspective, the Ground Tracking subsystem is significantly more sophisticated than the filtering architecture examined in Part 1.
The filtering stages are relatively conventional and largely reflect the limitations of the original PIC microcontroller.
The Ground Tracking subsystem, however, appears to contain genuinely detector-specific design knowledge.
Several characteristics stand out:- Event-driven operation.
- Historical state storage.
- Offset management.
- Predictive extrapolation.
- State-machine control.
These features are not commonly found in simple adaptive ground-balance implementations.
Open Questions
Although the overall architecture is becoming clearer, several questions remain unanswered:- What exact conditions trigger baseline capture?
- How are offsets derived internally?
- What physical quantity does the extrapolation process represent?
- How are tracking speed and stability balanced?
- Which variables correspond directly to soil phase information?
Answering these questions will require further analysis of supporting firmware modules and variable interactions.
Conclusions
The reverse-engineered firmware suggests that the White's MXT Ground Tracking system is not merely a slowly adapting filter.
Instead, it appears to be a state-based estimation system combining baseline capture, offset storage, extrapolation, and control logic.
While the digital filters discussed in Part 1 are relatively simple, the Ground Tracking subsystem demonstrates a considerably higher level of algorithmic sophistication.
The evidence suggests that much of the MXT's reputation for stable operation in difficult soil conditions originates from this subsystem rather than from the filtering architecture itself.
Understanding the precise behavior of the tracking logic will likely provide the most valuable insight into the engineering philosophy behind the MXT design.
Next Article
Part 3: VDI and Target Classification
The next article will examine how phase information is transformed into Visual Discrimination Indicator (VDI) values and how the MXT performs target classification and discrimination.
Comment
Comment