Will disabled plugings still make OCPN "fatter & slower"? & how to fully remove them

[rgleason]

"PC is a military-grade Dell 7202 Latitude 12 Rugged Tablet with intel graphics."
I agree that it is likely the Intel Graphics. What version number?

You should try to run OpenGL Extensions Viewer
OpenGL Extensions Viewer 6 | realtech VR | realtech VR

and report.

[Odysseus7]

Originally Posted by rgleason

I agree that it is likely the Intel Graphics. What version number?

It's Intel HD Graphics 5300.

Originally Posted by rgleason

You should try to run OpenGL Extensions Viewer
OpenGL Extensions Viewer 6 | realtech VR | realtech VR and report.

Great tip rgleason, thank you; will do.

[rgleason]

Also, try not using opengl, or even disabling texture mapping or acceleration under opengl. Sometimes these are not well supported by early Intel hd graphics. I have a 4300 board that is not too happy with opengl, but it works when I just use the opengl and none of the other selections.

That laptop also has an Nvidia GeForce card that is significantly faster. Can you get an Nvidia card for that.laptop? They fit nicely inside an opening in the back usually.

[Odysseus7]

Originally Posted by rgleason

You should try to run OpenGL Extensions Viewer and report.

So enclosed in the first image please find the OpenGL Extensions Viewer Summary Report; and in the second one the OpenGL Report.

Thank you.

[rgleason]

How old is this PC?
Have you run any of the OpenGL tests?
However I think a 5300 Intel HD Graphics board should be fine, it is newer than my nvidia, ..unless there is a hardware failure somewhere.


As Hakan suggested looking for changes (improvement) in performance:
1. Physically disconnect all nmea and start by just running Opencpn on your laptop, nothing else!
2. Turn off all OpenGL options, even try turning off Opengl
3. Then try rebuilding your chart database.
4. Then try renaming you config file and rebooting to create a new config. Test it for performance. Then copy your config file back to be used.
5. Reinstall Opencpn perhaps?

I am running out of ideas. Sorry. I have read the string.

[Odysseus7]

Originally Posted by rgleason

How old is this PC?
Have you run any of the OpenGL tests?
However I think a 5300 Intel HD Graphics board should be fine, it is newer than my nvidia, ..unless there is a hardware failure somewhere.


As Hakan suggested looking for changes (improvement) in performance:
1. Physically disconnect all nmea and start by just running Opencpn on your laptop, nothing else!
2. Turn off all OpenGL options, even try turning off Opengl
3. Then try rebuilding your chart database.
4. Then try renaming you config file and rebooting to create a new config. Test it for performance. Then copy your config file back to be used.
5. Reinstall Opencpn perhaps?

I am running out of ideas. Sorry. I have read the string.

Hakan and rgleason; first of all, many thanks for your support.

I have followed your steps; found and solved the problem. It's got nothing to do with the PC or OCPN. My (now former) GPS feed was the problem: The GPS receiver, which works just fine, is connected to the router/modem (Teltonika Rut955, I would highly advise to any sailor) and fed to the PC via an NMEA broadcast through the wireless connection between the two. Therein lay the problem.

Radar Pi plugin requires GPS data, among others. I thought the GPS feed could be causing the problem. When I disabled that incoming wireless GPS connection and created a new serial one using my good old substitute (now primary) Chinese USB GPS, everything worked like a charm. No stutter; and perfect performance from the PC with CPU power and RAM to burn. OpenGL and all sub-functions enabled; no problems whatsoever. OCPN CPU usage at round 5% and using 110mbs of the 8gb memory.

Problems arose when I used the router GPS potentially because wireless is not the best way to relay NMEA sentences; and maybe because the same wireless connection also carries the internet connection between the router and the PC; and concurrent use of both data streams is not a good idea. It would be great to learn; if someone in the know could comment; as to why that setup was jacking up CPU usage to around 30% and causing stutters in the radar sweep. While the GPS is able to relay Glonass, Galileo and Beidou as well as the US GPS; I only enabled US GPS to decrease the NMEA load; and also for the supposedly higher accuracy of the US GPS. Furthermore, I only allowed the GPGGA, GPVTG and GPRMC sentences to be relayed to decrease the load. Yet it still caused massive problems. I wonder why.

