Let's make a closely MXT like detector!

[KRinAZ]

I'm sure it was an 8-bit PIC, I think that's all they ever used. Don't know exactly which one and I sold my LST. No, Tesoro just shut down. Someone bought out their stock but I don't think it included IP.

Ok thx, I'm going to try to find an affordable Tesolo LST and it's PIC as well then...I'm sure that code would be useful as well...

[KRinAZ]

Pretty much. The 74HCT4053 demod switches will happily run on 3V logic. Where you might need 5V (say, the display) you can use open-collector GPIOs with 5V pull-up resistors. Most STM GPIOs are 5V tolerant.

Ok very good, works for me...

[Carl-NC]

I used to swing the Tesoro Lobo SuperTraq before the MXT, it was great detector also and I regret selling it. Happen to remember what micro it ran? Happen to know if anyone bought Tesoro's IP?

I'm sure it was an 8-bit PIC, I think that's all they ever used. Don't know exactly which one and I sold my LST. No, Tesoro just shut down. Someone bought out their stock but I don't think it included IP.

[Carl-NC]

I get the feeling I'm the only one fretting over logic levels in the switch from PIC to STM32 - (5v logic to 3.3v logic) - in this project - am I worrying over nothin'?

Pretty much. The 74HCT4053 demod switches will happily run on 3V logic. Where you might need 5V (say, the display) you can use open-collector GPIOs with 5V pull-up resistors. Most STM GPIOs are 5V tolerant.

[KRinAZ]

I should clarify that the transition from the MXT to the MX5 was initially limited to changing the micro from PIC8 to STM32...

I get the feeling I'm the only one fretting over logic levels in the switch from PIC to STM32 - (5v logic to 3.3v logic) - in this project - am I worrying over nothin'?

[QUOTE=Carl-NC;n447141]

[Altra]

Hi KRinAZ, can you tell us what your "fun tools" are? I have an old cnc machine controller that uses a pic18f. The company that made the controller has been out of business for at least 15 years. I would like to build a back up controller if I can dump the hex. Thanks

[KRinAZ]

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.

I used to swing the Tesoro Lobo SuperTraq before the MXT, it was great detector also and I regret selling it. Happen to remember what micro it ran? Happen to know if anyone bought Tesoro's IP?

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

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

My ITMD3 is supposed to arrive today, can't wait!...fascinating, interesting, and even though it affects low conductivity non-ferrous targets also - the MXT is still good on reasonably small gold...more code magic perhaps...

[KRinAZ]

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.
[/ATTACH]

I see, kool, wonder if claude would be so kind as to gen those diagrams in LibreOffice Draw format? Then they could be edited...and maybe start a KiCAD project from the schematic?...then we'd be on a start toward a PCB...meanwhile...I have some fun tools on order (probably 10 days out)(and a little code to write) and my PIC can't wait to reveal it's secrets

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

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

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

this could be wrong ...

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

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

[moodz]

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