Software alignment of magnetometers in a Gradiometer.

[I M]

Some years ago I bought some FGM-3 magnetometers from Bill Speake. I used them with a mixing cct and Arduino to construct a basic gradiometer for archeological research, but was never very happy with the result.

Other things occurred in life and so I've only now returned to the project and have written a little code for a Pi Pico to take the output from two FGM-3's and display that. The difference is also displayed, and there's a pushbutton input to zero it.

While that works relatively well the project as a whole is still in its infancy, and before going further with it I'd like to resolve an issue with alignment of the sensors. As with most gradiometers of this type they're presently mounted in line along their axis, around 500mm apart, with (nylon) screw adjustment for one sensor so that it may be mechanically aligned with the other sensor. In theory, once aligned, this should mean that rotating the sensors (in their housing) around the housing axis shouldn't result in any change in the difference between the output of the two sensors.

In practice I've not found this to be especially satisfactory and I'm reminded of my research from some years ago in which I found that later commercial gradiometers used what appears to be a software alignment procedure. With the Bartington 601 for example you first 'point' the machine north with the sensors vertical, press a button, then point south, then east, then west, then invert etc. Other gradiometers use not dis-similar processes to align the machine before use; they no longer require mechanical adjustment of the magnetometers as in earlier units.

From this information while it's evident that there's a methodology to 'align' the magnetometer error in software I have, unfortunately, not been able to locate any corresponding published research on the matter. Over time I've contemplated various methods of my own, but would like to read and understand more from experts in this area before going much further. To that end I wonder if anyone is able to point me towards any information they might know about on the subject?

Thank you.

[pito]

What signal are you dealing with, square , sine or Dc ?

[I M]

From the sensors? They're a standard FGM-3 and while it's been several years since I looked at the output via a 'scope Bill's notes say:

"The FGM type sensor has an output in the form of a large rectangular pulse whose period is proportional to the external magnetic field along its principal axis, within its linear range of operation."

Incidentally, while they're not rated for it they seem to be performing tolerably well on a 3.3V supply (given the Pico is a 3.3V device).

Not sure if you just wanted to know out of interest, or whether it's related to my question, but I trust that's of some use...

[Altra]

The FGM sensors output a frequency proportional to the magnetic field. What I did was measured the frequency of each sensor. Then with a push button command subtract the two frequencies. The difference became the offset value subtracted from the sum of frequencies. This removes the alignment error between the sensors

[pito]

F IN is your sensor the output is DC. Let say from S1 you have 2V and from S2 3V = not perfect alignment , the difference is Uo =1V, it is constant until the magnetic field is the same for both sensors, so you observe changes in Uo.
The software
Press the button = Uo = Uin
if (Uin ! = Uo)
{
tone(pin, frequency)
}
else
{
noTone(pin)
}



or you can use BFO method

[Altra]

F IN is your sensor the output is DC. Let say from S1 you have 2V and from S2 3V = not perfect alignment , the difference is Uo =1V, it is constant until the magnetic field is the same for both sensors, so you observe changes in Uo.
The software
Press the button = Uo = Uin
if (Uin ! = Uo)
{
tone(pin, frequency)
}
else
{
noTone(pin)
}



or you can use BFO method

With a micro controller you don't need the f to v converter. Just monitor the frequencies direct.

[pito]

The FGM-3 sensorThe data sheet quotes a typical frequency range of approximately 120 kHz to 50 kHz, the devices do vary, but typically the frequency for the current local field is about 65 kHz.

120kHz for microcontroller ?
The software will be much complicated than I suggest.

[Altra]

The FGM-3 sensorThe data sheet quotes a typical frequency range of approximately 120 kHz to 50 kHz, the devices do vary, but typically the frequency for the current local field is about 65 kHz.

120kHz for microcontroller ?
The software will be much complicated than I suggest.

A pic16f can measure 40mhz without problem. Using a timer counter gated at precise time periods. Uses little overhead since the counter is a separate module.

I don't use arduino/avrs. Search arduino frequency counter, you will see many examples

[pito]

I suggest 7 line of ready to use software, and two counters = haw long will be the program ?
And you need to find it.

[ivconic]