All the best.

[Hakan]

Odysseus7...
Many thanks for the report and very good you've solved the problem.
I can't imagine what was causing the trouble though. To use a wifi network to pass massive UDP and also TCP messages together with any internet traffic I do at home all time. I have a couple of PCs running on the same wifi net sharing NMEA feeds. My Internet traffic is on the same net.
So it must have been something with the GPS feed you now have dismissed. It's hard to point to anything specific when I can't see what's going on. But a normal NMEA stream would not choke the PC. To compare I've all what a GPS can feed, sounder, compass, wind data and, not less, some 500 AIS targets all time.

Håkan

[Karanga]

Bogging the PC like this sounds very similar to the issue I get with my radar connection. If radar_pi plugin is enabled, but radar turned off, the CPU will go veeery slow and have more than 50% consumed. If the plugin is not enabled, but the radar is turned on, in the RJ45 socket, the PC is again very slow.
So it might be something with OpenCPN tying up resources when it is waiting for expected data?

Tim

[rgleason]

Odyseuss

When I disabled that incoming wireless GPS connection and created a new serial one using my good old substitute (now primary) Chinese USB GPS, everything worked like a charm.

Thank you!

Problems arose when I used RUT955 LTE router GPS potentially because wireless is not the best way to relay NMEA sentences; and maybe because the same wireless connection also carries the internet connection between the router and the PC; and concurrent use of both data streams is not a good idea. It would be great to learn;

Listening to you and Hakan, I wonder if some network gurus would have an idea? Maybe Muttnik would have an idea. He might need some output nmea files to be saved and attached here however. I may PM him.


Note that the RUT955 has built in GNSS
GNSS Global Navigation Satellite System for location services and time synchronization

I would report this to RUT995 support and file a bug.

[rgleason]

How does this wifi gnss work with a tablet running Opencpn Android perhaps?
When the radar wifi is off, does the GNSS from the router work properly?
What are the Opencpn options> settings being used for both streams?

[Odysseus7]

Originally Posted by rgleason

I would report this to RUT995 support and file a bug.

Thank you rgleason, will do; pending the forum's comments and advice on the current router NMEA broadcast settings, which I will share below.

Originally Posted by rgleason

How does this wifi gnss work with a tablet running Opencpn Android perhaps?
When the radar wifi is off, does the GNSS from the router work properly?
What are the Opencpn options> settings being used for both streams?

I have an android phone and would be happy to check, but somehow Dave's OCPN Android version didn't work on my phone.

The GNSS works fine, allows you to geofence the boat and one can check the boat's location remotely.

So now that the problem has been isolated to the router to PC GNSS broadcast segment; I guess it would help common knowledge if I shared the current NMEA broadcast settings of the router and OCPN incoming connection settings.

Router NMEA settings:

