Software alignment of magnetometers in a Gradiometer.

[pito]

[/USER]
This is due simply to the earth's magnetic field and is nothing to do with nearby magnetic anomalies. As the difference will vary by some amount when they are rotated it will not be possible to use a single static value to correct for this.[/QUOTE]

This is not what I observe when I was working on scanning magnetometer 7 years ago.
https://www.youtube.com/watch?v=ksOiPFfbzuQ


The unique sensor of my design replaces these magnetometers

[ivconic]

In addition, you should make sure to always hold the magnetometer with the same side to you and not to wear unnecessary iron.
I saw positive and negative (inverse) pulse degaussing before each measurement in integrated magnetometers with dimensions of 3mm x 3mm, used explicitly or embedded in the internal program - they used an additional coil above each measuring coil.
At this point, Ivica, an idea came to my mind: could an additional coil in the FGM led out of the factory be used for a similar reset (setting) of the sensor characteristics?
I'm attaching photos of the use of the Helmholtz coil.

That's the idea. Cu wire coil properly wound across the entire sensor should do the job just fine.
Two short strong pulses with a change of polarity should "reset" the core and remove the remnants of artificial magnetization.
Or several pulses in a row. But then it takes a shorter time for the core to "settle down" and be ready for measurement.
Now you've given me an idea!
The "calibration" procedure would go something like this;
1) you place the sensor tube horizontally at a height of 1 meter from the soil, orientation East-West or West-East
2) you turn off the power supply to the sensors, send identical pulses to the coils around both sensors,
3) change their polarity a couple of times,
4) turn off the pulses,
5) turn on the power supply to the sensors,
6) read the state while the sensor tube is still in a "neutral" horizontal position at, say, 1 meter above the soil.

Option two:
1) you place the sensor tube vertically into the working position, making sure that the pipe does not rotate even slightly on its axis,
orientation East-West or West-East,
2) you turn off the power supply to the sensors,
3) you send teo short strong pulses with a change of polarity,
4) you turn on the power supply to the sensors, take a sample from sensors,
repeat from "2)" to "4)" during the whole survey of the same "matrix".

Both methods will probably show their flaws, but it's interesting enough to try!

[I M]

Just following up after an afternoon's research.

The Patents data was interesting, there were one or two that I looked at but they didn't assist directly, however it did help with my thinking on the subject.

ivconic reminded me of Anthony Clark's book so I re-read his chapter on Magnetics, he acknowledges the issue but doesn't go into any detail.

I skimmed a several papers, and re-read some sections of other books I had, which again didn't directly address the matter but added to my understanding. Surprisingly Archeometry didn't seem to have anything much, however I see a possibly interesting article in Archeological Prospecting, although I have some access issues there so haven't been able to read it at this time.

So at this point, to distill the issue down to a few points and hopefully clarify where things are at I consider there are three related orthogonal vector errors that could arise, and one instrumentation/sensor error. They are:

