This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Auto strarted track always begins in 1980
#1
Hi All,

I am running OpenPlotter 2 on a Pi4, 8GB, Moitessier HAT 2, but this issue is older than that.
  • I have OpenCPN configured to automatically start recording tracks.
  • OpenCPN starts at boot.
  • I do not have WiFi at my mooring
  • I power down the entire system when I leave the boat.

Result is that when the system is booted, OpenCPN strats a new track- and it gets a position fix well before it sets the system time. The result is that most tracks start 7/1/1980, see a track summary below.

Unfortunately I cannot 'fix' the incorrect data points from OpenCPN- so I would prefer the delay the autostart of OpenCPN to wait until the time is set. But how?

Any help on improving this configuration is appreciated.

Track properties
Name
Depart From Hoorn
Destination N/A
Total distance
Speed 0.00
Departure Time (m/d/y h:m) 1/7/1980 12:05:21 PM
Time enroute 14441 Days, 01:32

Leg Distance Bearing Latitude Longitude Timestamp Speed
--- 435.84 NMi 047 °T 52° 37.8858' N 005° 03.8719' E 01/07/1980 13:05:15 --
1 0.01 NMi 141 °T 52° 37.8805' N 005° 03.8789' E 01/07/1980 13:05:21 4.08
2 0.01 NMi 162 °T 52° 37.8692' N 005° 03.8849' E 01/07/1980 13:05:32 3.89
3 0.07 NMi 186 °T 52° 37.8000' N 005° 03.8723' E 01/07/1980 13:06:21 5.12
4 0.12 NMi 180 °T 52° 37.6838' N 005° 03.8729' E 01/07/1980 13:07:29 6.15
5 0.04 NMi 185 °T 52° 37.6405' N 005° 03.8670' E 01/07/1980 13:07:53 6.52
6 0.07 NMi 181 °T 52° 37.5700' N 005° 03.8653' E 01/07/1980 13:08:35 6.04
7 0.04 NMi 175 °T 52° 37.5340' N 005° 03.8706' E 01/07/1980 13:08:57 5.91
8 0.10 NMi 178 °T 52° 37.4291' N 005° 03.8752' E 01/07/1980 13:10:05 5.56
9 0.11 NMi 180 °T 52° 37.3159' N 005° 03.8754' E 01/07/1980 13:11:15 5.82
10 0.07 NMi 183 °T 52° 37.2412' N 005° 03.8690' E 01/07/1980 13:12:00 5.98
11 0.07 NMi 185 °T 52° 37.1669' N 005° 03.8576' E 01/07/1980 13:12:43 6.25
12 0.05 NMi 177 °T 52° 37.1131' N 005° 03.8629' E 01/07/1980 13:13:14 6.26
13 0.10 NMi 179 °T 52° 37.0129' N 005° 03.8659' E 01/07/1980 13:14:12 6.22
14 0.07 NMi 181 °T 52° 36.9416' N 005° 03.8644' E 01/07/1980 13:14:55 5.97
15 0.16 NMi 174 °T 52° 36.7872' N 005° 03.8915' E 07/22/2019 14:16:29 0.00
16 0.03 NMi 180 °T 52° 36.7561' N 005° 03.8918' E 07/22/2019 14:16:48 5.89
17 0.06 NMi 183 °T 52° 36.6961' N 005° 03.8859' E 07/22/2019 14:17:25 5.85
18 0.13 NMi 190 °T 52° 36.5665' N 005° 03.8486' E 07/22/2019 14:18:43 6.07
Reply
#2
Hummm. Maybe this would be an opportunity to implement a little RTC module? It might not have perfect time when you start up, but it would definitely be better than 1980!
Reply
#3
(2020-06-30, 06:50 PM)abarrow Wrote: Hummm. Maybe this would be an opportunity to implement a little RTC module? It might not have perfect time when you start up, but it would definitely be better than 1980!

Thanks for your reply.

I was kind of hoping I was not the only one with this little problem in OpenPlotter- as I already have the MoitessierHAT I am hesitant to add more modules to the pins...<edit>Might be a nice addition to the next gen of Moitessier HAT</edit>
If I am the only one- then why? What can I do (configuration wise) to prevent this? I was hoping OpenPlotter, which is in many ways a very complete package, would have a setting for this..
<EDIT2>I read somewhere that the Pi uses a fake-hwclock- which canb interfere. Will removing this interfere with standard OpenPlotter functionality?</EDIT2>
Reply
#4
Have you tried setting a delay in openplotter settings app, general settings, delay (seconds)?
Reply
#5
Thanks Sailoog- have not yet- will try- 1 minute should be enough...
Just to check- is this a common thing? Or do I have another problem somewhere else.. (The moitessier has an external antenna- if memory serves bought at your store..)
Reply
#6
(2020-07-01, 06:42 PM)Sailoog Wrote: Have you tried setting a delay in openplotter settings app, general settings, delay (seconds)?

Forget below- didn't see the stopwatch icon is actually a button...

I have just tried- the delay field doesn't seem to persist. When I enter a tine (tried 30 and 60) it will come up empty next tin I open the settings app- with no noticable delay in starting anything..
Reply
#7
Okay, it's more interesting. The time is an hour off, the date January 7, 1980. DST explains the hour difference. Starts to look a lot like the date rollover problem. Had not expected that on a new moitessier HAT Rev. 2...
Reply
#8
Last update- in case anyone still finds this interesting:
When booting the Pi has the date/time of shutdown - expected.
At some point- within a minute the system date is set by the GPS- if it then has no fix, this is Jan 6, 1980, 00:00- I guess by the SignalK plugin.
Some time later (more than 10 mins?) the proper date / time are set. I do not know by whom.

If this is done by the signalK server plugin (set System time) there is something very odd with the timing - the interval is set to 60 seconds- logging end debug enabled. In the log I see only one line of this plugin, then nothing. Changing the interval does not seem to do anything.

For the rest the system works properly, but this is an annoying little problem. Bug?
Reply
#9
I do not think a fix in the Moitessier HAT will solve this issue. Even if we could hold the date until a fix is done, people will have the same problem with other GPS devices.

Maybe the Set System Time plugin could block the date when the current date is older than the GPS date but you will have still the problem because your tracks will contain non real dates until the real date/time is downloaded from satellites.

The hardware solution (RTC) is the best for this case, any ideas for software solutions?
Reply
#10
(2020-07-05, 08:28 PM)Sailoog Wrote: I do not think a fix in the Moitessier HAT will solve this issue. Even if we could hold the date until a fix is done, people will have the same problem with other GPS devices.

Maybe the Set System Time plugin could block the date when the current date is older than the GPS date but you will have still the problem because your tracks will contain non real dates until the real date/time is downloaded from satellites.

The hardware solution (RTC) is the best for this case, any ideas for software solutions?

Thanks.

What I am wondering is why the system time plugin doesn't set the proper date, when it is already known? Yesterday I saw that the GPS time is correct (i love the data browse feature!) but the system date / time remains incorrect, for at least 5 more minutes. The system time plugin was set to update the system every 10 seconds.. (with logging enabled, it appears not to fire when I expect it to)

By the way- which time does OpenCPN use for track plotting? It  looks like system time, not GPS time???
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)