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

[Qiaozhi]

If you oversample the RX signal, and then divide the accumulated results by the number of samples, you will still have the same resolution as if you took only one sample. The only difference is a reduction in noise.

To increase the resolution of an ADC by one bit, you need to oversample by 4x. Somewhat counter-intuitively, the oversampling and decimation process requires a small amount of noise to be present in the signal. In other words, the signal needs to vary by at least half of the least significant bit, and in practice 1 to 2 LSBs are better. If the signal is essentially noiseless (less variation than 0.5 LSB) you will need to artificially add noise. This is referred to as "dithering" - something my wife is very good at. By the way, decimation is often called interpolation.

The process of decimation is fairly difficult to explain in a few words, but luckily is simple to implement. Basically, instead of adding the extra samples m and then dividing by m, you right-shift the added samples by n, which represents the extra bits of resolution required.
If you read the attached App Note, then things will become a lot clearer.

[scrungy_doolittle]

Actually, that's not correct. To increase the resolution you need to use decimation in conjunction with over-sampling. Integration alone will only help to increase the signal-to-noise ratio. The downside is the extra time required to perform the oversampling and decimation process.

Thanks for the correction. That is not what I understood from my research. (see the atmel explanation below)

In the pic24 the oversampling takes no extra time. It may also have a decimation feature as well, if I remember right.
It is a *very* impressive ADC system.
If it only had more ram, I would have picked it for everything. As it was, it would have made a good front end for the GG project, but there would still have to have been a way to get the data
transferred to a more capable processor for the processing.

So could you please explain to me how one would use decimation along with 10x oversampling to increase the resolution? I understand that decimation is used to reduce the data rate, i.e. throw away every few samples, but how would that improve the resolution?

The PIC24 also has a 16 bit sigma-delta but it only is a 62,500 samples per second ADC and would not be completely adequate to fully sample much over a 6592 hz signal with any kind of resolution. Sure it could get the nyquist criteria, but that would be about the same sample rate as the arduino.

here is what atmel has to say

Oversampling is a
process of sampling the analog input signal at a sampling rate significantly higher than the Nyquist
sampling rate. The main advantages of oversampling are:
1.It avoids the aliasing problem, since the sampling rate is higher compared to the Nyquist samplingrate.

2.It provides a way of increasing the resolution of the ADC. For example, to implement a 14bit converter, it is

enough to have a 10 bit converter which can run at 256 times the target sampling rate. Averaging a group of

256 consecutive 10bit samples adds four bits to the resolution of the average, producing a single sample with

14bit resolution.

3.The number of samples required to get additional n bits is = 2n^2

4.It improves the SNR of the ADC

[Qiaozhi]

Integrating the samples increases the resolution.

Actually, that's not correct. To increase the resolution you need to use decimation in conjunction with over-sampling. Integration alone will only help to increase the signal-to-noise ratio. The downside is the extra time required to perform the oversampling and decimation process.

[scrungy_doolittle]

What are you referring to (GG grouo, nucleo board)?

Tony had a project called the Golden Goose which was a computerized PI detector. A guy named MOODZ was doing the software, and using a PIC33. The way he was doing it did not work, and he eventually went off on his own. I've volunteered to help Tony and crew do this. The STM32F411 nucleo board is a 10.33 eval board for the STM32F411re processor. It can run at 100 mhz, but if you want USB you have to run it at 96 mhz. IT has some dsp type instructions as well. The ADC is a 12 bit ADC with a 2 megasamples per second rate (.5 usec), and has a DMA channel. I also have a project I want to do for an IB detector, so along with the guy that is working on the code for another project that Tony has, the two of us decided to try to use a common platform for both a sophisticated PI detector and an IB detector so common code would work.

My tack with this, is to run the ADC full tilt, with DMA to move the data to memory. For the PI detector we are going to be issuing a 10 pulse burst, digitizing it, and integrating it to the equivalent of a 1 pulse signal i.e. 10x over sampling. The rep rate is such that it should take a bit over 1 ms to accomplish, since each burst will be 100 usec followed by 7 microseconds of silence. Because of the design, we will be sampling immediately coherent to the pulse, so we will get the entire range of data, and can work on the section that normal PI's can't get to.
For the IB detector, I want to generate the sine wave, and digtize both it and the received wave on alternate channels of the ADC, using the dual buffer feature of the 411. This way, I will get
a sample of the transmitted coil in 500 ns. and one of the receive in the next 500 ns. By doing this it will be possible to capture a compete wave form or more than one, since we have over 100K of ram on this part as well as 512K of flash. Then sampling like is done on so many detectors (whites etc) where they use a pulse to gate a portion of the wave form, based on some phase shift offset, can be done by simply indexing into the buffers at the appropriate spot and averaging up the data values between the two sample point indexes.
I think this is what the KROT is doing. Basically, the same hardware engine and same sampling code engine will work on both applications. My goal is a pure digitial IB detector that is open source, and open hardware, public domain, not quite like the KROT which is open hardware, closed source code.
The Golden Goose project will be a very advanced PI detector. It is a diverse and spread out team, but a small one. Which works best I think.

