GPS

GPS in Kismet

Kismet can integrate with a GPS device to provide geolocation coordinates for devices.

Remember: Kismet uses the GPS to determine the location where a packet was seen. This is not necessarily the location of the transmitter, but can be used to determine where the transmitter is likely located.

The quality of the location estimates is determined in part by the quality of the sampling methods. Passing a transmitter once in a straight line (such as driving past) limits the possible location to that single path. By circling the area of the suspected transmitter, or navigating in a grid around it, the data available to deduce the transmitter location is greatly increased.

GPS data is included in the log files, in PPI pcap files, and exported over the REST interface.

Some devices (such as ADS-B aircraft, AIS vessels, Remote ID drones, and MeshCore and Meshtastic nodes) report their own location. As of 2026-10-R1, Kismet keeps this as a separate reported location (kismet.device.base.reported_location, and the reported_ columns in the kismetdb log), and the normal device location is always where Kismet was when it heard the device.

Remote datasources can be configured with static GPS coordinates, or paired with a remote GPS tool.

In addition to logging GPS data on a per-packet basis, Kismet maintains a running average of device locations which are exported as the average location in the Kismet UI and in device summaries. Kismet attempts to keep the running average location as accurate as possible by factoring speed into the location counts.

GPS reception

Modern cell phones use a fusion of GPS, cellular, Wi-Fi, and Bluetooth locational data to generate locational information under almost any condition. This can lead to a false sense of GPS reception in an area. USB GPS receivers typically only provide true GPS processing without fusion of other locational services. They typically require a clear view of the sky, and may be unable to obtain a GPS lock inside a building, or even when placed in a window, depending on orientation.

Some GPS units support multiple GPS variants implemented by different countries; these “multi-constellation” receivers may be able to obtain a stronger location signal in more locations, but typically are more expensive.

When testing GPS, be sure to give the receiver as much a view of the sky as possible.

Satellites

As of 2026-10-R1, Kismet reports the satellites each GPS has in view, as well as the number used in the fix, the DOP, and the estimated precision. Each satellite in kismet.gps.satellites lists:

  • kismet.gps.satellite.constellation: GPS, GLONASS, Galileo, BeiDou, QZSS, SBAS, or NavIC
  • kismet.gps.satellite.id: The satellite’s number within its constellation
  • kismet.gps.satellite.elevation and kismet.gps.satellite.azimuth: Where the satellite is in the sky, in degrees, or -1 if the receiver doesn’t report it
  • kismet.gps.satellite.cn0: The signal strength, in dB-Hz, or 0 if the satellite is in view but not being tracked
  • kismet.gps.satellite.used: 1 if the satellite is used in the fix, 0 if not, or -1 if the receiver doesn’t report it

The satellite list is filled in by NMEA GPS devices (serial or TCP), gpsd, and u-blox (UBX) and SiRF binary receivers. GPS devices which only report a location (such as the web and virtual GPS) have no satellite list.

The web UI shows the satellites, a sky plot, and the recent fix quality in the GPS window, opened by clicking the GPS status at the top of the page. The satellites are also logged to the kismetdb log.

Configuring GPS in Kismet

Kismet can handle multiple GPS types. Generally, you will only want to define a single GPS per Kismet instance, however if multiple GPS devices are defined, Kismet will use the location of the GPS with the most recent valid location report.

GPS definitions take the form of:

gps=[gpstype]:option1=value1,option2=value2

GPS is configured in the kismet.conf configuration file, or preferably, the kismet_site.conf configuration override.