I'm trying to precisely set a clock from a cheap GPS unit with PPS output on a Teensy 3.5. I have the code apparently working and in manual comparisons (pressing a button while watching a clock) to a real time source it's very good and clearly is using the PPS appropriately.
I am using the elapsedmillis() function to graft on milliseconds to the time by taking a baseline value immediately after setting the clock (which in turn happens immediately after the PPS pulse starts)
However as part of proper testing I have an Intervaltimer configured to pulse an output pin on 0 milliseconds (actually on 1000000 microseconds basis - heartbeattime=1000000)
I have a put both the PPS on the GPS board and the digital out pin on the Teensy3.5 into a scope and while I would happily accept there could be delays in my code meaning I might observe a static offset of the PPS high and the Teensy pin high, I didn't expect to see the Teeny wander away at the rate it is.
If a picture is worth a thousand words, then a video must be worth heaps more.
Sorry for the lack of full code. It's ugly++ at the moment as I am just figuring out a precise time setting mechanism - however given the video above seems to show a significant drift in the IntervalTimer, that's my specific question - is that expected? Is there a way to discipline the timer used for that?
For reference I did run the code here ( https://forum.pjrc.com/threads/24563-Question-re-RTC-compensation-function ) and got about -21ppm equating to [Teensy3Clock.compensate(181);] but that doesn't seem to work. I note that thread is from 2013 and maybe it's not relevant anymore.
Cheers - Neil G
I am using the elapsedmillis() function to graft on milliseconds to the time by taking a baseline value immediately after setting the clock (which in turn happens immediately after the PPS pulse starts)
However as part of proper testing I have an Intervaltimer configured to pulse an output pin on 0 milliseconds (actually on 1000000 microseconds basis - heartbeattime=1000000)
Code:
elapsedMillis secondcounter, msoffset;
[snip]
msoffset = 0;
testtrigger.begin(pulseout, heartbeattime);
[snip]
void pulseout() {
digitalWrite(ppsout,HIGH);
ms=(msoffset % 1000);
digitalClockDisplay(local);
testtriggeroff.begin(pulseoutoff, 100);
}
I have a put both the PPS on the GPS board and the digital out pin on the Teensy3.5 into a scope and while I would happily accept there could be delays in my code meaning I might observe a static offset of the PPS high and the Teensy pin high, I didn't expect to see the Teeny wander away at the rate it is.
If a picture is worth a thousand words, then a video must be worth heaps more.
Sorry for the lack of full code. It's ugly++ at the moment as I am just figuring out a precise time setting mechanism - however given the video above seems to show a significant drift in the IntervalTimer, that's my specific question - is that expected? Is there a way to discipline the timer used for that?
For reference I did run the code here ( https://forum.pjrc.com/threads/24563-Question-re-RTC-compensation-function ) and got about -21ppm equating to [Teensy3Clock.compensate(181);] but that doesn't seem to work. I note that thread is from 2013 and maybe it's not relevant anymore.
Cheers - Neil G