Proton BASIC Community

Hello all,

I have a circuit where I am using GPS clock (UTC time) to sync a RTC (DS1302) on regular intervals whenever possible (GPS signal is visible), but there is also a Time zone settings involved in the device. The time and date are used as time stamp and I use a separate routine to calculate the local time.

The problem is that UTC time only provides for Time of the day and no date. And the RTC is always kept in sync with the GPS UTC time clock if GPS signal is visible.

So when the RTC time + Time Zone overflow to the next day (ex. UTC 22:00:00 Zone +3h) then I have to correct for the day (and possibly month and year) but months have 28(29),30,31 days.

Currently I am using a complex and long If-then case scenario but I think there should be an easier way than that. Thus I decided to ask before I delve into I-net googling.

Thanks

Hi,
The ublox UBX-NAV-TIMEUTC sentence provides year, month, day, hour, minute and second data but indexed to UTC.
Similarly UBX-NAV-PVT provides the same information.   That said I'm not sure it will alter your long If-Then case situation.  Do you need to cope with Daylight Saving time too?

Cheers,
David

I see the standard RMC sentence also provides hours, minutes, seconds in one field and day, month, year in a second field.  Is this where you're starting?  I think you may be stuck with the long If - Then list.

David

Quote from: david on Dec 16, 2023, 09:01 PMI see the standard RMC sentence also provides hours, minutes, seconds in one field and day, month, year in a second field.  Is this where you're starting?  I think you may be stuck with the long If - Then list.

Thank you david. Actually this helps a lot. When I wrote the firmware I just looked through several NMEA messages and didn't see the date and it never occurred to me to look more careful through all NMEA message specifications, including the RMC.

I have foreseen in the firmware the necessary screens to set-up the RTC, but the main issue was syncing with the GPS clock around midnight where if synced a minute before midnight while the RTC is advancing it will cause a trouble.

So I prohibited RTC to GPS sync 15 minutes before and after midnight assuming that the GPS won't stay for so long without signal that the RTC will go out of sync by more than 15 minutes. However having a date and time taken from the GPS NMEA message solves that problem.

I was thinking of doing some "date/time to seconds from epoch" calculations then subtracting or adding the Time Zone in seconds and back calculating "seconds from epoch to date/time" calculations. But the If-Then listing seems faster than complex calculations.

Have a read of some of the timing specifications in this-
https://www.u-blox.com/docs/UBX-13003221
It should cover everything you would ever need to know.
Losing 15 minutes in an RTC would take a major loss of GPS and a shoddy clock.
Make sure you keep any digital lines well away from any tuning fork resonator tracks as these are very high impedance and easily coupled in to with only fractions of a pF.  It can result in an RTC running somewhat erratically fast due to the extra pulses.
There are GPS modules specifically configured as timing solutions and they usually have their location fixed.  i.e. they are "told" they are not moving so that any carrier Doppler is a result of the satellite and not the station moving.  They often use a choke ring antenna to eliminate low angle pick up that may originate from multiplexed signals.  They also have their elevation mask and power mask increased to only accept higher elevation satellites and the stronger signals.
You can't access network time for this application?

Cheers,
David

Quote from: david on Dec 16, 2023, 11:23 PMYou can't access network time for this application?

Thank you for the help david! I don't really need network time or high time precision in this project but still some time and especially date accuracy. The project is small portable solar-charged air-quality and back-ground radiation monitoring station.

The GPS and the RTC are backed-up by the large LiPo battery which can last probably decades if only self discharged and GPS time to first fix is quite fast because of the back-up but it is not certain for how long the station will be boxed or in transit before it sees new GPS signal - from there the need for GPS-RTC sync.

GPS signals are relatively weak with a full signal being around -134dBm and heading down to under -160dBm while still tracking.  Keep the antenna higher than any of the other electronics as the dielectric patch antenna has fairly good rejection to signals below its own horizon.
If the unit is exposed to cold just remember that most battery chemistries will suffer voltage loss, capacity loss and internal impedance hike at lower temperatures.  Worst case might be a cold, stored unit.  No sun, no signal and pulling acquisition current rather than tracking current.   There's also safety concerns when shifting Lipo powered equipment around.  Check out LiFePO4 batteries as a better possible alternative.
Good luck with the project.

Cheers,
David

Hi Trastikata,

If you need day light saving I have a procedure somewhere.

When setting time and date, or if resume after a power cut, it will automatically detect if it is in daylight saving or not. Daylight saving can be turned OFF or ON.

Only problem is that if there is a resume after a power cut or set time between the the hour when when it needs to go backward, i.e. 3a.m. to 2a.m., this is not recognised and it will go backwards 2 hours then.

But otherwise works.

Joe

Hello Joe, DST is a mess, so I prefer not going this way .

By the way, thanks for the advice david, RMC messages work perfect.

Not sure how much I'm going to say was repeated above so apologies if I do.

When I looked to do this I gave up. Not possible just on the device. In the end as the data collected was sent to a PC for processing I just did a GMT - Local conversion based on the local PC data/time.

Did you consider a routine to convert date and time to Julian date which includes the time.
No transitions to complicate things.
I have routines to do this.
I've not fully thought it through.
John

Quote from: trastikata on Dec 19, 2023, 08:16 AMHello Joe, DST is a mess, so I prefer not going this way .

By the way, thanks for the advice david, RMC messages work perfect.

That's ok.

I am attaching the file just in case someone wants to use it.

Regards

Joe

Daylight_Saving_Time.zip