RMC messages lost in NMEA stream

[maohls]

Hi.

I have a USB GPS device - a NaviLock nl-8002u - which I have set to receive GPS, Glonass and Galileo satellites.

When I look in the NMEA stream there are no RMC meassages in OCPN 5 (see attached dump).

But when I look in a simple NMEA moitor program, as well as in the device manufacturer's setup program there are RMC strings present (see the other dump).

I find this a bit interesting...or maybe it's just some setup error on my behalf.
I get a valid position from the other NMEA sentences that are read, though...

B.R.
Magnsu Ohlsson

[bcn]

115200 at baud rate?

[maohls]

Yes, 115.20 kBaud. Set in COM port properties and both programs.
I have tried other baud rates with the same result...
It's a fast device...
/Magnus

[bcn]

What happens if you ignore the checksum?

[maohls]

Will try that a bit later tonight...
/Magnus

[maohls]

Originally Posted by bcn

What happens if you ignore the checksum?

So, now I have tried unticking the cheksum.
Disappointing result though.
Some sporadic RMC sentences get through, as opposed to the stream in the NMEA monitor program where RMC sentences are spouted out three times every second, with checksum enabled.
(Makes sense - the GPS is set up for 3 Hz update rate)

/Magnus

[Moo]

Originally Posted by maohls

So, now I have tried unticking the cheksum.
Disappointing result though.
Some sporadic RMC sentences get through, as opposed to the stream in the NMEA monitor program where RMC sentences are spouted out three times every second, with checksum enabled.
(Makes sense - the GPS is set up for 3 Hz update rate)

/Magnus

Have you tried a more sane update rate of say 1 per second?

You don't need positional updates faster than that except for very special purposes. Heading information at high speed is useful of course but that would come in a different sentance.

[maohls]

Originally Posted by Moo

Have you tried a more sane update rate of say 1 per second?

You don't need positional updates faster than that except for very special purposes. Heading information at high speed is useful of course but that would come in a different sentance.

Hi.
Sorry!
Lowering the rate to 1 Hz and setting the port to 38.4 kBaud - no difference.
OCPN still doesn't receive the RMC sentences whereas the NMEA monitor program does...
/Magnus

PS. The reason I bought this device was not for the possibility of high update rate, but for being able to receive Galileo as well as GPS and Glonass DS.

[bcn]

On which Operating System are you?
Can your use a simple terminal program to hook to the serial port to get an input stream?

[maohls]

Originally Posted by bcn

On which Operating System are you?
Can your use a simple terminal program to hook to the serial port to get an input stream?

This is a Win10 laptop. I have used two separate NMEA terminal programs and they both show RMC sentences (see dumps in previous posts)...
/Magnus

[bcn]

Looking again on your NMEA debug window from OCPN

- why are there broken entries?
- and why are there garbled RMC messages - better: messages preceded by garbage?

And if you try with 4800 or 9600baud?
The Navilock devices are usually pretty well behaving. Have one running here.

[maohls]

Originally Posted by bcn

Looking again on your NMEA debug window from OCPN

- why are there broken entries?
- and why are there garbled RMC messages - better: messages preceded by garbage?

And if you try with 4800 or 9600baud?
The Navilock devices are usually pretty well behaving. Have one running here.

Yes, I noted those few corrupted RMC messages as well as other more obvious erroneous sentences such as "<0x0F>#" on several occurancies.

Backing down to 4800 Baud, 1 Hz didn't change the picture - still no RMC sentences in OCPN. The position is extracted through GGA, GLL and GNS which are received correctly.

Found a clue though!
The attached dump shows the stream, and EVERY RMC line is preceeded by some propriety UBX binary sentence.
Maybe this could cause problems for OPENCPN.
Will try to get rid of that...
/Magnus

[nohal]

May you record a bit of that data stream and post here?
We should sure handle crap like that better...

[maohls]

Thanks for looking into this - really great!
Here's a small recorded stream - as you see some crap in front of every RMC sentence...

/Magnus

PS. Remove the .doc extension. It's a zip-file, but that seemed to be an invalid file extension DS.

[Andreas29]

Hi,

I got something similar to this.

I use the nmea connection to send route Information to the Autopilot.
For that I set the filter for outgoing Messages to RMB and RMC sentences.
This worked great under OC 4.8.8

Now with OC 5.0 I got irregular wrong COG/SOG informations sometimes the right, sometimes totally wrong, sometimes only ------/-------.
Only when started a route (navigate to in the right click menue).
After I investigate the nmea data stream I found out that there was sentences where ALL the NMEA-sentences from my Network where combined and ther always started with the RMC-sentence from OC for the Autopilot.
After changing the filter for the outgoing sentence so that only the rmb sentence was send this was fixed and the Autopilot gets the route information too (rmb is enough for the pilot, the manual says he need rmc).

Regards

Andreas