OpenCPN Beta Version 3.1.1224 Released

[bcn]

Hi,

we can confirm that the reported issue of the ownship icon not showing the correct COG has disappeared with 3.1.1224

bcn

[Hakan]

Hej. Continuing UDP broadcast - It's actually not stable on Win XP.

This test is on a PC internally using two O's, one in Portable mode. The GPS and AIS was each connected to a serial port.

The connection is unstable in the way that it can start up when I, in toolbox, hit the "Apply" button but deactivates again after "Ok". Ones restarted It can also deactivate after some seconds without me touching anything. I can't find no particular connection to any clear contributory factor but I've the impression that one or more active serial ports make it worse. That's because at home, without any active com-ports, it's more or even very stable.
The connection stability is independent of used IP-address exactly as discussed here before. (Neither of 0.0.0.0, 127.0.0.1 nor 192.168.0.255)

I'm not even sure that this is a O' dependent problem. It can be XP as well? This said because the (IP)port occupations seems very reliable. A soon as a UDP connection is established from O, either in our out, the port, 10110, is opened from the applicable application. This was checked with "Netstat".

Does anyone have a clue how I should continue testing to find out clear dependents?

I did my very best to describe this but a clear English expression can be hard. Please ask if/when this is unclear.

[Gilletarom]

Hllo,

Originally Posted by STHR

Hi all,

... Also on the AIS Ship Detail Page some more info like tpe of GPS / DGPS, ... would be great.

For the Ship Size somethink like this LINK would be great. ....

For the size of AIS targets, there is some explanation on AIS | Official OpenCPN Homepage.

If you are french, see this page :
Utiliser l'AIS

[P_Dub]

I have suggested a few times that ships have a more appropriate shape, when zooming in. May I come back again on this to be included in a future
version.
Rgards.

[Gilletarom]

Hello Dave,

In this page : Data Connections | Official OpenCPN Homepage

I read this "Both boxes are configured to use the same broadcasting address 192.168.0.255 on the local network, using the default 10110 port"

and I try to use this adress. But i use TCP then OCPN was completetly blocked. Only Ctrl/Alt/spur for shutdown it. And once, crash.

Here my ini file :

[Settings/NMEADataSource]
DataConnections=1;1;127.0.0.1;11083;0;;4800;0;1;1; ;0;GGA;2;0;1;0;0|0;0;;0;0;COM4;38400;1;0;1;;1;HDM, HDG,HDT,RMB,RMC,WPL,RTE,GLL,VTG,GSV,GGA,GPwpl,ECRM B,ECRMC,AIVDM,AIVDO,FRPOS,CD,GP;0;0;0;0;0|1;0;127. 0.0.1;11083;0;;4800;1;1;0;;0;VTG;0;0;1;0;0|1;0;207 .7.148.216;9009;0;;4800;1;0;0;;1;HDM,HDG,HDT,RMB,R MC,WPL,RTE,GLL,VTG,GSV,GGA,GPwpl,ECRMB,ECRMC,AIVDM ,AIVDO,FRPOS,CD,GP;0;0;1;0;0|0;0;;0;0;5;4800;1;0;0 ;;0;;5;0;0;0;0|1;0;81.44.86.73;6001;0;;4800;0;0;0; ;1;;6;0;1;0;1|1;0;192.168.0.255;10110;0;;4800;1;0; 0;;0;;6;0;1;0;1
[Settings/MSWFonts]

join my log file. (it is ziped because it is to big and I have add ".doc")

I add : Using the same sockett, but with UDP mode, no problem.

B.R.

Gilletarom

[Hakan]

Originally Posted by Hakan

Hej. Continuing UDP broadcast - It's actually not stable on Win XP.

This test is on a PC internally using two O's, one in Portable mode. The GPS and AIS was each connected to a serial port.

