You think I don't understand this, but I do perfectly. And, it's the problem that I pointed a solution to. The RTC does not stop during power cycles. The leading and falling edges produced by its timing chain will remain in sync during power down, and the millisecond offset can easily be calculated any time after the first PPS interrupt.
Don't think of the PPS signal as an interrupt reset -- it is like the edge of BBC's or WWV's ticks when you are trying to synchronize your watch to the exact second (but we're trying to syncronize whatever is keeping track of time in the in the Arduino with whatever is in the RTC.
The pulse from the DS1321 is a square wave:
You can hook the DS3121's programmable square wave to a pin and trigger an interrupt off of it, and then you can know how the Arduino's internal millis() or micros() aligns with the RTC.
I meant, my main question was , is the PPS signal reset when you save a new date? Let's say I am 300ms before a PPS interrupt, I save a new date, the next PPS interrupt it's going to happend in 300ms or in 1000ms from the moment I save a new date? that was my question
One of my approach was to immediately ask the date before the first interrupt, and then just add +1sec on every interrupt (as well as store the millis)
Like this
volatile bool PPSisValid = false;
volatile uint32_t millisOffset;
...
void syncToPPS() {
if (not PPSisValid) PPSisValid = true;
millisOffset = millis();
}
The time of the next PPS is independent of your code, it's controlled by the RTC.
Not to be too presumptuous, but do you know how interrupts work? Your interrupt doesn't need to, and shouldn't need to know, what the calendar time is.
Well, it's that confirmed? Maybe the RTC has something internal that reset the 1 hz output every time you set a new time, I can think of a scenario where you set a time and the RTC changes to the next second in 100ms (because the interrupt happend) I'm not sure if you get my point
What are you going to do with the asked-for date? Update an LCD? Mark lightning strike signals with timestamps like 12:34:56.789012 ?
You shouldn't be setting the time constantly. Just once or whenever the RTC drifts more than you would like. I told you, reading it won't affect its time keeping.
Maybe the RTC has something internal that reset the 1 hz output every time you set a new time
Not maybe. It does.
I don't meant reading, I meant SAVING or SETTING a new date
Why are you worried about that? It will only take you a maximum of one second to resynchronize.
Yeah, that can be a very good equivalent of what I want to do
Man, thanks for your help, I appreciate it but I think we are going not to understand never 
I asked if the interrupt get reset when set a new date, you said no and now you said yes 
I did not say that. I said the RTC is reset. But why you care, I can't fathom. Usually, RTC is "set it and forget it". Unless you are constantly resetting the RTC (which seems totally nuts), it will never affect your interrupt or other timing.
Unless, you are synchronizing the RTC itself to some other source - but you didn't say anything about that...
In that case, you aren't setting the clock. You note the timestamp of the event based on millis() , micros() or whatever, and then you might interpret that internal machine timestamp in reference to the RTC for sharing with other systems.
You don't get the point, I don't want to reset the RTC , I never talk about reset the RTC , 'm always talking about the interrupt PPS cycle reset
Of course I want to sync the RTC with other source, then why i'm going to need millisecond resolution if the RTC date it's wrong? I said in my first post to make a NTP server or whatever to periodically save the new date into the RTC
As I said previously, the success of my aproachs depends on the PPS cycle reset, so when I set a new date 12:00:00 to the RTC, the PPS must to start to count from the moment I save the date and that's the confirmation I'm looking for.
As I understand, every PPS interrupts marks a new second in the calendar, so I understand, the PPS start counting from the moment you save/set the DATE into the RTC memory and in contradiction to what you say, the RTC PPS interrupt cares about what time is it the calendar
Exactly 
that's what I wrote in my first post, but I don't understand what mean, so I was asking for a clarification, also I don't understand about the 500ms after the seconds data transfer part
It is resetting the RTC -- When you write to the seconds register, it changes the seconds in the RTC, and synchronizes the PPS square wave with the write.
Testing on simulated Wokwi Uno (modified from ds3231WTF.ino - Wokwi Arduino and ESP32 Simulator) , it takes 572us to set the hours, minutes, and seconds, and 284us to set the seconds.
So 500ms after your call clk.setSecond(seconds);, the PPS square wave signal rises, and 500ms after that, the square wave falls.
2 Likes
No wonder my confusion. I wrote code to do that. I will attempt to find it and post it if I can. But, my system synced to GPS PPS, not NTP. The way I framed it, an independent, virtual millisecond timer is needed so that the difference in count between the system clock and the incoming pulse provides a correction factor for it. Except, I used microseconds. The short term drift is negligible, so it is feasible to apply some very simple and effective algorithms to provide corrected time on demand.
If you are using SNTP which sometimes passes as NTP, The network delays are only crudely estimated and introduce a significant error, vs. a one millisecond time frame. But the principles will be the same.
It all boils down to this - every time you update the time, be it from NTP, GPS, or whatever, store a time stamp. Also, after at least two stamps are collected, compare them. The difference tells you mainly the CPU clock error since it is usually the greatest. So now you can "bump" a virtual clock, or even better you could interpolate based on a now known origin and offset.
1 Like
I think the whole discussion is a moot point as this premise does not stand.
Your DS3231 is not going to stay true to the right time at ms precision nor will any arduino code over the long run.
High accuracy components with ± 1 ppm lose ± 0.09s/day
The question to me is more about why do you need this and if the DS3231 / Arduino Environment is a right choice for it.
There are other clocks for application needing more accuracy / stability