opencpn 4.2 will not see nmea sentences

[3cp]

Hi
I have bought a ShipModul 3wi miniplex and i want to connect my Garmin 620 gps/plotter to opencpn via the miniplex
Thing is, that it seems like opencpn won't konw the sentences, at least it don't position the boat on the position and it reacts as if it gets no position data at all.
Anybody out there had the same experience / found a solution.
A screen dump of how the sentences look are attached.

[rgleason]

We can't see the nmea sentences either! Your screenshot needs to be clipped.

Or even better, use VDR_pi to record the data stream and save it to a file. Then rename it to xxx.doc and attach to your forum post.

We are looking for any position sentences. You can do that too. I suspect the Garmin is not sending GPS possibly?

[3cp]

Sorry! but the picture show the nmea debug window from opencpn. It shows among others, a line with a GPGLL sentence that, i think, is a position.
It is the correct position, that in the sentence. But it seems like opencpn ignores it.

[CarCode]

Yes, your screenshot of the NMEA debug window shows valid GPS values.
However what is irritating for me are the chars "\s:MX75-1*42\" in front of each NMEA sentence without a space before the sentence starting with $GP...

I don't know where these supplement chars come from.

Gerhard

[3cp]

I think these characters are added by the miniplexer.

[CarCode]

Originally Posted by 3cp

I think these characters are added by the miniplexer.

That is possible.
But normally the Debug Window looks like this attachment.
After the time stamp is the information about the device in brackets, then a space and then the NMEA sentence ($GP...).
It may be that OpenCPN has problems to recognize your different input.
The Miniplex has a configuration tool. Perhaps you have a chance to alter something there.

Gerhard

[3cp]

Thanks! Carcode. Now i have something to compare to. I will try the config tool, to see if i can remove the bad parts.

[CarCode]

Originally Posted by 3cp

Thanks! Carcode. Now i have something to compare to. I will try the config tool, to see if i can remove the bad parts.

Another idea:
Can you try the WiFi output of the Miniplex instead of the USB connection?
Times ago I have installed the Miniplex for a harbour neighbor and it has worked very fine for his Windows computers, his Apple Mac and iPad; all using WiFi.

Gerhard

[3cp]

Sure i will and thanks again.
I still wonder, acording to the color of the lines (gray) the sentences should have been accepted by opencpn. Otherwise they should have had one of the other colors.

[did-g]

Originally Posted by 3cp

I think these characters are added by the miniplexer.

Hi
They are NMEA v4.0 tags, seeing them in the debug window should be ok as there's code in OCPN for removing them, too bad it doesn't work in all cases : it's broken at least for gps data over serial link...

Remove them in the miniplexer or use a network link

[3cp]

Is it something the miniplexer or the Garmin is doing?

[CarCode]

Originally Posted by did-g

Hi
They are NMEA v4.0 tags, seeing them in the debug window should be ok as there's code in OCPN for removing them, too bad it doesn't work in all cases : it's broken at least for gps data over serial link...

Remove them in the miniplexer or use a network link

I haven't found in NMEA ver 4.0 or latest version 4.1 any hint where the starting tag of a NMEA0183 sentence was changed from "$" to "\sMX75-1*42\$". Please enlighten me.

Gerhard

[nohal]

Gerhard...

The "\...*xx\" part of the sentence is NOT part of "starting tag". It is called a TAG block
If you need more enlightenment, read your documentation for NMEA v4 again or have a look for example at http://www.nmea.org/Assets/may%2009%...00183_v400.pdf (From Slide 15 onwards, Slide 22 of probably biggest interest for you)

Pavel

[muttnik]

Sorry to jump in without having looked hard at the problem. TAG blocks broke the code of everyone who had implicitly assumed that newlines would divide sentences including OCPN 3.something. I'd thought an update to the parsing (maybe by Pavel?) a couple of years ago fixed that but a quick look at the code suggests that serial data (and Garmin: we're assuming the interface isn't set for Garmin protocol, right?) is parsed using different routines (in OCP_DataStreamInput_Thread.cpp rather than datastream.cpp) to Network data, which is what I've mostly played with and what should handle TAG blocks ok.

In answer to 3cp, the TAG blocks are source identifiers being put out by the miniplex.

Assuming the miniplex input isn't erroneously expecting Garmin data I'm guessing the miniplex might be configurable not to output the source TAG. If not and this is on linux or Mac I can suggest a workaround. Probably someone more windowsy could do the same for Windows but if this *is* an OCPN parsing issue, maybe it's time for datastream parsing to be unified in one place?

[muttnik]

Other commitments have prevented me from looking very closely at this but seems that Dave committed something (commit 07f5438766c9e77a2fafc450ee23a24915e13686, prior to 4.2) in Nov 2015 which should deal with NMEAv4 TAG blocks (in multiplexer.cpp) immediately after a sentence has been passed to the multiplexer from the serial input thread. Yet 3cp's debug window is still showing them. A second pair of backslashes preceding that would account for why the TAG blocks weren't stripped out but I can't think why that would consistently happen. Also I note that the title mentions OCPN 4.2 but the image in the first post seems to be of 4.4