The connection is unstable in the way that it can start up when I, in toolbox, hit the "Apply" button but deactivates again after "Ok". Ones restarted It can also deactivate after some seconds without me touching anything. I can't find no particular connection to any clear contributory factor but I've the impression that one or more active serial ports make it worse. That's because at home, without any active com-ports, it's more or even very stable.
The connection stability is independent of used IP-address exactly as discussed here before. (Neither of 0.0.0.0, 127.0.0.1 nor 192.168.0.255)

I'm not even sure that this is a O' dependent problem. It can be XP as well? This said because the (IP)port occupations seems very reliable. A soon as a UDP connection is established from O, either in our out, the port, 10110, is opened from the applicable application. This was checked with "Netstat".

Does anyone have a clue how I should continue testing to find out clear dependents?

I did my very best to describe this but a clear English expression can be hard. Please ask if/when this is unclear.

Well... since none had a nice reply I've to do it my self?? No..joke! I'd some more tests and maybe closer to facts.
My assumptions are now:
First; this is not a O' initiated problem. The unstable UDP broadcast is about IP address, ports and OS handle. IP addresses are not really independently as said before. We have two different situations, one when broadcasting internal the local host/PC without network nor a LAN IP address, the other when connected to a network. The first is rather common when sailing and you want to use two O' windows, the latter if you've a wifi on board and want to broadcast to for example a cockpit PC.

