1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
|
** Display EPE and DOP in xgps
We should show posiion uncertainty as well as position in the test client.
** Detect a Garmin USB device
According to Hermann Kneissel:
major/minor number won't work, but assuming that if a gps ddevice is attached
to the usb bus the driver is also installed, you may
check /prov/bus/usb/devices
for an entry with vendor 091e/product 0003:
T: Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=ff(vend.) Sub=ff Prot=ff MxPS= 8 #Cfgs= 1
P: Vendor=091e ProdID=0003 Rev= 0.01
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=1ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=83(I) Atr=02(Bulk) MxPS= 8 Ivl=0ms
this will tell you, that a garmin gps is attached to the usb bus.
** Do the research to figure out just what the heck is going on with status bits
NMEA actually has *four* kinds of validity bits: Mode, Status, the
Active/Void bit (some sources interpret 'V' as 'Navigation receiver
warning'), and in later versions the FAA indicator mode. Sentences
that have an Active/Void send V when there is no fix, so the position
data is no good.
Let's look at which sentences send what:
GPRMC GPGLL GPGGA GPGSA
Returns fix Yes Yes Yes No
Returns status No Yes Yes No
Returns mode No No No Yes
Returns A/V Yes Yes No No
In addition, some sentences use empty fields to signify invalid data.
My first conclusion from looking at this table is that the designers
of NMEA 0183 should be hung for galloping incompetence. But never mind that.
What are we to make of this mess?
The fact that the FV18 sends GPMRC/GPGLL/GPGGA but not GPGSA
argues that GPGSA is optional. I don't see how it can be, since it
seems to be the only status bit that applies to altitude. Just how are
we supposed to know when altitude is valid if it doesn't ship GSA?
Can a receiver ever ship a non-empty but invalid altitude?
Which of these override which other bits? I don't think status is ever
nonzero when mode is zero. So status overrides mode. What other such
relationships are there?
* Things not to do:
Here are several things that look like good ideas, but that turn out
on closer inspection to be not possible or not worth the effort.
** Try to crank the update rate up past 1 per second
NMEA doesn't give us control of the update rate, and SiRF/Zodiac chips
don't seem to be able to set cycle times below once per second even in
binary mode. Even on a chipset that permitted it, at 50km/h (31mi/h)
that's only 13.8 meters change in position between updates. Faster
refresh might make sense for aviation applications, but not on foot or
in a car.
** Try to autodetect USB devices
Sigh. USB scanning won't work.
The fundamental problem is that there is no GPS device class in the
USB standard. When you get device information about a GPS from the
USB subsystem, all you get is info on the USB-to-serial chipset it's
using.
This means that GPSes are not distinguishable from other USB-to-serial
devices, in particular USB-to-RS232C adaptors. This is a crash
landing. We could live with the scanning code failing to detect a
GPS that's there, but we can't live with having it mis-identify
another USB device as a GPS. The least bad result from that would
be that the daemon opens and locks up the other device.
This cannot be fixed, short of USB 1.1 growing a USB device type
and vendor firmare advertising it.
|
