Algorithm Challenge

[ivconic]

I doubt this will work in a real-time metal detector where the amplitude & phase are changing almost on a cycle-by-cycle basis. This is why we demodulate and high-pass filter, leaving a target I&Q vector.
Yes, that's a Cortex M3 with hardware multiplication, so it can reasonably handle the math. But what about a crappy PIC? Or an M0?
It's hard to know what your time scale is, but the filter latency doesn't look all that bad. If you can't get the needed filtering & latency in a single filter, use cascaded filters.
Yes, it can be done in hardware, but that's the hard way. That's how White's did it in the old 6000 series, all analog & discrete logic. And a very impressive design. But (IMO) digital is easier and way more flexible.
Also, whatever graphic you embedded in post #3 doesn't show up for me. Likely for anyone else, other than you. Seems to be a forum bug.

A few good observations that I can't help but notice.
"...I doubt this will work in a real-time metal detector where the amplitude & phase are changing almost on a cycle-by-cycle basis..."
Exactly! That is the crux of the problem.
Am I wrong to assume that analog technology is more successful in dealing with that problem?
(not taking into account super powerful digital platforms which are both expensive and impractical for this kind of design)
"...This is why we demodulate and high-pass filter, leaving a target I&Q vector..."
A clear and generally accepted method. Almost a "dogma" in designing. Can we try to think "outside the box" this time? We are in no rush.
You said it before, I repeat; is that the main reason why the "pure" non motion approach was abandoned? Can something new be done about it?
"...Yes, that's a Cortex M3 with hardware multiplication, so it can reasonably handle the math. But what about a crappy PIC? Or an M0?.."
Powerful cores, lots of peripherals, plenty of resources... but ADC is still flawed. Back to the AMX stories.
"...crappy PIC" still beats in Deus... the fact that Deus started a new wave of ideas cannot be ignored.
Although I personally still understand AVR and ARM more easily.
"...but the filter latency doesn't look all that bad..."
This gives me an idea of more cheap processors with split tasks. Would it be bad to have a couple of Atmegas doing special jobs?
I have in mind that story from earlier about being able to reproduce a project without major problems by as many people as possible.
And it is an easier task if the work is divided among several people who have a good command of programming on Atmega.
One can write only one part of work on Atmega, another something else, third... in the end we have a project with several independent blocks of code.
Modular!
Someone won't like having an LCD on that detector. Someone will not use something else.
Modular, multiple solutions that are compatible and in the form of "Lego bricks" can be assembled as desired.
All these "modules" will be connected by one and the same "base", which should preferably be analog and universal.
I know you don't like it, you don't have to say, but how many people do you know here that will easily get the job done with some ARM?
You have the Atmega in a DIL package, anyone can solder it to the pcb. And what about Arm?
"...Yes, it can be done in hardware, but that's the hard way..."
That's exactly the right thing! If material that is easily available is used; it will be a very interesting project. From whom a lot can be learned.
"...But (IMO) digital is easier and way more flexible..."
Everyone has to agree with this.
But how many people are capable of following you as a couple who can do that?
And to get ready-made code from you... that's not it.
The gain is in the journey and not in just reaching the mere "goal" of having just another lookalike detector on a pile.
I apologize for the persistence.
But I've already seen everything similar on the AMX thread.
And not only on AMX, but also on a dozen others so far. A lot of attention and energy is spent on stories that ultimately never come to life.
If they ever come to life, it happens to one or two people...most are left deprived and disappointed.
Carl, it's clear why you would go that route, no one blames you.
But then it is not a project for the "broad masses". And we have seen that here on the forum many times.

[moodz]

Also, whatever graphic you embedded in post #3 doesn't show up for me. Likely for anyone else, other than you. Seems to be a forum bug.

[Carl-NC]

to extract the phase and amplitude of the target signal we solve ...




where a3 and theta3 are the amplitude and phase of the combined target + ground sinusoid.

a1 can be the ground amplitude and a2 can be the target amplitude.
theta1 is the ground phase and theta2 is target phase

so if you have a3 and a1 you can calculate a2 phase and amplitude by rearrangement....

