OpenCPN Beta Version 3.1.1224 Released

[Hakan]

Hej. A "Dummy" Wiki completion suggest.

The Wiki is nicely exhaustive and worthy of imitation. But for a sometimes dummy user like me, could there be quite a few of us?, I manage to first misunderstand the priority order in the Data Connections section. I've added a suggest to the cut text below indicating that a higher figure is actually a lower priority.

Notes om filtering

• If a NMEA sentence is filtered on an input connection, it will still enter the internal multiplexer. So, it will be available to output connections, unless it's filtered there as well. The exception to this is, echoing back a network connection, on the input port for output.
• If you have a connection using UDP and a broadcast address for output, set the priority of the connection lower than any real NMEA source. Set to "0" gives the highest priority,

[cagney]

Originally Posted by Hakan

Hej. A "Dummy" Wiki completion suggest.

The Wiki is nicely exhaustive and worthy of imitation. But for a sometimes dummy user like me, could there be quite a few of us?, I manage to first misunderstand the priority order in the Data Connections section. I've added a suggest to the cut text below indicating that a higher figure is actually a lower priority.

Notes om filtering

• If a NMEA sentence is filtered on an input connection, it will still enter the internal multiplexer. So, it will be available to output connections, unless it's filtered there as well. The exception to this is, echoing back a network connection, on the input port for output.
• If you have a connection using UDP and a broadcast address for output, set the priority of the connection lower than any real NMEA source. Set to "0" gives the highest priority,

Thanks for actually reading the wiki. It's great with some feedback.
Connections is a work in progress......
"0" is the lowest priority, at least it's supposed to work that way, as far as I can tell. I have rewritten bits and pieces, so please go back, and see if the present version is clearer.

Thomas

[cagney]

Dave

Connections priority. Changes in priority only gets into the log on restart. I'm not sure that it works properly either. I seem to get flip/flops between data streams with different priorities for the same message, in the log. For example, two AIS streams with different priorities, both show up on the screen.


Thomas

[cagney]

Originally Posted by tom_BigSpeedy

Cagney,
the "wind history" instrument is meant to be run as a standalone (vertical) instrument.
....
.....
......
t this is an dashboard-automatism and was not my programming :-)

Thomas

Thank you Thomas, for the explanation. I'll make sure it gets into the wiki somehow.
Unfortunately I can't test Wind History due to this -> OpenCPN::Tracker All Projects: Tasklist bug.

Generally the last couple of betas have been alright, but trying "Wind History" as a separate instrument brings it all back again and my computer grinds to a halt, almost!

Thomas

[Hakan]

Originally Posted by cagney

Thanks for actually reading the wiki. It's great with some feedback.
Connections is a work in progress......
"0" is the lowest priority, at least it's supposed to work that way, as far as I can tell. I have rewritten bits and pieces, so please go back, and see if the present version is clearer.

Thomas

Thomas.. Very nice indeed, more and relevant bits.
Maybe a note about filtering of the autopilot signals could be informative. If I'm right the produced signals when a route is active are the ECRMB and ECRMC sentences. This "EC..." is probably not known by all and could be worth mentioned as the GPRMB/C are also sometimes present but with less data and could perhaps delude the autopilot?

[Gilletarom]

Hello Dave,

Dasboard, Preferences

I select one of the 3 dasboard that I have previously created.

The checkbox "Display this dasboard" is not checked.

But :
1°
If I chek this checkbox, this dasboard is immediately displayed. This is new. With 3.02. It is not same. Is it normal ?

2° When I run the Dasboard plugin, all my dasboard are displayed.

Gilletarom.

[AISEAG]

Boat characteristics :

When selecting 'real size' instead of 'standard', the system is sending you an error message (even if the length of the boat is 10 meters see attached file).

This option was working well on the previous version.

Serge

[P_Dub]

In Widows 7, using real size boat, all is working correctly; so check what OS you are using it might be the cause of some of the errors or may be the compile you did, if you did it yourself.
Bye

[AISEAG]

Originally Posted by P_Dub

In Widows 7, using real size boat, all is working correctly; so check what OS you are using it might be the cause of some of the errors or may be the compile you did, if you did it yourself.
Bye

Thanks P_Dub,

I am running on XP,

I' have found the trouble :
the minimum size on the screen need to be >0,
I do not remember to have type something like this in the 3.1.1220 beta.
May I suggest to put 1 by default.
Serge

[P_Dub]

Originally Posted by AISEAG

Thanks P_Dub,

I am running on XP,

I' have found the trouble :
the minimum size on the screen need to be >0,
I do not remember to have type something like this in the 3.1.1220 beta.
May I suggest to put 1 by default.
Serge

That is exactly what I did.
Bye

[Gilletarom]

Hello,

For Dave :

trying 3.1.1224 as server ou trying as client, no problem now with TCP and UDP network. Using Polarcom for these tests, all is Ok for me.

For All:

I send with two conections, one TCP and one UDP, on the same adress : 127.0.0.1:11083, two differents types of NMEA sentences. All is Ok, Polarcom receive the two types of sentences.

Question : This type of practice he can, despite the apparent functioning, a problem? That it must OpenCPN does not allow?

[Gilletarom]

Hello Dave,

I committed intentionally, an error by creating a network connection type. I stuck the socket of one block in the address line, without putting the port number in the line port.
OCPN accepted the creation of this connection without a word.

This does not, however. Enclosed two screenshots

Similarly, I stuck the socket da, s line and port in the address line. It is accepted by NMSO. Obviously it does no good.

Should be put some alert messages in case:
the Ip address format is bad
the port number would be between 1 and 65536.

B.R.

Gilletarom

[muttnik]

Originally Posted by Gilletarom

I send with two conections, one TCP and one UDP, on the same adress : 127.0.0.1:11083, two differents types of NMEA sentences. All is Ok, Polarcom receive the two types of sentences.

Question : This type of practice he can, despite the apparent functioning, a problem? That it must OpenCPN does not allow?

If I understand this question correctly: Not a problem: they are two different transports so there is no possibility for adverse interaction. A UDP socket will not be passed TCP traffic and vice versa. The same address and port number does not imply any connection between them.

One thing I've been wondering though. This is an example of unicast UDP use. The common use case for UDP in the context of OpenCPN is presumably broadcast. There is no hint or restriction for a user trying to specify a broadcast address: No warning is given if a user specifies a non-local broadcast address (ie directed broadcast). How things stand is actually the most flexible arrangement (allows for unicast. directed broadcasts, whatever) and the simplest to code. Perhaps a "nice to have" for users not so comfortable with networking might be (when UDP is selected) a pull-down list of local interfaces which when the user selects one (e.g. "wlan0") the broadcast address is filled in automatically. Possibly somehting for the longer-term feature suggestion box though :-)

[Gilletarom]

Hello,

Originally Posted by muttnik

If I understand this question correctly: .. ..-)

Thank you Muttnik.

[Hakan]

Hej. A possible ECRMC failure?

I've tested the autopilot connected to serial port output. It seems that the ECRMC sentence produced by O creates an error. The magnetic variations field, #10, differs from a RMC sentence produced by the GPS, GPRMC. It's not much but what I could find is that the number of leading zeros before the decimal point differs. In GPRMC there are three but in ECRMC only one. Could this cause the error?
See my test method in attached PDF.

What more: Once again, this new mux is great, even live onboard. (Even though it's only "jetty sailing" due to the ice cover. )