DSP in commercial prospecting and treasure hunting metal detectors ... and GPZ 7000 speculation

[scrungy_doolittle]

This way of addition of 3 consecutive samples actually removes the 3rd harmonic, and with factors sqrt(0.5) also the 5th as the components of the 3rd and 5th contained in them get mutually subtracted. Higher harmonics are far more volatile with changing ground proximity, so this will give more quiet rig. Even harmonics are removed due to the balanced sampling.

I have no idea why dividing by 200, and it must have something to do with arduino atan2 function that returns arc tangent of y/x. Applying ideal atan2 function would yield same result with and without divide by 200. As I'm not familiar with arduino math, I have no idea what might be the motive there. Most probably atan2 is based on some lookup table and precision may vary.

What would I do different?
First off, I'd avoid micro in the first place, despite the tempting FIR boxcar filtering. Lets pretend I regained my liking for the micros.

First there are a few details that are missing here, namely ground balance. Without it this is merely a nice pinpointer. To add a ground balance, one should play with phases in a way that linear combination of the orthogonal phases (bin0⊥bin2 and bin1⊥bin3) produce zero at ground phase. Simple really, as the routine to establish phase is already implemented. In the end the amplitude (all metal, no ground) is absolute value of the ground balance vector, instead of the sum of squares, as implemented now.

The fun part with this rig is that it is fully static, with simple "calib" function to remove offset. It would be much simpler if there is a simple boxcar highpass added as well, but it would take many more samples to average than just 1024. If there is enough memory to do 1 full second or more, it would be interesting to see perfect FIR slow motion detector with no ringing. Switch on and go - that simple.

So my approach would be to add FIR boxcar high pass in duration of, say 4 seconds, and a button to turn on GB calibration in place of the "calib" function used now. THAT would be something else.

Dividing by 200 was just to keep things easier to send over the serial port he says.
So a high pass filter of 4 seconds would give you a gb signal that is updated every 4 seconds? With the Nucleo it should be quite easy.
As Tinkerer says, it is impressive, but you have to run it at 96 mhz if you want to use the USB channel for comms.

And as for a high pass FIR there are two ways to do this. keep a lot of memory readings, remove the oldest add in the newest. I do that with a 32 entry buffer in the medical device. BUT
There is also a way to do it with only having to store one value.
I don't have the basic algorithm handy, but my memory serves to tell me it involved taking a single stored value, and a sample value, and modifying the stored value by a multiply and divide involving the input.
Would have to do some webbing.
http://iowahills.com/5FIRFiltersPage.html seems to be a good general link.
With a filter designer.
http://stackoverflow.com/questions/1...and-data-total

4down vote

New average = old average * (n-1)/n + new value /n This is assuming the count only changed by one (in case it changed by m then: new average =old average * (n-m)/n + sum of new value/n). This is the mathematical formula (I believe the most efficient one), believe you can do further code by yourselves

Of course you have to replace old average with the new one....

[Daren]

STM32 the is the way to go. STM32F3 or F4 can sample 12 bits at 20nS

Correction: it should be 0.20uS at 12 bits.

[Davor]

So a high pass filter of 4 seconds would give you a gb signal that is updated every 4 seconds?

No, it would give me a motion detector, and a perfect one in case of a boxcar (FIR moving average) high pass. The only thing I can't do in analogue electronics is FIR filtering. Some other are difficult to achieve, but FIR is downright impossible.

As Tinkerer says, it is impressive, but you have to run it at 96 mhz if you want to use the USB channel for comms.

I couldn't care less about USB in metal detecting. I can use low power bluetooth, and perhaps even IR, but I have no use for USB(wires) nor WiFi (too much juice). I do care about ADC dynamic range, and 12 bits ADC is ****-poor on its own. Maybe in some differential configuration, but straight 12 bit is just silly.

And as for a high pass FIR there are two ways to do this. keep a lot of memory readings, remove the oldest add in the newest. I do that with a 32 entry buffer in the medical device. BUT
There is also a way to do it with only having to store one value.
I don't have the basic algorithm handy, but my memory serves to tell me it involved taking a single stored value, and a sample value, and modifying the stored value by a multiply and divide involving the input.

Recursive filters are known as IIR filters, and they have implementations in analogue world. If I want to use an IIR filter, I simply put a capacitor.

In metal detecting you have one elusive thing that only select few detectors have sorted properly. That's a recovery speed, and XP Deus among detectors. The vast majority of nowadays detectors have incredibly stupid amounts of inappropriate excessive filtering. IIR filters smear the response, and a sharp signal becomes blunt. After many stages of filtering the signal is so much bludgeoned and spread in time that you can't distinguish it from the next signal, and the vast majority of detectors simply cant discern, say, two coins in a row. Deus can, and my IGSL can as well.