1. x-error. This is the error that would show itself [assuming the sensors were not perfectly aligned] if you rotated the gradiometer about its z-axis from east to west.
2. y-error. Similar to x-error, except N-S.
3. z-error. This error would arise as the gradiometer is flipped vertically. Depending upon where you are in the world it could have a greater or lesser effect in real operation (ie. depends upon the inclination of the earth's mag field).
4. sensor-error. This error would come about through differences in the sensors even if they were held in precisely the same angle and position in the earth's mag field. Differences in temperature and manufacturing tolerance etc will affect this.

I am coming to a view as to how to deal with 1-3 (in software), I have already addressed 4.

pito We may be at cross-purposes here, not sure, but either way I'll have a look at your link shortly, thanks. That scanning array looks impressive!

ivconic and Krzysztof Interesting approach re Helmholtz and de-gaussing etc. Very worthy of discussion but I will just listen to what you're saying at present as I want to focus on this software thing first. Once I'm happy with that I'd like to address the sensors more as I think much could be done to improve, although you may well have sorted them by the time I get there

[Krzysztof]

I M, consider the technical possibilities of measurement:
The FGM characteristic is of the pseudo tg(x) type, which means that the sensitivity increases for the earth's magnetic field in the N-S axis,
and even better for the Z axis.
Assuming identical settings in the casing pipe (without twisting) and passing the terrain matrix in parallel with the same pipe holding and no fluctuations (deviation from the vertical < +/- 10 deg did not give me a significant error), you can neglect your dilemmas of the initial software configuration. A button for programmatically clearing the differential display at the beginning of the measuring field is mandatory.
Of course, the FGMs should have as similar characteristics as possible (preferably paired), the sensors embedded in the turned thermal casing, and the tube should have the best possible rigidity - the latter is the most important.

[Krzysztof]

Of course, I didn't come across any discussion of the initial setup anywhere, other than remarks about the pipe swinging like a propeller in the first few seconds after powering on (this was at least 10 years back). Back then, it was a matter of setting the maximum and min reads for higher resolution.

[ivconic]

Unfortunately, nothing is ever ideal in practice.
So far I have had over 50 maybe 100 FGM3 sensors.
I opened several of them during the period of time and looked at the internal morphology.
The long narrow pcb on which the coil (two biphalarly wound) is attached, is placed in a plastic container and filled with epoxy.
I assume that in the process of "curring" the epoxy, minimal relative displacements occur.
And most often, the whole assembly is slightly moved at the end.
As in the picture.
First from the left is the ideal situation, which never happens.
Most often, either case A or case B occurs.
It becomes clear why the sensor readings are not the same and are not linear to each other.
There will always be a error and difference.
Keeping this in mind; it is clear that the most accurate measurement is when the tube is always kept in the same position, orientation and rotation.
Because then the shift between readings is always the same.

[ivconic]

In such cases, the mechanical alignment of the sensor in the pipe becomes a very difficult and tiring job and essentially pointless.
Believe me, I spent hours and hours in nature, away from the industrial noise, trying to align the sensors ideally.
I also used the method Carl suggested in his PDF. I also used some other methods.
The greatest possible success that can be achieved is to reduce the shift to some minimum value.
Instead, I later decided on another way to solve this problem.
By using a software "filter".
I read both sensors in parallel and take 30-100 samples per sensor, find the average from those readings and take that value as the reading.
The push-button method described by Altra; calculates the difference between such records and sets the result as a "reference" for further measurements on the surface.
Once the button is pressed; the rest of the measurement should be done so that the sensor tube is always kept in the same orientation, position, rotation and height in relation to the soil.

[I M]

Krzysztof yes I expect that earlier hardware setups might have benefited from knowing the min/max field. These days there's not really the same limitation, however there remains a reason to note the vertical error (as I see it at this point) so inverting the unit at some stage during setup is probably still needed. Useful to read you didn't find much issue with a +/-10deg variation from the vertical though, thanks for that intelligence.

ivconic That's a lot of sensors! Not surprised to read your findings, I always felt they were something from a bygone era that a nice chap was building in his garage at home without ever improving or refining the design. The ones I have use a tapered carapace which I'm not sure is the most useful, but in addition to the issues you've highlighted I also have my reservations over the discrete components in use. My suspicion is that they may contribute to the drift I've noticed with mine, which I was disappointed to see...

Ok on your approach to dealing with the alignment issue. There are of course different ways to deal with these things, and it's very good to hear of what people do to make something work - thank you. At this point mine is already doing something similar (multiple sampling and a 'reference' pushbutton) but I'm keen to pursue the 'proper' setup mechanism, if nothing else so that the information is out in the public domain. To my mind it should already be, and instead of spending ones time re-inventing the wheel we could/should be refining whatever to make it better.

Anyway, having thought more about it overnight, I think the answer is remarkably simple, as these things often are when you get down to it. I will need to try and revive some high-school trig (from a VERY long time ago!), or better still 'phone a friend' but it would seem to me that all one needs to do is determine the offset between the reference fluxgate and the sensing fluxgate in software at each cardinal point (and z dir) as you would do mechanically, then combine the results and apply some trig so that the offset is nulled (and linearly changed) as you rotate from each of these points to the next. I hope that makes sense?

Of course this is independent of the sensors in use - i.e. you'd use this same methodology if you were working with Stefan-Mayer devices or whatever so whatever one comes up with should be applicable to other systems. If the resultant software works ok it should then be reasonably universal and, I would hope, useful to others

[ivconic]

There is nothing strange about it, I am still selling my Euromag 3D in kit.
And sometimes someone orders the whole device. From 2018 until now I have sold a lot of them, I have not kept records.
For each of those I have to get 2 sensors.
At first I purchased directly from Speake&Co. Unfortunately, life circumstances intervened and now I no longer have that option. But I found new sources.
...
In the last couple of years I've had cheap technology available to me, so I've been thinking of building some kind of gimbal based on a 3-Axis Gyroscope.
There are already ready-made projects on the net, so I don't even have to do the whole job, just adapt some existing ones for these purposes.
Pressing the button this time will do two things:
1) "zero" the sensors,
2) set the direction of the gimbal to maintain the position of the tube at all times.
There is only one problem that I can guess.
The small electric motors on the gimbal may affect the correct reading of the sensors, especially the upper one, with their field.
And that dissuaded me from the idea for a while. The next idea; fully mechanical gimbal with "weights" and "counterweights". It requires good mechanical thinking.
...
Oh yes, FLC type sensors are much more convenient to align.

