|
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,,*73the 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 |
[Prev in Thread] | Current Thread | [Next in Thread] |