I doubt this will work in a real-time metal detector where the amplitude & phase are changing almost on a cycle-by-cycle basis. This is why we demodulate and high-pass filter, leaving a target I&Q vector.

I am using STM32F103 and do not observe problem with that, what is slowing down program is method of removing the noise, filters, averaging etc,

Yes, that's a Cortex M3 with hardware multiplication, so it can reasonably handle the math. But what about a crappy PIC? Or an M0?

It's hard to know what your time scale is, but the filter latency doesn't look all that bad. If you can't get the needed filtering & latency in a single filter, use cascaded filters.

I posted the solution in post #3 it is performing this extraction using logs .... can be achieved with very simple analogue hardware.

Yes, it can be done in hardware, but that's the hard way. That's how White's did it in the old 6000 series, all analog & discrete logic. And a very impressive design. But (IMO) digital is easier and way more flexible.
Also, whatever graphic you embedded in post #3 doesn't show up for me. Likely for anyone else, other than you. Seems to be a forum bug.

[ivconic]

Today I was flipping through a collection of Elrad magazines from 1977 to 1997 and came across this:
- ELRAD 1995-03.pdf - "Trigonometrie mit CORDIC", pages 30 - 32
At the end of the article there are also references to some books (1959. year at one).
...
However, I can't shake the impression that the topic of metal detectors in reality was and remains totally uninteresting for all those big magazines.
A rough estimate is that it is just under 1% of the content of all those magazines (I have a huge digital collection, tens of gigabytes).
Taking into account that many authors of articles in those magazines are very big names in the world of science, in this case Electronics.
It seems kind of devastating, doesn't it?

[moodz]

a biiiiiiig if

I posted the solution in post #3 it is performing this extraction using logs .... can be achieved with very simple analogue hardware.

The pic below shows the output from extraction of 30mV / 300mv / 3volt input waveform with 100 mv peak peak noise to give a log recovery output with noise removed.

The top trace is the log level recovery.

The bottom trace is the waveform phase recovery.

I would probably need a high spec ADC to perform the same in DSP.

[ivconic]

I remember the button you're talking about, as I used to have a old non-motion Tandy detector that had one. I found a lot of stuff with that detector.
Are you wanting to replace it with a "Self-adjusting Threshold" (SAT)?

Yes. Because my great desire is to make one good non motion detector.
Something along the lines of the Cscope 1220B or one of the White's non motion detector series.
"...I found a lot of stuff with that detector..."
Well done!
Exactly!
Although they are not "deep" (by today's standards and by the criteria of today's bench tests); however with a proper understanding of the operation of such detectors and with proper manipulation of the controls on such a detector; the results are phenomenal.
I have found the best, most difficult to find, smallest and most valuable finds with such detectors.
And working with such a detector is very interesting, exciting... you feel as if you are "listening" to the soil and everything in it.
But all this can only be understood by someone who has such experiences.
Your sentence testifies to that.

[pito]

so if you have a3 and a1 you can calculate a2 phase and amplitude by rearrangement....

a biiiiiiig if

[pito]

OK, here is a mini-challenge. Let's say you design a mixed analog/digital detector. You read in the X & R signals to the micro, and at some point you want to calculate the magnitude and phase. Mathematically, they are:





However, these can be slow calculations in a micro.

I am using STM32F103 and do not observe problem with that, what is slowing down program is method of removing the noise, filters, averaging etc,


delay in amplitude filtering

[pito]

It is done in Quasar Arm, look R1 SIN_ C

So that we don't have to press that button often.

.

for that generator should additionally generate a sine wave with adjustable amplitude and phase, at first you can use 4 buttons and then replace them with pulses generated let say every, 5 seconds.
I can guide you if you can do programming.

[Qiaozhi]

I didn't mean auto balancing at coil!
How did this go that way??
All the time I think about the "auto-zero" circuit in non-motion detectors, whether it is IB or PI (probably a different morphology).
Ok, let's go slowly, so we have a non motion detector. It usually has a button next to which it often says "tune" or "retune" or "reset"...
When the detector starts to drift; you press that button and it calms down.
What is the name of the circuit that does that?

I remember the button you're talking about, as I used to have a old non-motion Tandy detector that had one. I found a lot of stuff with that detector.
Are you wanting to replace it with a "Self-adjusting Threshold" (SAT)?

