My take on the HH3

[waltr]

This project needs some updated info.
As Carl stated in the HH3 intro thread, the idea for the HH3 is to do as much of this detector design in software. Please go read the other HH3 threads for some discussions on processors, ADCs, and importantly Power Supplies as well and threads in other sections on Pre-amps, and TX switching circuits.
I will be describing mostly the Software process which can be applied to most PI detector hardware front circuits.
My take is to use only the TX circuit and Rx pre-amp circuit from the HH2. See the thread "My Take on the HH2" for back ground info:
https://www.geotech1.com/forums/show...ake-on-the-HH2

Since I have been using PIC micro-processors and have the knowhow and tolls for these I chose the PIC32MX250 in a 28-pin DIP package. The Dip makes prototyping and building easy compared to the smaller pitch surface mount packages. The PIC32MX runs at 50MHz and uses a mips 32 bit architecture.
It was Moodz's MagPi that inspired me to look into this PIC32MX. He also has some good idea on PI analog circuits and a PIC32MX baord. Details are here:
https://www.geotech1.com/forums/foru...l-Front-End-PI

Note: There are many other processors that can do the job like Atmel & STM. If you have a favorite then check the hardware for features that can do what I will describe.
PIC32MX features used are:
OC (Output Compare) hardware for pulse generation. Clocked from hardware Timer TMR2.
1Msps, 10-bit ADCs. Sampling rate clocked from hardware timer TMR3.
DMA to grab ADC readings and move into memory with hardware. Triggered on ADC IF (Interrupt Flag).
I2C interface to EEPROM to store settings.
SPI interface to display.
UART interface for testing and debugging.
Hardware timer, TMR1 interrupt to generate Audio tones.
Some Specs:
TX pulse rate at 1500Hz (666usec period). This is the same as my HH2 and is a multiple of 60Hz.
Run ADC sampling at 2usec starting at TX pulse ON and going 128usec after TX pulse off (RX sampling).

ADC discussion:
There has been much talk about ADC resolution and number of bits required. My solution is using a 10bit ADC and then summing 4 to 16 TX/RX cycles of ADC sampling. This does two things:
1- This effectively increases the number of significant bits.
2- Decreases random noise.
It does slow down the response but what is the required response time? I use the rules of about 30ms is the fastest a human can perceive and anything that responses within 30ms is perceived as 'real time". So, 30ms divided by 666usec is 45 cycles. Therefore summing 16 cycles happens in 10.7msec, plenty fast for 'real time'. Bit resolution increases to 14 bits and noise decreases by sqrt(16) = 4. Since this is a 32 bit processor summing 16 10-bit samples does not over flow and also allows 'larger' values to be processed. Max 10-bit value is 1023, times 16 = 16384 and is 1/4 of a 16-bit value. Keep this in mind when assigning value types later. A 'short' is a signed 16-bit value and two 'short's can be packed into one 32-bit value.
Testing has found that the ADC summed resolution is more than adequate.

[waltr]

Now for the code in Main() overview. I will leave out coding details for much later since having the concepts of how the main loop works is important.
Main starts with initializing all required hardware then starts the OC TX pulsing. The OC start of TX Pulse trigger an ISR (interrupt Service Routine) that starts the ADC auto convert sequence. The AD IF causes the DMA to read the ADC data register and move the data into a memory block (array).
In the main loop code waits for a 'DMA done' flag which is set in the DMA ISR. The DMA memory block is then copied to a 'working block' of memory . Copy is done only on the first occurrence of a 'loop counter'. This 'loop counter' is incremented on each TX/RX cycle and reset after 16 cycles. On cycles 2 to 16 the new ADC data, from the DMA memory, is summed into the 'working block'. Once the 'loop counter' in reset a flag is set to indicate a block of ADC data is ready to be processed.
ADC Data Processing:
This is where any number of things can be done with the data. What I am doing is:
Calculate the average of the last 16 data points calling this 'data_bias'. This is equivalent of an EFE sample and is subtracted from each ADC data point to correct for any DC offset from circuits and EF effects.
Nest the ADC data goes into an 'integrator' routine that does what the analog op-amp integrator does in the HH2. The equation is:
integr[new] = ( integr[old] + data(limited) - (data(limited)/decay_rate)
Where data(limited) is a limiter on the max value of the incoming data, the input series R in the analog integrator and decay_rate is the R parallel to the feed-back cap in the analog integrator. I use values of: limiter = 2000 & decay_rate = 16. These give a maximum integrated value of about 30000 and a rise/fall time constant of about 850msec. These values were obtained by Excel simulation and empirically.
Target detection can also be done in various methods.
One method is when the integrator output level exceeds a pre-set threshold (determined during start-up calibration or from an external adjustment pot).
Another is to Average a section of the data the same as in an analog PI's sampling switch timing.
GEB can also be done this way. I have not gotten a full detector built so no field testing or GEB yet.

[waltr]

Now another big piece of what goes on inside the 'main loop'. Since the TX pulse and the ADC sampling is all done with hardware the main loop only has to wait for 'DMA done' and then copy/sum the new ADC data. The copy/sum takes about 10usec and the TX/RX cycle is 666usec so the processor waits about 656usec doing nothing but wait for the DMA done flag. This is a huge waste of processor time.
Then PIC32MX does not have a FPU (Floating Point unit) so any task that requires Floating point math takes a bit of time. Now there is not really enough time to do everything needed between getting the last ADC data sum and the next time the ADC data is ready.
The solution to both issues is to split the processing tasks into each TX/RX cycle. This is done by assigning a task to be done on each 'Loop Count'. This is a very basic 'state machine' multi-tasker .
The Tasks are run as follows:
Loop count = 0:
1. Calculate EFE Bias and subtract
2. Integrator data
3. Average a time period of integrated data (target sample)
4. Check for target detection

Loop count = 1:
If target detected, calculate Exponential curve fit and return the curves Tau (target TC)
Loop count = 2:
If target detected, output target/debug info on UART
Loop count = 3:
If target Detected, output Audio tone
Loop count = 4, 5, 6, 7, 8, 9 & 10:
Update LCD display. This is split into multiple tasks due to the LDC timing constraints.
Loop count = 11,12,13,14,15:
Open for later tasks.

Then there are Tasks that can be done at a much slower rate. These are run from a second counter that that increments each time the 'loop counter' is reset. These happen at about 33.3msec rate and include:
Check for and get UART input command.
ADC Sampling of the Adjustment pots. These Pots are for:
GEB adjust
Delay 1
Sample 1 period
Threshold
Test/Debug UART outputs

[waltr]

Link to some more PIC32 programming discussions:
https://www.geotech1.com/forums/show...ng-in-hardware

Code modules for OC and DMA are in this thread.

Linked thread also discusses the PIC32MZ_EF which is only available in surface mount with 64pin as the smallest.
The PIC32MZ_EF however does have an FPU (Floating Point Unit), a MIPS DSP core, multiple 12-bit ADCs and runs at 200MHz.
If a lot of higher end Math is needed like IIR filters then this is a good processor to consider. Only down side is it is much harder to solder.

It does have all the hardware the PIC32MX has so all I discuss for running code on a MX will run on the MZ, most module setups are the same. Only the ADC setup is much different and more complex to get working but once setup works the same at the Main Loop level.