PI backend Atmega328P and firmware

[Teleno]

I'm sharing the backend of my PI detector, a tried and true working design with firmware.
The MOSFET is driven by PWM output OC1A of Timer1 and 1/2 of the NE556.
Audio is driven by PW2 output OC2B and the other half of the NE556.
The analog signal is sampled by the ADC (1st. 2nd. and EF samples) and filtered digitally (9-tap median filter -> low pass IIR filter).
The IIR filter has a coefficient of 1/64 and a gain of 4 to increase resolution to 13 bits (provided a minimum noise level of 1.5 ADC bits).

It includes:

1. MCU Atmega328P (DIP - 28 )
2. Gate and audio drivers NE556 (bipolar version)
3. I2C interface for 16x2 LCD display
4. Rotary encoder for menus.
5. Serial connector (for debugging, bluetooth or anything you want to do with it)
6. ISP connector for programming (USBasp, STK500 and compatible).

Connections to your own front end:

• Gate: to the MOSFET gate, N-channel.
• ADC3: from the amplifier. Max 5v and referred to MCU ground.

VCC is your frontend voltage, maximum 12V. The MCU 5V is derived from this by regulator U1.
AGND (analog ground) and GND must be connected to each other as close as possible to the MCU.



PI backend Atmega328P.pdf

Diptrace schematic

PI back end Atmega328P.zip

Please share your own modifications, PCB's, frontends, etc.

Firmware will follow.

[Teleno]

For the firmware, create a new folder in Documents -> Arduino named "PI_backend_m33328p" and uncompress the ZIP file there.

Arduino configuration:

• Select board "Arduino AVR boards (arduino)"-> "Arduino Duemilanove or Diecimila'
• Processor: Atmega328P
• Programmer: "STK500 development board"
• Port: (the COMx port of your programmer)

Do any changes in the code, compile, connect programmer to the ISP socket and then - Sketch: "Upload using programmer".

PS: diodes D1 and D3 are 3.6V zeners, 200 mW.

PI_backend_m328p.zip

[Teleno]

[Teleno]

Fuse settings for a blank Atmega328P. Program via ISP with avrdudess.

[ivconic]

Hey! I love ideas like this! Fresh and not completely conventional!
Be assured that I will devote my time to this! But because of summer commitments and crowds; maybe I'll move this to fall or winter. But I like the idea in general!
Post #4 is unnecessary in my opinion. I tried the code in Arduino IDE, selected Arduino UNO as the platform, the code compiled without problems and without errors.
Although I use Avrdudess a lot myself and love that little piece of software!
This can be done in many ways. But I am attracted to the concept which is very receptive!
As always before; I will spoil the whole story by asking; do you have a short video of a simple test on common coin type targets etc?
Even without that, I see this as worthy of attention. But such a short video would only confirm my assumptions.
BTW thank you for posting this. A real little refreshment after a long "drought" on the forum!

[Teleno]

As always before; I will spoil the whole story by asking; do you have a short video of a simple test on common coin type targets etc?
Even without that, I see this as worthy of attention. But such a short video would only confirm my assumptions.
BTW thank you for posting this. A real little refreshment after a long "drought" on the forum!

As a back end its performance will depend on the front end circuitry and the coil. The 10 bit ADC is pushed to the max here, with sufficient noise in preamp 13 bits are attainable. The resolution in terms of input voltage of my machine is (1.1V / 8192 / 20 gain) = 7 uV.

in my case the coil is an 18cm diameter, 140uH, 67pF, 1.4 ohm flat spiral in a carbon-shieldad case. It is driven at 1.8 A for 130us (flattened ramp) through 70cm coaxial cable.

So it's a small fast coil meant for hunting gold nuggets on exposed bedrock and ore outcrops. Earliest possible sampe is at 5.5 us still riding the transient.

Expected maximum detection depth is about the coil diameter. A 0.7g flattened nugget is detected at 12cm, a round 0.3 gram at 9cms in air.

I haven't shared the ground balance code yet but this is what this backend is capable of doing.

https://www.geotech1.com/forums/foru...balance-for-pi

[Teleno]

Probably a good approach is a PCB for this back end with edge connectors to apply different front ends.

[ivconic]

