Feature Requests

[MaVi]

Originally Posted by fgd3

Is there no provision for fitting the RPI4 with a real-time clock or for entering the date and time at boot time? What about a separate power supply for your GPS so it can be powered up and allowed to acquire a position before the RPI4 is booted?

no, not really. It is a Hat, powered by the Pi. It doesn't use much, but too much to leave running if I leave for a couple of days.. Setting it manually, every time I start my plotter, is not a realistic option...

How is your track getting the first six positions if you don't have a GPS fix? How would you retroactively adjust the times of those points? If your GPS doesn't have a fix you don't know where you were or at what time when those points were entered in your log.


Fabbian

Interesting point, there must be a time lapse between the position fix and setting the system time. As the position is written to the track file, it shouldn't be hard to retroactively update the times of each record as the system time is set. Logically only if the diff is more than one day

[AedanC]

Originally Posted by fgd3

Is there no provision for fitting the RPI4 with a real-time clock or for entering the date and time at boot time? What about a separate power supply for your GPS so it can be powered up and allowed to acquire a position before the RPI4 is booted?

There are various real time clock add on boards for the Pi that will keep time while the pi is powered up, you then just put a line in the local.rc startup script to set the Pi clock from the hardware clock.


Below is an article about one such clock, there are many. You can also get them with a small battery powered UPS that will keep the Pi powered up for long enough to allow it to shut down gracefully when the power is removed.


https://thepihut.com/blogs/raspberry...r-raspberry-pi

[MaVi]

Originally Posted by AedanC

There are various real time clock add on boards [...]
You can also get them with a small battery powered UPS that will keep the Pi powered up for long enough to allow it to shut down gracefully when the power is removed.

Graceful shutdown is not the issue- at boot the Pi has no idea about date / time- and I do not want the Pi to be an always-on appliance on my boat- the whole reason for going Pi / OpenCPN was to reduce power drain without losing functionality

[MaVi]

Originally Posted by fgd3

How is your track getting the first six positions if you don't have a GPS fix? How would you retroactively adjust the times of those points? If your GPS doesn't have a fix you don't know where you were or at what time when those points were entered in your log.

Fabbian

Your question is valid, and I am a bit stumped..

Been looking at a few other tracks that have this problem (well, all tracks have this problem- as OpenCPN starts with the Pi, and it starts tracking automatically, and the Pi gets its date/time quite late)

See below the first few records of a trip last year- the GPS is tracking me accurately enough, but for nearly 10 minutes the date/time is lost in the 80's.
I am running OpenPlotter with a Moitessier HAT, pretty standard configuration. The one thing of note may be that my Pi is not normally connected to a network...

Sadly I cannot edit the data points from OpenCPN, so there's no way to correct them easily..

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

[transmitterdan]

Where does the Pi get date/time when it finally gets the right time?

[MaVi]

Originally Posted by transmitterdan

Where does the Pi get date/time when it finally gets the right time?

The moitessier HAT. (GPS). It's the only source it has for date /time.

[transmitterdan]

It seems the simplest solution would be to write a script that runs at system startup. Let the script wait in a loop until the Linux system clock has a date in this century. Then start OpenCPN. Should not delay the startup very long.

[stevead]

A valid GPS fix, but incorrect date/time sounds very much like the GPS week rollover error that occurred last year. IIRC GPS week zero is 6/1/1980 which is remarkably similar to the date in your logs !


It seems odd that a recent GPS receiver such as the Moitessier HAT would suffer from this problem. Perhaps the firmware on the GPS receiver has to receive several GPS fixes before it internally corrects itself with a valid date/time ?

[AedanC]

Originally Posted by MaVi

Graceful shutdown is not the issue- at boot the Pi has no idea about date / time- and I do not want the Pi to be an always-on appliance on my boat- the whole reason for going Pi / OpenCPN was to reduce power drain without losing functionality

I was merely pointing out that there are several cheap and simple non-volatile clocks available that will solve your problem. I mentioned the ones built into UPS boards because they also solve another problem frequently encountered on boats, namely how to ensure graceful shutdown. Such UPS devices have small batteries and only run the Pi for a minute or two, but warn the Pi so that it can shutdown before power is removed.

[MaVi]

Originally Posted by transmitterdan

It seems the simplest solution would be to write a script that runs at system startup. Let the script wait in a loop until the Linux system clock has a date in this century. Then start OpenCPN. Should not delay the startup very long.

That's a very good idea- will experiment this weekend.


Sailoog (on the OpenPlotter forum) told me theres also a standard option to delay starting OpenCPN- will also test how long it would need- could still use a script for that ...

Originally Posted by stevead

...sounds very much like the GPS week rollover error that occurred last year. IIRC GPS week zero is 6/1/1980 which is remarkably similar to the date in your logs...It seems odd that a recent GPS receiver such as the Moitessier HAT would suffer from this problem....

Interesting observation- but would the GPS date fix itself eventually? It always does, so far...

Originally Posted by AedanC

I was merely pointing out that there are several cheap and simple non-volatile clocks available that will solve your problem...

And it us a useful thing- I might consider in the future. If you know of a simple (usb-based?) one, I'd be happy to try it. Otherwise I'd have to re-thing the entire housing solution of my current setting


All this said- it would, in my opinion, still be nice if I could edit data-points of a track from OpenCPN...

[MaVi]

The times used in recorded tracks turns out to be the System time.

I would love an option/switch to use GPS time- for reasons discussed earlier

[spithost]

Conceirning layers and UserIcons and their respective folders under the "config-folder" of OpenCPN....
I'd like to hereby "feature-request" that the folders, with the right names (layers and UserIcons), be created during the (re)installation of OpenCPN.
It's propably just a few lines of code, taking no time at all to execute and the produced folders "don't eat bread" as they say in the Netherlands, even if they aren't used.
Then there will be no more "fuss" in placing the gpx'es and pictures in manually created folders by end-users risking problems in incorrectly naming the folders...
I reluctantly have to admit my son came up with this brilliant idea

[cagney]

Spithost & others

I'd like to hereby "feature-request" that the folders, etc etc ...

Note that this thread is for discussing "Feature Requests".

The actual feature request must be done in the Tracker:

https://opencpn.org/flyspray/index.p...index&switch=1

You have to register an log in.

Forums like this is good for general discussions but not for developers to keep track of bugs and requests.

Thomas

[spithost]

Originally Posted by cagney

Spithost & others



Note that this thread is for discussing "Feature Requests".

The actual feature request must be done in the Tracker:

https://opencpn.org/flyspray/index.p...index&switch=1

You have to register an log in.

Forums like this is good for general discussions but not for developers to keep track of bugs and requests.

Thomas

Hi Thomas,

Thanks for the remark. I entered it as a feature-request in fly-spray ;-)


Klaus

[Mattzilla]

I would like to be able to map keyboard keys to certain functions - is this available or possible?