Feature Requests

[Ingo_2]

Originally Posted by bcn

Just change the extension to .doc

And as this is one of your first posts it can take a time for a moderator to enable your upload.

Hubert

Good idea. Thanks.

Here are the original VDR just renamed to .doc

[transmitterdan]

You can also zip the vdr file and rename it .doc. That allows to upload large vdr files because they compress a lot.

[CarCode]

Originally Posted by Ingo_2

Good idea. Thanks.

Here are the original VDR just renamed to .doc

Ingo,

just regard your files, thank you.
What is the difference for you of the 2 files? There is no NMEA40 or NMEA41 setting anywhere, not in OpenCPN nor in the configs for your Navilock device.
Regarding your files it seems however you have severe problems with the Navilock configuration. With your actual Navilock settings you do only receive the GSV sentence of Glonass and Galileo which is only data about satellites in view (elevation, azimuth and number) but no lat/lon data to get a fix. Lat/Lon you only receive as a combination of Glonass and GPS-US (lines with talkerID $GN...). OpenCPN can't use that, it needs talkerID $GP...
Try to correct your Navilock settings to get the needed sentences GGA, GSA, RMC, VTG and GSV for talkerID $GP which is even faster than a multiple GNSS. If you have problems to configure your Navilock and don't understand the provided manual of the device you should consult the support from Navilock Home
Depending the country where you live they have a hotline in your language.

Gerhard

[Ingo_2]

Originally Posted by CarCode

Ingo,

just regard your files, thank you.
What is the difference for you of the 2 files? There is no NMEA40 or NMEA41 setting anywhere, not in OpenCPN nor in the configs for your Navilock device.
Regarding your files it seems however you have severe problems with the Navilock configuration. With your actual Navilock settings you do only receive the GSV sentence of Glonass and Galileo which is only data about satellites in view (elevation, azimuth and number) but no lat/lon data to get a fix. Lat/Lon you only receive as a combination of Glonass and GPS-US (lines with talkerID $GN...). OpenCPN can't use that, it needs talkerID $GP...
Try to correct your Navilock settings to get the needed sentences GGA, GSA, RMC, VTG and GSV for talkerID $GP which is even faster than a multiple GNSS. If you have problems to configure your Navilock and don't understand the provided manual of the device you should consult the support from Navilock Home
Depending the country where you live they have a hotline in your language.

Gerhard

Hallo Gerhard,

the navilock device can be configured using the original U-Center-Software of UBlox (very powerful tool).
Under the topic NMEA several settings can be made e.g. the version. Only with 4.1 Gallileo will be used. It is quite easy to check this in U Center (see the picture in my former posting. Gallileo will disappear with version 4.0).
To be clear: The fix is transferred to OPENCPN and in use. It is absolutely correct. There is no mismatch or deviation. And this is independent of the version of the protocol. Just the data about the accuray are not understood by OPENCPN in case of version 4.1. So, to check the signal I have to close OPENCPN and to use U-Center. This is not pratical while navigating. That's the reason while I am mentioning this here.
I have the possibility to make some changes around the talker ID and will try this within the next week. However, I think this is not the point as the fix is communicated and understood by OPENCPN.
Let you know the outcome.

Regards,
Ingo

[CarCode]

Ingo,

please check the VDR files you have send for yourself. They have very little to do with OpenCPN itself but simply stores the data received by your computer via the serial or virtual serial (USB) port from your GPS device. Instead of the VDR tool you can use also any other software which is able to store serial data. Fortunately these NMEA data are human readable for anybody because they are in plain ASCII.
If your Navilock device doesn't send the correct data then no software even not OpenCPN is able to process them. So I strongly recommend to configure your Navilock first.

Gerhard

[bcn]

Ingo,

consider that the NMEA standards are closed ones: you have to license them and this includes an non-disclosure agreement. Not usable for open software therefore.

So the only way is to reverse engineer the "standard"
If you have additional information about the NMEA 4.0 or 4.1 please post it.

From your data stream:

It uses heavily the $ID, the talker ID.
$GN... is applied for the general GNSS sentences as RMC, GLA or ZDA etc.

The GSV sentences for PRNs or satellites are showing talker IDs or prefixes depending on the individual GNSS system.
$GP for GPS (US)
$GA for Galileo (EU)
$GL for GLONASS (RU)

Here a snippet from the Trimble website:

Message ID $--GNS 
Talker ID can be: 
GP: To provide information specific to the GPS constellation when more than one constellation is used for the differential position fix 
GL: To provide information specific to the GLONASS constellation when more than one constellation is used for the differential position fix 
GN: GNSS position fix from more than one constellation (eg. GPS + GLONASS)

Hubert

[CarCode]

Hubert,

Trimble is correct, you are not: The $GN talkerID is for GPS and Glonass (multi GNSS).
To have reverse engineered infos see here:
NMEA Revealed
It includes version 4.1 which is more than 4 years old now.

Gerhard

[transmitterdan]

Originally Posted by Ingo_2

Hello,

since a few weeks Gallileo is working more or less. It seems that this comes together with a new release of NMEA 4.1. (see Ublox-Homepage)
In OPENCPN NMEA4.0 is working very well. With 4.1 a combined fix (GPS-US, Glonass and Gallileo) can be transferred. However, all data about accuracy (HDOP, number of satellites) are missing or incorrect (still included in NMEA-communication but in other sentences)
It seems that with the update to NMEA 4.1 a view communication sentences have been outsorted (see also NMEA Homepage)

