[time-nuts] Using a UBlox NEO-6 GPS module for calibrating a PIC microprocessor based timer.

[quartz55]

Can't you simply use a .wav analyzer like Audacity and check the second pulses over time with a microphone?  That's what I'd do just to start, I think it would be plenty close for an analog clock? KISS, unless you really like these exotic projects.

Dave
  ----- Original Message ----- 
  From: Luke Mester 
  To: time-nuts at febo.com 
  Sent: Sunday, December 01, 2013 2:54 AM
  Subject: [time-nuts] Using a UBlox NEO-6 GPS module for calibrating a PIC microprocessor based timer.


  One of my hobbies is collecting and repairing mechanical clocks. I was
  looking at buying one of the specialized electronic timers used to measure
  the performance of mechanical clocks. I really couldn't justify the cost
  just for hobby use.

  Since I have electronics and programming skills I decided to build my own
  timer using a PIC chip. This became a much bigger project than I expected!

  I have my clock timer running and have most of the software features that I
  need working. I then realized that I need some way to calibrate it and
  verify it's accuracy.

  I didn't have any source of accurate time available.  After searching the
  internet and finding this mailing list I decided to try a GPS module. I
  bought a $20 module from DX.com. It has a built in antenna, voltage
  regulator, serial interface and most important, a 1 PPS output.The GPS is a
  UBlox NEO-6M. After reading the specs on this module I see that they claim
  a 99% accuracy of <60ns for the time pulse signal. What does this mean?
  What about the other 1%? How much variation can the time pulse have? If
  it's really 60ns it's much better than I need.

  I'm hoping that some of the time experts on this mailing list can give me
  some idea what to expect from this GPS module. Also, if there are any
  settings that I should change to get better timing performance. There are a
  huge number of settings available when I run it's configuration program. I
  have no idea what most of them do.

  I'm using one of the hardware timers on the PIC chip to measure the time
  interval. The PIC is running with a 100ns (10MHz) instruction cycle. The
  timer will provide 100ns resolution. I'm getting occasional variations of
  about a microsecond. Because I'm using interrupt driven code to capture the
  timer value there will be some unavoidable jitter in the timing. I was
  expecting about 4 or 5 cycles (400ns - 500ns) but I'm getting more than
  twice that. Is it safe to assume that these are due to problems in my
  hardware or software? Is this from variations in the GPS PPS output? Maybe
  I'm just not interpreting the data correctly.

  Below are links to some data plots:

  Four plots are shown. The first two are the Rate and Beat error that my
  timer reports while monitoring the GPS PPS signal. Rate is normally the
  average of two beats ( two time interval samples). If a clock is not in
  beat (the tick and tock take different amounts of time) the displayed rate
  would jump back and forth. Averaging two beats eliminates this jump. I have
  disabled this average in my code so that the rate is now showing each beat
  and not the average of two. I turned it off because I expect that this
  averaging could hide possible problems with my timer.  Beat error is the
  difference between the two beats. This shows the rate change for each pair
  of beats. This is needed so that you can get the clock pendulum or balance
  wheel adjusted properly.

  Raw Data <http://mesterhome.com/clock/data/RawData.png>


  Average Data <http://mesterhome.com/clock/data/AveData.png>

  Average data has been filtered with a 100 sample running average. The plot
  looks really good. The average is just hiding the instability.


  I also noticed variations that appeared to be due to temperature changes. I
  borrowed a temperature data logger from work and did some testing. The
  temperature and rate graphs track perfectly. I can see my furnace cycling
  and my programmable thermostat moving the temperature setting up and down!
  That got me interested in trying a TCXO instead of the standard crystal
  that I was using. A $3.00 TCXO from EBay made a huge difference! Both of
  these plots have the running average applied. You can't see the temperature
  changes with the raw data.

  Crystal <http://mesterhome.com/clock/data/RTvTP.png>


  TCXO <http://mesterhome.com/clock/data/RTvTPTC.png>

  In case anyone is interested, here is a link to a data file captured from
  the clock timer. It's in CSV format. The first column labeled "Rate" is the
  time for each beat of the clock. "Rate Avg" is a running average rate and
  "Beat E" the beat error.

  Data file <http://mesterhome.com/clock/data/tcxo.csv>

  Finally, I think I might be turning into a time nut! For the clocks that I
  work with this timer is already far better than I need. Millisecond
  accuracy Is good enough to test most mechanical clocks. Microsecond is
  great! I know that a microprocessor based timer is capable of better
  performance. I then had the problem of what I could use to measure the
  performance of my timer. I Needed a better clock than my timer. Now I'm
  wondering if this cheap Chinese GPS is good enough. I'm having fun tweaking
  the hardware and software to see just how good I can get it to perform!
  _______________________________________________