Let's make a closely MXT like detector!

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

[ivconic]

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

[boilcoil]

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

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

[pito]

My e class, not impress with it.

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

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

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

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

How critical are the "fudge factors" and the non quadrature relation of the X & R sampling ( which is usually critical to success ) ?

[KRinAZ]

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

Ok you put a lot of thought into all this, lots of good points.

I haven't yet read the "Carl Moreland's 2018 Stout Standards Q&A" but will try to later this eve or tomorrow. I hear your point on promoting Plan B, the idea is fascinating, but am very concerned about how huge an undertaking that would be.

I finally printed out the schematic and started pouring over it and looking up chip datasheets, here's where I'm at so far - as a result - and at this point I want to define what the project is about and what the end goal is. I'm not looking to get all PM technical (a sigh of relief from all!) but do want to set and keep a focus, and we're figuring out what that focus will be right now, great.

Let's not get hung up on if we call it Scope or Goals or what. Let's just define what we're doing and then start digging in.

So:

After spending time on the schematic - on the Plans question - I propose a Plan C: standing by the "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" - with the exception of upgrading the PIC to a STM32, and the addition to the Power Supply of 3.3v to supply the STM32. And of course the new display and Bluetooth. The more I look at the schematic the more I see how much magic there is in the code, and how making any tiny change to the existing MXT circuits will likely quickly degrade field performance - compared to the actual MXT. Heck just re-creating the MXT PCB as-is, ourselves - if we had the actual code for a PIC - alone wouldn't be easy (to me anyway).

There is one possible problem - I believe the STM32 expects 3.3v I/O but the PIC centric design is 5v based. I think I read somewhere that there are STM32's that are 5v tolerant...so maybe not an issue? But maybe an issue. If so...we're back to...I won't say it...

Here it is - the point of project success - our PCB & code matches the actual MXT in field performance - if it doesn't perform as well in the field as the MXT it ain't done yet. Straight up and simple.

So these are to be accomplished by this project:
Create a STM32 based version of the MXT PCB that is otherwise as close to original as possible. Hard part #1
Create code that mimics the operation of the actual MXT as closely as possible. Hard, hard part #2
Add a I2C or SPI or ? connected display. Easier part #1
Add Bluetooth to the end of the audio chain. Easier part #2
Fit our parts into an existing donor MXT

On your #5 - regarding IP, my understanding is that Garrett bought all of White's including their IP. My understanding is that First Texas owns Fisher, Teknetics, and Bounty Hunter, but, not Garrett, and First Texas competes with Garrett. But I don't follow the detector world's mergers and acquisitions so maybe I'm wrong here? But you're right - we should be careful to not get into it with Garrett...

And so:

This project would build a great base as a launch point for a massive range of mods. But as a mentor from long ago told me "first we have to do the basics and do them well".
...meaning...
The above would exclude changes to the MUX, ADC, or DAC and relegate them to mods to be done post project completion. I know how much fun the mods would be, but without a functioning base...

Not of course written stone (yet), I'm responding with my thoughts and look forward to responses.

I will write a new improved version of what we're accomplishing here, later this eve or tomorrow.

[KRinAZ]

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

Non-quadrature relation of X & R sampling? Ok that is a new concept to me. On a search to find out more...

... and "Another example is the higher gain R channel -- since this is the ground-balanced targeting channel you can boost the gain and improve performance." that is another good one not obvious (to me anyway) in the schematic.

[moodz]

this could be wrong ...

[KRinAZ]

this could be wrong ...

Another good block diagram and great starting point, couple changes to make but it's way late my time - so I'll be back.
I noticed the rail splitter (for the 2.5v) in the PS - U2 - should be TLE2426 instead of TLC2426, probably just a typo.

Curious, what software (and on what OS) you use to produce those diagrams?

On Friday I will produce a list of all the active components and their availability at legit sources like Mouser or DigiKey or wherever (I don't check CN sources as I make great efforts to avoid problematic clones of chips).

[moodz]

Another good block diagram and great starting point, couple changes to make but it's way late my time - so I'll be back.
I noticed the rail splitter (for the 2.5v) in the PS - U2 - should be TLE2426 instead of TLC2426, probably just a typo.

Curious, what software (and on what OS) you use to produce those diagrams?

On Friday I will produce a list of all the active components and their availability at legit sources like Mouser or DigiKey or wherever (I don't check CN sources as I make great efforts to avoid problematic clones of chips).

I have "trained" claude code as a metal detector expert engineer ... eye popping coding performance but reading schematics or making them is still a way to go. However it can produce these block diagrams in about 30 seconds .. I just tell it to go back and check the schematic again. If someone can dump the firmware from the PIC of an MXT I will show you something else it can do
Updated block diagram below.

[Carl-NC]

How critical are the "fudge factors" and the non quadrature relation of the X & R sampling ( which is usually critical to success ) ?

Going on memory here... as I recall it was mostly the GB code that had fudge factors, with comments like "this makes it work, not sure why." The MXT (and GMT) ground tracking was the best of its day, and is still probably one of the best out there. David told me that the Lobo ST tracking (which he designed before the MXT) was much simpler and worked almost as well, but he wrote all-new code for White's to avoid disclosure violations. Conceptually ground tracking isn't difficult but the devil is in the desire to not track out targets.

Here is the section in ITMD3 on non-quadrature demodulation:

... and "Another example is the higher gain R channel -- since this is the ground-balanced targeting channel you can boost the gain and improve performance." that is another good one not obvious (to me anyway) in the schematic.

When you lower the coil to hot ground, the X channel sees a big signal but the R (or G) channel does not because they should be ground balanced. Therefore you are limited by ground as to how much gain the X channel can have, but the R channel can be boosted more. You'll see this done in designs by White's, Garrett, and Fisher, probably others. Typically the R channel has 8x the gain and then the X channel data is shifted 3 bits in code to get back to a vector circle. Or, leave the gains alone and do the phase math on a vector ellipse (harder).