OpenCPN Release Candidate Version 3.1.1417 Released

[Hakan]

Dave... muttnic...
To confirm muttnic's info.
System:
Local Wifi router, Default setup.
PC1 WinXP, IP 192.168.1.65, Server
OCPN portable on PC1, client
PC2 Win7. IP 192.168.1.125, client

Using TCP: (Connections setup)
Server IP 0.0.0.0 or 192.168.1.65. Equal result using either of these addresses.
clients IP 192.168.1.65. The only functional but as of muttnic; either of the two client are working. Not both simultaneously. If I force PC2 to connect, by hitting "apply" in data connection window, the portable stop receiving and vice versa.
And as David says if no client is receiving the server output is red lined in the NMEA window.

Note: I havn't investigated if the router is hindering distribution to several clients. Could that be a cause? Please give me hint if that's likely.

Using UDP:
Server: IP 192.168.x.x
clients: only port assignment. (Well I can assign a IP but without system care.)
Works fine and reliable!

Håkan

[muttnik]

Originally Posted by Hakan

Note: I havn't investigated if the router is hindering distribution to several clients. Could that be a cause? Please give me hint if that's likely.

Not likely for a tcp connection. My tests were done with two clients on the same subnet as the machine running O.

[Hakan]

muttnic..
Yes thanks.
Another try:
TCP is per default a one-to-one connection. So to be able to connect to many using TCP the server has to send two or more sets of data.
So in my set up of post #31 I changed to:
Server set up in OCPN connection:
pri: 1, TCP, 0.0.0.0:10110 out-put yes
pri: 0, TCP, 0.0.0.0:10111 out-put yes.

Clients:
portable: TCP, 192.168.1.65:10110
PC2: TCP, 192.168.1.65:10111

Now I can send to two clients simultaneously!

Håkan

[bdbcat]

muttnik/Hakan...

OK, let me restate the problem and confirm my understanding.

Setup: PC1 with one TCP server mode connection, address 0.0.0.0


a. Two simultaneous connections to PC1 OCPN server mode connection is not possible.
b. One external connection to PC1 server mode connection, and (optionally) multiple client mode connections from PC1 to whatever are OK.

If the above is true, we will accept that functionality for Version 3.2.

-There would be no reason to use server mode to connect to a live AIS feed such as hd-sf.com. We should use O in client mode.
-Also, O does not respond to any input data in server mode. He simply echoes the NMEA stream without prompting when the connection is made.
-Finally, if you really need the functionality of multiple server mode connections, UDP broadcast is your best bet, since there really is no notion of a client/server command protocol in O. I think the use of TCP server mode will be rare, and is included to support the cases where a client (like an i-thing or droid) does not know how to do UDP.

For example, here is the problem solved...
http://www.cruisersforum.com/forums/...5-a-98058.html

Have I got this right?

Dave

[muttnik]

Dave,

Originally Posted by bdbcat

OK, let me restate the problem and confirm my understanding.

Setup: PC1 with one TCP server mode connection, address 0.0.0.0


a. Two simultaneous connections to PC1 OCPN server mode connection is not possible.
b. One external connection to PC1 server mode connection, and (optionally) multiple client mode connections from PC1 to whatever are OK.

Not quite. In my scenario I had one tcp client mode connection from O to hd-sf.com (for data input) then one server mode connection in O (ie address 0.0.0.0). The latter was the only one with output enabled. Server was running on OpenSuse 11.2, this morning's git.

I then connected one client to the server. All good. I then connected another client to the server. The connection "succeeded" but data only showed up on the new connection. Data was no longer being sent to the old connection.

Originally Posted by bdbcat

-There would be no reason to use server mode to connect to a live AIS feed such as hd-sf.com. We should use O in client mode.

I was only connecting to hd-sf.com in client mode. This was only to get data to send out and test the tcp server.

Originally Posted by bdbcat

-Also, O does not respond to any input data in server mode. He simply echoes the NMEA stream without prompting when the connection is made.

So "send only" is expected behaviour: fair enough.

Originally Posted by bdbcat

