Visit our Popular Forums

Hakan · 23-12-2012, 07:40

Hi
Have now tested with a GPS
WinXP: Crash or system slow down especially when "navigate to" is active and output to one or more ports are active.
PC Process load is not high but screen updating and OpenCPN response is very low.

Looking in the attached log file it seems that ports are restarted several times every second? When the timer 1 sec is involved then it's me reloading but not else. At the last program start is it evident. There are also NMEA sentences in the log due to a temporary ini-setting "DebugNMEA=500" during the latter start.

openpcn.ini-file and preferences print screen are attached as well.
Attach encryption:
...log1.pdf > A PDF print due its size.
...ini.pdf > take away the .pdf extension

Please have look.

Gilletarom · 23-12-2012, 07:58

hello Dave,

Tab connection, window "Sentence filter"

In the list of options, it would be nice to add "GP". Indeed, many GPS adds this prefix to the sentences issued. This is the case of Globalsat ND100

Other idea, add also "AI"

B.R.

Gilletarom

bdbcat · 23-12-2012, 09:16

Hakan....

OK, thanks.

2 points:

1. There is a performance problem with NMEA retransmit to Serial port on Windows. Working on this now.

2. If you do UDP re-broadcast, then you should set the priority of the "real" NMEA input to something higher than the UDP stream. The reason is that if you are broadcasting, then you yourself will get the UDP message as well. Obviously, it duplicates the "real" data coming from serial in this case. Thus we get source priority flip-flop on each message, since they have the same priority. So, set the serial priority to "1", and the UDP priority to "0". This will clean up your log.

I'll get back with more info on the serial port output slowdown.

Thanks
Dave

Gilletarom · 23-12-2012, 09:28

Hello Dave,

I currently testing the connections.

If you accepted, here are two ideas:

1°
It would be good in the list of connections, after column "Unable", there was a column "Priority" which recalls the priority given to each connection.

2°
It would be good that each time we create or change a connection, the order in which connections are displayed in the list reflects the priority of each connection.

B.R.

Gilletarom

Hakan · 23-12-2012, 09:35

Quote:

Originally Posted by bdbcat

Hakan....

OK, thanks.

2 points:

1. There is a performance problem with NMEA retransmit to Serial port on Windows. Working on this now.

2. If you do UDP re-broadcast, then you should set the priority of the "real" NMEA input to something higher than the UDP stream. The reason is that if you are broadcasting, then you yourself will get the UDP message as well. Obviously, it duplicates the "real" data coming from serial in this case. Thus we get source priority flip-flop on each message, since they have the same priority. So, set the serial priority to "1", and the UDP priority to "0". This will clean up your log.

I'll get back with more info on the serial port output slowdown.

Thanks
Dave

Dave
The priority issue is very good. That's of course why it's there and will use it. The UDP broadcast is really a nice thing. I've tried it to feed a second, portable, edition of O instead of a COM port splitter before both. Work nice and handy. My imagination was that it wasn't the UDP causing the slow down but more the serials. Your focus on that is probably correct.

Thanks and enjoy Christmas.

cagney · 23-12-2012, 10:40

Dave
I had the impression that you and Pavel agreed, that a sentence filtered on input, would still be available on the internal buss for output. It doesn't seem to work that way now?

Filtered and dropped sentences does not show up at all in the debug window. They are supposed to show up in a brown color.

Thomas

Gilletarom · 23-12-2012, 11:11

Hello,

Quote:

Originally Posted by cagney

Dave
I had the impression that you and Pavel agreed, that a sentence filtered on input, would still be available on the internal buss for output. It doesn't seem to work that way now?

Filtered and dropped sentences does not show up at all in the debug window. They are supposed to show up in a brown color.

Thomas

I confirm that Thomas said. It was different with the previous version.

Gilletarom · 23-12-2012, 11:43

Hello Dave,

W XP SP3. Test with serial connection. I see a problem.

