Let's make a closely MXT like detector!

[Carl-NC]

One piece of outside evidence worth putting on the table: Carl Moreland's 2018 Stout Standards Q&A (https://stoutstandards.wordpress.com...g-first-texas/). Carl is the guy who conceived both the MXT-Pro and the MX5 at White's, and he describes the MX5 as his most valuable contribution there - specifically because it took "a high-performance but dead-end platform" (the original MXT) and moved it to a modern 32-bit MCU with C code, which became the basis for every subsequent MX product. His own framing is that the MXT's *behaviour* was the asset worth preserving, and the *platform* was the thing that needed replacing. That's a fairly strong argument for Path B coming from the person who would know best.

I should clarify that the transition from the MXT to the MX5 was initially limited to changing the micro from PIC8 to STM32, and recoding the assembly to C. To minimize the chance of losing performance no change was made to any of the analog circuitry. Even the code was a literal translation (by hand, no AI back then!), no changes to its flow or operation. Even all the fudge factors were retained. Once we matched the MXT, then we started making updates to the circuitry and code.

We have the schematic for the MXT but we don't have the code. If the goal is to match the performance of the MXT, the most logical approach is to use the same circuit and come up with the code that does the job. I've already mentioned that the resonance-boosted TX circuit should be preserved. Another example is the higher gain R channel -- since this is the ground-balanced targeting channel you can boost the gain and improve performance. Yet another is the non-quadrature relation of the X & R sampling.

All that said, it does not mean that the circuitry can't be modified if we are certain it will be as good or better. Ferinstance, using better opamps, or using a simultaneous-sampling 24b ADC. But I wouldn't stray too far.

[moodz]

I like it Paul!
Except that I don't understand the "T1"?

I will discuss with you in the FCMD thread as the schema is from that project.

[moodz]

Yes I agree completely!

Having a Project Management background I am working on a Scope paragraph that would properly kick this project off.

We've had some good discussions already, now from that here's what I'm thinking:

SCOPE
1) Keep the design and electronics as close to the White's design as possible - as a great effort had been made to optimize tradeoffs, and perfected in field testing, with great success.
2) Determine discreet circuit sections that can instead be performed by micro peripherals along with associated code (e.g. ADC, DAC, comparators) as some of the higher end STM32s MAY have ADCs and DACs and such that are as good or better than those in the original design.
3) Identify discreet circuit sections that will remain (e.g. the entire TX and RX sections) - leave them as unchanged as possible.
4) For the remaining discreet circuit sections - list all active electronic components, check for ongoing availability, for discontinued components find currently available components - that will not alter circuit operation.
5) Any additions to the original design must not alter the original circuit function - e.g. adding Bluetooth to the end of the audio chain would not change the operation or function of the original design, or, changing from LCD to a more modern and perhaps I2C or SPI connected display. Neither of these would change the core function of the detector.
6) So basically make a true MXT that is as digitized as possible - while keeping to original function and performance and displayed information - in all 3 modes (Prospecting, Relic, C&J).

We can look to Carl's and ivconic's and moodz's, et al, previous posts for the wisdom in keeping the Scope to these goals.

Once this is accomplished, other threads and projects could pursue mods and attempts at enhancements, of which I'm sure I'll want to do also.

But not in this project.

Thanks KRinAZ - good instinct to pin down a scope before this sprawls, and I agree with the spirit of points 3, 5 and 6 (protect TX/RX, allow non-functional modernization like BT audio or SPI display, preserve the three-mode behaviour in Prospecting / Relic / C&J). The closing discipline - "enhancements go in other threads, not this one" - is exactly right and probably the hardest part to actually hold.

Before we lock it in though, I think there's a fork in the road worth naming explicitly, because my v0.1 post and your scope are pulling in somewhat different directions and "Yes I agree completely!" papers over it a bit:

- **Path A - Faithful MXT clone, selectively digitized.** Preserve the original analog TX/RX, substitute STM32 peripherals only where they're demonstrably equivalent-or-better. Success = matches MXT behaviour on the bench.
- **Path B - Minimal hardware, maximum software.** Treat the MXT as a *functional* target (three modes, comparable sensitivity, comparable discrimination) and reimplement from the coil inwards using whatever modern silicon and DSP gets us there cleanest. Success = matches MXT *field performance*, not MXT *topology*.

