Let's make a closely MXT like detector!

[pechkata]

So, from my little corner in Dante's hell (right moodz? ) here's what I think - going forward:

I know everyone really wants to not use a PIC micro, myself included (but only just), but there is one argument to be made for initially deploying a PIC16F76 - and that is because C code for the PIC16F is the closest / easier to produce C code (inspired by our disassembled code) that could be compiled and run in a MXT board - again I said initially, to test and verify we have good tested C code. If C code were produced that would compile and run in a MXT just as the original - then we would have a fully functional code base, tested, and ready to port to a STM32. My understanding is we currently do not have that yet.

The code is obviously both; where most of the operational magic is, and hard to produce even with the aid of AI. From where we are now - it seems to me to be easier to create code for a PIC16F than for the STM32 - as currently we have no way to test the code for a STM32 in actual hardware. Then as soon as that (C code for PIC16F) is accomplished the focus moves to; adapting the code base to run in the STM32, and producing the STM32 based version of a MXT board.

I have a number of things going on currently, so maybe I'm not moving so fast - but still I am currently chipping away at; producing a schematic of a STM32 based version of the MXT schematic, and understanding the specific differences between PIC16C and PIC16F in order to modify the disassembled PIC16C code to run in a PIC16F.

So what I propose as next steps:
1) Produce functional equivalent C code to compile and run - in a PIC16F76 - on a MXT board.
2) Test said code in MXT board and work out any bugs
3) Produce a STM32 centered schematic and pcb of the MXT
4) Have tons of eyes on said schematic and pcb to spot any flaws
5) Send the consensus approved gerber off to produce several pcb's
6) Port the PIC16F C code to the STM32
6) Have several folks run our pcb with our code in actual (modified for our use, more on that soon) MXT bodies and field test
7) Debug as needed

And enough with the copyright stuff, personally I don't give a hoot...let's move forward...onward thru the fog...

Thoughts? Disagreements? Agreements?

Hello KRinAZ
I will be one of those people.

[KRinAZ]

Google AI can do it:
"Is this the updated version?"

Hmmm, OK, well I suppose I don't know - since I don't know anything about a file named v2.40.hex, what it is, where it came from, what it is supposed to contain. Perhaps I missed the post where it was previously discussed, if it was...

[Aziz]

Hello, this appears to be Arabic?
I don't speak Arabic so don't know what this says. Google Translate didn't work so well...
As Carl said we need to post in English.

Google AI can do it:
"Is this the updated version?"

[KRinAZ]

شكرا لك KRinAZ

هل هاذي هيا انسخه. المحدثه v2.40.hex

Hello, this appears to be Arabic?
I don't speak Arabic so don't know what this says. Google Translate didn't work so well...
As Carl said we need to post in English.

[Carl-NC]

هل هاذي هيا انسخه. المحدثه v2.40.hex

Please make all posts in English.

[Fadel saleh]

هل هاذي هيا انسخه. المحدثه v2.40.hex

[Fadel saleh]

شكرا لك KRinAZ

[Taktyk]

Analysis of Selected White's MXT Firmware Subsystems

Based on Reverse-Engineered Pseudocode

Part 3: VDI and Target Classification

---

Introduction


The Visual Discrimination Indicator (VDI) is one of the defining features of modern VLF metal detectors. Rather than presenting raw signal information to the operator, the detector attempts to estimate the electrical characteristics of a target and map those characteristics onto a numerical scale.

For many users, the VDI appears to be a simple target identification number. Internally, however, the process is considerably more complex.

Analysis of the White's MXT firmware reveals that VDI generation is not performed from instantaneous signal measurements. Instead, the detector evaluates signal stability, tracks phase relationships over time, captures peak-response events, and only then updates the displayed target classification.

This article examines the architecture of the MXT target identification system and the mechanisms used to transform detector responses into VDI values.

---

Fundamental Principle


A VLF detector transmits an alternating magnetic field and measures the phase and amplitude of the resulting receive signal.

Different target materials produce different phase responses:
Ferrous Objects
↓
Negative Phase Shift

Small Gold
↓
Slight Positive Phase Shift

Coins and Conductive Targets
↓
Larger Positive Phase Shift


The purpose of the VDI system is to convert these phase characteristics into a repeatable numerical representation.

In theory, the process appears straightforward:
Phase Measurement
↓
Target ID Number


