Use GPS Time on PC

[Dockhead]

Originally Posted by Kenomac

I spend zero amount of time fussing with pc navigation, instead we use an Apple MacBook Pro for computer stuff along with a couple of iPads and Raymarine e127 chart plotters. Absolutely zero down time and time wasted fussing with stuff.

We still have the HP pc running Nobeltec Time Zero, but it hardly ever gets used, and I spent more time over a two week period several years ago trying to get that POS working than I've spent on all the Apple stuff combined over the past eight years. Last season, I only turned on the pc once, and I think it was by mistake.

Something to consider... unless you enjoy wasting days messing around with computers.

It all depends on what you want to do. If you're just following the dot on the map, like in your car, then IPad nav programs are fine. I have an IPad on board and use it myself, or used to -- I haven't turned it on in a few years.


If you're doing actual navigation, and even more, if you're keeping your log and so forth electronically, if you're doing complex collision avoidance, operating your radar, etc., then you need OpenCPN or something with similar capabilities, and there isn't really anything for Fapple.



I don't like playing with computers at sea, for sure, but there are certain jobs to do which require good functioning IT systems, so sometimes you have to mess around with them.

[Dockhead]

Originally Posted by conachair

Just did a quick test, looks like if gps time is available from NMEA my logbook uses that, if I turn off all connections the logbook uses system time. Quick glance looks like time is coming in with the RMC & GGA sentences, logbook 1.3007 on win10 >

Thanks -- very useful. So what is happening is the log is taking system time when it can't get GPS time, and is getting confused when they conflict, which they usually do. This sucks -- any way to tell the log not to use system time at all?


I have now put another time source in the system -- I connected my handheld VHF and O happily uses that at the same time as network data, even though that is two different GPS devices giving data at the same time. But now the log is deeply confused and is making all the entries with no time or date :headbang:


It would be good if I could choose which time and date data O uses for the log -- Nohal, no way to do this?


This computer will go in the trash as soon as I arrive, but I've got 1000 miles to go I guess I'm back to paper log for a while . . .

[conachair]

Originally Posted by Dockhead

Thanks -- very useful. So what is happening is the log is taking system time when it can't get GPS time, and is getting confused when they conflict, which they usually do.

Just had another little play, seems that if the logbook doesn't see gps time from nmea for about 10 seconds or so it will use the system time. Not really getting confused, just using system time if nmea gps time hasn't come in for a little while. If the gps sentence isn't getting sent about once a second then maybe there's a problem somewhere before the computer?

[Kenomac]

Originally Posted by Dockhead

It all depends on what you want to do. If you're just following the dot on the map, like in your car, then IPad nav programs are fine. I have an IPad on board and use it myself, or used to -- I haven't turned it on in a few years.


If you're doing actual navigation, and even more, if you're keeping your log and so forth electronically, if you're doing complex collision avoidance, operating your radar, etc., then you need OpenCPN or something with similar capabilities, and there isn't really anything for Fapple.



I don't like playing with computers at sea, for sure, but there are certain jobs to do which require good functioning IT systems, so sometimes you have to mess around with them.

Radar is on, we navigate as we're supposed to just like the sailors onboard the Navy cruiser we toured a few weeks ago. Nothing much more complex on their cruiser than aboard our modest vessel except for their radar capabilities. Digital radar via the Raymarine 24 inch dome on our boats controlled and monitored via iPads and e125 chart plotters. Paper as back up to the backups.

[Dockhead]

Originally Posted by conachair

Just had another little play, seems that if the logbook doesn't see gps time from nmea for about 10 seconds or so it will use the system time. Not really getting confused, just using system time if nmea gps time hasn't come in for a little while. If the gps sentence isn't getting sent about once a second then maybe there's a problem somewhere before the computer?

The GNSS receiver (a Simrad GS25) is set to transmit time and position data at 10hz. I see in the NMEA debug window $GPGGA coming through regularly, but only 6 to 10 messages per second or so seem to be handled, and there are more than that on the system, and $GPGGA does not get through every second. Maybe that's the issue -- there is so much traffic that $GPGGA is crowded out and goes missing for 10 seconds at a time.


