time-nuts@lists.febo.com

Discussion of precise time and frequency measurement

View all threads

TruePosition on the Arduino

MS
Mark Sims
Wed, Jun 7, 2017 2:39 AM

If you run it on a system with an accurately set clock,  Lady Heather can measure the offset (and standard deviation and ADEVs)  between the time in the receiver time code message and when the last byte of the time code message comes in.  It also calculates a histogram of the message offsets.  Since Heather does not use a 1PPS interrupt, it uses the message offset to adjust the receiver time code time to the displayed time (the on-screen clocks are updated when the last byte of the time code message comes in).

Most receivers are surprisingly well behaved in their message timing... a few are not.  Only a few receivers (like the Z38xx and RFTG-m) output the time code message before the 1PPS.  Most receivers have a message offset of around +200 milliseconds.  The Jupiter receiver time codes are off by around 1200 milliseconds!

I just added some code to Heather for doing an audible "tick" clock that ticks the second and beeps the minute (you can change that with your own sound files).  The tick clock uses the end-of-message offset time to make sure the ticks are closely aligned to the PPS time.


Calibrating your GPS pulse ambiguity is one of the all time great reasons to get a

WWVB based wall clock !!!

If you run it on a system with an accurately set clock, Lady Heather can measure the offset (and standard deviation and ADEVs) between the time in the receiver time code message and when the last byte of the time code message comes in. It also calculates a histogram of the message offsets. Since Heather does not use a 1PPS interrupt, it uses the message offset to adjust the receiver time code time to the displayed time (the on-screen clocks are updated when the last byte of the time code message comes in). Most receivers are surprisingly well behaved in their message timing... a few are not. Only a few receivers (like the Z38xx and RFTG-m) output the time code message before the 1PPS. Most receivers have a message offset of around +200 milliseconds. The Jupiter receiver time codes are off by around 1200 milliseconds! I just added some code to Heather for doing an audible "tick" clock that ticks the second and beeps the minute (you can change that with your own sound files). The tick clock uses the end-of-message offset time to make sure the ticks are closely aligned to the PPS time. --------------- > Calibrating your GPS pulse ambiguity is one of the all time great reasons to get a WWVB based wall clock !!!
BH
Ben Hall
Thu, Jun 8, 2017 10:27 PM

Hi Mark and list,

On 6/6/2017 9:39 PM, Mark Sims wrote:

If you run it on a system with an accurately set clock,  Lady Heather
can measure the offset (and standard deviation and ADEVs)  between
the time in the receiver time code message and when the last byte of
the time code message comes in.

I was not aware of this - very good to know!  I've got two of the
TruePosition boards.  One is being used in my Arduino programming
adventure and the second is destined to be connected up to Lady Heather
as another neat timepiece.  I'm not 100% sure how I'll end up doing that

  • maybe an old laptop, maybe something with an RPi.  LH worked great on
    an old laptop I had so I just may go back to that.

Most receivers are surprisingly well behaved in their message
timing... a few are not.  Only a few receivers (like the Z38xx and
RFTG-m) output the time code message before the 1PPS.

I did more work into this last night...which involved repeating my
previous test setup comparing the TruePosition with Arduino against a
Lassen LP and eventually the WWV dial-up telephone number.  I was back
to being exactly one second slow again on the TruePosition versus the
other two sources.

I started to doubt my sanity...as when I wrote my original message on
the 6th of June, I was certain that the TruePosition was not 1 second
slow.  One of the reasons I shave my head is so that I cannot pull my
hair out...else I'd have been doing that the other night.

So I went back to basics:

The Lassen LP manual clearly states that it asserts 1PPS high then some
amount of milliseconds later, puts out the time it was at that past 1PPS
tick via serial.

One thing I'd not done on the TruePosition was to crack open the manual
on the Furuno unit that's on-board.  You are 100% correct - the Furuno
acts the same way - outputs the 1PPS tick then sends the message
containing the time it was at the 1PPS tick.

My Arduino code reads that timecode...but doesn't display it until the
next 1PPS tick so it will always be one second slow unless I
compensate for this.  (which is easy, just add one to the seconds count)

Digging around further...I couldn't find a single GPS module that would
put out the timecode before the 1PPS tick.  I even looked at some of the
Ublox units we're using at work as a time source inside one of our
projects - it has the 1PPS then sends out the time code.

I want to thank you and the other respondents here - without y'all, I'd
never have figured this out!  I'm off work tomorrow as today is my wife
and my 15th wedding anniversary...so I may get some time Saturday to
continue playing with the TruePosition and the Arduino.  Once I get
something that's halfway decent...I'll put it out for people to give it
a whirl and tell me how crappy my programming skills are!  ;)

thanks much,
ben

Hi Mark and list, On 6/6/2017 9:39 PM, Mark Sims wrote: > If you run it on a system with an accurately set clock, Lady Heather > can measure the offset (and standard deviation and ADEVs) between > the time in the receiver time code message and when the last byte of > the time code message comes in. I was not aware of this - very good to know! I've got two of the TruePosition boards. One is being used in my Arduino programming adventure and the second is destined to be connected up to Lady Heather as another neat timepiece. I'm not 100% sure how I'll end up doing that - maybe an old laptop, maybe something with an RPi. LH worked great on an old laptop I had so I just may go back to that. > Most receivers are surprisingly well behaved in their message > timing... a few are not. Only a few receivers (like the Z38xx and > RFTG-m) output the time code message before the 1PPS. I did more work into this last night...which involved repeating my previous test setup comparing the TruePosition with Arduino against a Lassen LP and eventually the WWV dial-up telephone number. I was back to being exactly one second slow again on the TruePosition versus the other two sources. I started to doubt my sanity...as when I wrote my original message on the 6th of June, I was certain that the TruePosition was not 1 second slow. One of the reasons I shave my head is so that I cannot pull my hair out...else I'd have been doing that the other night. So I went back to basics: The Lassen LP manual clearly states that it asserts 1PPS high then some amount of milliseconds later, puts out the time it was at that past 1PPS tick via serial. One thing I'd not done on the TruePosition was to crack open the manual on the Furuno unit that's on-board. You are 100% correct - the Furuno acts the same way - outputs the 1PPS tick *then* sends the message containing the time it was at the 1PPS tick. My Arduino code reads that timecode...but doesn't display it until the *next* 1PPS tick so it will always be one second slow unless I compensate for this. (which is easy, just add one to the seconds count) Digging around further...I couldn't find a single GPS module that would put out the timecode before the 1PPS tick. I even looked at some of the Ublox units we're using at work as a time source inside one of our projects - it has the 1PPS then sends out the time code. I want to thank you and the other respondents here - without y'all, I'd never have figured this out! I'm off work tomorrow as today is my wife and my 15th wedding anniversary...so I may get some time Saturday to continue playing with the TruePosition and the Arduino. Once I get something that's halfway decent...I'll put it out for people to give it a whirl and tell me how crappy my programming skills are! ;) thanks much, ben