I think the opencpn
does not add the CRLF at the NMEA
sentences to be sent or output to an autopilot
I have installed opencpn
version 4.8.4 Build 2018-04-21 and do run it on a windows 10 tablet. Use oesens charts
, a NMEA
multiplexer on COM4 (4800), a Garmin GPS
receiver and a Nasa clipper GPS repeater. To say it upfront, the connection between the GPS and ist repeater works perfect, until opencpn comes into the play.
My aim was to supply an existing GPS repeater (NASA clipper) in the cockpit
with bearing, tracking, SOG, distance to waypoint. The old GPS shall be replaced, because it’s to slow and oftens shuts down during sailing. So i was eager to test opencpn out. It works nearly perfect, got all the inputs from AIS
, GPS mouse, GPS from Garmin
instrument running. Only the sending of NMEA sentences to my GPS repeater does not work
The repeater receives the NMEA signals. The first signals sent with the repeater in the settings Position shows correct position received from the external GPS (Garmin GPS 158i) – then the disaster starts. The display shows in the following a crumble of letters and switches on and off all signs. First i thought it was caused by a wrong baudrate and tried out several ones ranging from 1200 to 9600 - with no difference.
I plugged the repeater (NMEA in @ 4800) diectly into the GPS and the world was fine again. Everything displayed correctly.
Then again through opencpn and now I analysed the data stream between the GPS through opencpn to the repeater by watching the NMEA debugger
The sentences received nearly comply with the sentence sent– with only one however important exception:
the sentences received (black from COM4: NMEA Multiplexer) finish with CRLF <0x0D><0x0A>
The sentences sent (blue to COM4
lack that CRLF <0x0D><0x0A>. I can’t see them in the debugger and the lack would explain the odd behaviour of the GPS repeater. For the GPS repeater the sentence is NOT finished, so it displays also the following letters. In the example in the picture 1 (please see attachment) it starts wit $GPRMB and it does not stop with the checksum but continues then with the next line $GPGGA and then GPGSA.
Also in the documentation
all screenshots with NMEA sentences been sent for example to an autopilot
, they lack the CRLF at the end. Although i have read in the documentation
that opencpn would process the CRLF, i suspect that exactly not happening.
One thread in the forum mentioned the GSA command, what opencpn itself does not provide. But in my case that GSA was provided by the Garmin GPS and then sent to the output, as shown in the pic 1 in the 3rd blue line.
For me all the observations make only sense, if the CRLF are not added to the NMEA sentence sent from opencpn.
I have checked the opencpn documentation and found in none of the screenshos for NMEA sentences sent (connection to Autopilot) the CRLF at the end of the sentence. (example in picture 2 in the ttachment here chapter „connections“: black – received with CRLF, blue without
Maybe the AP understand the sentences better than the GPS repeater, but the lack of the CRLF explains the odd behavior of the display of the GPS repeater.
I checked also the ini file an found nothing about CRLF at the NMEA sentences. Or is there anywhere a flag which says if o if not a CRLF <0x0D><0x0A> shall be added ?
Or is there a bug forgetting the CRLF at the sentences sent ?