The MXT firmware demonstrates that the practical implementation is significantly more sophisticated.

---

Separation Between Detection and Classification


One of the most important observations is that the MXT separates target detection from target classification.

The detector first determines whether a signal event is valid.

Only after signal quality requirements have been satisfied does the firmware attempt to calculate a target identification value.

Conceptually:
Target Detection
↓
Signal Validation
↓
Target Classification


This architecture reduces the influence of noise and unstable responses on displayed VDI values.

---

Signal Stability Evaluation


The firmware continuously evaluates the relationship between multiple filtered signal channels.

Rather than using a single sample, the detector observes signal behavior over time.

The system monitors:

• Signal polarity.
• Relative phase behavior.
• Comparator transitions.
• Signal persistence.
• Peak magnitude.

These measurements collectively determine whether a signal should be considered suitable for classification.

---

Peak Response Acquisition


The MXT does not classify targets from arbitrary signal samples.

Instead, the firmware attempts to identify the strongest and most stable portion of the target response.

Conceptually:
Target Pass
↓
Peak Detection
↓
Snapshot Capture
↓
Classification


During a sweep, the detector captures signal values near the point of maximum response.

This approach improves classification consistency because measurements are performed when the signal-to-noise ratio is highest.

---

Snapshot-Based Processing


A notable feature of the MXT architecture is the use of internal snapshots.

Rather than continuously updating classification variables, the detector stores selected signal states when specific conditions are satisfied.

These snapshots preserve:

• Signal magnitude.
• Relative channel information.
• Internal filter states.
• Timing relationships.

Once captured, the stored values are used as the basis for subsequent calculations.

This design reduces sensitivity to short-term fluctuations and unstable target responses.

---

Phase Estimation


After a valid signal event has been identified, the detector estimates the phase relationship associated with the target.

Although the exact implementation varies between detector designs, the objective remains the same:
Receive Signal
↓
Phase Estimation
↓
Target Conductivity Representation


The resulting value forms the foundation of the VDI calculation.

The firmware evidence suggests that the MXT performs this process only after signal stability criteria have been met.

---

VDI Scaling


The calculated phase information is transformed into the detector's numerical identification scale.

Conceptually:
Phase Estimate
↓
Scaling Function
↓
VDI Value


The scaling process allows targets with similar electrical characteristics to produce similar identification numbers.

This provides the operator with a practical method of distinguishing between common target categories.

---

Target Classification


Once a VDI value has been generated, the detector can perform classification and discrimination operations.

Typical classification regions include:
Iron
↓
Foil
↓
Small Gold
↓
Nickel Range
↓
Pull Tabs
↓
Coins
↓
High Conductors


The precise boundaries are determined by firmware tables and discrimination settings.

The classification stage converts continuous phase information into discrete target categories useful to the operator.

---

Relationship to Discrimination


VDI and discrimination are closely related but perform different functions.

VDI attempts to estimate target characteristics.

Discrimination determines whether those characteristics should be accepted or rejected.

Conceptually:
Target Signal
↓
VDI Calculation
↓
Discrimination Decision
↓
Accepted / Rejected


This separation allows the detector to maintain a consistent target identification system while providing adjustable rejection behavior.

---

Design Philosophy


The MXT target identification system reflects a broader design philosophy visible throughout the firmware.

Rather than relying on instantaneous measurements, the detector emphasizes:

• Observation over time.
• Stability verification.
• Event detection.
• Peak capture.
• State preservation.

The objective is not simply to calculate a VDI value as quickly as possible, but to calculate it only when the detector has sufficient confidence in the measurement.

This philosophy prioritizes identification reliability over response speed.

---

Engineering Assessment


The analysis suggests that the MXT target identification system is built around signal validation rather than direct measurement.

Many modern explanations describe VDI as a simple representation of target phase. While technically true, the firmware demonstrates that a significant amount of processing occurs before phase information is accepted as valid.

The detector continuously evaluates signal quality, waits for stable responses, captures peak events, and only then performs classification.

This architecture helps explain the reputation of the MXT for producing stable and repeatable target identification under difficult field conditions.

---

Conclusions


The White's MXT does not generate target identification values directly from instantaneous signal measurements.

Instead, the detector employs a multi-stage acquisition process involving signal validation, peak-response capture, phase estimation, and classification.

