GPS rollover, older GPS units & OpenCPN

[codger]

Many users (like myself) may still be using older GPS units on their boats. Some of these units no longer provide an accurate date since the last GPS rollover on April 6, 2019. My GPS reports today's date as Nov 3, 2000, for example. It does not stop the unit from reporting the correct time or giving an accurate position fix, and until it actually breaks I don't really intend on replacing it.

Any OpenCPN functionality the relies on GPS date is broken if you don't have the correct date from GPS, or, maybe even more importantly, if you have no connection to GPS, regardless of the system date being correct. An easy example is Local Sunrise/Sunset in Dashboard. In my case, today it's presumably reporting sunrise/sunset for Nov 3, 2000.

The Dashboard manual states:

Sunrise/sunset are computed based on the date and lat/long from the GPS NMEA input data. They are not computed from the CPU clock or the ship's position. So unless you have a GPS connected then the times of sunrise/sunset are probably not going to be right. It has always been thus.

I'd argue that silently failing and reporting erroneous data (even if it's as innocuous as sunrise/sunset) shouldn't be acceptable for a robust and mature piece of software like O. And "it has always been thus" shouldn't be an acceptable excuse!

I'd suggest that OpenCPN should not rely on a GPS date for any date-related function, since in addition to some legacy devices no longer reporting the date accurately, many users also periodically use OpenCPN 'offline' at various times, without a GPS actually being on and with no date/time NMEA data sentence.

System date and current ship position lat/long are always available to OpenCPN and should be used rather than an NMEA data stream which is not always available. My two cents anyway!


Many thanks to the developers for a great piece of software.

[transmitterdan]

How can sunrise and sunset be computed without accurate GPS data?

Does your GPS have a firmware update available? What model/brand is it?

[Dsanduril]

Well, I run OpenCPN on a computer with no hardware clock (Raspberry Pi). And I generally run it offline with no internet access. So I appreciate a system that takes date/time from my GPS and applies it to my system clock.

Different use cases have different needs.

[SCarns]

I had that problem with an old Garmin 17HVX or whatever it was. A simple firmware upgrade solved the problem.

[codger]

Originally Posted by transmitterdan

How can sunrise and sunset be computed without accurate GPS data?

Does your GPS have a firmware update available? What model/brand is it?

It could use ship position for lat/long instead of GPS. That way it would work when a GPS was available, where GPS position = ship's position, and it would work offline, when ship's position is wherever you drop it on the map.

My GPS is an ancient Raystar something or other with a Raymarine RC520 plotter. Probably impossible to upgrade - if I recall they simply recommend keeping using it if date is not important as long as position fix is good, and turf it otherwise...

[codger]

Originally Posted by Dsanduril

Well, I run OpenCPN on a computer with no hardware clock (Raspberry Pi). And I generally run it offline with no internet access. So I appreciate a system that takes date/time from my GPS and applies it to my system clock.

Different use cases have different needs.

I agree different use cases have different needs. In either case, though, it can't be best practice for Dashboard to give erroneous data when no NMEA datastream exists...

[BMD21]

We all realize that GPS depends on accurate time to compute position? Down to the nanosec. I'd suggest that somehow the GPS under discussion has broken the link between the GPS time and date update.


It's been 20 years, but I remember that our GPS rolled over correctly. We were on a trip up to Alaska at the time; we'd of been in a world of hurt with the wrong date. I'd suggest a reboot or even a new GPS. They're only $35 for a USB device.


Boris

[wholybee]

Opencpn, i would think, Must reley on gos date and time for sunrise and sunset. I frequently sail across time zones and my pc time remains at my departure time until i make landfall. I believe this is standard practice. There is no way for opencpn to know that the gps date is wrong. In fact, the gps should be considered the most accurate source. If it isn't, that is something you need to address.

[requiem]

I agree, GPS is best if it's there, but otherwise it would be appropriate to fall back to the boat position, even if manually entered. Thus, if I'm using a laptop with a sextant instead of a GPS puck, it should be using the computer time and the plotted ship's position. (Even Windows machines follow the proper practice of knowing the time with respect to a given time zone, I believe.)

[transmitterdan]

Just so everyone knows the sunrise sunset feature is in the dashboard plugin. Plugins are driven primarily by the NMEA data stream. So it isn’t straightforward to change that to somehow automatically figure out the GPS is wrong and use a different clock.