Initially the UDP listener can/shall in all cases use IP address 0.0.0.0.
The UDP talker shall use IP 127.0.0.1 when broadcasting PC internally and something like 192.168.x.255 when connected to a network. (That's what the wiki now says)
In above cases all shall use the same port. (Wiki suggests nicely 10110)

Now O's UDP setup is handling this in a say funny or maybe unexpected way.
In the first case, local host; If only one O-app is active and talking to UDP everything that's sent out is echoing back, like discussed in other posts before. But as soon the listener starts up and occupies a port the echoing stops! (The funny thing!) See pics "UDP_LOC_1 &_2".
In the second case, network; Echoing is always there and it seems that a buffer is used especially when network traffic is considerable. I do assume this buffering indicates a busy machine and should be avoided if possible. See attached pics "UDP_LAN_1 & _2" showing normal and buffer situations.

A suggestion:
To avoid a busy machine it could maybe help if O' don't occupie a listening port if not needed? (This is beyond my knowledge please judge) If so it would be nice to split the UDP handling to one talker type and one listener type of connection. In this way we could also maybe get rid of echoing discussed here and in other posts.

Well.. this was my assumptions and more. I wish you all a happy new 2013 and I look forward to use the new brilliant O' when spring eventually arrives.
/Håkan

[nohal]

Originally Posted by STHR

For the Ship Size somethink like this LINK would be great. There is also a little Port Problem, can you build a sub so that the`re alinged with the sheet pile wall?

We can probably argue about the shape of the ship - not all of them are the same and AIS simply gives us just the width and length (and that's what we show, anything else would be a, most likely wrong, guess).
There is no problem with the ports, we show what the targets transmit and I would consider it to be a VERY bad idea to try to be smart and display something else - remember that it can be the chart that is wrong, not the transmitted info.

Pavel

[STHR]

Originally Posted by nohal

We can probably argue about the shape of the ship - not all of them are the same and AIS simply gives us just the width and length (and that's what we show, anything else would be a, most likely wrong, guess).
There is no problem with the ports, we show what the targets transmit and I would consider it to be a VERY bad idea to try to be smart and display something else - remember that it can be the chart that is wrong, not the transmitted info.

Pavel

Hi Pavel,

thanks for the update. You`re totally correct but the Ships are morred. because of the GPS hopping it looks like they`re moving (Ships are 100m +x). The Charts are by the .gov It can also be a problem with sheet pile wall and the compass. On the Max zoom Level it would be an option to draw the whole ship size with colour like the AIS Symbol.

PS: Please include in the AIS Info Window the type of GPS / DGPS, ...

[STHR]

The AIS Options MID (Country Name of Ship) would also be a nice gift.

[phiggins]

I have two plugins that I compile (Windows) under OpenCPN V3.1.1224 and they work fine on that system and one running V3.1.919. But if I try to run them on OpenCPN V3.0.2 they fail to load. Open CPN gives this message:

Error: Failed to load shared library 'C:Program\Files\OpenCPN\plugins/ge2kap_pi.dll' (error 127: the specified procedure could not be found.)

and a similar message for the other plugin.

Here is the WANTS of both them:

ge2kap_pi:

(WANTS_TOOLBAR_CALLBACK |
INSTALLS_TOOLBAR_TOOL |
WANTS_PREFERENCES |
WANTS_ONPAINT_VIEWPORT

Triplog_pi:

WANTS_CURSOR_LATLON |
WANTS_TOOLBAR_CALLBACK |
INSTALLS_TOOLBAR_TOOL |
WANTS_CONFIG |
WANTS_PREFERENCES |
WANTS_NMEA_SENTENCES |
WANTS_NMEA_EVENTS |
USES_AUI_MANAGER |
WANTS_ONPAINT_VIEWPORT |
WANTS_PLUGIN_MESSAGING

Should a plugin compiled on the latest version work on V3.0.2 ?

[tiberius64]

Hi cagney,

about the sound problem what should be fixed -I installed the two packages you mentioned above, updated the wx packages and updated to opencpn 3.1.1224 but the sound does not work, I run Ubuntu 12.04. What information could be helpful for you to help me with my problem - the sound worked with the earlier beta.

Thanks in advance

tiberius

[cagney]

Originally Posted by tiberius64

Hi cagney,

about the sound problem what should be fixed -I installed the two packages you mentioned above, updated the wx packages and updated to opencpn 3.1.1224 but the sound does not work, I run Ubuntu 12.04. What information could be helpful for you to help me with my problem - the sound worked with the earlier beta.

Thanks in advance

tiberius

Thanks for the report!

I did find an error in the 64 bit package on the download page.
I could not get the sound to work either!
It showed up that I had, without being aware, un-installed "portaudio19-dev", through some dependency flip/flop.
O compiles fine without it, but sound will not work.
Note that "portaudio19-dev", is only necessary if you compile yourself.
A corrected package is now available on the normal download page.

I hope this helps.

Thomas

[tiberius64]

Hi Thomas,

it works - thank you for your fast reaction

tiberius

[rgleason]

Tom bigspeedy, Thank you for the improvements to the Dashboard including the wind history, and thanks to Dave and all others for their work on Nmea Mux. Need to try it out.

[cagney]

Originally Posted by hypex

Hi,
Thanks for the beta. I've loaded .1224 onto Ubuntu 12.10. I have Prolific GT730F. I used gpsd, tested for port Nobody,Somebody etc. and all OK.
Sorry, I don't understand, please explain!

On openCPN used Net 2497, and get a data stream on NEAMA debug window. Button on top right of window shows "red" indicating no GPS data.
Not necessarily! It shows that no fix is available!
Autofollow is also red but position way off. Back checking with xgps no satellites, or lat long data.
If xgps isn't working, it's a gpsd problem!
Any suggestions?
opencpn/libgrib_pi.so
11:54:24 PST: Chart cache purge
11:54:24 PST: Closing NMEA Datastream GPSD:localhost:2947
11:54:24 PST: Closing NMEA Datastream Serial:ttyUSB0
This line makes no sense at all! Don't use /dev/ttyUSB0 either, together with GPSD. That's asking for problems!
11:54:24 PST: Closing NMEA Datastream Serial:/dev/ttyS0
Just curious, what's this line used for?
11:54:24 PST: Stopping Secondary Thread
11:54:25 PST: Stopped in 1 sec.
11:54:25 PST: LOGBOOK: 2012-12-26 19:54:25 UTC OFF: Lat 48.66370 Lon -133.59240
11:54:25 PST: opencpn::MyApp exiting cleanly...

13:26:01 PST:

Hypex
Sorry it's taken some time to answer.
Have you made any progress?
So, first get gpsd going. Is it installed?
Please print your return from this command

dpkg-query -l |grep gps

Then insert your gps and print the return from

ps aux|grep gpsd

Thomas