On Sat, Nov 03, 2018 at 05:42:26PM +0100, Mark Kettenis wrote: > > Date: Sat, 3 Nov 2018 17:00:47 +0100 > > From: Landry Breuil <lan...@openbsd.org> <snip> > > > > 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.
Same, so that might stay this way for now. The DOPs are interesting, but a bit abstract to me.. > > - 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). Agreed, from what i understand there's a difference between 'the unit in which the value is stored internally in the int64_t' and the 'the unit used when displaying the value'. As nothing uses SENSOR_DISTANCE for now, we can decide to switch all 'users' to show it as meter right now, don't change the current internal storage unit (ie, uMeter per the sensors.h comment ?) and if there's a proximity sensor someday (with its native unit being millimeters) it will be displayed as '0.00022 m' for 0.22mm, right ? > > >From that point, questions: > > - should i add more 'interesting' sensor values, like amount of satellites > > seen/used ? > > Number of satellites is probably interesting. Ok, will add that one. I dont necessarly want to clutter the hw tree with all sensors/values available, only keep the relevant ones.. > > - 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. In that case, if i understand it right, that would be 'store internally as micrometers per second' then 'display to user as meter per second' ? > > - should i add a SENSOR_ALTITUDE type in meters ? > > I don't think so. Ok, will withdraw that part, add SENSOR_VELOCITY and reuse SENSOR_DISTANCE. Thanks for your comments !