Meantime I stumbled across the arduino project based on a 16 mhz processor with a 1 mhz/16 ADC. (16 clocks allowed, typically at 8 bits it is 13.5 clocks,) but 8 bits is not much. So I want to port this over to the STM32 or a pic24 and work on it. Thus I am trying to understand what is actually going on in the code, which is why I posted it to the forum.

I *will* eventually get to an open source IB that should be a good one.
My preference was a PIC24FJ128GC010 running at 24 mhz with a 10 msample ADC, but it does not have much ram (8K) which is not enough for the PI project, but would be pretty good for an ib.
Consider 6592 hz (which is what whites runs at). 1 cycle is 151.699 usec. So at a sample rate of .5 usec, that is about 306 words (at 12 bit resolution, that would be 612 bytes). So one could store 10 cycle samples in a bit over 6K. Since in either case, that is done via DMA and ADC, all you have to do is work on a section of a buffer, that is essentially a window into a sliding
buffer of data, you let the DMA move the buffer around.
I can do this with the stm32 or a pic24.

As I said, I am working on a project with an STM32 for a PI so the same sampling logic will work.

there is no big difficulty in doing realtime sampling and processing at 6 -12 khz.

[bklein]

Yeah. The GG group is using a STM32F411. The nucleo board is cheap. 10.33

What are you referring to (GG grouo, nucleo board)?

[scrungy_doolittle]

The Cortex M4 family was publicly released by ARM in 2010. STM32F4 family is Cortex M4. I am not sure when ST Microelectronics had the STM32F4 in production, however you can be sure they had early libraries from ARM since they are an enormous ARM customer. Carl and scrungy_doolittle have referenced DSP used (in some manner) in commercial detectors to answer my original Q. Thx folks!

I'll opine that the use of DSP seems relatively slow to adopt in this industry relative to say, audio consumer products. More than anything, I'll opine this is mostly an economics issue. The world-wide metal detector industry is but a minuscule fraction of the worldwide consumer audio industry. For every Carl and Bruce Candy, there are several orders of magnitude more equally sharp engineers with proportionally more $ behind them developing audio products (as just one consumer product example extensively utilizing DSP for many years).

Maybe the "STM32F???" in the GPZ 7000 is a STM32F4 (or higher end) using direct sampling?

