Visit our Popular Forums

transmitterdan · 09-01-2017, 07:27

Quote:

Originally Posted by 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

I did not see any acceleration data in the files. For example NMEA41 shows RMC and VTG messages with no speed greater than 50 knots. Hardly a Maserati.

Where can one find acceleration data in the NMEA format?

bcn · 09-01-2017, 10:23

Quote:

Originally Posted by transmitterdan

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.

Dan,

in Europe Google Earth is generally spot-on a they use geo-referenced ortho-photos from the local administrations. Said generally...

The GPSD repository has some comments about the latest ideas and findings about the talker IDs and PRNs. Gerhard mentioned the main doc page.

The latest change logs with information about this part are here:
https://fossies.org/diffs/gpsd/3.14_...83.c-diff.html
and here
https://fossies.org/diffs/gpsd/3.15_...83.c-diff.html

From this I understand that using PRNs of Galileo are not mapped into different number spaces - different from Glonass.
And that the vendors of GNSS chip sets do not show a stringent use of talker IDs neither.

For a graphical presentation of the received constellation one might use a Prefix (P, L, A, B,..) corresponding to the talker IDs and/or different color for the individual systems.
I admit that fitting 24 or more sats in the graph might be challenging. And limiting the presented elevation in this cases?

Hubert

Ingo_2 · 09-01-2017, 11:32

Hello,