Although there is no absolute need for both sensors to be aligned and to be forced to give the same measurements; however, everything is neater and better when it is the case.
Especially if we want linearity and matching of the frequency range with the range of the measured magnetic field expressed in one of the accepted measurement units.
And that is not easy to achieve with FGM type sensors, due to their morphology.
For amateur archeological purposes it is not very important. So all described methods can be used equally well.
But a step beyond that; would be absolute linearity and matching with the range of the measured magnetic field expressed in one of the accepted measurement units.
One of the (not so brilliant and inventive) solutions is to hire software/code that will do various adjustments, conversions, scaling, mapping, etc.
And all that will take too many clocks of such code.
The main cause of the problem should first be defined.
And that is the core that is on the verge of saturation. And by its structure very unstable.
Experiment: take a piece of neodymium magnet (if you don't have anything better, you can take a piece from the hard drive) and bring it close to the FGM type sensor.
The sensor will change the range drastically. After removing the magnet; range will not return.
It is optimistic to expect that the sensor will return to normal after the passage of time; chances are it won't be complete return.
What is needed? "Reset" the core, so to speak.
Further, the optimists will wave the same magnet around the sensor, trying to neutralize the previous "damage"... to a greater or lesser extent, they have a chance to succeed to some extent.
This reminded me of the "good" old days of CRT TVs, when for some reason the screen demagnetization circuit (degaussing) failed.
So a piece of magnet (mostly from a discarded speaker) is waved in front of the screen in various directions; to "unfold" the rainbow stain on the screen!
A method that never gives good enough results. But it was an unprecedented fun goofing off like that!
What is a better solution?
Expose the core to the influence of a uniform magnetic field of a certain strength.
What comes to mind?
Helmholtz coil setup, of course!
It would be ideal to always have a miniature Helmholtz coil setup around such sensors and to "reset" the the sensor before starting measurements.
Easier said than done.
I've been thinking about it for a quite q while, how to make a miniature Helmholtz coil assembly universal for adding to FGM type sensors.
I have no particular reason for it, but it is a kind of challenge.

[ivconic]

Now that I mentioned "degaussing"; who remembers, the younger ones certainly don't, how it was performed on CRT TVs.
Along the perimeter of the cathode ray tube on the inside of the tv, on the back side of the screen there was a coil, mostly Cu wire, 0.3-0.5mm with several tens or even hundreds of windings.
Coil was in series with PTC thermistor, tied to the mains voltage, just after the main switch.
When turning on the TV; mains voltage 50Hz (60Hz) goes through the coil, suddenly creates a strong magnetic field, but the PTC reacts very quickly, increases the resistance and interrupts the flow.
That strong magnetic field "stretches" properly all remnants of magnetization on the surface of the screen.
The result of that short process is correctly and accurately distributed colors on the screen. No stains, no rainbow colors, etc.
The Chinese are not red, the Indians are not yellow and John Wayne is not green, anymore!
However when degaussing fails down; the viewer is immediately exposed to wrong racial prejudices!
So... there's an initial idea for our "problem" here!

[ivconic]

The point (who didn't understand); all programming acrobatics are in vain if the sensor (core) is unstable and subject to strong external influences (unintentional proximity to a strong magnet and the like).
The method described by Altra is good and solves the problem in such cases:

...with a push button command subtract the two frequencies. The difference became the offset value subtracted from the sum of frequencies...

But any sudden external impact on the core will require the button to be pressed again.
And if we are halfway through the measurement somewhere on the "matrix" (area on soil divided by rows/columns), the following measurements will not be in continuity with the previous one.
Pressing the button is done only at the beginning of the measurement, on R1/C1. When changing columns, I always recommend the "parallel" method, rather than the "zig-zag" method.
Precisely because imperfect FGM sensors are orientationally/rotationally/positionally very dependent and labile.
The introduction of constantly available "degaussing" solves all these problems more effectively.
The first big problem; the "degaussing" field must be weaker than the threshold of the natural field, otherwise a lot of sensitivity and resolution is lost.
Another big problem; so a "strong" (weak) "degaussing" field must be sufficient to "reset" the core.
A very delicate task to solve!
Instead; there is a more practical way: a fluxgate sensor with a torus core, with an excitation coil and a "receive" coil.
The core is constantly under the influence of excitation.
Such sensors are superior to FGM sensors.
But in self-construction, it is a big problem to find the right torus with the appropriate permeability. Professional producers generally won't disclose details about it.
All we have to do is experiment.
I tried to find a steady source of such very high permeability torus cores... I failed. At least not such a source available to me and my capabilities.
Existing projects that have dealt with the production of such sensors in detail; they mostly use cores that are "masked" with some labels that are almost impossible to find today.
As a test, I tried to find a core with a higher permeability on Aliexpress... ha, ha, ha!
...
P.S.

And as per the unwritten rule; Murphy interfered again!
I've been looking for months, years, and I haven't found it. Now, for the sake of a joke, I tried; and I found it!
https://kingmagnetics.en.made-in-chi...Ring-Core.html

[Krzysztof]

1. I don't recommend introducing additional nonlinearities of the f/v converters into the digital FGM - it's better to measure directly in the processor on the counter input. A decade ago, my ATMega8 was able to measure FGM directly. Today, the ATMega328 can easily handle 400kHz (without any dividers). Almost no code, you read within 1 second and the value counted is the frequency you are looking for.
2. I've never suggested playing with a neodymium magnet near the sensor.
In my opinion, a strong alternating magnetic field is used for zeroing and it can be a simple homogeneous coil.
I use my own Helmholtz coil design to study the characteristics of the sensor.
3. Due to its design, FGM is not symmetrical in its axis (flat coil over PCB with electronic components).
The solution is, of course, to set it in one long axis, but additionally in the same mechanical position (power outputs in the same parallel position, without twisting).

[ivconic]

[Altra]

ivconic, I agree totally! The op asked for ideas. I never did any field test, but ended up buying a surveyors mag for field use.