The STM32F411 is current production. It has DMA and a fast ADC, so completely and accurately reproducing the received waveform is pretty trivial and doesn't load the processor down to much.
You have to run it at 96 mhz if you want USB, but it will run at 100 mhz. So there is more than enough processing horsepower (and it even has some DSP type instructions).
The development environment is free (they are just releasing a bare metal IDE/Compiler from openstm32.org. No royalties on either the code or the compiler, or what you produce with it.

[scrungy_doolittle]

2MSps is more than enough speed, but 12 bits isn't enough resolution. The Minelab X-Terras are direct sampling, and the White's Prizm 6T/CoinGT is a direct quadrature sampling. I believe that both use 24 bit ADCs. You could do a reasonable direct sample with as little as 64kSps (8X for 8kHz).

Integrating the samples increases the resolution. In the PIC, you can specify an oversample count. So at the PICS sample rate, maximum at 10 million samples per second, and you set the oversample count to 100, you get a reading on each completed sample set that you can divide by 100 to get an average. This picks up some number of bits of resolution. Really, Carl, all you
need to do is to *COMPLETELY* digitize the signal coming in. And 12-14 bits is more than adequate. Once you have the *entire* waveform in memory, then you can multiply, and filter and yank samples out of the wave form and get pretty accurate data. using DMA to move the data to memory removes constraints on samples and interrupts, which are normally what limit you more than just resolution. 12-16 bit resolution on a 200 mv signal is quite good.

[Qiaozhi]

I sure would like to understand the math behind this: https://github.com/dc42/arduino/blob...alDetector.ino

Specifically, this uses 8 samples per period, but it looks like he is taking the negative swing and subtracting it from the positive swing.
Basically he set T0 to interrupt 62,500 times per second, and uses T1 to divide the system clock by 256 then further divides it by 8 to get the clock tick.
Then in the timer 0 interrupt overflow handler, he reads the ADC (which is only 8 bits at this 1 mhz sample rate, and he adds the first 4 samples into a 4 entry array, then subtracts the next 4 ADC readings which are negative going from the first 4 which makes no sense whatsoever.
Then after he has added up 1024 samples, he copies the array somewhere and zeros it and starts over. This sampling is on 45 degree increments.
The code that I don't understand is the following:

double bin0=(averages[0]+.707 * (averages [1]-averages[3])) / 200.0
double bin1= (averages[1]+.707 * (averages[0]+averages[2]))/200
... there are two more of these He says he is removing the 3rd harmonic and dividing by 200. What the heck is this doing?

Looks like everyone is too scared to answer this question.

I'm not familiar with the Arduino platform, but it looks as if he's taking 8 samples per TX cycle, and splitting the cycle into 4 quadrants (or phases), where:
phase0 = 0 to pi/4
phase1 = pi/4 to pi
phase2 = pi to 3pi/4
phase3 - 3pi/4 to 2pi

The TX coil is driven directly by the processor at 7.8125kHz. Since this is a square wave (which consists of the fundamental plus all the odd harmonics) he seems concerned abut the 3rd harmonic. I don't pretend to understand how he's attempting to eliminate it, but I assume it's part of the subtraction process. The division by 200.0 appears to be some sort of convenient scaling factor, probably obtained empirically, as there's no obvious relationship with the timer settings.

As far as I can see. there are 2 samples per phase. The addition and subtraction between the various phases should yield a zero result when no target is present, but since the RX signal is offset in phase from the TX, he also includes a calibration mode which stores the residual values due to the phase offset. These are then subtracted from the actual values.

Then

double amp1= sqrt((bin0*bin0)+(bin2*bin2));
doubel amp2=sqrt((bin1*bin1)+(bin3*bin3));
and
phase1= atan2(bin0,bin2) * radiansToDegrees+45.0;
phase2= atan2(bin1,bin3) * radiansToDegrees;

I don't understand what is going on in these lines of code. Perhaps someone can look at this, and explain in simple terms what he is doing.....

These two equations are calculating the amplitude and the phase of the RX signal.
In that case, the previous addition and subtraction of the various phases must be demodulating the RX signal to separate out the X and Y signals. The first two equations calculate the square-root of the sum of the squares to get the magnitude of the vector, and the second two equations are calculating the phase shift using the well-known arctan function. Since the phase-shift = arctan(Y/X), we can conclude that bin0 and bin1 =Y, and bin2 and bin3 = X.

I will need to think about this a bit more to understand exactly what's going on, but it appears to be a software implementation of the usual synchronous demodulation process that is common in VLF detectors.

[scrungy_doolittle]

A VLF could do with 4 synchronised samples per period, or at least twice as many in case of unsynchronised operation. IMHO VLFs are not nearly as developed as they could be with nowadays state of the art, and most VLFs suffer from traditionalistic approach that limits them.

I sure would like to understand the math behind this: https://github.com/dc42/arduino/blob...alDetector.ino

Specifically, this uses 8 samples per period, but it looks like he is taking the negative swing and subtracting it from the positive swing.
Basically he set T0 to interrupt 62,500 times per second, and uses T1 to divide the system clock by 256 then further divides it by 8 to get the clock tick.
Then in the timer 0 interrupt overflow handler, he reads the ADC (which is only 8 bits at this 1 mhz sample rate, and he adds the first 4 samples into a 4 entry array, then subtracts the next 4 ADC readings which are negative going from the first 4 which makes no sense whatsoever.
Then after he has added up 1024 samples, he copies the array somewhere and zeros it and starts over. This sampling is on 45 degree increments.
The code that I don't understand is the following:

double bin0=(averages[0]+.707 * (averages [1]-averages[3])) / 200.0
double bin1= (averages[1]+.707 * (averages[0]+averages[2]))/200
... there are two more of these He says he is removing the 3rd harmonic and dividing by 200. What the heck is this doing?

Then

double amp1= sqrt((bin0*bin0)+(bin2*bin2));
doubel amp2=sqrt((bin1*bin1)+(bin3*bin3));
and
phase1= atan2(bin0,bin2) * radiansToDegrees+45.0;
phase2= atan2(bin1,bin3) * radiansToDegrees;

I don't understand what is going on in these lines of code. Perhaps someone can look at this, and explain in simple terms what he is doing.....

[Davor]

When properly premeditated, every system can be extremely simple, yet effective. After all, the nowadays machines all share the same physics.

[Taktyk]

It is possible for VLF operating on one frequency (Deus has switching frequency) - for more frequency the system must be more sophisticated. I myself use the PI system of direct sampling and brings a good benefit. The system is extremely simple.

[Davor]

A VLF could do with 4 synchronised samples per period, or at least twice as many in case of unsynchronised operation. IMHO VLFs are not nearly as developed as they could be with nowadays state of the art, and most VLFs suffer from traditionalistic approach that limits them.

[Carl-NC]

Carl, Deus XP uses a direct sampling - 8 samples per period and is very sensitive detector..

TAKTYK

That's interesting, I did not know that.

[Taktyk]

I can't imagine that the GPZ would use direct sampling. If you want to squeeze out every drop of performance, direct sampling is definitely not the way to go. It is more useful for implementing multiple modes, as in software-defined radio. With the hardware available right now, I would only use direct sampling in low-to-mid range detectors.

Carl, Deus XP uses a direct sampling - 8 samples per period and is very sensitive detector..

TAKTYK

[Davor]

Precisely, it is a constant current Tx. The name ZVT is a marketing-derived meaning of constant current drive. At constant current the ideal coil would have zero volts across. We already discussed the benefits of constant current here.
I think a certain detector Manufacturer-Who-Must-Not-Be-Named is not capable of naming a piece of copper wire by its common name.