On Sat, Nov 03, 2018 at 05:00:47PM +0100, Landry Breuil wrote: > 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. > > - 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. > > From that point, questions: > - should i add more 'interesting' sensor values, like amount of satellites > seen/used ?
Yes, num sats is as quality indicator to show how much error is in the gps fix. > > - 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 ? Hmmm...what's the common case for movement: are we walking (m/s), driving (km/h), or on a boat (knots)? > > - should i add a SENSOR_ALTITUDE type in meters ? Yes. > > - is there any interest in all this, from the sensors framework POV ? I think it'll be niffty to be able to trigger on events via sensord. +--+ Carlos > Otherwise i can leave it as is and just use gpsd in userspace, which > works 100% fine... > > 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
