Modified sketch for improved timing precision.

[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)

[Teleno]

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

This is the corrected sketch.

Aduino_PI2.zip

[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.

[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]

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.

[SaltyDog]

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

[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.

[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]

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]

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]

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.

[SaltyDog]

Good Info, will try it out .... needed to see this to decide to make the step to modify the board (pin swap)

[pito]

and here is simple code for stm32f103,

HardwareTimer pwmtimer2(2);

void setup() {

  pinMode(PA3, PWM);// CH4
  // pinMode(PA3, OUTPUT);// CH4
  pinMode(PB11, INPUT_PULLDOWN);
  //Timer 2
  pwmtimer2.pause();
  //pwmtimer2.setPrescaleFactor(180);// 180 = 4kHz
  // pwmtimer2.setPrescaleFactor(1800);// 1800 = 400Hz
  // pwmtimer2.setPrescaleFactor(3600);// 3600 = 200 Hz
  //pwmtimer2.setPrescaleFactor(5000); // 140 Hz
   pwmtimer2.setPrescaleFactor(3000);
  //pwmtimer2.setOverflow(100 - 1);//
   pwmtimer2.setOverflow(90);        // =
 // pwmtimer2.setOverflow(50);        //
  pwmtimer2.setCompare(TIMER_CH4, 1);
  pwmtimer2.refresh();
  pwmtimer2.resume();
}
void loop() {
  /*
    if (digitalRead(PB11) == HIGH)
    {
    }
    else
    {
    pwmtimer2.refresh();

    }
  */
}​

pic, 200 ns and 20 us

[SaltyDog]

And what is the point of posting that here? This is an Arduino PI forum, unless I am mistaken.

[Teleno]

Here's how to do the mod on the PCB with minimum impact.

Cut the "south' pins of R5 an R11 as close to their pads as possible (so that you can solder them back to undo the mod) and pull their free ends slightly up (~30 degrees) .

With a soldering iron and a length of insulated mod wire, connect the free end of R5 to the old pad of R11. Another length of wire and connect the free end of R11 to the old pad of R5. Done!

To avoid accidental shorts place some foam/tape between the cut pins and their old pads.

The red lines in the figure mark the pins to cut.

Test point TP2 is no longer the TX signal but the EFE signal. To see the TX probe the "north" end of R11 instead (the one soldered to its pad).