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.

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.

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.

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.

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?

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.