PIC32 Pulse timing in hardware.

[waltr]

Waltr: what you describe is averaging. Also a type of FIR filter, specifically a rectangular FIR filter.

I realized that long after posting.

Thanks everyone for suggestions. They are all good.
I also do the over sampling to get better results.

Eclipse:
I assume this is PI detector code since you say 'delay pot'.

The TX/RX cycle time is much shorted than the period needed to adjust the 'delay pot'.
So take a 'delay pot' ADC sample every TX/RX cycle and then after x# cycles take the average.

To feel like 'real time' adjustment a new pot value is only needed about every 30ms.

[Carl-NC]

If you want to effectively increase the resolution of your ADC, you can use a process called "over-sampling and decimation".

Since this is a DC application, there is no difference between this and just accumulating a bunch of samples.

If you're trying to read a pot at 8 bits or higher, you may need some averaging or hysteresis. Hysteresis is cheaper in memory usage but might create a discernible backlash effect. Usually not at high resolution. If you are at 6 bits or less, especially with an 8-10 bit ADC, you really should not need any software massaging. If you do, then I would suspect input noise on the ADC pin, and a cap or RC filter should solve that.

[eclipse]

It's a custom made development board powered by dc/dc 5V adapter so it's probably due to some noise (no RC filters on ADC pin) and im trying to improve it a little.
PIC32MZ has 12Bit ADC. If I increase to ~1500 steps for 30uS delay the glitch is very small probably 25-50 ns but it wasn't there before the delay pot so i still need to attempt to get rid of it.

[eclipse]

So I've added averaging technique - SUM 8 measurements of the delay pot (set adc reading flag = true, once every 5 ISR cycles) and if significantly changed (>0.1% from previous average) update the timing diagram. After this there's no glitch (even when tapping with a finger, been a problem too!, and without RC filter on the input) the timing is so precise there's absolutely no way to measure instability issues with standard tools. The adjustment of the delay is quite smooth, can't tell the difference is it analog or digital timing circuit. Very happy with the result

[Qiaozhi]

Since this is a DC application, there is no difference between this and just accumulating a bunch of samples.

If you're trying to read a pot at 8 bits or higher, you may need some averaging or hysteresis. Hysteresis is cheaper in memory usage but might create a discernible backlash effect. Usually not at high resolution. If you are at 6 bits or less, especially with an 8-10 bit ADC, you really should not need any software massaging. If you do, then I would suspect input noise on the ADC pin, and a cap or RC filter should solve that.

I used over-sampling and decimation in an application where I had to measure a 48V battery using a PIC with a 10-bit ADC. Since the PIC could only measure a maximum input voltage of 5V, there was a potential divider at the input to restrict the voltage such that 50V became 5V at the input of the ADC. The resolution was then effectively reduced to approximately 50mV, but I wanted a resolution of 10mV. In that case, over-sampling and decimation was required. It actually worked very well.
As a general rule, however, I don't use it when the ADC's resolution is good enough for the application, such as reading an external pot.

[waltr]

It's a custom made development board powered by dc/dc 5V adapter so it's probably due to some noise (no RC filters on ADC pin) and im trying to improve it a little.
PIC32MZ has 12Bit ADC. If I increase to ~1500 steps for 30uS delay the glitch is very small probably 25-50 ns but it wasn't there before the delay pot so i still need to attempt to get rid of it.

I noticed on your 'MINI board.pdf" schematic you have AVdd directly connected to Vdd.
Figure 2-1 of the PIC32MX EF data sheet recommends a small inductor from Vdd to AVdd to improve ADC noise rejection. Even a small value resistor here can help.

[waltr]

So I've added averaging technique - SUM 8 measurements of the delay pot (set adc reading flag = true, once every 5 ISR cycles) and if significantly changed (>0.1% from previous average) update the timing diagram. After this there's no glitch (even when tapping with a finger, been a problem too!, and without RC filter on the input) the timing is so precise there's absolutely no way to measure instability issues with standard tools. The adjustment of the delay is quite smooth, can't tell the difference is it analog or digital timing circuit. Very happy with the result

Sounds like you found a solution.

[ivconic]

Since this is a DC application, there is no difference between this and just accumulating a bunch of samples.

If you're trying to read a pot at 8 bits or higher, you may need some averaging or hysteresis. Hysteresis is cheaper in memory usage but might create a discernible backlash effect. Usually not at high resolution. If you are at 6 bits or less, especially with an 8-10 bit ADC, you really should not need any software massaging. If you do, then I would suspect input noise on the ADC pin, and a cap or RC filter should solve that.

Sometimes simple RC filter placed as closest as possible to ADC pin solves all the trouble and there is no need for additional digital filtering. Especially at low bits and slower sampling rates.
When "reading pot" (scanning several buttons across the resistors is the same) ; simple lightweight averaging is all what one need to get perfectly smooth readings.
But for serious direct sampling at high rates, for example, heavyweight filtering is almost mandatory. With one important notice: heavyweight filtering need a lot of "horse powers" at mcu.
Otherwise such filtering will introduce unacceptable delay and there would be no benefit.
At modest mcu's like Atmega328P is; is always better to use polling and interrupts for critical measurements along with precise calculated RC filter at ADC input.
But to whom am i talking here!
Guys you all are driving various Bugatti's there, while i am still rolling the Tartan Prancer here!

[eclipse]

For next task with the PIC32 I will attempt to build auto_min_delay feature.
It will monitor RX voltage to adjust automatically the point where sampling should take place.
Different coils require different min-delay, also if the target is very large the RX signal takes more time to settle down so I'm thinking this will benefit coil swap/detecting very large targets which overload the preamp input and it settles much later than usual.

This needs to work faster and little bit harder - I need to know the exact point in the timeline where the RX voltage passes over a predefined threshold level.

[waltr]

For next task with the PIC32 I will attempt to build auto_min_delay feature.
It will monitor RX voltage to adjust automatically the point where sampling should take place.
Different coils require different min-delay, also if the target is very large the RX signal takes more time to settle down so I'm thinking this will benefit coil swap/detecting very large targets which overload the preamp input and it settles much later than usual.

This needs to work faster and little bit harder - I need to know the exact point in the timeline where the RX voltage passes over a predefined threshold level.

Are you doing fast ADC sampling from end of TX pulse for about 120usec?
This is what I have done with the PIC32MX. ADC sampling at 500kHz (2us per sample) for 256usec = 128 samples.
Then have a function that 'finds' when valid data starts. This sets an index (in a acquisition structure) that is used for further processing.
Also sum 8 cycles of RX data before state of any processing. This 'averages' out noise and give larger data values to work with.
Also allows 8 cycles to do step wise processing- basic state machine where a different process is done on each cycle.
I am running a TX/RX cycle of 666.6usec (1500Hz rate) which did not allow a lot of processing time.
Attached is a zip of this PIC project's source files.

[eclipse]

I will check your codes thanks for posting.
I was thinking to sample every us after the TX end up to about ~30uS. Put the values in array. Do averaging on the array values every N ( 8 ) TX cycles.
Test the sum (3) sub-sequential values of the array for predefined threshold level.
If done right I will be able to determine proper sample times based on different coils and different targets.

[waltr]

Started a thread on HH III Code using a PIC32MX here:
https://www.geotech1.com/forums/show...ake-on-the-HH3