Let's make a closely MXT like detector!

[moodz]

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.

[Taktyk]

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?

[pechkata]

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.

[Taktyk]

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.

[KRinAZ]

By the way, this is the original HEX file, don't remember if it was uploaded elsewhere in these posts...

[KRinAZ]

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.

[KRinAZ]

There has been enough posted on here to fix your detector ... ( files / schems / etc ) ... No one will get you for repairing a detector you own.

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

[Okelm]

It's true, Mxt is an outstanding detector, I'm following this thread with bated breath, unfortunately Garrett buried the best projects in the depths,White, and apart from 24k they did nothing, it's a great pity, unfortunately, Vortex is unfortunately, in terms of its structure and programming, like an unfinished project, it lacks that White Spirit, I don't know if they are so proud that they decided not to touch White's projects, I have the intuitive impression that the Vortex is to some extent a GTI 2500, and although I know it was a great detector, it lacked the accuracy that the Mxt lacks.,Anyway, best regards and thanks to everyone who has tried to improve such a great detector as Mxt

[moodz]

Now here is a python harness that exercises the firmware and you can see if its working or not.
But its real power is that the AI can "see" this interface and debug the software in a loop without me having to flash and check it manually.

Files attached below openmd cref with python harness gui ... see the readme .... Its all clean room code.

[moodz]

These changes would not infringe the patent rights of the manufacturer.

There has been enough posted on here to fix your detector ... ( files / schems / etc ). I think all the whites patents have expired but copyright has not.
The only real concern would be if someone started manufacturing MXT clones with the original or derivative firmware ... then Garrett may complain .. maybe they dont care .. maybe they do.

No one will get you for repairing a detector you own.

[pechkata]

Hello all, I've been away for a while, getting back to detecting as I have found a few remote old gold mines here in AZ with apparently untouched mine dumps :^>

So, since White's is sadly no more and the MXT no longer made, I propose a project to make a detector as close as possible to the original White's MXT - with the following few changes:
Essential
1) Highly water (rain) resistant if not waterproof
2) More ergonomic - the MXT's wide control box frequently hits my hip while in motion
3) Powered by Li Ion or Li Po batteries
4) Circuit to charge the batts
5) Bluetooth to output audio to Bluetooth earbuds
Would be nice
2) Maybe a strange option, but option to switch between, or even blend, PI and VLF, both modes with ground balance

The VLF's I have experience with are the Tesoro Lobo SuperTraq (great detector), White's GMT (fantastic but fragile from my experience), White's IDX (good detector), Garrett AT Gold (OK but didn't compare to the MXT or GMT detection), Gold Bug (also great detector). Of all these if I had to pick only one (as I actually did) - the MXT wins.

Why this project?
I'm currently using my old White's MXT to detect the dumps - IMO the MXT the best detector for this and actually IMO the most versatile VLF detector that I have used.
But, I am terrified it will die as it's predecessor - a White's GMT did after getting - not rained on, but just sprinkled on, and White's could not repair it. If my MXT were to die I would try to repair it, but without schematics, firmware, and such...
Hoping there are other MXT fans that would also like to see this project happen, thoughts?

These changes would not infringe the patent rights of the manufacturer.

[moodz]

Here is the semantic C verision of the Clean Room firmware - derived from the clean room assembly.

[moodz]

Private thread sounds good. Maybe split the firmware research/discussion from the general project.

[Carl-NC]

I dunno if Garrett read this forum ... but putting up a fully reverse engineered copy of the source code would be a copyright infringement IMHO.
Maybe Carl knows ....

Here is what I understand... It is legal to reverse-engineer code for the purpose of understanding how the code works. First Texas did this with the Quest detector to determine that they had exactly copied the T2 code. But it is probably not legal to then use that code to develop a derivative product, unless you substantially re-write the code. "Substantially" is a gray area. Publicly posting the code probably violates copyright, but this can also be gray because we are attempting (as a group) to understand how the code works. It may be easier to pass a "sniff test" if this thread were private to the few people involved.

Here is where I am at on the issue:

If you want to stay on the safe side of copyright, don't publicly post any of the exact MXT code. Post pseudo code, or just describe what is happening.

We can move this to a private thread if preferred.

If Garrett complains, the whole thread may disappear.

[boilcoil]

Maybe a new topic?