My #61 schema was pitched as Path B. Your scope reads as Path A. Both are legitimate projects, but they lead to very different boards, very different debates on point 2, and very different answers to "is this substitution allowed?" - so worth settling up front rather than arguing case by case for the next five pages.

One piece of outside evidence worth putting on the table: Carl Moreland's 2018 Stout Standards Q&A (https://stoutstandards.wordpress.com...g-first-texas/). Carl is the guy who conceived both the MXT-Pro and the MX5 at White's, and he describes the MX5 as his most valuable contribution there - specifically because it took "a high-performance but dead-end platform" (the original MXT) and moved it to a modern 32-bit MCU with C code, which became the basis for every subsequent MX product. His own framing is that the MXT's *behaviour* was the asset worth preserving, and the *platform* was the thing that needed replacing. That's a fairly strong argument for Path B coming from the person who would know best.

A few other things I'd want to add to whichever path the group picks:

1. **Success criteria / definition of done.** Schematic? PCB? Working prototype? Bench-matched to an MXT? Field-tested? Point 6 as written ("as digitized as possible while keeping to original function and performance") isn't falsifiable, and without a finish line point 2 becomes infinite.
2. **Explicit non-goals list.** Easier to defend scope from "what this project is NOT" than from "what it is."
3. **Point 2 needs a decision rule, not a judgement call.** "Can be performed by micro peripherals" is where every scope argument is going to land. Something like: substitution allowed if (a) the peripheral meets-or-exceeds the original part's spec in the relevant dimension, (b) no change to signal-chain behaviour inside the MXT's operating envelope, (c) agreed by [whoever].
4. **Point 4 (obsolescence sweep)** is really a work item that falls out of the scope - worth pulling out so the scope doc stays about goals rather than tasks.
5. **IP / clone framing.** Worth a sentence on what "MXT-like" actually means here given First Texas still sells MX-family products. The thread title "closely MXT-like" is probably the safer frame than "true MXT."

Happy to take a shot at a v0.2 scope doc once the fork is settled - but which path we're on is the thing to decide first.

PS Do you realise there is a specially reserved spot for PMs in the deepest pit of the 7 hells. Of course there may be some engineers in there with you ( but they will be wearing environmental suits - you wont).

[KRinAZ]

...to only use the simplest / minimal but best hardware that can be easily obtained and then do everything in software.
Another thing about software is that it occupies no space and does not weigh anything.
This is version 0.1 ... I would not build off it but should give you an idea what is possible...

Yes I agree completely!

Having a Project Management background I am working on a Scope paragraph that would properly kick this project off.

We've had some good discussions already, now from that here's what I'm thinking:

SCOPE
1) Keep the design and electronics as close to the White's design as possible - as a great effort had been made to optimize tradeoffs, and perfected in field testing, with great success.
2) Determine discreet circuit sections that can instead be performed by micro peripherals along with associated code (e.g. ADC, DAC, comparators) as some of the higher end STM32s MAY have ADCs and DACs and such that are as good or better than those in the original design.
3) Identify discreet circuit sections that will remain (e.g. the entire TX and RX sections) - leave them as unchanged as possible.
4) For the remaining discreet circuit sections - list all active electronic components, check for ongoing availability, for discontinued components find currently available components - that will not alter circuit operation.
5) Any additions to the original design must not alter the original circuit function - e.g. adding Bluetooth to the end of the audio chain would not change the operation or function of the original design, or, changing from LCD to a more modern and perhaps I2C or SPI connected display. Neither of these would change the core function of the detector.
6) So basically make a true MXT that is as digitized as possible - while keeping to original function and performance and displayed information - in all 3 modes (Prospecting, Relic, C&J).

We can look to Carl's and ivconic's and moodz's, et al, previous posts for the wisdom in keeping the Scope to these goals.

Once this is accomplished, other threads and projects could pursue mods and attempts at enhancements, of which I'm sure I'll want to do also.

But not in this project.

[pito]

My e class, not impress with it.

[boilcoil]

Except that I don't understand the "T1"?

This module can implement two different operating modes:
- pure resonant mode;
- class "E" mode;

[ivconic]

I like it Paul!
Except that I don't understand the "T1"?

[moodz]

Here is my suggestion ... I have breadboarded this schema and it works as well as any.
The real win is to only use the simplest / minimal but best hardware that can be easily obtained and then do everything in software.
Another thing about software is that it occupies no space and does not weigh anything.
This is version 0.1 ... I would not build off it but should give you an idea what is possible.