Maybe I need to do input filtering, to get rid of the superfluous messages? I see I can choose "accept only sentences" and "ignore sentences", for each particular connections. What do you think?

[conachair]

Originally Posted by Dockhead

The GNSS receiver (a Simrad GS25) is set to transmit time and position data at 10hz. I see in the NMEA debug window $GPGGA coming through regularly, but only 6 to 10 messages per second or so seem to be handled, and there are more than that on the system, and $GPGGA does not get through every second. Maybe that's the issue -- there is so much traffic that $GPGGA is crowded out and goes missing for 10 seconds at a time.


Maybe I need to do input filtering, to get rid of the superfluous messages? I see I can choose "accept only sentences" and "ignore sentences", for each particular connections. What do you think?

Worth a go! Or can you slow down the Simrad message send rate to see if tht helps?

[transmitterdan]

Originally Posted by Dockhead

The GNSS receiver (a Simrad GS25) is set to transmit time and position data at 10hz. I see in the NMEA debug window $GPGGA coming through regularly, but only 6 to 10 messages per second or so seem to be handled, and there are more than that on the system, and $GPGGA does not get through every second. Maybe that's the issue -- there is so much traffic that $GPGGA is crowded out and goes missing for 10 seconds at a time.


Maybe I need to do input filtering, to get rid of the superfluous messages? I see I can choose "accept only sentences" and "ignore sentences", for each particular connections. What do you think?

It’s a bad idea to send O gps messages 10 times per second. O tries to update a lot of stuff after each message. Try setting it for 1Hz and probably all will be well.

[Dockhead]

Originally Posted by transmitterdan

It’s a bad idea to send O gps messages 10 times per second. O tries to update a lot of stuff after each message. Try setting it for 1Hz and probably all will be well.

Thanks for the suggest. I tried it -- no effect.


I also tried disconnecting the boat network (normally connected via Ethernet) and connecting only the Standard Horizon VHF, which sends a much simpler set of 0183 sentences -- only GPS related ones (GPGGA, GPGSV, and GPGLL).



So no overload possible here But Logbook insists on using computer system time, not GPS time.


Interesting that the NMEA debug window is also using computer system time.


Is this configurable somewhere? Logbook is not working as described.

[Dockhead]

I have always used logbook time selection "UTC", rather than "local = UTC + ___" or "GPS Auto".


I just tried to set to "Local = UTC + __", and to "GPS Auto". I tried some crazy values for "Local = UTC + ___". The log book ignores all of this and persistently uses computer system time.



When I try with no data source connected, the log gives an error message in "remarks" for the relevant the log entry -- "No GPS-Signal"! This seems to indicate that the log recognizes that there is GPS data on the system, when I'm connected. Nevertheless, it stubbornly uses only computer system time no matter how I set the time preferences.

[Lake-Effect]

On a virtual machine setup (Linux server VM running on a Mac) I had the problem of the VM's own system clock pausing whenever the Mac took a snooze. So I wrote a small bash utility that would do a NTP lookup and reset the time. Yes it had to run as admin (root).

Something similar could be done on the Atom (in bat, Perl, Python, Java, C/C++ etc) - a small utility that ran at startup, as long as it had access to the GPS time data. I imagine it might need to run at admin level as well.


This would be a great startup option on OpenCPN, too.

[Dockhead]

This behavior now verified on another machine with a good clock.


Logbook Konni uses computer system time no matter what. It uses GPS data only for changing time zones.

[conachair]

Originally Posted by Dockhead

This behavior now verified on another machine with a good clock.


Logbook Konni uses computer system time no matter what. It uses GPS data only for changing time zones.

Just tried it on laptop & raspberry pi, both use GPS if there and system if no GPS.

[JAFO]

Originally Posted by Dockhead

One problem I have unrelated to the software is my wonky system clock, which plays hell with my logbook. I am running a low power Atom based PC with Win 10, and I guess the system clock battery failed or something.

Originally Posted by Dockhead

I'm very happy with the little Atom box, which I believe has 8 cores, and uses something like 3 watts. Except for the carpy system clock

Originally Posted by hoolie

