Feature Requests

[spirare]

Is this a known issue ?
Is there a fix for this problem ?

Here is the set up:
- W10;
- GPS+AIS via USB to PC (That is on COM4);
- Set of virtual port created with com0com (CNCA0-->COM7);
- hum4com route all COM4 to CNCA0;

Device manager shoes COM7 as available in the Port section.

Putty connected to COM7 shoes all the NMEA0183 sentences.

Other software can connect to this port and get the data ok... but not OpenCPN (with the correct connection parameter).

OpenCPN can connect to COM4 and get all the data (work around but I don't want OpenCPN to be the main entry point for all my navigation data stream).

p.s.:I have made sure nothing else uses COM7 when I try to connect with OpenCPN.

Regards,

[Ambler]

Any chance of the AIS target COG predictor length (in minutes) getting sychronised with the COG predictor length of own vessel?

It is something I change between offshore and harbour from 1 hour to 15 minutes to achieve relevance of all moving vessels to my own course and speed.

Cheers

[Dsanduril]

Originally Posted by spirare

Is this a known issue ?
Is there a fix for this problem ?
...,

IMO yes, this is a known issue based on the number of similar threads. Not being a part of the development team can’t tell you status.

Seems to affect 5.0 on Win 10 with some virtual com ports.

You could try a different com splitter (gpsgate, etc.) to see if it does better than comOcom.

In every case it seems 4.8.x works in the exact same installation, so definitely related to how 5 deals with virtual ports.

(All spoken solely on field experience - zero knowledge from development side).

[spirare]

Thanks...also have issues with NMEA0183 sentences not interpreted but OpenCPN... all very frustrating issues that I will report as bugs that I hope will be prioritize as urgent since its the core of its function to interface. Cheers from NZ

[spirare]

Hi Dave, Just registered in the OpenCPN bug report tracking system...however I can't figure out how to report a new bug...any hints ?

[transmitterdan]

Originally Posted by spirare

Thanks...also have issues with NMEA0183 sentences not interpreted but OpenCPN... all very frustrating issues that I will report as bugs that I hope will be prioritize as urgent since its the core of its function to interface. Cheers from NZ

What NMEA sentence is not interpreted by OpenCPN?

[Dockhead]

Originally Posted by fgd3

I believe the ideas in this discussion are already in the manual. Look under "OpenCPN User Manual/TOOLBAR Buttons/Create Route" and read the "Route Concepts" section all the way through the end of "Route Handling Techniques".


Also under "OpenCPN User Manual/TOOLBAR Buttons/Route & Mark Manager" read the section on "Export & Import GPX Files".


Fabbian

I can confirm that it's all there, and that it works flawlessly.

This is an everyday problem for me especially when I'm in the Baltic, where a days run might need a few dozen waypoints, impossible to plan on a normal plotter.

I transfer the routes by thumb drive from ship's computer to the nav system, which is a bit of a faff, but it works. As was advised, to update a route, just delete it from your nav system, and then upload again the revised route from O.

Remind me please why it is that "send to GPS" doesn't work? Ships computer and nav system are connected with Ethernet; I have all the network data and even radar everywhere. You would think it wouldn't be too hard to get a few bytes of data back across that connection. Is it because Navico plotters won't accept incoming data of any kind, or something like that?

[Dockhead]

Originally Posted by Ambler

Any chance of the AIS target COG predictor length (in minutes) getting sychronised with the COG predictor length of own vessel?

It is something I change between offshore and harbour from 1 hour to 15 minutes to achieve relevance of all moving vessels to my own course and speed.

Cheers

I think it's in the spirit of O that you can set them differently if you want. Is it hard to set them both, when you're changing?


And do you really find it useful to have it set on 1 hour? I always keep mine on 10 minutes, onshore and off. If you want to see how a crossing is developing, MUCH more valuable than COG predictor lines is the wonderful "Show CPA" function, which graphically illustrates the crossing whether it's five minutes or two hours away. This is one of the very best features in O.

[Ambler]

Originally Posted by Dockhead

I think it's in the spirit of O that you can set them differently if you want. Is it hard to set them both, when you're changing?


And do you really find it useful to have it set on 1 hour? I always keep mine on 10 minutes, onshore and off. If you want to see how a crossing is developing, MUCH more valuable than COG predictor lines is the wonderful "Show CPA" function, which graphically illustrates the crossing whether it's five minutes or two hours away. This is one of the very best features in O.

No you are right, it's not hard to set the two COG predictors. As I can't imagine what would be the point of leaving them both unequal?

I do like to see 1 hour ship COG predictors when off shore and coastal as it gives me an idea of what is likely to happen over the next hour or so. Ships do tend to do slight course changes well ahead of time which is immediately apparent via the longer predictors. Also especially good when I do a hand over to the next watch - no surprises.

Thanks for your thoughts on the features built in to O in regard to CPA etc. My Vesper Watchmate (screen only) handles all that and I most likely wouldn't buy one again. Though I do like it working tirelessly dedicated to that single task of collision avoidance of AIS targets and its 4 different alarm profiles.

Thanks for thinking it through and responding.

Cheers
Wayne

[spirare]

Originally Posted by transmitterdan

What NMEA sentence is not interpreted by OpenCPN?

I am still experimenting and I will publish my findings in another thread and report the problem to the dev team. What I can say for now is that Old Raymarine SeaTalk1 to NMEA converter box was used to sent NMEA to PC... although all the NMEA sentences where displayed buy OPENCPN NMEA Debug Windows, none except the GPS where interpreted by OPENCPN and displayed through the Dashboard plug-in tool.

[rgleason]

Originally Posted by spirare

I am still experimenting and I will publish my findings in another thread and report the problem to the dev team. What I can say for now is that Old Raymarine SeaTalk1 to NMEA converter box was used to sent NMEA to PC... although all the NMEA sentences where displayed buy OPENCPN NMEA Debug Windows, none except the GPS where interpreted by OPENCPN and displayed through the Dashboard plug-in tool.

Serge,

In my opinion, it is possible, but very unlikely that OpenCPN has such problems, it has been tested and used daily by many. It is more likely that there is some problem specific problem with your configuration or your converter box, and I doubt the development team would be able to help you with this unless there were found to be some specific sentence that has a problem.


Nevertheless, I suggest you start a specific thread of your own, as you said, and explain your hardware setup, and the problem specifically by posting some screenshots and attachments as necessary. Troubleshooting issues like this is a strength in this community.

[transmitterdan]

Originally Posted by spirare

I am still experimenting and I will publish my findings in another thread and report the problem to the dev team. What I can say for now is that Old Raymarine SeaTalk1 to NMEA converter box was used to sent NMEA to PC... although all the NMEA sentences where displayed buy OPENCPN NMEA Debug Windows, none except the GPS where interpreted by OPENCPN and displayed through the Dashboard plug-in tool.

Please learn how to use the VDR plugin. That is how you communicate such problems to others. A VDR file is just text containing NMEA sentences. There is a plugin (voyage data recorder) that can create such files whilst OpenCPN is running.

I am sure dashboard displays all valid messages it knows about.

[skipperearly]

In the dashboard plugin the last received value is shown even when the stream of NMEA has died (e.g. pressure, temperature etc) - it would be nice if e,g, the color changes or the value blinks if no update NMEA has been received for a given period (e,g, 10sec)

Dont know if this behavior is only for the XDR sentences but suspect same for depth of wind data (just cant test right now as am on the dry)

[Hakan]

shipper...
Depth, heading and wind data will have a watchdog in next O release like e.g. GPS. No data shown but "---" instead. (about 10 sec) See shot. (Boat position is always shown but boat icon is gray and compass red.)
XDR temp (air, water) and baro-pressure are not yet foreseen to be watched in the same manner. Probably no big problem to add more if it's important. Other opinions?
Håkan

[bcn]

Håkan,


what about a red dot ("led") with the latest data received in all single data rows - lat/lon as well - after time-out?
Time-out of 10s(?)..


Hubert