Chronodot - Sync 1hz square wave?

johnhuebbe:
Ok, so it seems like I need to keep track of the number of mills from when the PPS goes off and then count up 500 mills and then set the time.

I'll try and write up a simple sketch to test it out. Thanks!

It's simpler than that. When the pulse from the GPS occurs, get the time from the GPS, set the RTC with RTC.set() and the system time with setTime(). The falling edge of the 1Hz signal from the RTC should then be synchronized with the pulse from the GPS.

Be sure to call setSyncProvider() in setup() to keep the system time in sync with the RTC time.

Being naive here, Is the pulse width from the RTC 500ms?

johnhuebbe:
Being naive here, Is the pulse width from the RTC 500ms?

I assume so, or darn close to it. By definition if it's truly a "square wave" it should have a 50% duty cycle but that's a term that might be somewhat loosely applied.

Yes. If you set up an interrupt to occur on the falling edge of the Chronodot's 1Hz square wave, those edges occur one second apart.

Pete

Is the falling edge of the Chronodot's 1hz square wave when the clock ticks over a new second? or is that on the rising edge?

Yes, in a test that I did it turned out to be the falling edge when the second ticks over.

Pete

el_supremo:
Try setting the seconds when the button is pressed. You could, for example, set up your code so that the user pushes the button at exactly the minute and the code then just sets the seconds to zero. I think that will do it.

Pete

Ah yes, I recall now - the seconds field is specially rigged to reset the counter.

The output is a square wave, and can be set to one of four different frequencies which are taps
on a ripple counter. The pin is called SQW/OUT (square wave out).

One thing I've noted is that the square wave out is open-drain - pull-up resistor needed (just in
case anyone's playing with an RTC and getting confused).

Maybe I'm not doing something right with my code. Currently I have my Interrupt from the GPS PPS pulse trigger setting the Chronodot, but when I compare the time between the two after it is set, they are never synced. If I reset the sketch multiple times, they time they are out of sync is never the same. It seems like the 500ms delay that is listed in the datasheet is not consistent.

I haven't used a chronodot, but I've used the DS1307 and it's really pretty easy to set. Time begins when you write to the seconds register, assuming the oscillator is already running, that's why they say the SQW output will go HIGH 500mS later. Going LOW is when seconds tick. The oscillator could take a couple of seconds to get going if it is disabled, so I always have it going when I set the time. You need to know which edge of the GPS matters so you can trigger your interrupt at the right time and not try to wait 500mS to accommodate triggering on the wrong edge. I think many GPS modules only guarantee the one edge is accurate, I don't think many guarantee a 50% duty cycle. What kind of interrupt are you using to sync this up?

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.

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);
}

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.

afremont:
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 Adafruit Ultimate GPS Breakout - 66 channel w/10 Hz updates [PA1616S] : ID 746 : $29.95 : Adafruit Industries, Unique & fun DIY electronics and kits
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.

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.

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.

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.

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?

afremont:
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.

afremont:
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:

  attachInterrupt(1, pps_interrupt, RISING);
  attachInterrupt(0, rtc_interrupt, FALLING);

and the time from both looks to be in sync.

afremont:
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.

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);
}

I have a ds3231 SQW-Pin an a GPS PPS-Pin attached to a atmega avr1284p. How do i Sync the rtc 1HZ SQW Output to the PPS from gps.? I want to have the falling Edge of the rtc SQW to Trigger exactly on the rising edge of the PPS Signal from GPS. What is the best way/Code to do this? Thank you very much!

johnhuebbe:
Is it possible to sync the 1hz square wave of the Chronodot to an interrupt or button press? So that the square wave is in exact sync.

I'm working on a clock project and would like to sync the Chronodot's RTC to the exact time an interrupt goes off or the exact time someone presses a button (after setting the time into some variables).

Alternatively just record the discrepancy in a variable and regenerate a correctly timed pulse using a timer?