1° I breakdown windows and I re-run windows with GPS ND100 in port 4. So all is new.

I run Xportand I send N°4 in N°5 and N°6.
Then I run Polarcom and I connect Polarcom on N°5. All is Ok. The NMEA sentences are present in the NMEA terminal of Polarcom.

Then I run OpenCPN. At this moment, the connetion with port 4 was active because this connetion was active before I breakdown Windows.
Then I modify the connection and I replace the port n°4 by n° 6. And I click on "Apply" ("Appliquer" in french)

And there is no NMEA sentences in the debuging window of openCPN.

See screen copy.

This problem do not exist with previous version.

Gilletarom

Gilletarom · 23-12-2012, 11:57

HHello,

Other test with VSPE.

I create a splitter and send port 4 to port 1
I create an other splitter and send port 1 to port 2.

Then I run OpenCPN, I destroy the connection with port 4
I create a connection with port 1. No sentence in NMEA debugger window
Then without destroy connection with port 1
I create a second connection with port 2. Then crash.

bdbcat · 23-12-2012, 14:01

cagney/Gilletarom..

I confirm a problem with input filtering, debug window, and output data.
Simple misplaced character in the source. Fixed in github and next Beta

Thanks
Dave

muttnik · 24-12-2012, 07:26

Quote:

Originally Posted by bdbcat

2. If you do UDP re-broadcast, then you should set the priority of the "real" NMEA input to something higher than the UDP stream. The reason is that if you are broadcasting, then you yourself will get the UDP message as well. Obviously, it duplicates the "real" data coming from serial in this case.

I can confirm that filtered sentences are now making it through to be ouput (in today's git source) but does this present another problem? If you filter something on an input and then re-broadcast it over udp, you will receive it again and unless you filter the udp interface as well. What you were trying to block will still get to opencpn.

I thought perhaps the trick of setting the udp output to a lower priority than the input might solve this, as it might depending on whether the prioritisation code is invoked before or after the filtering code. Curiously with the udp interface (with re-broadcast) set to be lower priority than the (tcp) input, in the debug window I see my filtered packets dropped and re-broadcast, but not re-accepted by the udp interface (ie no green input messages as there would be with equal priority on the interface). All good and correct. Except that data *is* coming in. I have the San Francisco AIS stream coming in via tcp and I can still see traffic moving and AIS updating in opencpn. If I then filter AIVDM the UDP input as well as tcp, updates stop.

I'm aware that I'm not using a proper beta (to get the fixed code bdbcat mentioned in the previous post) and that this may be a known and currently worked on problem, but I thought I'd mention it.

I was wondering whether it might be an option to do a getifaddrs() and drop any udp broadcast packets originating from a local interface, but a quick look at your code (I don't claim to be a C++ coder, just an antediluvian C hacker) suggests that's not really an easy option with the datastream abstracted out in wxSockets.

AISEAG · 24-12-2012, 07:28

Quote:

Originally Posted by cagney

Right clicking a Dashboard -> Preferences -> Dashboard -> Caption

Whatever changes in Caption, Calling it "Dashboard 1" or "Whatever", is not displayed on the screen. Each dashboard is always just called "Dashboard".

adding:
Why is the "Edit" button in the Dashboard preference dialog?
As far as I can say, there has never been any "action" connected to it.

Thomas

Hello Thomas,

This caption is working (at least for me), you have to stop and re-start OpenCPN after the change.

Serge

bdbcat · 24-12-2012, 07:40

cagney....

Regarding:

Right clicking a Dashboard -> Preferences -> Dashboard -> Caption

Whatever changes in Caption, Calling it "Dashboard 1" or "Whatever", is not displayed on the screen. Each dashboard is always just called "Dashboard".

Seems to be a bug in wxWidgets. The new Dashboard caption takes effect after the next start of O, at least on linux. Or if you dock/undock the Dashboard.
Windows?

Thanks
Dave