The resulting VDI system represents a carefully controlled decision process rather than a simple numerical conversion of phase data.

This design reflects the broader engineering philosophy observed throughout the firmware: use simple computational building blocks, but combine them through carefully designed state logic to achieve robust real-world performance.

---

Next Article


Part 4: Discrimination Logic and Target Acceptance

The next article will investigate how the MXT uses VDI information to accept or reject targets, how discrimination thresholds are implemented, and how the detector balances target recovery speed against classification accuracy.

[Taktyk]

Analysis of Selected White's MXT Firmware Subsystems

Based on Reverse-Engineered Pseudocode

Part 2: Ground Tracking Architecture

---

Introduction


In the previous article, we examined the digital filtering architecture of the White's MXT and found that the signal-processing chain is built primarily from cascaded first-order EMA filters and simple difference operations.

While those filtering stages are important, they are not what made the MXT famous among detector users.

The detector's reputation was largely built on its ability to maintain stable operation in difficult ground conditions while preserving target response and identification accuracy. This capability originates from the Ground Tracking subsystem.

This article analyzes the architecture of the MXT Ground Tracking system based on reverse-engineered pseudocode and attempts to identify the design principles behind its operation.

---

The Ground Problem


All VLF metal detectors must solve the same fundamental problem.

The receive signal contains contributions from:
Target Response
+
Ground Response
+
Environmental Noise


In highly mineralized soils, the ground response can be significantly larger than the signal generated by a coin or relic.

A detector that simply amplifies the received signal will either become unstable or lose sensitivity.

The purpose of Ground Tracking is therefore to estimate and remove the ground component while preserving target information.

---

Classical Ground Balance


Many detectors implement ground compensation using a slowly adapting low-pass filter:
ground ← ground + α(signal − ground)


where the estimated ground value gradually follows long-term changes in soil conditions.

Although simple and effective, this approach presents a compromise.

If adaptation is too slow:

• Ground changes are not tracked efficiently.

If adaptation is too fast:

• Target signals may be incorporated into the ground estimate and effectively disappear.

This trade-off is one of the central challenges of detector design.

---

MXT's Different Approach


Analysis of the firmware suggests that the MXT does not rely exclusively on a continuously adapting ground estimate.

Instead, it appears to combine:

• Signal observation.
• Event detection.
• State capture.
• Offset estimation.
• Predictive correction.

In other words, the system behaves more like a state-driven estimator than a simple tracking filter.

---

Ground Tracking Subsystem Overview


The reverse-engineered firmware reveals four particularly important functions:
capture_threshold_baseline()
capture_offset_baseline()
apply_baseline_extrapolation()
tick_ground_counter()


Together these functions form the core of the Ground Tracking system.

Rather than continuously modifying the ground estimate every sample, the firmware periodically captures and evaluates internal states before deciding how the ground model should be updated.

---

Baseline Capture


The first significant mechanism is baseline capture.

During specific operating conditions, the detector stores internal filter states representing the current ground environment.

Conceptually:
Current Ground State
↓
Snapshot
↓
Stored Reference


This snapshot serves as a reference point for future corrections.

Instead of relying solely on a moving average, the detector preserves historical information about previously observed ground conditions.

---

Threshold-Based State Capture


The function:
capture_threshold_baseline()


appears to monitor specific signal conditions and record baseline values when predefined criteria are met.

Although the exact trigger conditions require further study, the mechanism resembles event-driven sampling rather than continuous adaptation.

This design choice is important because it allows the detector to capture stable ground information without constantly reacting to transient target signals.

---

Offset Capture


A second mechanism stores offset information associated with the current ground estimate.

Conceptually:
Ground Estimate
↓
Offset Calculation
↓
Stored Offset


This offset acts as an additional correction term that can later be applied during ground model reconstruction.

The existence of dedicated offset storage suggests that the MXT internally separates baseline estimation from correction compensation.

---

Ground State Extrapolation


One of the most interesting discoveries within the firmware is the extrapolation stage.

The function:
apply_baseline_extrapolation()


combines previously stored information to generate a predicted ground value.

The operation resembles:
predicted =
snapshot
− offset
+ bias


and in some operating modes:
predicted =
snapshot
− 2 × offset
+ bias


Although the exact interpretation of each variable requires further investigation, the structure itself is significant.

This is not merely filtering.

The firmware is actively attempting to predict the expected ground state from previously captured information.

---

Predictive Ground Compensation


Traditional adaptive filters estimate ground conditions from recent samples.

The MXT appears to supplement this process with prediction.

Conceptually:
Past Ground State
+
Current Offset
+
Current Bias
↓
Predicted Ground State


This strategy may explain why the MXT often feels unusually stable when moving between regions of differing mineralization.

Rather than waiting for a filter to settle, the detector attempts to anticipate the required correction.

---

Ground Tracking State Machine


The function:
tick_ground_counter()


appears to implement a state-management system controlling the tracking process.

Responsibilities likely include:

• Timing updates.
• Managing tracking intervals.
• Determining when new baselines should be captured.
• Deciding when extrapolation should occur.
• Preventing excessive correction activity.

This indicates that Ground Tracking in the MXT is governed by explicit control logic rather than a continuously running filter alone.

---

Why This Matters


The architecture suggests that the MXT designers recognized a key limitation of purely adaptive filtering.

A conventional tracking filter must constantly balance:
Fast Tracking
vs
Target Preservation


The MXT attempts to reduce this conflict by introducing state capture and prediction.

Rather than blindly adapting at every sample, the detector selectively updates its internal model and uses previously captured information to guide future corrections.

This approach potentially allows:

• Faster adaptation to changing ground.
• Improved target preservation.
• Reduced instability.
• More consistent detector behavior.

---

Engineering Assessment


From an engineering perspective, the Ground Tracking subsystem is significantly more sophisticated than the filtering architecture examined in Part 1.

The filtering stages are relatively conventional and largely reflect the limitations of the original PIC microcontroller.

The Ground Tracking subsystem, however, appears to contain genuinely detector-specific design knowledge.

Several characteristics stand out:

• Event-driven operation.
• Historical state storage.
• Offset management.
• Predictive extrapolation.
• State-machine control.

These features are not commonly found in simple adaptive ground-balance implementations.

---

Open Questions


Although the overall architecture is becoming clearer, several questions remain unanswered:

• What exact conditions trigger baseline capture?
• How are offsets derived internally?
• What physical quantity does the extrapolation process represent?
• How are tracking speed and stability balanced?
• Which variables correspond directly to soil phase information?

Answering these questions will require further analysis of supporting firmware modules and variable interactions.

---

Conclusions


The reverse-engineered firmware suggests that the White's MXT Ground Tracking system is not merely a slowly adapting filter.

Instead, it appears to be a state-based estimation system combining baseline capture, offset storage, extrapolation, and control logic.

While the digital filters discussed in Part 1 are relatively simple, the Ground Tracking subsystem demonstrates a considerably higher level of algorithmic sophistication.

The evidence suggests that much of the MXT's reputation for stable operation in difficult soil conditions originates from this subsystem rather than from the filtering architecture itself.

Understanding the precise behavior of the tracking logic will likely provide the most valuable insight into the engineering philosophy behind the MXT design.

---

Next Article


Part 3: VDI and Target Classification

The next article will examine how phase information is transformed into Visual Discrimination Indicator (VDI) values and how the MXT performs target classification and discrimination.

[Taktyk]

Analysis of Selected White's MXT Firmware Subsystems

Based on Reverse-Engineered Pseudocode

Part 1: Digital Filtering Architecture

---

Introduction


The White's MXT is one of the most influential VLF metal detectors ever produced. Despite its age, the detector earned a reputation for excellent ground handling, stable target identification, and reliable performance in highly mineralized soils.

While much has been written about the MXT from a user perspective, relatively little information exists regarding its internal digital signal-processing architecture. This article presents a technical analysis of the MXT filtering system based on reverse-engineered pseudocode derived from the original firmware.

The objective of this study is not to reproduce the original firmware, but rather to understand the design decisions behind its digital signal-processing chain and identify which concepts remain relevant for modern detector designs.

---

Historical Context


The MXT was designed around a Microchip PIC16-series microcontroller. At the time of its development, processing power, memory capacity, and arithmetic capabilities were severely limited compared to modern embedded systems.

As a result, the MXT firmware was engineered around several constraints:

• Minimal RAM usage.
• Minimal program memory consumption.
• No hardware DSP engine.
• No multiply-accumulate unit.
• Predominantly fixed-point arithmetic.
• Preference for shift operations instead of multiplications.

