Chronodot - Sync 1hz square wave?

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).

The squarewave comes from the RTC oscillator divide-chain and as I understand it is not resetable except by stopping and restarting the oscillator - and since the oscillator takes a while to start up you can't define the timing very well.

Well that's my understanding at least.

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

Hmm... ok. I guess I'll have to rethink how I setup my project. My goal was to sync the Chronodot's clock to an interrupt set off by the pulse from the PPS pin of the Ultimate GPS.

Right now I get the time from the GPS and set the time on the Arduino (using time.h library) and on the Chronodot (using DS1307RTC.h library) once the interrupt goes off. The time on the Arduino seems to be in sync with the GPS, for a while anyway until it drifts. But, it looks like the Chronodot and the GPS are not synced (to within less than a second) My hope was to sync the Chronodot to less than 50 milliseconds of the GPS.

From the datasheet, p12:

The countdown chain is reset whenever the seconds register
is written. Write transfers occur on the acknowledge
from the DS3231. Once the countdown chain is reset, to
avoid rollover issues the remaining time and date registers
must be written within 1 second. The 1Hz square-wave output,
if enabled, transitions high 500ms after the seconds
data transfer, provided the oscillator is already running.

What you’re trying to do should certainly be possible to within 50ms.

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!

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.

[quote author=Jack Christensen link=topic=155012.msg1162686#msg1162686 date=1363663894] 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. [/quote]

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

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.