Teensy 3.6 as a precision event timer

Status
Not open for further replies.
A little follow up. After more tests, it became clear that temperature change, including board self heating, was problematic for the desired long term stability. Tests were done to try and control temperature drift, but the dynamics appeared too difficult toward achieving stable operation within a few tenths of a degree. So, I ran tests to determine a timing correction coefficient versus temperature. It was found to be a simple linear relationship and an equation easily applied. A thermocouple input module will be added (when it arrives) such that the Teensy board can report on its own (xtal area) temperature. The host computer can then acquire the data and make the appropriate corrections. This has been tested manually with good results.

Defragster, thanks for the tip on com ports greater than 9. The Windows thing was that nearly all com ports were busy - even though only two +Teensy USB ports were in use. I still need to sort that out. BenS
 
Very interesting application! If you've already implemented the thermocouple solution, that can certainly work. For most simple temperature measurement tasks, I find an integrated sensor like a LM35 is easier to use, because you do not need extra circuitry. You just get a straightforward +10 mV per degree C output that the ADC can read directly. The LM35 claims +/- 0.25 C accuracy at room temperature. An ANSI Class 1 type K thermocouple is accurate to +/- 1.5 C.
 
Thanks JBeale for the info. I wasn't aware of the LM35, but will keep that in mind for future projects - nice device.
For this project I veered away from the thermocouple method in favor of using an ntc thermistor along with the example sketch in Teensyduino Tutorial #4. Most of the spade work has been done and my only job is to install the thermistor and setup the communications with the host (done). The thermistor will be bonded directly to the xtal with thermal adhesive. The thermistors should arrive here within a day or two. BenS
 
In case of interest, here's a quick test of the clock frequency vs. temperature on the newly released Teensy 4 model. Mine has a tempco around -0.24 ppm / C near room temperature, but it was interesting to me that its tempco drops to near zero when you warm it up by 20 C. Note this is the T4, not the T3.6 you mention, and I only have one board at the moment, so this may not generalize. https://forum.pjrc.com/threads/5726...ck-adjustments?p=212914&viewfull=1#post212914

On the general subject of precision timing, I can't help making another note if you're not aware of it. At one time, just $3 could buy a "picPET" event timer which was simply a 12F675 Microchip PIC in a DIP-8 package, clocked by external 10 MHz signal, that gave you a 19200 baud serial stream of event timestamps up to a hundred events/sec. This had only 400 ns granularity but with no long-term drift at all, assuming you have a 10 MHz source locked to GPS. http://www.leapsecond.com/pic/picpet.htm Of course the Teensy offers dramatically better resolution and could also self-calibrate its clock, assuming an external timing signal is available.
 
Last edited:
Regarding the clock drift with temperature, you might also consider using a temperature compensated RTC. (really easily Googled), such as the DS3231.

For a minimums of fuss, Adafruit has a dev board version: https://www.adafruit.com/product/255 . No doubt there are many others available.

The actual RTC part - its main selling feature - is a nicety, but you’ll likely find the precision square wave output more helpful for your project. Using a simple software PLL (phased locked loop), you’ll be able to maintain an accurate, synthetic clock that will pass on it’s accuracy to your readings - all while the temperature compensation part is primarily handled by people who have already ironed out the details.

It’s worth noting that most GPS hardware can also output an extremely stable 1Hz pulse train.

In many cases, having timing components on the same die can be highly beneficial. However, I have the feeling that this is probably a case where a source independent from the MCU would be preferable.

As I haven’t had need for a T4 just yet, I haven’t compared the compensation accuracy of the DS3231 to the T4’s on-die comp. I guess that’s as good a reason as any to pick one up. If anyone’s really interested, lmk and I’ll try to compare them to our high-accuracy clock standard (it has something crazy, like +/- 10ns). Maybe I’ll become curious enough myself...

Sounds like a fun project!
 
Last edited:
Several months have passed since my last post here. I acquired another Teensy 3.6 and a TCXO with 0.1 ppm tolerance specs with the understanding that they might both become scrap. Removing the existing crystal was very simple thanks to another experimenter whom I have lost track of. With the soldering iron at 800F the crystal was heated on the top side and within a second or so by tapping the board on the edge, the crystal dropped off cleanly. The 16 MHZ crystal is the larger of the two. The smaller on is for the rtc.
Under the 16 MHz crystal are four pads, two are ground and one of the other two accepts the TCXO signal. It tried the signal on both, but it only worked using the non-ground pad nearest the board edge.
The TCXO was purchase on eBay ($18) it is a large device - i.e., not the lastest model. It is spec'd to operate on 3 to 5 vdc. I set it up to run on the 3.3 volt Teensy regulated voltage.
After tidying up and loading the code, the event timer now has the accuracy I've been looking for. That is, given gps derived test pulses at 1 pulse per 64 seconds the drift of that pulse over 30 minutes is <= 500 ns. One hour tests have brief 1 us excusions, but these are clearly outliers. The event timer is now operational at the observatory and improves the overall detectability of SETI type laser pulsed signals. Thanks again to all for your help and guidance.
 
That is, given gps derived test pulses at 1 pulse per 64 seconds the drift of that pulse over 30 minutes is <= 500 ns. One hour tests have brief 1 us excusions, but these are clearly outliers. The event timer is now operational at the observatory and improves the overall detectability of SETI type laser pulsed signals. Thanks again to all for your help and guidance.
Very impressive stability from an inexpensive modification!
 
To take in account the 2^32 rolls up I made following routine that takes in account that t1 is higher than t2:

Code:
float _frequency(uint32_t t1,uint32_t t2)
{
  if (t2<t1) 
  {
    t2+=1<<31;t1-=1<<31;
  }
  double dt=t2-t1;
  return ((float) (     ((double) F_CPU)/dt   ));
}
 
Status
Not open for further replies.
Back
Top