Is it planned to update OPENCPN to NMEA 4.1? I would be really glad because the quality of the fix is really improved with Gallileo supporting e.g. anchor watch (I guess it can stay in a circle of 5 m radius according to my first tests)).

Bye,
Ingo

Ingo,

The latest version of OpenCPN in Github understands the GLONASS sentence in your NMEA41 VDR file. However, the Galileo sentences are not decoded by OpenCPN. The Galileo sentence sent by your device seem to be in error. These sentences are reusing satellite PRN numbers from the GPS constellation. GPS uses PRN numbers up to 32. GLONASS uses 65-96 which your device is properly sending.

$GPGSV,4,1,15,02,20,233,29,05,59,281,37,06,01,200,,07,62,075,39,0*65
$GPGSV,4,2,15,09,32,093,36,13,23,270,36,16,06,020,,20,12,313,21,0*63
$GPGSV,4,3,15,21,00,347,,27,02,046,08,28,09,155,37,30,67,179,41,0*66
$GPGSV,4,4,15,33,25,209,31,36,25,152,34,49,29,184,35,0*51
$GLGSV,3,1,09,69,44,123,,70,73,319,,71,21,309,28,73,11,197,34,0*7C
$GLGSV,3,2,09,78,14,031,,79,52,048,,80,55,177,,86,15,299,,0*7D
$GLGSV,3,3,09,87,15,355,14,0*4D
$GAGSV,2,1,05,02,01,199,,08,15,296,20,09,06,119,,24,56,083,34,0*7C
$GAGSV,2,2,05,26,04,359,,0*4E

You can see in the last two sentences from Galileo the PRN numbers 02, 08, 09, 24, and 26 are used which are the GPS assigned values. I do not know what PRN values were assigned to Galileo. In any event OpenCPN ignores these sentences.

In the github version of OpenCPN it displays first the constellation status from GPS, then from GLONASS, then GPS, then GLONASS and so on. On some systems OpenCPN may not show either the GLONASS or GPS status because one is constantly being replaced by the other messages. I can see the alternating status by playing the VDR file very slowly.

[CarCode]

I strongly recommend to read the reverse engineered NMEA documentation:
NMEA Revealed
It is also usefull to read the OpenCPN source code if possible. OpenCPN uses the GSV sentence only if available for its Sat watchdog and the compass window usually in the right upper corner of the screen. Any other data of GSV are used by the Dashboard plugin but not all the GGA data which might be usefull to know how many Sats are really used only (see Dashboard attached).

When replaying these VDR files however one can see also high speeds over ground (SOG about 50 knots) which is also a sign of bad data.

So without doubt this GPS receiver is badly configured and should only be used when correct configured.

OpenCPN might have some weak points but its GPS data visualisation is correct.

Gerhard

[transmitterdan]

Gerhard,

The data was obviously recorded on land. Probably driving around in an automobile. That's why the speed is so high. I think the data is valid.

If the different satellite constellations are going to report their status using different Talker ID's then Dashboard will have to change considerably I think.

[CarCode]

Originally Posted by transmitterdan

Gerhard,

The data was obviously recorded on land. Probably driving around in an automobile. That's why the speed is so high. I think the data is valid.

If the different satellite constellations are going to report their status using different Talker ID's then Dashboard will have to change considerably I think.

What about first checking and then publish your conclusions?
Assumptions doesn't help...

Gerhard

[transmitterdan]

Originally Posted by CarCode

What about first checking and then publish your conclusions?
Assumptions doesn't help...

Gerhard

I did check my conclusions. The attached .kml files were made by OpenCPN after creating a track from the NMEA files. They look like roads that autos would drive on. The speeds are not ridiculous for such roads.

How in the world did you get to be such a curmudgeon?

[bcn]

Dan,

The second one is interesting for running at a track with quite a lot of trees (without leafs I would suppose due to the season) being stable with an offset of about 5m to West. An environment that invites for spikes easily.

About your second question:
Håkan did come to the conclusion sometime ago that the observed issue is the fall-out of the coffee brand G. is using for breakfast.
He has to admit though that his theory has not been contrasted in the field.

Hubert

[CarCode]

Hopefully Ingo will tell us soon which kind of car he has used.
I once owned a Maserati which was not capable to accelerate from 0 to 100 km/h within a second...

Gerhard

[transmitterdan]

Originally Posted by bcn

Dan,

The second one is interesting for running at a track with quite a lot of trees (without leafs I would suppose due to the season) being stable with an offset of about 5m to West. An environment that invites for spikes easily.

Hubert,

I cannot be sure if the GNSS unit is off by 5m or if Google Earth is off. Anyway, I am confident the NMEA data was produced by a real receiver and not just "made up".

So does anyone have any idea how OpenCPN Dashboard should represent satellites from different constellations? Right now it just displays data from whichever satellite view message was received most recently (but ignores Galileo birds). That seems like a recipe for confusion. And the widget doesn't really have room to display 20+ satellites anyway.

It may not be obvious but the reason it is a closed loop is because OpenCPN does than when playing the VDR file again. The actual data is just a simple track without the loop back.