-Finally, if you really need the functionality of multiple server mode connections, UDP broadcast is your best bet, since there really is no notion of a client/server command protocol in O. I think the use of TCP server mode will be rare, and is included to support the cases where a client (like an i-thing or droid) does not know how to do UDP.

If one client only in "server" mode (or, as hakan's last post suggests, one per server connection instance) is expected behaviour then fair enough: I only raised it in case this was supposed to be a listen-fork/create thread-accept styley concurrent server (your wx classes are a little opaque for me to grasp with a quick look).

I personally don't need that functionality in O and if I did I could just use kplex as a shim layer: just trying to help with the testing, and if this is expected behaviour then it's all looking fine.

[Hakan]

Originally Posted by bdbcat

muttnik/Hakan...
Parts of...
If the above is true, we will accept that functionality for Version 3.2.
Have I got this right?
Dave

Yes I do really think we can accept it for 3.2
And yes if I got it right from the beginning you certainly are. And I agree that using two or more TCPs out from O will be rare, but there is a possibility. So the task raised in the other thread you referred to is possibly solved with that.

Conclusions:
For broadcast from O use UDP.
If some items don't know about UDP one or more TCP can be used. They have then to be port separated. And clients IP address to O:s IP and respective ports.
See my settings attached.

Håkan

[Littlechay]

I'm not sure if this is specific to this release or not, but recently due to slow performance I have been deleting my larger layers when I try to do anything with OpenCPN at low levels of zoom (ie, looking at routing for an ocean crossing).

Now it seems that I can't delete large layers; OpenCPN hangs.

Windows 7
Intel i7

[Paul Elliott]

I'm using OCPN Version 3.0.2 Build 2012-07-07, and it crashes when I zoom out to the small-scale chart, and drag it around (NOAA chart 560 showing the US west coast out past Hawaii). If I disable chart quilting it doesn't crash.

OS: Win7/64
Processor: i7-3770
Graphics: NVIDIA GeForce GT 620

[mrm]

A repeatable segmentation fault (in a borderline test case).

Fresh compile of OpenCPN from source, then:

~/OpenCPN/build$ ln -s /usr/share/opencpn/uidata .

do not link gshss and s57data dirs

~/OpenCPN/build$ ./opencpn -p

-> 'no charts installed. Please select chart folders in Options > Charts.'

-> OK

-> OK (without adding any charts)

-> choose 'Show ENC Text (T)'

Segfault.


Linking to s57data dir makes it OK.

[NEVERMIND]

Hi,
GPS is not connected but the icon is green GPS
See on the screenshot
Jean Paul

[Hakan]

Jean Paul..
There are a couple of black lines coming in from connection COM10. The $IIRMC sentence includes a position, 42 58.466N and 009 30.514E.
The "II" says it's a talker/sender designated as "Integrated instrumentation". Whatever connected to COM10 it has a conception of its position.
If you don't want to see that when the GPS is disconnected I think you can try to filter it out. I should have tried to filter incoming data on COM10 to not include "RMB and "RMC".
Håkan

[NEVERMIND]

Thank you for your answer.
JP

[Hakan]

Jean Paul...
I'm sorry but I think I didn't read all your NMEA data before my last post. There is actually a $IIGGA sentence that must be the cause for OCPN to see a position and not the $IIRMC. A closer second thought made me doubt my quick expression. "Why should OCPN care for a RMC sentence?" There must be a GGA! And Yes.
So.. A better tips must be to exclude "GGA" or "IIGGA" from incoming data to COM10.

Again, I'm sorry being that rash before.
Håkan

[mrm]

Dave,

Recent discussion on hotkeys led to removal of 'R' - toggle rocks.
However, there are other hotkeys which remove some information from a displayed chart. Some of these hotkeys do not have any visual feedback to the user, which, although the information removed is not critical, is never a good thing in user interface design.

I thought about an unobtrusive way to provide such feedback (and also to provide a quick reminder what those keys are) and made a small modification to compass window. See attached images and a patch.

Only the visual part is done.

What do you (and other developers / users) think ?

Marius

[Hakan]

Originally Posted by mrm

Dave,
a small modification to compass window. See attached images and a patch.
What do you (and other developers / users) think ?
Marius

Gorgeous!