Let's make a closely MXT like detector!

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

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

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

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

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

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?

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