Bordonbert
Member
Hi guys. I have a finished working project on an Arduino Nano of a high accuracy pulse delay unit (Nano? High accuracy? I hear you say). The remit was to accept a 'start' pulse and output a 'completed' pulse at the end of a predetermined time period, and to achieve as close to 20ns accuracy as possible. The first was ultra simple, the second was an impossible call of course. Nothing more! The functional side was a piece of cake of course, the accuracy side was unachievable given the Arduino's 16MHz clock speed though I get pretty damned near to it.
I set up a process to take in the preset time required using the IDE and USB and to calculate how that translates into clock ticks and then on to timer loops and the residual. I then adjusted those figures to account for a possible very small residual which would leave its count as the final loop very near the previous overflow. Knowing that the counter continued to run when other interrupt actions might be taking place, I worried that this could, on a few occasions, conceivably allow a small number of lost cycles as the interrupts were reset at the end of the final full loop. If the residual clock cycles was below a certain very low minimum I reduced the full loop count by 1, added half a full loop to the residual and added a loop of half the count at the start, shifting the final residual then to the middle of a loop count.
Of course, this was either going to be a very rare event or even was probably not necessary at all but it worked well with the figures in practice as all calculations were done before the count was triggered. Then the timer count was started when the pulse was received and the overflows captured to another variable while the active interrupts could be changed and set up for the different functions when it was required without worrying about lost counts during that process. As I said, that may not be necessary but I didn't know enough about interrupts to know if it was a genuine worry or not.
This gave excellent results when measured using an ultra-high accuracy dedicated card used in a professional seismic recording device for which the unit is meant to act in a test bed. With its 16MHz clock the Arduino has a claimed 62.5ns accuracy which I got close to. The drift is another problem of course but it proved to be not as bad as many Arduino users said they had experienced.
So basically the unit was close to the required spec. I am now twitchy to get things to another level of accuracy and I am going to set up the same functionality in a Teensy 4.0 with it's close to 1ns capability. I'm a teensy virgin! The programming is no problem but, through working with the Arduino, I learned that there are often "peculiarities" in how you should approach this for a particular board. I wondered if anyone could point out whether there is anything unique or odd about the Teensy 4.0's timer set up which might save me some time in discovering it?
I set up a process to take in the preset time required using the IDE and USB and to calculate how that translates into clock ticks and then on to timer loops and the residual. I then adjusted those figures to account for a possible very small residual which would leave its count as the final loop very near the previous overflow. Knowing that the counter continued to run when other interrupt actions might be taking place, I worried that this could, on a few occasions, conceivably allow a small number of lost cycles as the interrupts were reset at the end of the final full loop. If the residual clock cycles was below a certain very low minimum I reduced the full loop count by 1, added half a full loop to the residual and added a loop of half the count at the start, shifting the final residual then to the middle of a loop count.
Of course, this was either going to be a very rare event or even was probably not necessary at all but it worked well with the figures in practice as all calculations were done before the count was triggered. Then the timer count was started when the pulse was received and the overflows captured to another variable while the active interrupts could be changed and set up for the different functions when it was required without worrying about lost counts during that process. As I said, that may not be necessary but I didn't know enough about interrupts to know if it was a genuine worry or not.
This gave excellent results when measured using an ultra-high accuracy dedicated card used in a professional seismic recording device for which the unit is meant to act in a test bed. With its 16MHz clock the Arduino has a claimed 62.5ns accuracy which I got close to. The drift is another problem of course but it proved to be not as bad as many Arduino users said they had experienced.
So basically the unit was close to the required spec. I am now twitchy to get things to another level of accuracy and I am going to set up the same functionality in a Teensy 4.0 with it's close to 1ns capability. I'm a teensy virgin! The programming is no problem but, through working with the Arduino, I learned that there are often "peculiarities" in how you should approach this for a particular board. I wondered if anyone could point out whether there is anything unique or odd about the Teensy 4.0's timer set up which might save me some time in discovering it?