GPSD Receiver Reporting Form

Please use this form to report gpsd successes or failures with GPS and AIS units, and also to upload a sample of the receiver's output so we can add it to our regression tests and ensure continued support of the device.

Information gathered so far:

No vendor.
No model specified.
No document URL.
No output sample.
No contact address.
No packaging type specified.
Chipset not specified.
Firmware not specified.
NMEA version not specified.
No interface type specified.
No GPSD version specified.
No GPSD compatiblity specified.
How baud-rate changes are handled is unspecified.
No technical notes.
No sample location specified.
No sample date specified.
No notes on the sample.

Required fields are missing; please fill them in.

Fields marked Important! have to be filled in for the report to be useful. These are: submitter contact address, vendor, model, documentation URL, and output sample. Other fields represent things we might be able to find out ourselves, but which are easier for you to determine. Every bit of information you can give us about your receiver will help make the support for it more reliable.


Receiver type identification

Important! Identify the vendor and model of your device.

Example: Haicom and 303S.

Vendor: 

Model:  

Important! We need a URL pointing to a technical manual for the device. You can usually find this on the vendor's website by giving a search engine the product name. If it's not linked directly from the vendor's page for the individual product, look under "Technical Support" or "Product support" on the vendor's main page.

Example: http://www.haicom.com.tw/gps303s.shtml

URL of a technical manual:

It is useful to have an indication of how the receiver is packaged.

Packaging:

A "mouse" is a standalone sensor in a display-less case designed to be used as a peripheral cabled to a computer.
A "dongle" is a standalone sensor in a display-less case resembling a thumb drive intended to be plugged directly into a USB port.
A "handset" is a standalone unit with a display and human-usable controls.
A "handsfree" is a hands-free unit with display designed for mounting on a car windshield or boat console.
A "survey" unit is packaged for field-survey use.
An "OEM module" is an un-cased circuit board with edge connectors.
A "chipset" is a bare chip or chips packaged for surface mount.
None of the above

Please identify the device chipset and firmware version, if possible. You may be able to get this from the display of xgps; look for a Device Type field or at the window title bar. Alternatively, you may find it in the technical manual.

Example: SiRF-II and 2.31ES.

Chipset:  

Firmware: 

Please identify, if possible, the NMEA version the receiver emits. You may be able to get this information from the technical manual. Likely values are 2.0, 2.2, 2.3, 3.0, and 2000 for NMEA2000 devices. If the GPS emits only a vendor binary protocol, leave this field blank.

NMEA version emitted: 


Interfaces

Please identify the receiver's interface type (USB, RS-232, Bluetooth, Compact Flash, CAN bus, etc.). If the receiver has adapters that support other interfaces, tell us the one you have and mention the adapters in the "Technical Notes" box. If it has an exotic interface not listed here, select "Other" and tell us about it in "Technical Notes".

USB Bluetooth Compact Flash RS-232 TTL CAN Other

If your device is USB, it probably uses a USB-to-serial adapter chip. Try to find out what this is by looking at the output of lsusb(1).

PL2303 UC-232A FTDI Cypress M8 CP210x Other

GPSD compatibility

Please tell us what version you tested with. If you used a published release, give us the full release number, like 3.5. If you built your code from our development repository, please give the revision ID.

GPSD version: 

Please rate how well this receiver functions with GPSD:

Excellent -- gpsd recognizes the receiver rapidly and reliably, reports are complete and correct.
Good -- gpsd has minor problems or lag recognizing the device, but reports are complete and correct.
Fair -- Reports have minor dropouts or problems, including occasional transient nonsense values.
Poor -- Reports frequently have values that are wrong or nonsense.
Broken -- gpsd frequently, or always, fails to recognize the device at all.
Other -- See Technical Notes.

Device sanity when probed or speed-switched:
Sane: accepts baud-rate changes and probes.
Insane: goes catatonic on baud-rate changes and probes.


Technical notes

Now tell us the things that didn't fit in the rest of the form. Appropriate things to put here include how to read any LEDs or other unlabeled indicators on the device, a warning that the product has been discontinued, a list of alternate interfaces, descriptions of errors in the documentation, descriptions of special abilities such as the ability to vary the sampling interval, and a note if it's an OEM module rather than a retail product. Anything else you think we need to know should go here too.


Output sample

Important! We need a sample of the output from your receiver - not the gpsd logfile, just raw output. We'll use this for mechanical regression testing, which is your best guarantee that support for your device won't get broken in a future release. Please be advised that these logs will be sent to a publicly archived mailing list, and will be available in the public code repository.

Almost all receivers will simply start throwing data to your port immediately when they're plugged in. You should normally be able to capture this output to a file with the gpscat utility.

There will be some unusual cases in which this isn't possible, because the device needs some kind of activation sequence written to it before it will start reporting. Some Garmin GPSes (the ones that speak Garmin binary protocol rather than NMEA) are like this. If you think you have one of these, ask for help on GPSD's development mailing list.

A log file is most useful when it contains (a) some sentences generated when the receiver has no fix, (b) some sentences representing a fix with the unit stationary, and (c) some sentences representing a fix with the unit moving.

There is some auxiliary data we like to have in our regression-test files.

Location of the log capture. A good format would include your nearest city or other landmark, state/province, country code, and a rough latitude/longitude. A GPS will give an exact location; we want this as a sanity check.

Example: Groningen, NL, 53.2N 6.6E

Location: 

Year-Month-Day of the log capture (the receiver will give us hour/minute/second).

Example: 2011-05-14.

Date: 

Finally, add any notes you want to about how the sample was taken. One good thing to put here would a description of how the unit was moving while the log was being captured. If the sentence mix changes between "fix" and "no fix" states, that too is a good thing to note.


Contact information

Important! We need a valid email address for you in case we need to ask you followup questions about the device. While we won't use your address for anything other than asking you questions about your receiver, and maybe asking you to test specific changes, this device report will be sent to the gpsd-dev list which is publicly archived.

Example: Eric Raymond <esr@thyrsus.com>

Name and email address:

(It is not actually very likely we will contact you, but we need to be able to do it if we can find no other way of getting information about the device. Expect to hear from us if your receiver is obsolescent or exotic and the information you provide in the rest of this form turns out to be insufficient. Or if your browser is broken enough to botch the output-sample upload.)


To see what you have entered so far, click Review

Required fields are missing; please fill them in.

Reset Form