Making a TCP/IP Connection

[Glen96]

Hi all,

I like the design philosophy of OpenCPN Connections and I am trying to create a robust TCP or UDP connection, but without success.

My box is a Win 7 32 bit machine and OpenCPN is version 3.3.2118. My c/c++ programming experience is very low and I do not understand the fundamentals of TCP, but I can try to learn.

Is there a DLL or some other code appropriate for the task that can be used or modified to connect the elements together. I am aware of Win7 WinSock.dll but that is far to complex for me to master in the time I have left. I would prefer not to use Serial connections for all the services if I can avoid it.

Thanks for your interest and help with this issue.
Look forward to your comments.

Cheers
Glen.

[rooiedirk]

Glen,
No need for an extra dll or programming. I think it is pretty explained in the help file. If it doesn't work check the firewall settings of windows.

How do you get the data into your network???

[Glen96]

Hi Rooiedirk,

Thank you for your reply.

The help files and UI are very well done and I have no problem understanding, working with or entering the Connections dialog data in OpenCPN.

If I am to connect to OpenCPN with TCP then I need some software on my side to make the connection and send and/or receive the relevant data sentences. Sorry if that was not clear in my original post.

The answer to “How do you get the data into your network???” is a long story.
In 2000 I look my yacht out of charter service to visit the Kimberly Region in the NW of Australia, 300 nm of pristine coastal wilderness. I fitted davits and an intergrated nav system with autopilot, electronic charts and other bits for single handed operations assisted by my dog Nick. Departed Airlie Beach heading north inside the Great Barrier Reef.

The nav system worked very well but with 2 shortfalls.
1. The tracking algorithm was very slack.
2. Waypoint transit did not exist.
Sailing in reef waters requires a degree of care and precision, so by the time I got to Darwin I was ready to fix the problems. As luck would have it a fellow sailor from USA was very good with electronics and he designed and built hardware to interface with Seatalk via a serial connection and so all the bus traffic was available on the PC. I do not know how the electronics did it but a two way interface worked very well.

I set about writing the software. Because of my flying career (and training in astro nav) it was a natural to base the AP and Wp transit on methods used in aircraft navigation and equipment.

The AP read the GPS and calculate a heading correction and issued a “steer heading xxx” command. In a general sense the closure heading correction asymptoted to 0 along the curve of an ellipse, a gain factor provided sensitivity. The set or current flow was calculated as well (plus other things). The Kimberly area have 10 m tides and strong currents in the reef areas.

The Wp transit became part of the AP responsibilities. The solution was to divided the problem into 4 phases.
1. Approach: Calculate an accurate DR turn time as a function of all data available GS, rate of turn , set etc.
2. Transit: At turn time simply turn to the next outbound heading.
3. Departure: Establish outbound tracking using a responsive gain factor.
4. Cruise: Maintain track using a lesser gain factor.

Having enjoyed the Kimberly's I completed the circumnavigation and returned to Airlie Beach. Now that I was at home I wrote a simulator to drive the motion for further software RAD.

Eventually I decided it was time for a tree change so I gave the Seatalk hardware away to a passing cruiser who wanted to install a similar system on his yacht and sold my boat and moved to a lifestyle farm in Under Down Under (Tasmania).

Time has moved on and I am ready to go back to boating, but I am land bound.

I have pulled the original nav system software out of the archive and now want to connect the Simulator version to OpenCPN. Why? to do more RAD.

To do that I need to write TCP/IP network interface. The WinSock.dll is the software to master to achieve the TCP, but that is far to complex for me to master in the time I have left (am 73).

This is a common need for members wishing to connect TCP but lack the c/c++ programming skill and TCP experience.

Cheers
Glen

PS. 95% of my programing is done with Delphi .
PPS. If your coming to the Kimberly’s fit davits. Crocs think the dingy is baby boat and eat it. A croc also sank a float plane when getting amorous with one of the aircraft floats.

[muttnik]

