Pages: 1 [2]   Go Down
Author Topic: Chronodot - Sync 1hz square wave?  (Read 2416 times)
0 Members and 1 Guest are viewing this topic.
St. Peters, MO
Offline Offline
Newbie
*
Karma: 0
Posts: 45
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Ok, I guess I'll have to look at the RTC library I'm using and see if it is turning off the oscillator.  Maybe that's why it is never in sync.

The interrupt I'm using is when the PPS pulse from the GPS goes high.  The GPS PPS seems to be accurate (at least to my eyes).  I've compared it to other atomic clocks I have and it looks to be pulsing right at the second and doesn't skip a beat.

Here is a bit of my code, where I use the interrupt from the GPS PPS and RTC SQW to light up 2 LEDs (to visually see if the clocks are in sync).  When I set the time in my loop, they are never in sync.  I'll try and look through the RTC library code tonight and post what it's doing.

Code:
const int PPS_LED = 13;  //pin 13
const int SQW_LED = 11;  //pin 11
const int SQW_PIN = 2;
const int PPS_PIN = 3;
volatile boolean pps_led_state = true;
volatile boolean sqw_led_state = true;

void setup () {
  pinMode(SQW_LED, OUTPUT);
  pinMode(PPS_LED, OUTPUT);
  pinMode(PPS_PIN, INPUT);
  pinMode(SQW_PIN, INPUT);
  digitalWrite(PPS_LED, LOW);
  digitalWrite(SQW_LED, LOW);
  attachInterrupt(1, pps_interrupt, RISING);
  attachInterrupt(0, rtc_interrupt, FALLING);
}

void pps_interrupt(){
  if(pps_led_state){
    pps_led_state = false;
  }
  else{
    pps_led_state = true;
  }
  digitalWrite(PPS_LED, pps_led_state);
}

void rtc_interrupt(){
  if(sqw_led_state){
    sqw_led_state = false;
  }
  else{
    sqw_led_state = true;
  }
  digitalWrite(SQW_LED, sqw_led_state);
}
Logged

texas
Offline Offline
God Member
*****
Karma: 27
Posts: 862
old, but not dead
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

You need to look at the GPS datasheet and verify which edge you should be looking at.  Some GPS modules put out a relatively narrow pulse so if you looked at the wrong edge, you could be as much as 999+mS in error.  The minimum error you would face by looking at the wrong edge of the GPS PPS signal is 500mS assuming a 50% duty cycle.  The time signal provided by a GPS receiver is going to be the most accurate time signal you are likely to ever encounter in every day life.  With satellite lock, it's not going to be off by even 1uS, much less a large fraction of a second.  It should take less than 1mS to set the clock in the chronodot so you should be that well aligned.

The MSB of the seconds register acts as an oscillator control bit.  If it is set, the oscillator is off.  The factory default in the chip is for the bit to be set when the device first powers up.  If you don't have a backup battery installed, your chip likely powers up with the oscillator off every time.

Don't automatically expect that because the falling edge is important to the clock chip that it is also the important edge coming out of your GPS module's PPS output.  That may not be the case.

The DS1307 is sensitive to noise pickup on the crystal if the case is not grounded.  It can also pick up environmental noise adding significant error to its timekeeping ability.  The added noise generally makes the clock gain time as the internal ripple counter is seeing extra clock ticks.  I assume that the chronodot has the same potential problems, but I have never used on.  The chronodot is supposed to be very accurate.  If you are seeing drift that results in things being visually out of sync after only a few minutes or noticing that it is not keeping time well, then you have a noise pickup problem.  For example, picking up 60HZ AC noise will add 2-3 minutes per day.
Logged

Experience, it's what you get when you were expecting something else.

St. Peters, MO
Offline Offline
Newbie
*
Karma: 0
Posts: 45
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

You need to look at the GPS datasheet and verify which edge you should be looking at.  Some GPS modules put out a relatively narrow pulse so if you looked at the wrong edge, you could be as much as 999+mS in error.  The minimum error you would face by looking at the wrong edge of the GPS PPS signal is 500mS assuming a 50% duty cycle.  The time signal provided by a GPS receiver is going to be the most accurate time signal you are likely to ever encounter in every day life.  With satellite lock, it's not going to be off by even 1uS, much less a large fraction of a second.  It should take less than 1mS to set the clock in the chronodot so you should be that well aligned.

The MSB of the seconds register acts as an oscillator control bit.  If it is set, the oscillator is off.  The factory default in the chip is for the bit to be set when the device first powers up.  If you don't have a backup battery installed, your chip likely powers up with the oscillator off every time.

Don't automatically expect that because the falling edge is important to the clock chip that it is also the important edge coming out of your GPS module's PPS output.  That may not be the case.