These constraints strongly influenced the architecture of the digital filtering system.

---

Overview of the Signal Processing Chain


Analysis of the firmware reveals the following high-level processing structure:
X/Y Demodulated Channels
↓
Baseline Tracking
↓
Delta Extraction
↓
EMA Filter Stage 1
↓
EMA Filter Stage 2
↓
Phase Filter Pair
↓
Edge Detection
↓
Ground Tracking
↓
Audio / VDI Processing


An important observation is that the MXT does not perform ground compensation immediately after demodulation. Instead, several filtering stages are applied before the Ground Tracking subsystem becomes involved.

This differs from many modern architectures, where ground subtraction is often performed near the beginning of the processing chain.

---

Baseline Tracking


The first stage maintains a slowly changing reference signal, referred to here as the baseline.

Its purpose is not target detection but long-term signal stabilization.

The implementation resembles a simple first-order recursive filter:
baseline ← baseline + α(x − baseline)


where α is implemented using power-of-two scaling rather than explicit multiplication.

The resulting baseline follows slow environmental changes while rejecting short-duration target responses.

Conceptually, this stage acts as a long-term reference model for subsequent processing.

---

Delta Extraction


Once the baseline has been established, the firmware computes the difference between the current signal and the baseline estimate.
delta = signal − baseline


This operation removes a significant portion of the slowly varying background component and emphasizes transient responses generated by metallic targets.

The resulting delta signal forms the input to the next filtering stages.

---

Cascaded EMA Filtering


The most notable characteristic of the MXT filtering architecture is the extensive use of cascaded exponential moving average (EMA) filters.

A typical stage is implemented as:
state ← state + (input − state)/8


which corresponds to:
α = 1/8


in a conventional EMA representation.

Several such stages appear sequentially throughout the signal path.

From a modern DSP perspective this may appear simplistic, but within the constraints of the original hardware it provided several advantages:

• No multiplication required.
• Minimal memory usage.
• Numerical stability.
• Predictable execution time.

The cost of this approach is increased signal latency and longer impulse responses compared to more advanced filter structures.

---

Phase Filter Pair


One of the most interesting sections of the firmware is the phase filtering stage.

Its structure can be simplified as:
EMA1
↓
EMA2
↓
EMA1 − EMA2


The subtraction of two low-pass filtered signals effectively produces a band-pass response.

This technique is widely used in low-cost embedded systems because it provides useful frequency selectivity while requiring only additions, subtractions, and bit shifts.

Mathematically, the structure behaves similarly to a first-order high-pass filter followed by additional smoothing.

The result is a signal that emphasizes changing target responses while suppressing slow background variations.

---

Edge Detection


Following band-pass filtering, the firmware analyzes signal transitions rather than relying solely on signal amplitude.

The code monitors:

• Sign changes.
• Zero crossings.
• Transition timing.
• Signal polarity.

These events are converted into internal flags that are later consumed by higher-level subsystems.

This indicates that the MXT relies not only on signal magnitude but also on temporal characteristics of the filtered response.

---

Design Philosophy


The filtering architecture demonstrates a clear design philosophy.

Rather than implementing mathematically sophisticated filters, the designers chose a sequence of computationally inexpensive building blocks:

• First-order recursive filters.
• Difference operations.
• State capture mechanisms.
• Event-based decision logic.

The complexity of the detector does not arise from any individual filter but from the interaction between multiple simple stages.

This approach was particularly well suited to the hardware limitations of the period.

---

Engineering Assessment


From a contemporary perspective, the MXT filtering architecture appears conservative.

Modern microcontrollers can easily support:

• FIR filters.
• Higher-order IIR filters.
• Biquad sections.
• Adaptive filtering.
• Floating-point processing.

Consequently, many of the original MXT filter stages could be replaced by more efficient or more selective DSP structures.

However, such a conclusion would miss an important point.

The MXT was not designed to maximize theoretical DSP performance. It was designed to achieve reliable detector behavior within extremely limited computational resources.

Viewed from that perspective, the architecture is remarkably efficient.

---

Conclusions


The analysis reveals that the MXT digital filtering system is built almost entirely from cascaded first-order EMA filters and simple difference operations.

No advanced DSP structures are present. Instead, the firmware relies on carefully tuned recursive filters implemented using fixed-point arithmetic and bit-shift operations.

