-3

I have a bit of python code that queries gpsd with

session=gps.gps(mode &c &c
report=session.next()

as published all over the www. It works nice, but gives altitude in metres and speed in km/h. Being in aviation (and in the free world), I want knots and feet. Of course I can convert, but that would add cpu load and reduce accuracy. Isn't there a way to make the gps library yield the "proper" units of measurement?

Karlchen9
  • 25
  • 5
  • regarding < put on hold as unclear what you're asking by jonrsharpe, Antti Haapala, karthik, Odedra, Piyush Please clarify your specific problem or add additional details> I can read the speed with report=session.next(), speed="{:.0f}".format(report['speed']) (if the report is of class "TPV". Nice so far. BUT the reported speed is in km/h, and I should like the python gps package to report the speed in knots. Perhaps by setting an environment variable – Karlchen9 Feb 09 '15 at 17:51
  • ... such as export gpsd.units=imperial or by modifying the gps library's parameters. – Karlchen9 Feb 09 '15 at 18:06
  • It looks like you're using python-gps, the module provided with the gpsd package. [This reference](http://www.catb.org/gpsd/gps.html) has details how the different gpsd front ends choose the units they use. One of my systems was displaying in imperial units when I wanted metric (for science) like another system, and the difference was in the LANG environmental variable, en_US vs en_GB. – datu-puti Nov 01 '17 at 16:16
  • @elBradford, thanks! finally someone understood what I meant. However I have stopped using the gpsd module, except for driving ntp; for navigation purposes I found it (in my application) too complex and insufficiently stable. – Karel Adams Nov 02 '17 at 18:23
  • @KarelAdams What did you end up using instead? – datu-puti Nov 03 '17 at 00:51
  • A one-page python script. Of course it has none of the sophistication of gpsd, but the job at hand requires stability above all; all other requirements are only basic. – Karel Adams Nov 03 '17 at 19:24

1 Answers1

5

It would certainly not slow down your program to almost any measurable extent to convert the units in Python, and neither would it reduce accuracy. 1 knot is exactly equal to 1.852 km/h and 1 foot is exactly equal to 0.3048 meters, thus we get:

knots = speed / 1.852
altft = alt / 0.3048

And these numbers are as exact as possible.

As to how much error these would do, such divisions are safe operations w.r.t. precision, lets assume that the 32-bit IEEE floats are used, and you do 1 extra multiplication and 1 extra division. Each of these would have a maximum error of 0.5 binary digits of precision, for a total of 1 binary digit of error out of 23 bits of precision. Thus the maximum of the error is certainly not more than 1 / (2^22), or 1/4194304. For speeds in range of 500 knots, it would make a difference of 8.7 inches per hour, for altitudes of ~30000 feet it would make a difference of 0.86 inches (oops, maybe your GPS receiver is upside down). If you think these errors are significant, you should know that any sane library and Python alike use doubles already, and thus the error would be approximately 1073741824 times smaller.

Antti Haapala -- Слава Україні
  • 129,958
  • 22
  • 279
  • 321
  • Thanks for trying to help, but there was no need to show me how to do division. Also I do believe there would be some loss of accuracy, never heard of a floating point division without rounding errors. But that point is moot, the accuracy will still be more than sufficient for private aviation where traditional instruments have margins of at least 5%. It doesn't alter the fact that I hate wasting cpu cycles - NMEA delivers the speed to gpsd in knots (on most receivers, surely on mine), why should it get converted to km/h then back to knots? Sheer waste I call that. Likewise for altitude. – Karlchen9 Feb 08 '15 at 16:10
  • @Karlchen9 gps data is initially metric. Your receiver does the math to display the same data in *non*-metric form. If you want gps data in something that is not metric you *must* expend 'cpu cycles'. Even km/h must be converted from m/s. Also given the inherent errors in gps precision you will not even notice floating point division errors, nor will you notice the extra load on your cpu. – Nodak Feb 09 '15 at 03:54
  • @Nodak: I have to disagree. Hitec 204 outputs speed in knots, altitude in feet in the NMEA records. – Karlchen9 Feb 09 '15 at 17:59
  • @Karlchen9...sure, your receiver does the conversion on the unit, and the unit pays the conversion cost. You could tailor `?WATCH_RAW`, or `NMEA` pass the data that way, and still be less ''efficient" counting the entire process just on the computer. Then if you switch to something not Hitec, it might be less so. Suck it up, go JSON and do the float division. It will be cleaner, (faster), and you'll be happier. Check out [gps3](https://github.com/wadda/gps3). It's still alpha, but it looks to be a slightly leaner python interface for gpsd, allowing leftover cpu cycles for a game Tetris. – Nodak Feb 10 '15 at 01:38