Minelab 8000

[Aziz]

Hi all,

now added multi path definition feature. A coil can consist of several individual parts.
Move, scale and rotate on section is also implemented.

Dilatation and contraction of wire path referred to its reference is also important.
I have maybe implemented 50 % of the required features.

[Aziz]

Dilatation and contraction is very important as a coil bundle can't be really realised with scale only commands.
And I am also thinking of cubic spline interpolation feature for coils. A better coil geometry and accuracy can be realised.

Oh man!, it is more than 34 years ago I have done cubic spline interpolations (in the exam!).
This might be a good job for AI coding...

[Aziz]

Yep, I really need 3d-cubic spline interpolation. This is a must-have feature.
We can model complex fusion reactor coil arrangements with it..

There we have the next evolution and slight changes:
I have to distinguish between a wire path (physically existing wires, implemented in the current version) and a geometric path (which does not create any wires). From the geometric path definition, I can create the smooth wire path finally.

Let me think of it further.
Thinking. Changing. Implementing. Testing.

[Aziz]

WTF, how to contract and dilatate a path?

I have finally found the implementation of the dilatation and contraction algorithm part (already implemented in 2024).
This is beeing used for magnetic flux calculation of the single wire element.
dir = 0: calculate magnetic flux up to the center axis of wire element
dir = 1: up to the outside of the wire element (dilatation)
dir =-1: up to the inside the wire element (contraction)
pLeiter->LeiterR is the dilatation/contraction distance (wire radius in this case).

I think, I can reuse the code section.

      // 2024 neu: Winkelabhängigkeit wird berücksichtigt
      //
      VEKTOR _dse, _R1e, _R2e;
      double a1, a2, tan2a1, tan2a2, rx1, rx2;

      VekCopy(_dse, pLeiter->ds);
      EinheitsVektor(_dse);

      VekCopy(_R1e, _R1);
      EinheitsVektor(_R1e);

      VekCopy(_R2e, _R2);
      EinheitsVektor(_R2e);

      a1 = _PI_H - acos(-SkalarProdukt(_R1e, _dse));
      a2 = _PI_H - acos( SkalarProdukt(_R2e, _dse));
      tan2a1 = tan(a1);
      tan2a1 *= tan2a1;

      tan2a2 = tan(a2);
      tan2a2 *= tan2a2;

      rx1 = pLeiter->LeiterR * sqrt(1.0 + tan2a1);
      rx2 = pLeiter->LeiterR * sqrt(1.0 + tan2a2);

      VekAddSkalarMul(_R1, _R1, rx1*dir, _R1e);
      VekAddSkalarMul(_R2, _R2, rx2*dir, _R2e);
​

Don't ask me what I have did. I don't know anymore.
But it speeds up the implementation.

AI totally sucks! It can't do it.

[Aziz]

Well ok,

dilatation/contraction of a path needs a more accurate solution.

This elliptical coil is done with duplicate scale modifier. Note, that the bundle thickness scales too.

And this is done with dilatate/contract modifier. The bundle thickness stays same.

But the latter one produces inaccurate wire locations.
Back to the black board.
AI, why don't you do that?

[Aziz]

Hi all,

well, the very basic dilatation/contraction variant could still be enough to use it. Slight model inaccuracy on special shaped coils won't really matter much.
For circular coils, there won't be any inaccuracy.

The wire element start and end point locations are consistent.
We can define each wire path individually for more accuracy without using the dilatate and contraction function at all.

I'll look for another solution with better results.

[Aziz]

I am probably soon able to model the GPZ 7000 Super-D/X-coil. All this development effort was just made to be able to model any shaped coils.

[Aziz]

Hi all,

ok, there is a good solution for the dilate/contract feature problem. Fortunately, the related functions share the same infrastructure for 3d-cubic spline interpolation function.
There are some wire/path management functions required. And I have to introduce tag-ID for wires and path. Similar to NEC antenna modelling specification.
This is the big change.

[Aziz]

Have a look:

Part 4:
https://www.youtube.com/watch?v=BYNw-QmCMcI
and this
Why you get extreme detection depth on small bits of gold: The Truth.
https://www.youtube.com/watch?v=QQ4ixTo-ds4

Old technology with the right coil would be an outperformer for big deep gold.
A noisy detector would drive me nuts. Really. The GPZ 8000 seems to be quite noise.

[Aziz]

Hi all,

I have now integrated the new geometric definition of special coils into the coil software.
Scaling, Rotating and Movement of coils already implemented.



We are very close to simulate fusion reactor coils.

[Aziz]

[Aziz]

Hi all,

a good quiz for all smart brains out there.

A DD coil: TX 300 µH, 1 A TX current, RX 300 µH
What happens, if we halve the TX coil inductance from 300 µH into 150 µH?
According to TX coil reactance:
XL = 2*pi*f*L -> XL will be halved too
If we neglect the ohmic resistances, the TX current doubles into 2 A with the same voltage source.
But we have the same coil energy E stored in the TX coil:
E = 0.5*L*I²

RX coil inductance remains at 300 µH.

What is better regards to target response seen on the RX coil?
a) don't change anything (initial condition)
b) half TX inductance, twice TX coil current

Don't feed the text into AI! You will get the correct answer!

[Carl-NC]

But we have the same coil energy E stored in the TX coil:
E = 0.5*L*I²

Energy is doubled.

[Aziz]

Energy is doubled.

E1=0.5*L*1² = 0.5*L
E2=0.5*L/2 * 2² = 0.5*L/2 *4 = 0.5*L*2
Yes, my bad! Thanks.


I am asking myself:
A metal detector coil is specified. After market coil makers must use the specification.
But what happens, if a coil maker takes 240 µH for the TX coil (instead of 300 µH) and 400 µH for the RX coil (instead of 300 µH).
Would that outperform the exact specified detector coil?
You know now, why some after market coils run better than the original coils.

[Aziz]

Hi all,

this is my first attempt and experience on any shape coil design. I have scanned upper half of a picture of a commercial DD coil (left part only). Translated pixels into a coordinate system. Scaled the coordinate system to a fixed coil size. The calculated coordinates were taken into the coil description file. There is a good work-around for dilate/contract problem at the moment. I have to change my reference point to the mean center of the coil. Then made the dilate/contract commands (horizontal). Then made the bundle by duplicate move commands towards z-direction (vertical).

The receive coil does use the same coil geometry definition file. Just mirrored the x-coordinates by the scaling vector (-1 1 1).
That's all. This is the coil geometry code:

ref 0, 0, 0
xyz
0.031778    0,000000, 0
0.031778    0.027995
0.030008    0.052964
0.027902    0.078689
0.024412    0.106684
0.020429    0.130139
0.015132    0.141488
-0.006810    0.161917
-0.030265    0.180833
-0.043127    0.187642
-0.059017    0.188399
-0.077175    0.183859
-0.102144    0.174023
-0.127113    0.158134
-0.152081    0.140732
-0.172510    0.121060
-0.192939    0.097604
-0.210028    0.068853
-0.222447    0.031778
-0.225000    0.000000
sec path
dups 1 -1 1
ref -0.085, 0, 0
sec sort
sec path
dupd 0.0025
dupd 0.005
dupd -0.0025
dupd -0.005
sec path
dupm 0 0 0.0025
dupm 0 0 0.005
dupm 0 0 0.0075
end

This is the generated DD-IB coil system.


We should even be able to work at this current stage of the coil software.