PPS responses not handled

[richli]

It seems that PPS responses from gpsd are not handled, so gpsd_proto panics.

Here's a log at trace level:

[2019-06-22T08:43:38Z TRACE gpsd_proto] {"class":"VERSION","release":"3.16","rev":"3.16-4","proto_major":3,"proto_minor":11}

[2019-06-22T08:43:38Z TRACE gpsd_proto] {"class":"DEVICES","devices":[{"class":"DEVICE","path":"/dev/ttyAMA0","driver":"u-blox","subtype":"SW ROM CORE 3.01 (107888),HW 00080000,FWVER=SPG 3.01,PROTVER=18","activated":"2019-06-22T08:43:38.163Z","flags":1,"native":1,"bps":9600,"parity":"N","stopbits":1,"cycle":1.00,"mincycle":0.25},{"class":"DEVICE","path":"/dev/pps0","driver":"PPS","activated":"2019-06-22T08:43:38.001Z"}]}

[2019-06-22T08:43:38Z TRACE gpsd_proto] {"class":"WATCH","enable":true,"json":true,"nmea":false,"raw":0,"scaled":false,"timing":false,"split24":false,"pps":false}

[2019-06-22T08:43:39Z TRACE gpsd_proto] {"class":"PPS","device":"/dev/pps0","real_sec":1561193019, "real_nsec":0,"clock_sec":1561193019,"clock_nsec":286,"precision":-20}

thread 'main' panicked at 'gpsd error: JsonError(Error("unknown variant `PPS`, expected one of `DEVICE`, `TPV`, `SKY`", line: 1, column: 14))', src/libcore/result.rs:997:5
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

[bwolf]

Hi, I've never seen this response so far. Just curious, what device are you using? The u-blox website lists many. Anyway, PRs are welcome.

[richli]

I'm using a MAX-M8Q GPS receiver connected to a Raspberry Pi.

I think it's interesting that the WATCH request has the pps field set to false and yet gpsd still issues a PPS object anyway. Perhaps it's because gpsd sees two devices: /dev/ttyAMA0 for the main data and /dev/pps0 for the timing pulse. Maybe if a WATCH request is sent with the device field explicitly set, then the PPS device would not be watched?

[bwolf]

I see. I would say try it with the device specific WATCH request. I personally find the gpsd documentation lacking and did a lot of experiments to find out the typical behaviour. I think that this is a general problem of a lot of software. People tend to describe the interfaces and not the inner working which is often required to understand what is going on.

[bwolf]

PR merged, thanks.

[bwolf]

Btw. if you don't want to mess with serde, you could provide me example JSON data with those sentinel values.

[richli]

Here's one I received a few minutes ago:

Sky { device: Some("/dev/ttyAMA0"),
	xdop: Some(1.23),
	ydop: Some(1.03),
	vdop: Some(1.41),
	tdop: Some(1.1),
	hdop: Some(1.15),
	gdop: Some(2.13),
	pdop: Some(1.82),
	satellites: [
	Satellite { prn: 2, el: 52, az: 45, ss: 43, used: true },
	Satellite { prn: 4, el: -91, az: 0, ss: 31, used: false },
	Satellite { prn: 5, el: 45, az: 124, ss: 16, used: true },
	Satellite { prn: 6, el: 11, az: 49, ss: 39, used: true },
	Satellite { prn: 12, el: 66, az: 155, ss: 16, used: false },
	Satellite { prn: 25, el: 68, az: 296, ss: 36, used: true },
	Satellite { prn: 29, el: 42, az: 300, ss: 37, used: true },
	Satellite { prn: 31, el: 14, az: 311, ss: 43, used: true },
	Satellite { prn: 194, el: 13, az: 310, ss: 38, used: true },
	Satellite { prn: 65, el: 21, az: 57, ss: 25, used: true },
	Satellite { prn: 72, el: 4, az: 17, ss: 23, used: false },
	Satellite { prn: 79, el: 58, az: 249, ss: 23, used: true },
	Satellite { prn: 80, el: 30, az: 321, ss: 31, used: true },
	Satellite { prn: 81, el: 57, az: 349, ss: 37, used: true },
	Satellite { prn: 82, el: 32, az: 278, ss: 27, used: true },
	Satellite { prn: 88, el: 28, az: 48, ss: 29, used: true }
	] }

Note the second Satellite has an elevation of -91 degrees, which the comments in gps.h defines as invalid.

[bwolf]

Ok, I'll check this. Thanks for the data. Maybe we could encode these as Option<u16> as before. At least this my plan. What do you think?

[richli]

Yeah, an Option<u16> makes sense. Although elevation can go from -90 to +90 (where -91 is the invalid value), so that at least should be an Option<i16>.

According to the header, the SNR (ss field) is a double. I assume it's integerized at some point before being output in JSON, but I haven't checked that.

[bwolf]

Ok, I'll try to come up with some code after the weekend. Once again it seems to me that gpsd is i'll specified.

[bwolf]

Keep as is because it keeps this crate as much as streamlined to upstream gpsd.