[I M]

... selling my Euromag 3D in kit... I've been thinking of building some kind of gimbal based on a 3-Axis Gyroscope...
The small electric motors on the gimbal may affect the correct reading of the sensors, especially the upper one, with their field.
And that dissuaded me from the idea for a while. The next idea; fully mechanical gimbal with "weights" and "counterweights". It requires good mechanical thinking...

That explains the number of sensors, I didn't realise you were manufacturing something using them.

Not quite sure whether your comment on gimbal is related to your 3D kit, or whether it's to do with a gradiometer (maybe the 3D kit IS a gradiometer?), but I wonder about using a mechanical gimbal today when it's so easy to correct angular error in software with a MEMS gyro. In addition to the physical design being much simpler you wouldn't have the issue of motor interference with the mags. No doubt there's a good reason but FWIW some years ago I designed and built a self-balancing scooter (like a 'Segway') using just this methodology and it worked very well. I expect it would be trivial to adapt that code to operate as a virtual gimbal (something I alluded to in an earlier post here), in fact there are probably much better code examples today that would fit such a need than what I did back then.

I recall thinking the Stefan-Mayer sensors were well made, and potentially more stable (would be interested in comments on this from anyone that's used them - particularly with regard to drift), however I was less happy with the whole ADC->DAC thing. Seemed to me to be an unnecessary step and something prone to noise etc, one plus point for Bill Speake's units when interfacing with a micro of some sort.

[ivconic]

I can't think and comment on something I haven't had contact with before.
I have had some work with MEMS microphones but not with gyro.
I have several accelerator modules from similar things.
I have ADXL345 and MPU-6050 in my pile of modules.

[I M]

MPU-6050 would do nicely I'd have thought? IIRC I've used one with both C and Python in several disparate projects, but sadly not as a virtual gimbal so that code wouldn't be directly applicable.

However a quick search shows quite a few examples that would be adaptable, if not a complete fit as is. Where they're being used (say with an Arduino) to control servo motors in a mechanical gimbal arrangement you could probably take the control output (in the code) as correction data (sans the servos) and combine with the magnetic sensor output.

I realise this is a fairly high-level view, and that there could - indeed are probably - issues with such a proposal, but it would initially seem do-able to me?

[I M]

ivconic just to show there's nothing new under the sun:

https://www.nxp.com/docs/en/application-note/AN4248.pdf
https://www.best-microcontroller-pro...pensation.html

I only had a very quick look and haven't read anything in detail (busy today), and there seemed to be many more examples, but from what I saw they were all about 3-axis mags, however the principle would be much the same for a gradiometer or whatever. It was always my intent to explore this, but only once I've got this orientation thing sorted - at least in my mind. For my purpose I could just do what I want with an IMU, or additional 3-axis mag (or perhaps neater still a 9-DOF MEMS chip) but that would seem to me to be 'cheating', and may not be necessary...