Yes, I watched all the videos on your channel yesterday but I couldn't connect the story, it's clearer now that you explained.
Yes, the problem about being solved here is the rest of the hardware.
Atmega has proven that it is capable of doing a solid job.
A few years ago, Joop wrote a clever method based on Carl's idea from the first ITMD book.
I took the Joop's code and tweaked it for the Barracuda.
The Atmega perfectly well and accurately generates all the necessary pulses, although it is limited to only 3 physical pins,
but the problem I encountered is the rest of the hardware on the Barracuda.
So I put it aside for some "better times". In the meantime, many other projects appeared and accumulated, and all that went into oblivion.
I like your approach. With a note that for audio I'd rather use a CD4046 with PWM directly from the Atmega.
The good thing is that the Atmega has 6 pwm pins and for less demanding tasks any of those 6 pins will get the job done without any special tweaking on the timers.
So that the current state of the timers, which you have; it doesn't have to change for better audio.
The CD4046 will give you more linearity and agility than the 556.
In any case, this is still a very interesting idea. It will certainly be a very nice project for the long boring winter days.

[Teleno]

The audio half of the 556 is just a power buffer for the audio square wave that 's directly generated by the atmega. No need for a VCO. The frequency is proportional to the log2 of the target signal. The minimum and maximum frequencies are set by the software in file "log_sound.h"

freq =  (((uint32_t) 400) << PRECISION) + 46 * (do_log(signal_memory) - 1);
    freq = freq >> PRECISION;​

The first number 400 is the lowest frequency.

The second number 46 is for the highest frequency and is calculated as (Highest - Lowest) / 13; round to integer.

it's a software logarithmic VCO.

[ivconic]

I understood it from the code.
But we didn't understand each other.
The logarithmic behavior of the audio is worse than the linear solution.
The 4046 lets you do that ... PLUS it frees up resources that are currently employed around audio signal generation.

[Teleno]

I understood it from the code.
But we didn't understand each other.
The logarithmic behavior of the audio is worse than the linear solution.
The 4046 lets you do that ... PLUS it frees up resources that are currently employed around audio signal generation.

The main challenge was to get the AVR chip to do everything: pulsing, sampling, filtering, integration, display, rotary switch and sound within 1ms. It can do it and there's still plenty of time left, so MCU resources are not a problem. Adding an extra chip would make things unnecesarly complex and expensive.

I don't really understand how you intend to connect the 4046, but I guess you mean to drive the VCO with an analog input, which would require extra analog amplification and defeats the purpose of the DSP. This is not just a pulse generator, it does the signal processing too.

If you want linear sound you just need to change that line of code to a linear funtion, for exampke a map() function. Really simple. This would also free 60us of MCU time which is what the log funcion takes.

The front end is also minimal, just the MOSFET and a preamp with low gain around 20. The ADC is set to a 1.1V reference, it can be changed to 5V though but sensitibity will suffer.

[Teleno]

This is what a front end might look like.

[ivconic]

Simple analogWrite() on any digital pin available:

[Teleno]

Simple analogWrite() on any digital pin available:

In AVR arduino, analogWrite() generates a PWM signal with a mere 256 discrete steps (duty cycles), so you'll get only 256 different frequencies with your 4046. Not equivalent to a pot as in the video, but rather to a jumpy pot and sound like a Nintendo.

Instead, generating the frequencies directly as per this firmware, using registers OCR2A and the Timer2 prescaler, gives you a much finer resolution and dynamic range in increments of 1 bit. You can go from a minimum of 30Hz to a maximum of 16MHz is steps of less than 2% of the desired frequency.

I mean, it's your choice but as the author of the firmware I wouldn't advise to go that road.

Minimum 400Hz - maximum 800Hz in 400 steps. Smooth enough (That's a 0.7g gold nugget)

[ivconic]

You are absolutely right.
But that video is confusing me now!?
I hear the nice linear audio on it that I've been thinking about all along.
And earlier on one of the videos I heard different behavior. That's why I proposed the changes.
255 "states" on a 10k potentiometer (from my video) is not a very "linear" sound. It's more "graded" than yours from that video.
I don't know which video I saw where I thought it was too "graded" and logarithmic.
Ok, for now your solution is definitely better.