Anyway here it is ...

[Hristo]

Also like to add to MXT circuit and MXT2 (makro2 circuit Technetic T2 hardware clone) for reference and compare Garrett AT Max original circuit from FCC ID: https://fccid.io/DBD the only one there who is official aviable free.

[KRinAZ]

I may do that in next few weeks. First I will need some clarifications. I will prepare some questions directly for Carl. But now I have to go on short trip.
If somebody else is willing to to that; my hat down and thanks!

I'm working on that also and going over the schematic, would prefer to work together rather than by myself so maybe we can team up when you get back? I'll have some Q's for Carl also...soon...
One note - I'm not so sure an external ADC is needed, nor more than one micro needed. More on that soon.
I think it would be wise to start simple and only add more complexity if testing proves it necessary. Some of the higher end STMs may have the resources we need internal, it's late in my time zone, more soon.

[ivconic]

I may do that in next few weeks. First I will need some clarifications. I will prepare some questions directly for Carl. But now I have to go on short trip.
If somebody else is willing to to that; my hat down and thanks!

[Hristo]

so who will redraw mxt ANALOG front end on PCB module with separate dedicated A/D chip and SPI or I3C interface to display and STM32H7 or ESP32 separate board modul construction with one Analog and other display and control board with integrated audio and who ever like other things.

[ivconic]

There is too much talk about various powerful processors (which 70% of the world cannot get easily and cheaply) and that is unnecessary.
If you looked at the schematic any more seriously; you will see that the detector does not require a powerful processor.
The processor does a very simple task in MXT. Even the Atmega328P can do the job. Not to mention ESP32. STM32 blue pill too.
And those are 3 processors that anyone on the planet can easily get.
ESP32 can do the most. ADC on ESP32 is not the best. Linearity is not the best. But it certainly may use some cheaper external ADC.
The ESP32 has an integrated DAC. I'm not advocating ESP32 here, just stating some of my personal experiences.
Instead of talking about the choice of processor; first of all, a "scenario" should be made about what will be done from MXT and in what way?
Personally, I am attracted to the analog part of the device. Although there are details that I do not fully understand on the schematic.
This seems to be another one of those threads where everyone will say what they want and eventually the thread will stagnate and disappear.

[Hristo]

Hi, you have my suport voice for STM32 H7 series: High horsepower/graphics. This is sure overkill but today we can aford it. My MXT concept is with not one microcontroler design two , tree and many chips design with ewery one with dedicated specific task to do for example this most powerful will engage only display keyboard or touch screen - capacitive input and perhaps jesture and mimic of face control example with blinc an move on the eye with dedicated stereo 3D video cam two or tri in triangle configuration and other separate die for audio and so on for everi task distributed computing network paralel processing arhitekture design. s Multiple Instruction Multiple Data (MIMD) parallel computing design.

Now serious, the MXT circuit use analog TX generator design this avoid digital jitter with Tx signal if is generated with Microcontroller and microcontroler generate phase with zero and 90 degree ofset signals for demodulator in quadrature like software radio design SDR in modern design chip without clasic demodulator with diode in radio circuits state of the art of now days. this function needs of smal pic microcontroler enough fast to do the job with phase control on demand with ground eliminating and zerro salt adjust for reactive and resistiwe components X,Y Q I and so on have many names to confuse ewery one who hope to andarstend anithing more than notning.

And for audio separate processor who is responsible of audio sound managing already says

lest but no least left most important processor in this project this is heart of MXT design is the discriminator had find chip master CPU who control all other co-processors in this multi CPU design. This may be classic ordinary old PIC Microchip and assembly codded control software with tremendius responce time ot I/O pins contrary to modern fast STM32 H7 with jitter and delay on all of them I/O pins.

[KRinAZ]

Unfortunately all BGA and all use external flash. Tougher for the hobby crowd.
For me:

• H7: High horsepower/graphics
• U5/C5: Medium horsepower
• L0/G0/C0: Low cost/low power

I have to look into the H, C, and U families and learn more about them. The H7 Family keeps coming up as a contender for this project.

And ah, but that tantalizing NUCLEO-N657X0-Q though with neural and computer vision capability. Laugh now, but imagine a detector that SEES (spectral analysis) the rock with a target ID and says to you; Nah mate that's just a hot rock, or, Hey mate I'm seeing gold there