The filtering stages themselves are relatively straightforward and primarily serve to prepare signals for later processing.

The true sophistication of the MXT appears to lie elsewhere—particularly within the Ground Tracking subsystem, which will be examined in the next article of this series.

---

Next Article


Part 2: Ground Tracking Architecture

The next article will investigate how the MXT models ground conditions, captures baseline information, performs extrapolation, and maintains stable operation in changing soil environments.

[KRinAZ]

So, from my little corner in Dante's hell (right moodz? ) here's what I think - going forward:

I know everyone really wants to not use a PIC micro, myself included (but only just), but there is one argument to be made for initially deploying a PIC16F76 - and that is because C code for the PIC16F is the closest / easier to produce C code (inspired by our disassembled code) that could be compiled and run in a MXT board - again I said initially, to test and verify we have good tested C code. If C code were produced that would compile and run in a MXT just as the original - then we would have a fully functional code base, tested, and ready to port to a STM32. My understanding is we currently do not have that yet.

The code is obviously both; where most of the operational magic is, and hard to produce even with the aid of AI. From where we are now - it seems to me to be easier to create code for a PIC16F than for the STM32 - as currently we have no way to test the code for a STM32 in actual hardware. Then as soon as that (C code for PIC16F) is accomplished the focus moves to; adapting the code base to run in the STM32, and producing the STM32 based version of a MXT board.

I have a number of things going on currently, so maybe I'm not moving so fast - but still I am currently chipping away at; producing a schematic of a STM32 based version of the MXT schematic, and understanding the specific differences between PIC16C and PIC16F in order to modify the disassembled PIC16C code to run in a PIC16F.

So what I propose as next steps:
1) Produce functional equivalent C code to compile and run - in a PIC16F76 - on a MXT board.
2) Test said code in MXT board and work out any bugs
3) Produce a STM32 centered schematic and pcb of the MXT
4) Have tons of eyes on said schematic and pcb to spot any flaws
5) Send the consensus approved gerber off to produce several pcb's
6) Port the PIC16F C code to the STM32
6) Have several folks run our pcb with our code in actual (modified for our use, more on that soon) MXT bodies and field test
7) Debug as needed

And enough with the copyright stuff, personally I don't give a hoot...let's move forward...onward thru the fog...

Thoughts? Disagreements? Agreements?

[moodz]

If you had actually understood the MXT software, you would know that there is absolutely no point in porting it to a new platform. Everything in it is highly optimized specifically for an 8-bit PIC microcontroller, because back then, there simply was no other choice.

And everything in that code can be done much better now something that was structurally impossible in the '90s.

You simply got way ahead of yourself with these legal accusations and never paused to think that someone might actually dig in and realize there is no 'magic' in this software. But instead, you chose to make this whole rant. The reality is, everything in the MXT code is up for improvement today.

More BHI ....just to set the record straight. . YOU are the one who was reverse engineering the code and porting it not me. Get your facts straight that's my last word ...

[KRinAZ]

I think this would be an excellent project. IMO, the MXT was about the pinnacle of single frequency and is still competitive... ...but I would start simple and build on that.

...words of wisdom...

[KRinAZ]

My 2 cents for what it's worth -

I don't see a copyright problem with code inspired by other code - the tech world is filled to bursting with it, it is the basis of AI LLM's, right?

So again, the mission is to first create a very MXT like detector using as much as possible the existing electronics, only replacing electronic components where necessary - yes it is old technology, but it (the MXT) works better than a lot of what is "current technology", right? Isn't that why the interest in the MXT?

IMO we have to get the base "very MXT like" project working first, proven in the field, then we can mod it right up to current technology, testing each small mod along the way to verify functionality is maintained and/or enhanced. Then I'm sure the more ambitious mods will take many branches...

But if we make something that isn't the "very MXT like" base - and it does not perform - was it the mod or just that we don't have a working base yet?

And if we shift to make something utilizing modern technology - and setting aside the tech in the MXT (old as it is) - what we are doing really is just designing a new detector. That is not what this particular thread is all about.

Why is that not what this thread is all about? - because what it is about is making modern improvements to the MXT as outlined in Post #1, and heeding Carl's suggestion in Post #2.

[KRinAZ]

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.

You're welcome! and apologies - didn't realize that I hadn't yet uploaded the HEX...