Time-wise the best of FIR filters is the simplest one, a boxcar. It has a very finite time response, and silly but usable frequency response. In frequency response the most important feature is -3dB bandwidth that limits the noise and keeps S/N in favourable limits. That's it. Everything on top of it excessive.

[golfnut]

One potential improvement in response is the use of adaptive filters who alter their response.


For fast swingers it would move the filter up and vice versa.

So the BW isnt high all of the time, reducing S/N


Lots of machines have a filter a little tight, set a little low forcing the user to a slow swing, and at an exact rate, but often the user swings at 'their' rate and looses sens as any targets would be reduced by the roll off.

For top sens and least noise for - all users - all of the time, a small accellerometer would give info for swing rate. The filters would centre on the freuquency where signals would come thru


the other thing that sprung to mind writing this is, the fastest part of the swing is in front of you, and zero at the ends- the filters could track the sweep so all of the signal was in the filter

[Davor]

That could do fine, and perhaps some future generation of rigs will have such option, now that accelerometers are so ubiquitous. You'll not get much improvement that way, but some improvement nevertheless. We are not advancing lately at all, so that would be something.

[scrungy_doolittle]

No, it would give me a motion detector, and a perfect one in case of a boxcar (FIR moving average) high pass. The only thing I can't do in analogue electronics is FIR filtering. Some other are difficult to achieve, but FIR is downright impossible.


I couldn't care less about USB in metal detecting. I can use low power bluetooth, and perhaps even IR, but I have no use for USB(wires) nor WiFi (too much juice). I do care about ADC dynamic range, and 12 bits ADC is ****-poor on its own. Maybe in some differential configuration, but straight 12 bit is just silly.

Recursive filters are known as IIR filters, and they have implementations in analogue world. If I want to use an IIR filter, I simply put a capacitor.

In metal detecting you have one elusive thing that only select few detectors have sorted properly. That's a recovery speed, and XP Deus among detectors. The vast majority of nowadays detectors have incredibly stupid amounts of inappropriate excessive filtering. IIR filters smear the response, and a sharp signal becomes blunt. After many stages of filtering the signal is so much bludgeoned and spread in time that you can't distinguish it from the next signal, and the vast majority of detectors simply cant discern, say, two coins in a row. Deus can, and my IGSL can as well.

Time-wise the best of FIR filters is the simplest one, a boxcar. It has a very finite time response, and silly but usable frequency response. In frequency response the most important feature is -3dB bandwidth that limits the noise and keeps S/N in favourable limits. That's it. Everything on top of it excessive.

O.k. Davor, lets assume that you have dropped, for the moment and the purposes of discussion, your aversions to micros . I assume you certainly understand enough of C to write some.
Given the way this code uses "boxcar" filters (which I have always called 'bucket' ) filters, can you express the additions that would be necessary in the code to give a ground balance?
Suppose we have the 4 second "boxcar" high pass filter. What do you do with that? And where and how would you use that to implement ground balance? I think his calibrate is a crude ground balance, as it takes a reading presumably over a non target, and saves it. by subtracting that from the ongoing signals, you essentially remove the sensed component that you calibrated, and that should be the ground matrix. So how would you implement an auto ground balance? Please note, that he is using an 8 BIT dac, because at the sampling rate he is using, the arduino can only resolve 8 bits, but he is gaining 5 bits in the boxcar filter.. However, with a 12 bit ADC and a 1024 boxcar, by the same logic mentioned in another post (and I think it was you that said it) , it should be equal to a 16 bit.
Regardless, lets see if we can take this logic and manage to add ground balance, and auto-tracking ground balance to it. Even with the bad dac. Cause it will be fairy easy to move the code
to a more capable platform.

[Qiaozhi]

I think his calibrate is a crude ground balance, as it takes a reading presumably over a non target, and saves it. by subtracting that from the ongoing signals, you essentially remove the sensed component that you calibrated, and that should be the ground matrix.

It appears from his description that the calibrate function is really a form of self-adjusting threshold (SAT), which is not the same as ground balance. His implementation is essentially a T/R detector, and would require the coil to be kept parallel to the ground, and for the ground to be flat.

[Davor]