But the OP's problem, which is one I share as I have the same type of miniPC, is that the clock stops when the device is unpowered. There's no back-up battery to keep it going so time has to be set each time the PC is turned on.

Originally Posted by valhalla360

But even for your situation, do they make a battery backup for the clock similar to a regular PC? So many computer functions rely on time, I would be surprised if it's not an option.

I recently replaced my father's dying desktop PC with a Raspberry Pi desktop setup. For that I used a neat little RPi desktop case that provides 3 things the Pi lacks.. an on/off/shutdown button, a battery-backed realtime clock, and an mSATA connector for up to 1TB of SSD storage.
https://core-electronics.com.au/pi-desktop.html



Maybe there's something similar available for your little Atom boards?

[Buzzman]

Originally Posted by muttnik

Some observations which may be obvious to some but not obvious to others...

NMEA gps strings aren't a particularly accurate way of setting your time. If you don't have a functional real time clock they may be ok for setting your time to the nearest second (which is probably good enough for most people) but the NMEA strings alone will be offset and subject to lots of jitter so you *definiteyl* don't want to go anywhere near continually adjusting your time from the nmea strings alone.

To use a GPS receiver as a reference clock to feed ntpd you need a receiver which also outputs a PPS signal to synchronize the nmea strings to exact seconds. As an exercise a couple of years back I built an ntp reference clock from a raspberry pi hooked up to an adafruit ultimate gps receiver (which does output a pps signal). I used kplex to feed the nmea strings to ntpd (for the hell of it) but the "normal" (and easier) way is just to use gpsd. Of course a rasperry pi doesn't have the hardware to be a decent reference clock (not least because of dodgy network performance) but it's a fun project for some.


Of course the easiest thing is valhalla360's suggestion to fix the clock....

And I'm a 'young person' who doesn't understand a word of this....

There is definitely a 'geek speak' thing going on in this thread.

Or my google translate has malfed....

[CarinaPDX]

I can't help with the original Windows request, but I can provide some (hopefully) useful background. Older GPS modules output on RS-232-C the NMEA data, which was accurate to the millisecond range. Some receivers (such as the Globalsat BU-353) put out the pulse-per-second (PPS) signal on a second serial port, so if 2 ports were available time was accessible in the microsecond range. The USB pucks of the day used RS-232-C to USB adapter chips, which reduced accuracy significantly (if milliseconds count as significant). Modern modules put out USB from the module and can provide time with the USB output synched to the PPS (approx) - think sub-microsecond accuracy - with the right software and hardware. By right I mean a dedicated Pi with minimalist Linux install and GPSd. These can be used as accurate time sources for laboratories, short of atomic clocks. The reason a Pi with Linux is that it isn't dealing with a lot of interrupts unlike Win/Mac laptops and desktops which create variability.

For those of us using Linux I strongly recommend installing GPSd. It contains all of the drivers for pretty much any GPS, including the odd-ball Garmin stuff. And it can then provide the NMEA data strings to multiple apps in parallel (it is an option in openCPN). System time can also be set from the GPS, including PPS if available. Another advantage is that it contains UBXTOOLS since v3.18: this is the easiest way bar none for configuring uBlox 8 GPS modules. Things like NMEA rate (4800, 38400, etc), sample rate (1Hz, 10Hz, etc), GNSS selection (GPS, GLONASS, Beidou, Galileo), PPS enable, NMEA sentences output, and on and on. Many pucks do not have flash to store configurations, so running the configuration in a script on startup solves that problem. With flash it is a one-time configure. Very cool...

Unfortunately there is no one building GPSd for the Mac anymore, and of course it wouldn't be compatible with Windows anyway. (uBlox does have a user-hostile Windows program for the purpose - uCenter - download from their site). It would be easy enough to install VirtualBox and then some flavor of Linux if anyone really wanted to give this a try.

I just received a new puck from China which has the uBlox 8 module (8030kt) inside (all 4 GNSS) and contains flash for storing the configuration. It is incredibly small, and costs only $17 US. Anyone interested order this:

https://www.aliexpress.com/item/Indu...947709096.html

[\geekout]

Greg