[moodz]

to extract the phase and amplitude of the target signal we solve ...




where a3 and theta3 are the amplitude and phase of the combined target + ground sinusoid.

a1 can be the ground amplitude and a2 can be the target amplitude.
theta1 is the ground phase and theta2 is target phase

so if you have a3 and a1 you can calculate a2 phase and amplitude by rearrangement....

[Carl-NC]

When zeroing the coils, we always tried to achieve a balance as close to zero as possible.
With hand held meters I have always found 7-14mV to be a well balanced coil.

OK, suppose you have 100mV of ground signal and a 50mV target signal. You can't extract the target phase with a zero-crossing algorithm.

I was hoping for analog solutions... but somehow everything slipped back into the domain of programming.
Ok, that's what you called the topic.

Yes, I specifically mentioned an algorithm for a micro. If you want to talk about analog solutions, then post a challenge/competition for that. Same for the autotune circuit. Or electronically-nulled coils.

[ivconic]

I know that, not good enough!
There is slightly better one in White's Eagle series, forgot the exact schmatic, but I am sure I have it... also not good enough!
Dang!
That's why I proposed that stage as separate project here.

[moodz]

There are auto tune implementations ... heres one from Garrett again ( patent expired ).

[ivconic]

So you want an auto zero function
....I was pretty sure you were talking about the coil balancing here ... sorry

No, Carl intentionally started this fuzz!



This is an attempt, for full-scale range input, obviously it will be corrected and adapted to real x, y values, also depending on hardware and what levels coming from it, yet just an example.
I am tempted to see how Atmega328P will deal with this, will it choke or slow down?
Don't have prepared hardware though...

#include <Arduino.h>
#include <math.h>

// Sensor and ADC information
const float InputRange = 5.0f; // Full-scale range of the input
const int analogResolution = 10; // ADC resolution

// Scaling factor (optional)
const float scalingFactor = 10.0f;

// Define analog pins for x and y readings
const int xPin = A0;
const int yPin = A1;
// Define the K array for CORDIC algorithm
static const float K[8] = {
  0.6072529350088812f,
  0.4142135623730950f,
  0.2500000000000000f,
  0.1591549430918954f,
  0.1023381623379956f,
  0.0645161290312500f,
  0.0408407044921875f,
  0.0255017857524998f
};
// Fast arctan approximation using CORDIC algorithm
float fast_atan(float y, float x) {
  // Initialize variables
  float z = 1.0f;
  float angle = 0.0f;

  // Check for special cases
  if (y == 0.0f) {
    if (x > 0.0f) {
      return M_PI_2;
    } else if (x < 0.0f) {
      return -M_PI_2;
    } else {
      return 0.0f;
    }
  }

  // Perform CORDIC iterations
  for (int i = 0; i < 8; i++) {
    float d = x - K[i] * z;
    if (d < 0.0f) {
      angle += K[i];
      x = d;
      z += K[i] * y;
    } else {
      angle -= K[i];
      x = d;
      z -= K[i] * y;
    }
  }

  // Final adjustment and correction for quadrant
  if (y < 0.0f) {
    angle = -angle;
  }
  if (x < 0.0f) {
    angle += M_PI;
  }
  return angle;
}

void setup() {
  // Configure analog pins as inputs
  pinMode(xPin, INPUT);
  pinMode(yPin, INPUT);
}

void loop() {
  // Read analog values
  int x_raw = analogRead(xPin);
  int y_raw = analogRead(yPin);

  // Convert raw values to voltage
  float x = (float)x_raw * (InputRange / pow(2, analogResolution));
  float y = (float)y_raw * (InputRange / pow(2, analogResolution));

  // Apply scaling factor (optional)
  x *= scalingFactor;
  y *= scalingFactor;

  // Calculate arctan
  float angle = fast_atan(y, x);

  // ... further processing with the calculated angle ...
  // Example: print the angle to the serial monitor
  Serial.print("Angle: ");
  Serial.print(angle * 180.0f / M_PI);
  Serial.println(" degrees");

  // Delay to slow down the loop execution
  delay(100);
}
​