@scrungy_doolittle, first off, I consider you lucky to receive the ground balance concepts before other concepts mess your head too much.
Ground is balanced in multiplicative way in VLF, and additive way in PI. Additionally in PI you start sampling after the full response of ferrous ground, and most of the salts have subsided, and you only need to remove the superparamagnetic (viscous) soil response typical for the gold fields. Simple PI devices gained popularity because of virtually no ground response on easy soils.
Using addition to remove ground works in multifrequency VLF though. I did not think highly of it before, but I changed my mind.

You may consider ground as one huge target. Easy groud responds in phase (~0°) with Tx, and it is only shifted for the degree determined by salts. Most nowadays VLF-s have up to 30° regulation for ground balance. You can't remove ground by simple offset as I believe you had impression so far, simply because coil wobbles over ground and proximity changes. Removing offset works against "air signal" though.

In PI easy ground follows the Tx field verbatim, so when flyback subsides you only have responses of targets, a coil (!), and the soil viscous effects - if any. Offset is removed in PI by means of EF sample.

Suppose we have the 4 second "boxcar" high pass filter. What do you do with that?

Remove offset and too slow changing phenomena, like temperature, battery voltage etc. A strong source of offset is "air signal" - a residual voltage that is impossible to remove completely while balancing a coil. Air signal is also affected by Tx amplitude, so noisy Tx destroys your depth.
Such filter is basically a simple boxcar averaging lowpass whose value is subtracted from the incoming signal, servo style. Each phase on its own.

And where and how would you use that to implement ground balance?

Not. You need to remove offsets so that your trigonometry starts working. Otherwise you have no target ID.

I think his calibrate is a crude ground balance, as it takes a reading presumably over a non target, and saves it.

Nope, just offsets.

by subtracting that from the ongoing signals, you essentially remove the sensed component that you calibrated, and that should be the ground matrix.

It does not remove ground matrix because the ground effects are dynamic, and offsets not so much.

So how would you implement an auto ground balance?

By implementing a PLL/Costas loop GB chasing procedure in a single frequency implementation, and only some simple arithmetic in case of multifrequency.

Please note, that he is using an 8 BIT dac, because at the sampling rate he is using, the arduino can only resolve 8 bits, but he is gaining 5 bits in the boxcar filter.. However, with a 12 bit ADC and a 1024 boxcar, by the same logic mentioned in another post (and I think it was you that said it) , it should be equal to a 16 bit.

Which is barely enough to make a semi-decent detector for your kids.

Regardless, lets see if we can take this logic and manage to add ground balance, and auto-tracking ground balance to it. Even with the bad dac. Cause it will be fairy easy to move the code to a more capable platform.

I thought of that, and concluded that only an interactive automatic GB makes sense in single frequency VLF. Call it semi-automatic if you like. Fully automatic would GB on the targets as soon as you start pinpointing, rendering it useless when you approach a target and become slow.

Much easier is a multifrequency approach, assuming I regained my liking for the micros.

[scrungy_doolittle]

@scrungy_doolittle, first off, I consider you lucky to receive the ground balance concepts before other concepts mess your head too much.
Ground is balanced in multiplicative way in VLF, and additive way in PI. Additionally in PI you start sampling after the full response of ferrous ground, and most of the salts have subsided, and you only need to remove the superparamagnetic (viscous) soil response typical for the gold fields. Simple PI devices gained popularity because of virtually no ground response on easy soils.
Using addition to remove ground works in multifrequency VLF though. I did not think highly of it before, but I changed my mind.

You may consider ground as one huge target. Easy groud responds in phase (~0°) with Tx, and it is only shifted for the degree determined by salts. Most nowadays VLF-s have up to 30° regulation for ground balance. You can't remove ground by simple offset as I believe you had impression so far, simply because coil wobbles over ground and proximity changes. Removing offset works against "air signal" though.

In PI easy ground follows the Tx field verbatim, so when flyback subsides you only have responses of targets, a coil (!), and the soil viscous effects - if any. Offset is removed in PI by means of EF sample.



Remove offset and too slow changing phenomena, like temperature, battery voltage etc. A strong source of offset is "air signal" - a residual voltage that is impossible to remove completely while balancing a coil. Air signal is also affected by Tx amplitude, so noisy Tx destroys your depth.
Such filter is basically a simple boxcar averaging lowpass whose value is subtracted from the incoming signal, servo style. Each phase on its own.



Not. You need to remove offsets so that your trigonometry starts working. Otherwise you have no target ID.



Nope, just offsets.



It does not remove ground matrix because the ground effects are dynamic, and offsets not so much.



By implementing a PLL/Costas loop GB chasing procedure in a single frequency implementation, and only some simple arithmetic in case of multifrequency.



Which is barely enough to make a semi-decent detector for your kids.