Hostname: 192.168.1.119 (static IP of the PC on the boat)
Port: 10110
Protocol: UDP
Contain connection: Enabled
NMEA forwarding cache: ram (alternate is flash)
Maximum sentences: 5000 (was default)
NMEA collecting: Disabled (don't need it)
Enabled sentences: GPGGA, GPVTG and GPRMC
Forwarding interval: 5 seconds (default)
Disabled sentences: GPGSV, GPGSA, GLGSV, GNGSA, GNGNS, GAGSV, PQGSV and PQGSA

OCPN Incoming Connection:

Protocol: UDP
Address: 0.0.0.0
Port: 10110
Priority: 1
Receive Input on this port: Enabled
All other connection tick boxes are disabled.

All the best.

[Hakan]

Originally Posted by Karanga

Bogging the PC like this sounds very similar to the issue I get with my radar connection. If radar_pi plugin is enabled, but radar turned off, the CPU will go veeery slow and have more than 50% consumed. If the plugin is not enabled, but the radar is turned on, in the RJ45 socket, the PC is again very slow.
So it might be something with OpenCPN tying up resources when it is waiting for expected data?

Tim

Tim..
May bee out of this thread but: Try to update your radar_pi. This sounds like an old issue. There was also a Halo connection issue now solved in the radar_pi beta released today. If your issue is not solved by master catalog version 5.1.4 try the Beta catalog version 5.2.0-beta2.
All in OCPN Options->Plugins->Update plugin catalog

[muttnik]

Per Håkan's response, multiple streams of NMEA data shouldn't add a significant additional load to normal browsing traffic on a wifi network.

Is it my imagination or in one debug window Odysseus7 posted are there 3 identical RMC sentences in the same second and in another 4 identical VTG sentences in the same second? This says "loop" to me, whether it's caused by the ocpn config. Can we double check that Odysseus7 paid particular attention to step 4 in Håkan's debug suggestion? The loop might be in something else on the network. The #1 thing to confirm would be that the "other chartplotter program" isn't re-broadcasting GPS data on 10110.

Out of interest...I've re-read the thread a couple of times but can't see where the radar data are coming from. Is that over wifi too? We all know about the perils of radar over wifi, although if the problem is apparently solved by eliminating the broadcast gps connection then that's presumably the thing of most interest.

[Odysseus7]

Hello Muttnik, first of all, many thanks for getting involved per rgleason's suggestion.

Originally Posted by muttnik

Is it my imagination or in one debug window Odysseus7 posted are there 3 identical RMC sentences in the same second and in another 4 identical VTG sentences in the same second? This says "loop" to me, whether it's caused by the ocpn config.

It really is not your imagination and is sadly the case.

Originally Posted by muttnik

Can we double check that Odysseus7 paid particular attention to step 4 in Håkan's debug suggestion?

Originally Posted by Hakan

Start the TCP receiving program and check for changes in the debug window.
If black input (UDP) rows are increasing when the TCP connection is enabled there's something wrong in the setup.
Håkan

I believe this is the step you mention; will check again but once I start the wireless GPS broadcast it's NMEA rodeo choking the PC. It was much worse before I removed the GPGSV, GPGSA, GLGSV, GNGSA, GNGNS and GAGSV sentences from the broadcast set; which I believe is another testament to making the case for a loop.

Originally Posted by muttnik

The #1 thing to confirm would be that the "other chartplotter program" isn't re-broadcasting GPS data on 10110.

Already changed the TCP connection between the other chartplotter program and OCPN to another port, namely 10012, and the problem remains the same.

Originally Posted by muttnik

Out of interest...I've re-read the thread a couple of times but can't see where the radar data are coming from. Is that over wifi too?

No the radar connection is from the 4G radome to the RI10 interface then to the PC via an ethernet cable. And I deliberately didn't take that connection through the router in order to have an isolated clear high speed data delivery with no interference.

So now thanks to Muttnik who has diagnosed a loop, would be fantastic to find where it is. Just to recap, here's the data flow between the three nodes:

Router NMEA Output:

Hostname: 192.168.1.119 (static IP of the PC on the boat)
Port: 10110
Protocol: UDP
Contain connection: Enabled
NMEA forwarding cache: ram (alternate is flash)
Maximum sentences: 5000 (was default)
Enabled sentences: GPGGA, GPVTG and GPRMC
Forwarding interval: 5 seconds (default)
Disabled sentences: GPGSV, GPGSA, GLGSV, GNGSA, GNGNS, GAGSV, PQGSV and PQGSA

OCPN Input :

GPS: Input UDP Address 0.0.0.0 Port 10110

OCPN Output:

All NMEA Data: TCP Address 0.0.0.0 Port 10112

Other Chartplotter Input:

TCP Input 127.0.0.1 Port 10112, as input from NMEA Multiplexer to enable multiple data feeds in one connection

All the best

[Karanga]

As per Hakan's suggestion, I back-installed a production version of OpenCPN, which allowed me to install the beta version of radar_pi.
I have only managed to test this once so far. It looks like the CPU-hogging no longer happens when the radar is turned on without radar_pi enabled. So likely a fix for that.
The beta also appears to be working well with Navico Halo24 unit.
Thank you to you wonderful geniuses!
Tim

Originally Posted by Hakan

Tim..
May bee out of this thread but: Try to update your radar_pi. This sounds like an old issue. There was also a Halo connection issue now solved in the radar_pi beta released today. If your issue is not solved by master catalog version 5.1.4 try the Beta catalog version 5.2.0-beta2.
All in OCPN Options->Plugins->Update plugin catalog