Moodz' Awesome Gold Pulse Induction Version 3 - MAGPI V3 Project

[AhmatAhmatov1959]

well I have an idea in the works .... it will improve things and you will be able to reuse the MAGPI circuit.
Might take a little while .... ( couple of months maybe or sooner if things work out ).

Hello. I don't speak English. I received the chips and the metal detector is working. The firmware is 1.4. What do SIG, TSS, XSS, BAL, TSW, and XSW mean on the display? Four months ago, you said the firmware could be improved. Has anything changed?

[haylaz0036]

Do you have a video of this project in action?Do you have a video of this project in action?

[IBGold]

I'm not sure what the reaction to gold is like. I had to tune my XSS. But I was also using modified firmware with too large of a Tx pulse. Now my detector seems to finally detect a large silver coin at 10cm. The last time I had gold, it couldn't detect it because my settings were wrong, and I was using modified source code. It was a tiny amount in a small container.

This is an updated version that includes a major change in audio and target response. Sine wave calculation sample array has been increased from 128 to 1024. MAGPI008_v1.4b.zip
Audio tone needs tweaking, but sounds better when increased.
ADC conversions now use interrupts instead of polling. Encoder turning needs tweaking

Auto ground balance tracking is included, as well as a different way of doing the exponential target response. Varying coil swing speeds are somewhat accounted for. The exponential rise gives reasonable responses for slow movements, and isn't quite as responsive on the faster movements. It's impressive how fast you can swing things past the coil and hear the response. The detector design is quite good. I like looking at the schematic and learning about it.

Hi Van0014,

I have responded to this post and sent you a PM.

Regards, Ian.

[van0014]

Hello. I don't speak English. I received the chips and the metal detector is working. The firmware is 1.4. What do SIG, TSS, XSS, BAL, TSW, and XSW mean on the display? Four months ago, you said the firmware could be improved. Has anything changed?

Hello, I'll start by saying that the firmware I posted does not seem to be as sensitive as Moods' firmware. I mostly used artificial intelligence to make it.

I'll explain what I think the variables are. I cannot be certain.
SIG - Metal target signal. This changes as the magnetic field around the detector coil changes
TSS - Transmit signal start. This may be zero in the firmware. It might not actually be used
XSS - X sample start. This is the start point of when the reactive 'X' part of the signal is measured. It controls when the damping point happens, which should be about when the signal reaches zero. This must match the detector coil, and can vary per coil. It's critical for sensitivity and is best found with an oscilloscope, or by making sure your coil matches the recommended specifications
BAL - Balance. This should be the dividing point between two important signals. The receive signal time can be divided at this adjustable 'balance' point. The first part is used to sample the flyback error (by adjusting the balance, I think more or less of the signal is allowed in, but I don't quite know how it's used.). The second part, or the other side of the balance point, the latter half, is used for signal noise rejection.
TSW - Transmit signal width - The transmit pulse time, in microseconds or clock cycles, but probably in clock cycles. In the source code, a duty cycle of 3000 clock cycles can be resolved to mean a transmit time of 30uS. (3000 / 50 = 60uS). This corresponds to a 50% PWM signal happening in 60uS, or, 3000 clock cycles. At 50%, that's a 30uS Tx and a 30uS Rx. One of the most recent versions of the source code seems to have the time set to 5000, which is a 50uS transmit time. This may be a little bit too long, on my board, the MOSFET avalanches with anything above 42uS Tx on time.
XSW - X sample width. This directly affects the signal damping. It shortens or lengthens the amount of signal that is sampled, which then gives more or less weight to the damping signal.


The firmware I posted:
I better let people know that I no longer think the version I made is worth using. It is not as sensitive.

The bar graph is showing the balance. 750- and +750 shows the bar graph range, which is really mostly a gimmick. I haven't added anything. The balance is the same as before, but I offset it to zero. It's the number to the right of 1.60 (XSS) on the second LCD row.
The tone is at the top left, default 000. Volume is default 010. Then the signal is shown, and finally the voltage. It's a different layout but most or all information is there. The firmware has a different way of calculating the signal, which I believe uses an exponential increase to signal changes. The AI suggested a way of doing exponentials with some floating points between 0 and 1 to set the strength of the exponential increase. The code doesn't seem as sensitive after I changed a few things, and i'll need to put a bit more time in to get something that's not as experimenmtal

[moodz]

You have it almost totally right. The main reason that sensitivity is lost is because of overloading of the damping circuit ( eg avalanche or the damping control feedback voltage not tracking properly ).

I sort of know what to do but I dont have much time to to even tell you let alone test it.

Sorry about that.

[van0014]

Moodz, I really appreciate this design you’ve made. It’s a heck of an upgrade from the detector I had, the gm1000. I didn’t want to spend any more than what those are worth, but wanted the same or better sensitivity. Then out of the blue, your design shows up. I’ve looked a bit through the source too, and can really appreciate what goes into it. I do a bit of arduino programming, and saw you must’ve put a fair bit of work in on the bench with this detector, having set up a fair bit of serial debugging code in the source

For the firmware version I have, I wanted to try a different approach to the signal processing. In the ADC ISR, the signal is averaged by first looping 16 times then bitwise shifting down 16, I think. I used to think that was an exponential measuring method, but it could be a way of averaging. I experimented with this ISR, and tried to get a nice and configurable exponential result. It ended up working, with adjustable rise and fall time for the target. But also seemed to introduce sensitivity loss. It was a really nice response though. The largest of targets that would basically overload the signal for a short while would now still be able to give a strong response but also a double response as they’re passed over the cores of the coil. I liked that, but gave up with it after the AI frustrated me, and kept forgetting my strict parameters such as C89 compliance, not initialising variables inside for loops.
I’m hoping to work on it again, and to make smaller changes to have a more useable result. Focusing on practical things. I think using ISR for the encoder worked well, and gave better response for adjusting. I was removing unused delay code and looking for spare ISR and change notice capabilities to use. A quadrature lookup table for the encoder may also have been what made it respond better, if the ISR alone was not the reason. I really enjoyed going through your code, and learned a bit more about your circuit in the process

[ahmet]

Hi, congratulations on the great project, Moodz!! Has the project finished, or is it continuing elsewhere?

[moodz]

Thanks .. I have been busy in VLF design / projects .. I did some work on MAGPI V4 a few months ago .. but cant publish it as it all needs tieing together.
However I have been using a STM32H743 chip and something like this chip will be used in the V4 .. this will greatly simplify the project.
I might get the AI to work on it because I dont have alot of time at the moment.

[ahmet]

I think the project is quite successful, but I have some observations, and the idea is important to me. In projects like this, isn't the input voltage regulator, noise, and current sufficiency inadequate? Wouldn't using a booster and a low-noise LDO be a better option? Wouldn't the voltage drop tendency lead to op-amp level changes? Wouldn't measuring the discharge time in metal identification be more stable than measuring the phase shift? If I implement these changes in the code and hardware, will I get positive results in terms of stability? Thank you for your answer.

[ahmet]

The STM32H743/753 lines contain the Arm^® Cortex^®-M7 core (with double-precision floating point unit) running up to 480 MHz. Performance

• 480 MHz f_CPU/, 2424 CoreMark /1027 DMIPS executing from Flash memory, with 0-wait states thanks to its L1 cache
• L1 cache (16 Kbytes of I-cache +16 Kbytes of D-cache) boosting execution performance from external memories

perfect..