I think what the sunset calculator was designed to do is report nothing if there is no GPS data. I will look into that.

[Tehani]

Originally Posted by codger

It could use ship position for lat/long instead of GPS. That way it would work when a GPS was available, where GPS position = ship's position, and it would work offline, when ship's position is wherever you drop it on the map.

My GPS is an ancient Raystar something or other with a Raymarine RC520 plotter. Probably impossible to upgrade - if I recall they simply recommend keeping using it if date is not important as long as position fix is good, and turf it otherwise...

The Raystar 120 model uses a non-rechargeable button cell battery inside. When it runs out, the GPS stops sending the date and time, and it takes longer to find the satellites.
Since the Raystar's case is sealed with adhesive, it is almost impossible to open it without breaking it.
In addition, these antennas gave coordinates with low resolution.
Honestly, I would change the GPS receiver.

[SVHarmonie]

The “wrong date” error on older GPS actually does not usually come from the April 2019 rollover of the week epoch number from 1024 to 0000 but from a rollover error that appeared in October 2108 when the week number went from 999 to 1000.

At least one vendor of GPS chips used in lots of products did not allow sufficient memory space to handle the number in decimal format. (Software QC? We need no stinkin’ QC!!)

The error actually only affects the human readable version of the date, and then whatever OTHER software relies on that—which would be everything on the N2K network... Internal position fixing calculations are not affected because they do not use the decimal version of the date.

[codger]

Originally Posted by transmitterdan

Just so everyone knows the sunrise sunset feature is in the dashboard plugin. Plugins are driven primarily by the NMEA data stream. So it isn’t straightforward to change that to somehow automatically figure out the GPS is wrong and use a different clock.

I think what the sunset calculator was designed to do is report nothing if there is no GPS data. I will look into that.

I think that's really the crux of the matter - if Dashboard requires NMEA data to operate (and I understand better now why that would be the case and why it would be unreasonable to expect a programming workaround, thanks for the clarification TDan) then missing data should lead to null values in the Dashboard tools. This is what happens for most of the Dashboard fields (COG, SOG, trip log etc). If the sunrise/sunset tool computes its values from GPS position fix and position date, then absent either of those variables in the NMEA datas stream it should return null, not seemingly random times... I do think that's an important fix to make.

I do take the point that I can't expect Dashboard to know that the NMEA date is wrong, though, and default to system date. And ultimately I agree with the posters who say I should just upgrade my GPS; you're all undoubtedly right. However, I'm sure I'm not the only budget sailor trying to make do with equipment that "mostly" works... but yes, I will be upgrading the GPS sooner rather than later. (Its internal battery ran out some time ago and it takes a lot longer to acquire a fix, as pointed out by Tehani)

[requiem]

Originally Posted by transmitterdan

Just so everyone knows the sunrise sunset feature is in the dashboard plugin. Plugins are driven primarily by the NMEA data stream. So it isn’t straightforward to change that to somehow automatically figure out the GPS is wrong and use a different clock.

I think what the sunset calculator was designed to do is report nothing if there is no GPS data. I will look into that.

When I fire it up on my laptop, I see that it appears to adjust the displayed time based on the boat position (i.e. if I manually drop it further north, the time advances). It appears to take from OCPN_DBP_STC_LAT and OCPN_DBP_STC_LON to do this. My impression is that those are fed from a NMEA stream if present, and uses the manual position if not. Not sure if this is correct, the code appears to be generally undocumented.

However... I've also enabled the display of the GPS clock, the local GPS clock, and the local CPU clock. It looks like the plugin itself has a setting for local UTC offset (i.e. timezone). Since I don't have a GPS attached to my laptop, the GPS clock is "00:00:00".

The local GPS clock offsets correctly (i.e. will read "01:00:00" if I set it to +1 hour), unless I leave the offset at 0, in which case it offsets to "16:00:00". The local CPU clock does display the correct local time. The sunrise/sunset value shows a very incorrect time; presumably if the zero'd out GPS clock also has a zero'd out date, the sunrise time might be correct for that date?

[transmitterdan]

Sunrise and sunset calcs require date and location.

I wrote the code for the various types of clocks. But they do not depend on location.

I’ll take a look and see what can be done to make sunrise/set not produce bogus times. But I can’t really fix wrong NMEA data.