If your program was designed to read/write a serial line you can probably avoid any network programming by using a COM port redirector. If you intend to run your program on the same machine as OpenCPN you can probably avoid the network completely and have the two communicate via a virtual COM port. OpenCPN acts as a data multiplexer so you can attach your "real" boat data serial line to OpenCPN and have it write to/read from your program. Whilst I could give recommendations for Linux/MacOS, I sadly have little experience with Windows but hopefully someone else can chip in here.

I'n not clear though on whether your program reads/writes seatalk or NMEA-0183. If your mate was connecting you to the seatalk bus via a NMEA-0183 to seatalk converter you're fine. If what was installed as a straight connection to the seatalk bus and you're dealing in seatalk you may have some conversion to add to your program. Although I've seen some work on seatalk in OpenCPN I don't believe it's complete.

I don't do Delphi but a quick search suggests that you can use it for network programming. High level languages tend to hide a lot of the gubbins of networking from the programmer so it might be a lot less intimidating than you think

[rgleason]

Glen do you think your program might be the basis for an opencpn autopilot plugin?

Sent from my SCH-I545 using Cruisers Sailing Forum mobile app

[Glen96]

Hi muttnik,

The year 2000 equipment is long gone and my thoughts are to the future.

Serial ports were the technology of the day, but I think TCP/IP is the way of the future, Ethernet and LAN are now in common household use. The OpenCPN crew are to be congratulated for providing the TCP connection. The freedom to network with virtually unlimited port connections is very attractive when thinking of applications that have not been thought of as yet.

On my side of that system I worked in NMEA and read/wrote to Seatalk in translated “giberish” via serial ports. Only a few translations were required to complete the task. The Raymarine AP (helm) was put in Heading Mode (Auto) and then Turn Commands were issued to control the navigation. It was a very simple interface. Refer to Thomas Knauf Â*Â*Â*Â*SeaTalk Technical Reference as a reference. A code snippet of the “giberish” translations follows:

const
   PORT_NM   = 'RST Data i/o';
   LOG_NM    = 'Log RST.txt';
   ECHO_ERRS = true;
   CMD_MINUS_10  = '862106F9';
   CMD_MINUS_1    = '862105FA';
   CMD_PLUS_1      = '862107F8';
   CMD_PLUS_10    = '862108F7';
   STANDBY_KEY    = '862102FD';
   AUTO_KEY         = '862101FE';
   TRACK_KEY        = '862103FC';
   WIND_KEY         = '862123DC';
 type
   TDecodeProc = function(var CmdNm, Res: string; HexCmd: string): boolean  of object;

Delphi is a clean powerful OOP language with many “Component” objects available, TUdpSocket, TTcpServer and TTcpClient are of the TCP flavor. I wrote some simplistic applications to make the connections with OpenCPN, some worked and others would not connect. I will persist and try to achieve a stable and consistent set of socket interfaces with OpenCPN.

I cannot help but feel some one has already done this!!
I hate reinventing the wheel.

The objective at this time is to simulate the GPS, Compass and AP.
I am land bound at the moment, the real nav world can come later.

Cheers
Glen

[Glen96]

Hi rgleason,
Thanks for your interest.

No this software will not be release as a AP for OpenCPN. For that to happen the express approval of the principal members of the OpenCPN project is required. An AP is a serious application with potential to create serious and or fatal damage if it should miss behave at an inappropriate time. At the very least rigorous testing would be required to mitigate liability.

The simulator connection to OpenCPN will provide a workshop development platform to pursue RAD concepts of which AP may be one of them. Even that may not be condoned by the principals of OpenCPN.

Sorry to disappoint at this time.

Cheers
Glen

[Glen96]

Hi All,

A very basic TCP/IP interface has been achieved using Indy TIdTCPServer and bench development and testing of the Autopilot has started.

The TCP/IP interface still needs to be developed to be as robust as possible. This is not my area of knowledge or experience and is probably best left to those that know. I will stay with the Navigation and Autopilot areas.

A dialog with the OpenCPN developers is now required. I will start a new “Autopilot Development” thread for this topic.

Thanks
Glen