thanks to all for the comments. Unfortunately, I was unable to check the adjustments so far.
But to end the speculation: The data are real and recorded during a drive by car (normal cruise, so don't overestimate the isolated acceleration in one second).

I will experimente with the settings to figure out what changes in talker ID could bring.

Regards,
Ingo

CarCode · 09-01-2017, 12:27

Ingo,

as you have remarked yourself already the configuration of an ublox device can be very difficult. It is even more difficult when you use the multiple GNSS Assistance Services for u-blox GNSS receivers instead of the U-Center software delivered with the device (example attachment). As we even don't know the firmware version of your device I strongly recommend as pointed out already to contact the hotline support of Navilock to help you to get the device back to usable settings.

Gerhard

transmitterdan · 09-01-2017, 14:25

Quote:

Originally Posted by Ingo_2

Hello,

thanks to all for the comments. Unfortunately, I was unable to check the adjustments so far.

But to end the speculation: The data are real and recorded during a drive by car (normal cruise, so don't overestimate the isolated acceleration in one second).

I will experimente with the settings to figure out what changes in talker ID could bring.

Regards,

Ingo

Ingo,

Last night I used both your NMEA data files to step through OpenCPN source code. Both files seem to work ok with OpenCPN. The only issue I noticed was the satellite information was erratic. That is because It jumps between status of GLONASS and GPS talker IDs. OpenCPN displays whichever status message it received most recently. It does not set one as the priority as it probably should.

But this is not a fatal problem and I think your device should work ok with OpenCPN. I am happy to look at any other NMEA recordings you can make if you do make adjustments to the setup. The more of these recordings we get the better can be OpenCPN.

I think it is an easy change to give a user option in the Dashboard setup screen to display satellite status of either GPS, GLONASS or Galileo. We could set default to GPS but then one could manually look at the other constellations by just selecting the desired option in the Dashboard setup screen.

bcn · 09-01-2017, 22:44

Dan,

will you take care and change the logic of OCPN treating multi constellation environments - what will be the standard in the future - or has this go to Flyspray?

Hubert

transmitterdan · 10-01-2017, 10:57

Hubert,

I might have enough software experience to "fix" Dashboard depending on what the community want. But I am not able to decide what the fix should be. If satellite status comes from multiple constellations what should dashboard display?

bcn · 10-01-2017, 11:31

Dan,

the picture:

The software of the GPS receivers showing coverage (the plot of elevation and Azimuth) will bring up all the Sats in view for all constellations.
From the $..GSV sentences.

We should try to get this data displayed. The common approach is either putting some prefix to the Sat(PRN) to indicate the GNSS system or using a different color.

All this gives an idea about the confidence one can have about the fix shown.
Low elevation=bad
From there the idea: if you can't fit all sats in the graph, skip low elevations - that's a zoom from a (sat) bird's view looking at your GPS. Indicating perhaps that it is zoomed..

Coming back to Gerhard's comment about "Sats used": an indicator of the judgement the GPS receiver has about the confidence of the single sats for its solution.
Discarding low level contributors. The receiver does not need to use all sats. Just the optimal ones.

To remember:
For one GNSS system 4 sats are the minimum to get a (3D) fix.
If the receiver works with a multi GNSS configuration it will need one additional sat for each GNSS constellation to resolve the timing synchronization.

1 system/4 parameters to solve: lat, lon, alt, time;
for each additional system one more unknown: +1 for time(syncGNSS)

Hubert

transmitterdan · 11-01-2017, 18:29

Quote:

Originally Posted by Ingo_2

Hello,

thanks to all for the comments. Unfortunately, I was unable to check the adjustments so far.
But to end the speculation: The data are real and recorded during a drive by car (normal cruise, so don't overestimate the isolated acceleration in one second).

I will experimente with the settings to figure out what changes in talker ID could bring.

Regards,
Ingo

Ingo,

I have done some more research. The reason Dashboard doesn't like the "NMEA 4.1" data is not because of the TalkerID. It is because there is an extra number in the GSV records. This is what the NMEA 4.0 file has:

Code:

$GPGSV,4,1,14,02,04,222,15,05,63,240,31,07,45,063,29,08,05,067,08*71
$GPGSV,4,2,14,09,15,103,18,13,40,279,22,15,10,285,16,20,28,307,20*75
$GPGSV,4,3,14,21,09,335,15,27,08,030,26,28,28,147,21,30,77,112,38*71
$GPGSV,4,4,14,33,25,209,,49,29,184,*7B
$GLGSV,3,1,09,69,23,137,,70,82,151,38,71,41,314,,73,33,203,*66
$GLGSV,3,2,09,79,31,039,31,80,79,148,31,86,01,284,,87,15,334,18*67
$GLGSV,3,3,09,88,10,020,20*5D

This is what the NMEA 4.1 file has:

Code:

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

Notice there is an extra 0 before the checksum in the NMEA 4.1 data. This confuses Dashboard but does not confuse OpenCPN itself.

Do you know what this extra 0 is supposed to do?

CarCode · 12-01-2017, 02:17

Quote:

Originally Posted by transmitterdan

Do you know what this extra 0 is supposed to do?

You might want to read the NMEA docs a little bit?
Extract:

Quote:

"Some GPS receivers may emit more than 12 quadruples (more than three GSV sentences), even though NMEA-0813 doesn’t allow this. (The extras might be WAAS satellites, for example.) Receivers may also report quads for satellites they aren’t tracking, in which case the SNR field will be null; we don’t know whether this is formally allowed or not."

Since we don't know if Ingo's device is correct configured nor we know the used firmware version of this device there are only assumptions right now.

Gerhard

bcn · 12-01-2017, 06:02

Quote:

Originally Posted by CarCode

You might want to read the NMEA docs a little bit?
Extract:................................
Gerhard

Gerhard has seen this here:
NMEA Revealed
(NMEA Revealed, Eric S. Raymond, <esr@thyrsus.com>, version 2.21, Jan 2016)

From the notes of GPSD 3.15

Quote:

* In the GLONASS version sat IDs run from 65-96 (NMEA0183 standardizes
* this). At least two GPS, the BU-353 GLONASS and the u-blox NEO-M8N,
* emit a GPGSV set followed by a GLGSV set. We have also seen a
* SiRF-IV variant that emits GPGSV followed by BDGSV. We need to
* combine these.
*
*NMEA 4.1 adds a signal-ID field just before the checksum. First
* seen in May 2015 on a u-blox M8,

Source:
https://fossies.org/diffs/gpsd/3.14_...83.c-diff.html

The Navilock NL-80x2U uses the u-blox M8 chip set

transmitterdan · 12-01-2017, 06:32

Quote:

Originally Posted by CarCode

You might want to read the NMEA docs a little bit?
Extract:

Since we don't know if Ingo's device is correct configured nor we know the used firmware version of this device there are only assumptions right now.

Gerhard

Of course I read the NMEA "docs" that are online which are not the real docs. But it seems you have missed the issue I am asking about. There is just one extra 0 in each record. It is not an extra quadruple. It is just an extra field in each sentence. It is easy to fix Dashboard to ignore this extra field. I just wonder why it is there. It may very well be a software bug in the device. I could not find anything in "NMEA Revealed" that explained the extra zero.

transmitterdan · 12-01-2017, 06:34

Hubert,

Ok, that explains the extra zero. I can fix Dashboard to ignore this extra zero for now.

Thanks for digging this up.

transmitterdan · 15-01-2017, 07:01

Ingo,

The latest development version of OpenCPN in git now permits the NMEA 4.1 messages to reach the satellite status instrument. So this fix should be in that next release version.