0 - OpenCPN - Feature Requests

This is the project for all Feature Requests except the ones concerning plugins. Please add this Feature Requests to the respective plugin project - thanks.
Tasklist

FS#356 - NMEA Autopilot using only one com port to send data to and receive data from OpenCpn

Attached to Project: 0 - OpenCPN - Feature Requests
Opened by claude (on3chd) - Thursday, 24 February 2011, 15:39 GMT-7
Last edited by Serge Davenel (AISEAG) - Sunday, 08 December 2013, 02:58 GMT-7
Task Type Feature Request
Category Backend / Core
Status Closed
Assigned To Dave (bdbcat)
Operating System All
Severity High
Priority Normal
Reported Version future version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

When assigning
- one port com (identical number running at 38400 bds)
- to the 3 different port com to be used by the 3 different talkers / listeners (i.e. gps,pilot, ais)
- and when activating one route
- MUX does not receive back ( checked via Hyperterminal)on the same port com any info that have to be output to drive the autopilot.
This task depends upon

Closed by  Serge Davenel (AISEAG)
Sunday, 08 December 2013, 02:58 GMT-7
Reason for closing:  Won't implement
Additional comments about closing:  Hi;
Sorry but as I don't use open cpn anymore was in trash.
You can delete my request.
Thanks.
BR.
Claude Dulait
Comment by topi kanerva (topi) - Friday, 18 March 2011, 09:01 GMT-7
Please have a look at your opencpn.log ... it should have a line saying
"
Autopilot output device open failed: COM1
"

In my case, COM1 is used both as the autopilot output port and as the input port for AIS and GPS data. (behind it, is a ShipModul multiplexer which gathers all NMEA data sources and brings them over to the computer via the USB virtual serial port.

Since COM1 is already used for the AIS data port, it seems Windows is unable to open that same port for writing.

Also, baud rate restrictions (like 38400 for AIS or 4800 for Autopilot) are senseless, because the multiplexer uses any baud rate on the virtual serial side of the box, and the bauds that are set in its setup for the outgoing RS422 ports (like 4800 to the autopilot).

This means that the configurations for the serial ports need a revamp.

I am suggesting that a similar option to be added to the choice of Autopilot Output Port as there is in NMEA Input Port, namely "AIS (Shared)". Then, data should be sent to that port at the same baud rate as the port is configured in.

Comment by topi kanerva (topi) - Friday, 18 March 2011, 09:16 GMT-7
I forgot to comment why people possibly aren't seeing this problem:

In windows, it seems you can't open the same serial device twice (i.e. with two different handles) even though one of the would read, and one of them would write.

In Linux and OSX, the unix way applies, if you open the serial port as nonblocking, then nothing prevents opening it twice (with two different file descriptors) and using the other to read, and the other to write data.

Hence, to support using NMEA multiplexers (where you most likely want to have the same COM port for both NMEA input and Autopilot out, and also mirror the incoming GPS sentences over to the Autopilot port), it would make most sense to allow for port sharing for the autopilot as well as AIS/NMEA.

Comment by Patrick Guélat (patg) - Wednesday, 30 March 2011, 23:32 GMT-7
Another approach might be to implement a software nmea MUX directly into OpenCPN,
using a switch matrix to specify which message-types should be replicated to which
port. While there are generic virtual com-solutions like VSPE for windows,
linux and mac lacks such tools. Another drawback is that these tools are not
NMEA-aware, they either replicate nothing or all data received on a port.

During the last weeks I helped to upgrade an old amel maramu ketch of a friend, we installed
new navman instruments with log, depth sounder & wind. These instruments all have a seperate
NEMA out, as has the AIS and the GPS. We installed an industrial PC with 7(!) com-ports.

The multi-display instrument of NavMan also accepts additional NMEA data to the data
received through the navman-network. The radar also would also like to receive some data.
One approach is to install a hardware-nmea multiplexer, but the 'cheap' and quite elegant
solution would be to use OpenCPN for this task.

Such a nmea message-switching matrix would probably cover all needs, like connecting
OpenCPN to a hw-mux to receive all data on one port and sending out autopilot on the same
or on the contrary having a bunch of com ports with individual sources and sending out
filtered and replicated nmea data for radar, autopilot, multipurpose instruments on certain ports.

I guess this stretches the initial feature request quite a bit, maybe it's better to open
a new request for this. Comments ?

Loading...