My goal is to synchronized the ds3231 using a time pulse of 1Hz/0.1s from a NEO6 gps and whenever the gps signal goes down to keep having that 1Hz/0.1s alive!
The code bellow doesn't behave as i was expecting and i don't know why!
I uploaded the code on 2 breadboards and i notice that their output is not synchronized. I was expecting to have a synchronized output on both of them after 21 seconds from start!
My goal is to use these two devices to blink 2 lamps in the same time, the lamps are 600m apart. The gps signal in that location is not great that's why i went with rtc ds3231. From time to time i loose gps signal for a couple of hours!
I'm having trouble following your code, and that may be because I don't really understand what you want to do. The GPS interrupt occurs every second and sets the flag, but the flag only gets cleared every 20 seconds. Anyway, maybe you could explain exactly what you want to happen.
In any case, timeTosync needs to be a volatile variable.
I want to output a HIGH on pin d10 everytime the seconds of the rtc changes. I also want every 20 seconds to reset the rtc to zero based on the timepulse that i receive from the gps module. I want to do this because i need my two breadboards to output a HIGH on d10 in the same time.
they are side by side as we speak and they don't work! I don't mind having the output of the 2 setups out of sync until both gps modules are fixed on sattelites. I need them to output in the same time after the gps timepulse arrives and continue to output in the same time in case the gps signal is lost!
Well, that is NOT going to happen. The two devices need to communicate with each other to stay in sync. Even two identical pendulums will not stay in sync when they are side by side.
Well you might try changing the declaration of timeTosync to volatile:
volatile bool timeTosync = 0;
So you don't really need to know the time of day at all. You're just looking at when the seconds register changes.
I would point out that if you set the DS3231 to output squarewave at 1Hz, that output will go low at exactly the beginning of each second. So instead of reading the seconds value from the RTC over and over until it changes, the RTC could generate an interrupt for you at the beginning of each second.
Also, the DS3231 has automatic temperature compensation, as well as an aging register that lets you calibrate it to keep time to within a few seconds a year. So I wonder if GPS gives you a meaningful benefit, particularly if you lose reception for hours at a time. Might the DS3231 be good enough on its own?
I will try with "volatile" but i don't think this is was is causing this not to work!
I don't thing you understand what i'm after, maybe i'm bad at explaining!
We have 2 independent devices, A and B, each device has and output, A_out and B_out. Device A is powered at 12:00:0, device B is powered at 12:00:5.3 (5 seconds and 300 ms). Both outputs A_out and B_out are outputting "1" every second. After 50 seconds the gps of device 1 is locked on sattelites and so it starts delivering the timepulse, the seconds register of device A is reset to 0. After 1 minute the gps of device B is ready to deliver timepulse and it reset the seconds reg of rtc and by doing this we get rid of those 300ms between blinks. Now both devices blink in the same time (well maybe a couple of ms that are not visible by eye) even though one has started earlier and the second one was resetted later.
Ok, so each device has its own GPS receiver, and their PPS signals should be in sync. Well, try the volatile declaration and the other change I suggested above, and see what happens. Also, with the delays totalling one second, you'll be getting output on D10 every time you go through the loop, so there's no chance for the GPS to reset the RTC asynchronously. You might try eliminating the first (900) delay altogether.
Dont forget that the time put out by the GPSs could be 2-3 seconds out depending on whether they have both actually received the leap seconds update that goes out every 12.5 minutes.
I dont see that you need to read the actual time from the GPS at all.
But first, where are these lights located and why does the GPS apparently fail after some period ?
Second turn the light on when the GPS time sync pulse appears and then reset and start the RTC from time 0 and start the 1hz output. Turn on the light when the GPS time pulse OR the 1hz output goes active. No need for the RTC to know the actual time.
The cable option is out of discussion, there's no way i can run that cable between the 2 devices.
RF could be an option but i have buildings between the devices and that might be an issue!
I only use the timepulse pin of the GPS, when the gps is locked on sattelites it outputs a 1Hz signal on a pin and i use that to reset the RTC seconds register to zero! Also the system could expand in the future and i might have devices that are located much far away from each other.
I think the problem with your original code is that there's no connection between the time the GPS interrupt takes place and the time the seconds value is reset to zero. So if the interrupt takes place in the middle of the 900ms delay, there's nothing that resets seconds immediately, or exactly one second later. It just resets about a second after it last changed value.
The code below records the millis() time of the interrupt in the ISR when it takes place. Then the seconds reset takes place one second later. Also, I thought it made sense to move the reset IF up into the main IF. And the variable declarations have changed. Anyway, see what you think.
I got it working with my initial code + "volatile" attribute for timeTosync variable, i also added a pull down resistor on pin d2 (GPS_SYNC) since that one was floating.
Also tested your last version which is working great, i initially thought about alligning gps pulse with driver output but i was too focused on getting it working!
Is it critical that the TRIGGER_LAMPS output be a 900mS LOW followed by a 100mS HIGH, or is there some flexibility in one or both of those times? Trying to maintain an exact 1000mS cycle using delay() or millis(), while at the same time trying to stay synced with the RTC/GPS second, is not going to work unless you can guarantee the millis() counter is running slightly fast. Also, which is the important part of the TRIGGER_LAMPS output, the 900mS LOW, or the 100mS HIGH?
I like the suggestion of using the SQW output of the DS3231. Use that to trigger an interrupt, instead of spending the time to actually read the RTC.
Now that you actually have your code working, this is my idea of how to do it: