gpsd-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-users] Communicating NMEA to gpsd as if my software was a GPS


From: Ellon Paiva
Subject: Re: [gpsd-users] Communicating NMEA to gpsd as if my software was a GPS device
Date: Fri, 6 Sep 2019 14:56:26 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0

Yo again Gary!

On 9/5/19 7:48 PM, Gary E. Miller wrote:
On re-reading the NMEA 0138 doc, I see I made a mistake.  The spec
allows as many digits as you want.  But it still looks like way more
digits than possible given GNSS accuracy.

Indeed, it seems to be too much. I'll adapt it for the accuracy I need. Thanks!

Field 10, HDOP.  Missing.  
This was in purpose, as I am not really simulating localization from 
satellites.
And yet you include accuracy estimates which are derived from the DOPs,
which are derived from the skyview.

My accuracy estimates come a covariance matrix from which I extract the error ellipsoid and standard deviations used to fill the fields of a GST sentence. I know that these fields are supposed to have information derived from skyview, but I think skyview doesn't apply here.

I think I could find a way to derive HDOP from the same covariance matrix... but first I need to understand better the HDOP concept on GNSS.

Should I put a value, like one of this table here ? 
A good rule of NMEA, if you don't know the value, leave the field blank.

OK, thanks for the tip.

Field 11, altitude: 0
Missing decimal point.  
Thanks!
And on re-reading the spec, I see it is not required to have the decimal
point, just not normal.

OK!

At the end I'm not sure these would disturb gpsd.
I found some of these by looking at the gpsd output.  Some, like the
228 E latitude clearly confused gpsd.  Others, like the variable, or
missing, decimal points, are handled by gpsd.

By the way, I tried to understand the "226 degrees east" problem, and in fact I realized it's not a problem! In the sentence you mentioned
$GPGGA,103642.879013,4850.432180742773,N,226.381659556439,E,7,08,,0,M,0,M,,*73
the lon/lat are expressed in "Degrees Decimal Minutes" as I understood that's the way they should be described. So longitude "226.381659556439,E" in fact means "2 degrees and 26.381659556439 minutes east". The same thing with the latitude: "4850.432180742773,N" means "48 degrees and 50.432180742773 minutes north".

So, considering that this was in fact correct (ignoring the large number of decimal digits), than what could confuse gpsd in these sentences?

And gpsd is not the gold standard, you likely want your psuedo NMEA to
work for most NMEA decoders.

In fact I would like it to work in gpsd because gpsd is already used in our project. Indeed having it working with most NMEA decoders would be a bonus, but we're not interested on that (as far as I know).

I also found other illegal items that I did not mention.  Spend some
time with the spec.

OK, thanks. I'll do it.

About the missing fields, it seems that they 
are just not informed to gpsd clients,
gpsd can pass on the NMEA to clients for further processing.  

I forgot about that!

Always best to follow Postel's Law.

which would be a problem if
the clients expect them, but I think that's not my case...
There are a ton of NMEA clients, very hard to know what they expect, best
to do things by the spec.

Okay! :-) Thanks again!

Best,

Ellon


reply via email to

[Prev in Thread] Current Thread [Next in Thread]