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

[muttnik]

Originally Posted by Odysseus7

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

What I was wondering was whether the *other* chartplotter, or indeed something else on the network, is re-broadcasting data on 10110. The debug window shows the additional sentences coming in over the UDP connection.

Ideally it would be nice to see the source address on those incoming data so we can see if they're coming from something else in addition to the source that originally generated them. Do you have wireshark or something installed that could help you look at source address for incoming udp broadcasts on 10110? I'm sadly not a windows users so not best placed to advise on windows built-ins which could help but I'm sure others could.

[rgleason]

Thank you muttnik! (this is an interesting puzzle)

Thank you Odyssues7 for your thoroughness and resilience pursuing the problem.

Maybe there is a RUT955 router program running in the background? Like their GPS program which should be turned off?
Maybe the router could be bypassed or eliminated to see if that solves what Muttnik identified? Just a thought.

[Odysseus7]

Originally Posted by muttnik

What I was wondering was whether the *other* chartplotter, or indeed something else on the network, is re-broadcasting data on 10110. The debug window shows the additional sentences coming in over the UDP connection.

Well there is only one UDP connection on the boat's network; and that is the one from the router to OCPN. The only plausible explanation (if that is even possible, don't know) then is that even though it's an input only connection, OCPN is somehow reflecting the same data back to the router; ad infinitum.

Originally Posted by muttnik

Ideally it would be nice to see the source address on those incoming data so we can see if they're coming from something else in addition to the source that originally generated them. Do you have wireshark or something installed that could help you look at source address for incoming udp broadcasts on 10110? I'm sadly not a windows users so not best placed to advise on windows built-ins which could help but I'm sure others could.

I don't know much about networking; but will install, run and see if I can make something out of Wireshark. In order to do away with the necessity to be on the boat while doing this test (which would turn the exercise to chess by post of the olden ages) , I will install this tool to simulate the broadcasting of GNSS data over UDP. If anybody has an advice for a better freeware (or at least free to try), would be appreciated.

http://www.nmeasoft.com/?ckattempt=1

Originally Posted by rgleason

Thank you Odyssues7 for your thoroughness and resilience pursuing the problem.

My pleasure, I thank you for your help and support!

Originally Posted by rgleason

Maybe there is a RUT955 router program running in the background? Like their GPS program which should be turned off?

Well, the RUT955 is the GPS receiver; there's only a GPS antenna connected via an SMA socket.

The only three distant possibilities to that end could be:

1. Geofencing doing an unintended broadcast, which is very unlikely as it is simply rule based: Define a pivot and radius; and the router sends a signal to the Remote Management System, which triggers the Teltonika RMS app on your mobile to alert, and the Remote System sends an email at the same time. But this is inactive as long as it is within the defined fence.

2. There is a constant stream of GNSS data to the Remote Management System, which seems very unlikely as I did not define any server based alerts but honestly need to check. These days we need to opt out as opposed to opting in But honestly, why should it broadcast over UDP and over the same port, just luck?

Furthermore, there is no GNSS reception on OCPN as long as I turn on the NMEA forwarding stream; which to me proves that there is no autonomous GNSS feed on UDP Port 10110 like the two above.

3. For a bizarre reason that I don't know, I found among the myriad of router services, that Modbus TCP Slave was enabled on Port 10110. Please find enclosed the screenshot. But this is TCP and how can it be relayed back to UDP in the absence of a rule, of which there are none. So this seems implausible to me as well. [/LIST]

Again, thanks a lot.

[rgleason]

Odysseus7


I saw this post where you are using a Noland RS11 Engine Converter with Steve's Engine Dashboard plugin.
Is this also involved in this problem or not? Can't have too many things going on a once.
https://www.cruisersforum.com/forums...ml#post3288917


Which leads me to ask if you have disabled all unnecessary plugins? - Which I think you have done so.

[Odysseus7]

Originally Posted by rgleason

Odysseus7


I saw this post where you are using a Noland RS11 Engine Converter with Steve's plugin.
Is this also involved in this problem or not? Can't have too many things going on a once.
https://www.cruisersforum.com/forums...ml#post3288917

No it's not involved in the problem; I'm not using that plugin. Furthermore, tested the system with and without the RS11 running. It has a serial usb connection to its own client on the pc, and utilizes a custom coding that is neither NMEA0183 nor NMEA2000 in that connection. The RS11 has a proper NMEA2000 output but I don't have or need an NMEA2000 network; at least for now.

Originally Posted by rgleason

Odysseus7
Which leads me to ask if you have disabled all unnecessary plugins? - Which I think you have done so.

I sure did, I'm running as lean as I can now.

[rgleason]

Originally Posted by Odysseus7

No it's not involved in the problem; I'm not using that plugin. Furthermore, tested the system with and without the RS11 running. It has a serial usb connection to its own client on the pc, and utilizes a custom coding that is neither NMEA0183 nor NMEA2000 in that connection. The RS11 has a proper NMEA2000 output but I don't have or need an NMEA2000 network; at least for now.

I sure did, I'm running as lean as I can now.

Thanks.

Simple is good, but sometime you could use to Nmea2000 and convert the PGN to signalK and then use Steve's Engine Data Plugin to display, but that is all for another time, maybe. Simple is good.

[Odysseus7]

I don't mean to resurrect a dead thread but I feel it would be great if I shared this app, which is Windows Store certified and free. With this you can bench-test a UDP broadcast of GNSS sentences.

https://www.microsoft.com/store/productId/9PGRXJ5KLD5Q

On a final note, a non-solution report. I couldn't get rid of the loop problem however much I tried. When I bench tested at home, with another PC broadcasting these sentences, there was no problem and OCPN ran at about 5% of the CPU. However, on the boat it's still around 25%. I pretty much gave up on the router-linked GPS and all's good now

All the best.

[Moo]

Why not use TCP instead of UDP broadcast in such a simple network? Don't use UDP unless you absolutely have to as data can be lost.