I thought of that, and concluded that only an interactive automatic GB makes sense in single frequency VLF. Call it semi-automatic if you like. Fully automatic would GB on the targets as soon as you start pinpointing, rendering it useless when you approach a target and become slow.

Much easier is a multifrequency approach, assuming I regained my liking for the micros.

ROTFLMAO!
Typically when pinpointing you don't have GB present. I am using my whites 5900di pro (actually a 6000 Di Series 3) for my comment. I search about 70% of the time in TR mode without ground balance, but with a VDI meter. I have found a lot of stuff that way, just yesterday I hit my second Sacajawea US dollar! But I digress. I also do use GEB TR, but when you go to pinpoint mode, it does geb normal.
Since TR mode is a non motion/slow motion mode, I use it to pinpoint a lot of the time. I'm basically just a coin shooter at this point.
One has to walk before running. So a simple manual ground balance in a computerized one is a good first step. So if we can just add the code to this arduino sketch, that would give you ground balance, i.e.
Raise the detector, press a button. lower the detector, listen to the signal if it changes, alter the ground balance and repeat until it doesn't change, then we have a detector that can be tweaked to be at least as good as the 6000 di series 3. The 6000 di pro did an auto ground balance and tracking, and an awful lot of guys didn't like that. The old manual gb was more popular.

That being said, auto gb would be a good thing, and would be fairly easy to add.
The problem I see with doing this on the arduino code, is that there is no way, with 8 samples to be able to apply some arbitrary phase shift and get data. I want to port this to a decent processor that can take at least 180 samples over the full cycle, which would give you a 2 degree resultion. Even better would be 360 samples, so you have a single degree resolution for phase shifting and sampling the digitized data.

So for theoretical: Suppose that we could digitize a waveform at 360 samples per cycle. We can get the sample points by indexing into the buffer at indexes correspondint to the 8 samples, and put those in the boxcar filter. At that point, we have exactly what he has in the arduino code. BUT we also have all the other sample points available. If you digitized the received signal and transmitted signal, then you can do anything with them.

That being said, I still wonder how one would do GB on the same code. I would think that multi frequency would actually be much harder, because you would need to drive 3 coils at different frequencies simultaneously and be able to extract and separate the 3 signals and process each of them. This is obviously what the 3 frequency whites machines are doing.

Get a single frequency one done and working first.....

[golfnut]

"because you would need to drive 3 coils at different frequencies simultaneously and be able to extract and separate the 3 signals and process each of them. This is obviously what the 3 frequency whites machines are doing."


Id guess they utilise the fact that a resonant circuit will resonate at the fundamental, and the odd integer multiples ,,,, 3rd 5th etc

[Davor]

I want to port this to a decent processor that can take at least 180 samples over the full cycle, which would give you a 2 degree resultion.

Total overkill. You need only 4 samples to obtain any phase shift you want. A little bit of trigonometry is all you need. With single frequency rig all you need to do is a way to increment/decrement phase shift in small steps, say 1°. You only need a shifted Q phase such that it remains at zero while bobbing a coil. You can achieve that by two buttons, or a single button for semi-automatic solution.

As for multifrequency, you may use coil in resonant mode, or non resonant, and you may use various waveforms. CZ uses a simple square wave and observes the 3rd harmonic. It can be made incredibly simple, but I'm not sharing as yet. I need to try it first.

[6666]

It can be made incredibly simple, but I'm not sharing as yet. I need to try it first.

Davor are you planing to post your results even if they are good or bad ?

[Davor]

I can only speculate about results until I can get any. These ideas cost money and time. I'm short on time, and I can't expect anyone to invest time or money over some half-done ideas. I'm pretty certain it will not happen this year at this pace.

Besides, I might just suddenly start some production - who knows?!?!

Perhaps it would be easiest to play in a micro. For start I'll need to overcome my aversion to micros, find a platform I can trust not to do vanishing act in a year or two, which also has some decent specs on ADC, lots of memory, low power consumption, and easy programming tools. Any suggestions?

[CAS]

Perhaps it would be easiest to play in a micro. For start I'll need to overcome my aversion to micros, find a platform I can trust not to do vanishing act in a year or two, which also has some decent specs on ADC, lots of memory, low power consumption, and easy programming tools. Any suggestions?

I have ordered one of these. Discovery Board for STM32F411E

http://au.rs-online.com/web/p/proces...-kits/8463503/

Good price, good speed, 12 bit ADC plus a few added goodies like onboard Audio DAC

[6666]

Besides, I might just suddenly start some production - who knows?!?!

Dont stop now