For a GPSclock i use TimeLib.h for time.. It uses the TinyGPS to read UTC..
XHour=hour();
and XHour=hour(now());
forgets the timezone, while now() is stable (= correct).
This works fine:
XHour=(now()/3600)%24;
But i have to recalculate the day, month and year as these also fluctuates for the duration of the Timezone.
I used SoftwareSerial for communication with the GPS module..
As this seems to be not so stable, i tested NeoSWSerial.. But this made it much worse!!..
Experimented with noInterrupt() ... Interrupt(), with no result (exept for a no working when placed around parts that seem to need interrupts)
If you are doing time zone/DST corrections, maybe look at TimeZone.h Arduino library.
Have you simply used a TimeLib.h function to set the Arduino system time, say setTime() or setSyncProvider() ?
My sketch is huge (~90% on a UNO) but this is the part where it happens:
void ReadGPS(){
long syssecs;
if (SerialGPS.available()>0) {
if (gps.encode(SerialGPS.read())) {
unsigned long age;
gps.crack_datetime(&Year, &Month, &Day, &Hour, &Minute, &Second, NULL, &age);
if (age < 500) {
setTime(Hour, Minute, Second, Day, Month, Year);
adjustTime(3600*Timezone);
//XHour=hour(); DOESN'T WORK WELL
//XHour=hour(now()); DOESN'T WORK WELL
XHour=(now()/3600)%24; //WORKS FINE FOR HOURS ..
}
}
}
}
I use TimeLib.h with setTime() and adjustTime()
Just had a quick look at TimeZone,h... have to see how i implement it in my sketch..
(Some pollution in the code due to all experiments.. )
Yes, i think i have to use my own code then.. I have written it already and this works like it should be, but still i can't get my finger behind it why the TimeLib malfunctions when i add all the other functions (no time related things, just buttons, LED's, Oleds and some shiftregisters to drive nixies..)
As i use 2 Oleds on the I2C-bus, i didn't want to use an RTC there.. I2C corrupts quite easily with these SH1106 Oleds.
All works stable, except for the Timezone-adjustment...
For most of my clocks, of which I have many, I run the clocks in utc and, for display purposes, convert it to local time. I use the TimeZone.h library to provide the local time and TimeLib.h functions year, month, mday etc. (as previously suggested) for display.
I even have a satellite clock which uses an STM32 (blue pill) MCU.
The nice part of timelib is that the time runs all the time, even if there is no stable reception/sync with satellites.. That's why i still use it... now() works fine, so i used that to calculate the time and date: like this:
void SetTimeZone(){
nowsecs=now()-1577836800 + (3600*timeZone); //from 1-1-2020 00:00:00 to speed up the next loop..
XYear=2020;
while(nowsecs > Sec_year){
nowsecs-=Sec_year;
if(XYear%4==0)nowsecs-=Sec_day;
XYear++;
}
XMonth=1;
if(XYear%4==0) maand[2]=29; else maand[2]=28;
while(nowsecs> (maand[XMonth]*Sec_day)){
nowsecs-=(maand[XMonth]*Sec_day);
XMonth++;
}
XDay=1+(nowsecs/Sec_day);
XHour=(nowsecs/3600)%24;
XMinute=(nowsecs/60)%60;
XSecond=nowsecs%60;
}
See what happens on the 31th of december in a leapyear.. i see something...
Kees
I also used DateTime and TimeZone libraries with both GPS and NTP based sources, but I never had any problem with offsets. I am pretty sure there should be no problem just adding an offset to obtain local time, most of the hassle is with daylight savings time which has to modify the offset twice a year. As far as I know, the code in the DateTime library converts now() values to YYMMDDHHMMSS values just fine. I don't really understand why you've written your own conversion routine.
I understand you have had no problems with timeLib.: When i reduce most of the functions in this clock, i don't have any problems either.. Not even with DST... But when i add all functions ( driving Oleds with large 36 point fonts, WS2812 Leds etc etc..) it seems that there is something interfering with the Timezone-calculation in TimeLib...
Strange enough: now() is stable. In TimeLib they just add the timezone (3600* offset).. Nothing special to me, but the result is a fluctuating time. Not just every second but too often to neglect it..
At first i thought the softwareserial could be the problem as this is infamous for its stability.. but the "better" serial made it even more worse
Appearently i had to decipher the now() value myself.. This works fine..
But i still don't understand what makes Timelib giving me the fluctuating time when i load the process a bit more..
Tried to block interrupts on some parts.. Or it didn't work at all (so there was something that needed an interrupt) or it didn't cure the problem..
It's no use pointing the finger at TimeLib when it's much more likely that there is an unrelated problem in your program, such as a buffer overflow. It's quite common to see problems like that come and go, depending on what code is included or excluded. Under those circumstances, it's futile to try to grasp what it is about the included/excluded code that makes that happen. Really, the solution usually only results from bearing down and finding the actual underlying bug.
So the focus in this thread, on the "patch" you have, is not useful in fixing the problem. It's really just a verbose instance of, "posting a snippet". So please post your entire sketch.
You probably know all this, but are hoping for a miracle. Usually it doesn't happen.
)