The DS1307 is sensitive to noise pickup on the crystal if the case is not grounded.  It can also pick up environmental noise adding significant error to its timekeeping ability.  The added noise generally makes the clock gain time as the internal ripple counter is seeing extra clock ticks.  I assume that the chronodot has the same potential problems, but I have never used on.  The chronodot is supposed to be very accurate.  If you are seeing drift that results in things being visually out of sync after only a few minutes or noticing that it is not keeping time well, then you have a noise pickup problem.  For example, picking up 60HZ AC noise will add 2-3 minutes per day.

I'm using the Adafruit GPS http://www.adafruit.com/products/746
Datasheet http://www.adafruit.com/datasheets/GlobalTop-FGPMMOPA6H-Datasheet-V0A.pdf

"A pulse per second (1 PPS) is an electrical signal that very precisely indicates the start of a second. Depending on the source, properly operating PPS signals have typical accuracy ranging 10ns"

I didn't see anything in the datasheet about if it is rising or falling or what the pulse width is.  I assumed rising is a new second.
Logged

texas
Offline Offline
God Member
*****
Karma: 27
Posts: 862
old, but not dead
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

The datasheet doesn't specify, some datasheet.  I found another reference, and it does look like you should pay attention to the rising edge of the GPS pulse.  The falling edge of the SQW output is what counts with the clock chip though.  Once you trigger on the rising edge of the GPS pulse, you should be able to set the date and time in the chronodot  in something like 1mS. 

I looked at the datsheet for the chronodot chip (good thing too) and you enable the oscillator by turning off the MSBit of 0x0E (control register).  If you are having to do that every time, then give the crystal about 5 seconds to stabilize before syncing the time.  If you have the backup battery, then it should probably be staying enabled between uploads and resets.  Looks like the oscillator is always enabled when powered by Vbat regardless of what the bit contains so I don't see you having to wait for crystal startup.
Logged

Experience, it's what you get when you were expecting something else.

SF Bay Area
Offline Offline
Edison Member
*
Karma: 11
Posts: 1244
Arduino Ninja
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I'd also make sure you aren't trying to reset the seconds register every time the PPS signal triggers.

If you get really fancy, you might be able to create an iterative routine that monitors both pulse outputs, and adjust the delay to account for I2C timing until they're as in sync as the Arduino can measure. Perhaps even measure the drift and trigger another re-sync cycle when it's more than 1mS off.
Logged

Unique RGB LED Modules and Arduino shields: http://www.macetech.com/store

St. Peters, MO
Offline Offline
Newbie
*
Karma: 0
Posts: 45
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I tried a different library and that worked.  I don't know what was going on with the one I was using.  I have the 2 clocks synced to within 15-20ms.  Pretty good.

I'm going to try and copy over some of the code from the library into my own sketch so I better understand exactly what it is doing.  I'll post my code later to show how I synced the 2 clocks.

For future reference, it seems like the GPS pulse rising is the start of a new second.
Logged

texas
Offline Offline
God Member
*****
Karma: 27
Posts: 862
old, but not dead
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

15 - 20 mS still seems like a large error to me.  There are allot of internal registers in the chronodot, so maybe with library overhead it takes that long to get the stuff written.  Maybe the library will let you set only the seconds alone which should be a lot faster to do.  You could do the slow call to set everything and then sync the second on a subsequent GPS edge.  I don't see why you can't get the error to less than 1mS.

Ok, on the GPS rising edge, that agrees with what I saw out there.  Do you find that the chronodot is making a falling edge when the GPS is doing a rising edge?

How are you measuring the sync accuracy, do you have a scope?
Logged

Experience, it's what you get when you were expecting something else.

St. Peters, MO
Offline Offline
Newbie
*
Karma: 0
Posts: 45
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

15 - 20 mS still seems like a large error to me.  There are allot of internal registers in the chronodot, so maybe with library overhead it takes that long to get the stuff written.  Maybe the library will let you set only the seconds alone which should be a lot faster to do.  You could do the slow call to set everything and then sync the second on a subsequent GPS edge.  I don't see why you can't get the error to less than 1mS.

I would agree with you. I'm going to look into the library and copy out some of the code and modify it for my own time sync.

Ok, on the GPS rising edge, that agrees with what I saw out there.  Do you find that the chronodot is making a falling edge when the GPS is doing a rising edge?
I setup my interrupts for the Chronodot and the GPS with this:
Code:
  attachInterrupt(1, pps_interrupt, RISING);
  attachInterrupt(0, rtc_interrupt, FALLING);
and the time from both looks to be in sync.

How are you measuring the sync accuracy, do you have a scope?

Am not using a scope. Do not have one.  In each of my interrupts I keep track of micros() and I just subtracted the 2 numbers to see the difference between the 2 interrupts.
Code:
void rtc_interrupt(){
  rtc_micros = micros();
  if(sqw_led_state){
    sqw_led_state = false;
  }
  else{
    sqw_led_state = true;
  }
  digitalWrite(SQW_LED, sqw_led_state);
}
Logged

Pages: 1 [2]   Go Up
Jump to: