Modified sketch for improved timing precision.

[Teleno]

These scope captures are made with persistency set to infinity and the trigger set to the falling edge of the pulse (yellow).
We see the superposition of a sequence of rising edges and the variability in pulse width.

- Pulse driven by digitalWrite(). We see jitter excursions of over +-2us from the average pulse width.




- pulse driven by Timer1 PWM output using this sketch. Rock steady, constant pulse width with no jitter. Notice that the scale here is 200ns versus 2us above, still no visible jitter.

[Gunghouk]

As I said interrupts in Atmega328P are not deterministic. I don't know why you insist on something that is not. This discussion is pointless. If you think you don't need this sketch then just ignore it but don't make up objections with no base. You can't do better with code than HW, full stop.

Where did I disagree with you and where are my objections? Read my first sentence. THE END

[Teleno]

Agreed a hardware solution is the ultimate fix for pulse timing jitter but equally deterministic software that runs consistently without conditional branching also helps.

As I said interrupts in Atmega328P are not deterministic. I don't know why you insist on something that is not. This discussion is pointless. If you think you don't need this sketch then just ignore it but don't make up objections with no base. You can't do better with code than HW, full stop.

[Gunghouk]

It's rather a matter of usecs.

But the issue is the jitter which affects sensitivity. It's not important if your delay is +- 500ns what you wanted it to be, as long as it is fixed. The problem is when you get +500ns in one period and -500ns in the next, and everything in between.

PWM solves the problem because its HW, "faster digital writes" doesn't.

Agreed a hardware solution is the ultimate fix for pulse timing jitter but, equally, deterministic software that runs consistently without conditional branching also helps. This was the target with my sketch. If you combine both hardware and software techniques you've got the best of both worlds.

BTW faster writes reduced the time in the ISR.

[Teleno]

Teleno Do you have before/after measurements to show improvement in sensitivity?

I have the measurements of rock-solid timing. That's all what's needed for the timing part to NOT degrade sensitivity.

This sketch is a choice I give you for FREE, so if you're interested just try it out and share your findings, but if you're not then fine with me.

[SaltyDog]

Teleno Do you have before/after measurements to show improvement in sensitivity?

[Teleno]

Definitely an elegant solution but maybe one left for 'Son of PI' what with the hardware pins reassignment. In my fast version of the original sketch the floating point maths is replaced with integer and the main loop minimized with faster digital writes throughout and analog bit (noise) reduction.

At the end of the day what's a few nanoseconds between friends

It's rather a matter of usecs.

But the issue is the jitter which affects sensitivity. It's not important if your delay is +- 500ns what you wanted it to be, as long as it is fixed. The problem is when you get +500ns in one period and -500ns in the next, and everything in between.

PWM solves the problem because its HW, "faster digital writes" doesn't.

[Gunghouk]

Definitely an elegant solution but maybe one left for 'Son of PI' what with the hardware pins reassignment. In my fast version of the original sketch the floating point maths is replaced with integer and the main loop minimized with faster digital writes throughout and analog bit (noise) reduction.
Replacing the pot with an encoder was a mod that I had considered doing some time in the future.
At the end of the day what's a few nanoseconds between friends

[Teleno]

A next step would be removing the delay pot, which is jittery by nature (on top of the ADC noise), and replace it by a rotary encoder.

The width of the efeSample can also be made exact by using one PWM output of Timer0. It would break the delay() function although it's not used in this sketch. The AVR _delay_ms() can be used instead. Timer2 is out of the question because it would break the analogWrite() function.

[Teleno]

I inadvertedly zipped a sketch with some essential lines commented out (the pot reading).

This is the corrected sketch.

Aduino_PI2.zip

[Teleno]

This version drives the Tx and mainSample pins using two PWM outputs of Timer1 rather than driving them "manually" with digitalWrite(). The duration of the corresponding pulses is jitter free and can be changed in exact increments of the system clock period (62.5 ns).

Since TImer1 only has two separate PWM outputs, the driving of the efeSample pin is still done manually with digitalWrite(). Jitter in the efeSample is not critical because at this delay the input signal is almost constant.

In the original version the mainSample pin is already assigned to a PWM output of Timer1, so this pin is left unchanged. On the other hand, the Tx pin is not PWM, so in order to use this sketch you must physycally swap the Tx and efeSample pins (Tx -> pin 10; efeSample -> pin 8 ) so that TImer1 PWM output OC1B can drive the Tx signal.

The original also contains variabes that can be replaced by #define statements of the C preproessor, saving memory for further modifications (adding an I2C display, etc.). Other variables are no longer necessary as this version requires less calculations.

Timer1 is configured as CTC (clear timer on compare), with the maximum count being stored in the ICR1 register. This would be the txPeriodCount. The Tx pulse starts at count 1 and ends at txOn + 1, according to the values stored in OCR1B and the set/clear flags in TCCR1A. The interrupts take care of dynamically changing the configuration between each edge of the pulses to prepare the next edge. The timing of the Tx and mainSamnple signals is done by hardware and do not depend on the latency of the interrupts (no offset values required).

Aduino_PI2.zip

10us delay between the end of the Tx pulse (blue) and the beginning of the mainSample (yellow)



50us duration of the mainSample (yellow)