> Date: Sat, 3 Nov 2018 17:00:47 +0100 > From: Landry Breuil <lan...@openbsd.org> > > Hi, > > here's a diff to add 5 new sensor values to nmea: altitude, quality, > hdop, vdop & pdop. altitude and quality are provided by GGA messages: > http://aprs.gids.nl/nmea/#gga, quality is either 0 (no fix), 1 (gps fix) > or 2 (dgps fix). > > The last 3 are 'Dilution of precision' values, respectively horizontal, > vertical & positional (ie 3d), cf > https://en.wikipedia.org/wiki/Dilution_of_precision_(navigation) & > http://www.trakgps.com/en/index.php/information/gps-articles-information/65-gps-accuracy > and are provided by GSA messages: http://aprs.gids.nl/nmea/#gsa it is > generally considered good precision when the DOP is below 2, so i've set > the sensor status warning accordingly. > > this provides for example (angle values hidden for 'privacy', just after > the gps got a fix): > nmea0.indicator0 On OK Signal > nmea0.raw0 1 raw OK GPS fix > nmea0.raw1 1920 raw OK HDOP > nmea0.raw2 2520 raw WARNING VDOP > nmea0.raw3 3170 raw WARNING PDOP > nmea0.timedelta0 24.867 ms OK GPS autonomous > nmea0.angle0 xx.yyyy degrees OK Latitude > nmea0.angle1 z.wwww degrees OK Longitude > nmea0.distance0 371.50 mm OK Altitude > > and after a while, when precision improved: > nmea0.indicator0 On OK Signal > nmea0.raw0 1 raw OK GPS fix > nmea0.raw1 800 raw OK HDOP > nmea0.raw2 1300 raw OK VDOP > nmea0.raw3 1530 raw OK PDOP > nmea0.timedelta0 -296.499 ms OK GPS autonomous > nmea0.angle0 xx.yyyy degrees OK Latitude > nmea0.angle1 z.wwww degrees OK Longitude > nmea0.distance0 355.50 mm OK Altitude > > two problems with this display: > - DOPs are usually decimal values, ie 1.3, 1.53.. but raw sensors only > support integers, hence *1000.
We could add a SENSOR_FIXEDPOINT if we can come up with a reasonable representation. Probably should be binary, and maybe we'd simply put the radix point smack in the middle. But I'm not convinced DUP is a good enough reason to introduce this. > - GGA messages provide altitude as '355.5' in meters (i *think* the unit > is fixed in the protocol, because altitude in feets is provided by > PGRMZ) - and we only have a SENSOR_DISTANCE type in mm (which doesnt > seem used by any driver..). Thus altitude shown in milimeters.. > This sensor types were added in > https://github.com/openbsd/src/commit/d95200b806051887b8c69294833e22dad6302828 > but no driver apparently makes use of it. Well, altitude really is just a vertical distance, so SENSOR_DISTANCE is the right one. You obviously should convert the altitude from meters into millimeters. If you think it would be more appropriate to display distances in meters, we (you?) can adjust sysctl(8). > >From that point, questions: > - should i add more 'interesting' sensor values, like amount of satellites > seen/used ? Number of satellites is probably interesting. > - i want to add speed value (as RMC has it in knots?, and VTG in various > units, per http://aprs.gids.nl/nmea/#vtg), but we only have > SENSOR_ACCEL type in m.s-2 (which is only used by asmc(4)). Should we > add a 'speed' sensor type ? in m/s ? in km/h ? knots ? SENSOR_VELOCITY would make sense. It should be m/s with some appropriate scaling. We don't need to represent speeds higer than 299792458 m/s, so micrometers per second would be a good choice. > - should i add a SENSOR_ALTITUDE type in meters ? I don't think so. > - is there any interest in all this, from the sensors framework POV ? > Otherwise i can leave it as is and just use gpsd in userspace, which > works 100% fine... Having the position and some quality indicators available makes sense to me. > All this done with an > umodem0 at uhub1 port 1 configuration 1 interface 0 "u-blox AG - > www.u-blox.com u-blox GNSS receiver" rev 1.10/2.01 addr 3 > > which works fine with ldattach & gpsd, ie i run doas gpsd -N -D2 $(doas > ldattach -p nmea /dev/cuaU0) and gpsmon shows me the msgs received by > the device, sent to the kernel via ldattach, and forwarded to gpsd. > > comments welcome, diff not to be commited as is of course (nmea_atoi is > *horrible*, i know..) > > Landry
