[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Public GPS/GNSS receivers on the Internet?

From: Gary E. Miller
Subject: Re: Public GPS/GNSS receivers on the Internet?
Date: Fri, 4 Feb 2022 15:16:44 -0800

Yo Mike!

On Fri, 4 Feb 2022 22:57:34 +0000
Mike Tubby <> wrote:

> I am re-developing a vehicle monitoring and location system first 
> written over 25 years ago when it used Trimble TSIP with Trimble TANS 
> and Trimble S-VeeSix

Cool.  I hope the new code is a lot better than the hot mess that is
TSIP.  I'm just playing with TSIpv1, much better, now with length and
checksum.  But they still have not learned a lot of lessons of the past.
They still do not even ACK many types of request packets.

> and which has been completely re-written to run 
> under Linux using GPSD and I would like to test it with a range of 
> GPS/GNSS receivers to ensure that my parsing and business logic is 
> working as expected.

Did you notice the large number of raw GNSS receiver capture files in
gpsd/tests/daemon?  Pretty much every low cost receiver has raw samples
in there.  Plus the matching gpsd generated JSON.  All sorts of odd
corner cases present.

OTOH, if you are reading JSON from gpsd, then the regression test JSON
is very complete.  The problem is all the raw variants.

> Static tests are fine for the shake down that I want to do.

They sure keep gpsd honest, mostly.

> All my testing to date has been with a range of Trimble ACE-II,
> ACE-III and Lassen-iQ devices as that's what I have at hand.

Ouch.  TSIP with few channels and GPS only.  Wait until you have to
implement 7 constellations over a dozen signal types, on 172 receive

> Does anyone have GPS receivers connected to the Internet via GPSD and
> if so might I be able to connect my client to your GPSD service to
> perform some testing for 10-15 minutes?

All that takes is "gpsd -g", but until you can handle the gpsd
regression tests, there is no point.

> I am particularly interested in testing against receivers including:
>   * Ublox 6, Ublox 8, Ublox 9
>   * Qualcomm iZat that are part of mobile phone modules like Quectel
>     EP06, EM12, etc.

Qualcomm has gone there own, closed and propriery, way.  Gpsd can not
support it without any documentation.

Quectel is very different than Qualcom, and has a ton of "Quectel
Quirks".  They clearly never read the NMEA spec and just made up shit.

>   * Something with SiRF

SiRF is Qualcomm.  gpsd has support up to SiRF 4, but SiRF V, outside
of the unsupported by gpsd cell phone chips, is rare.

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

Attachment: pgpWSq6pKbGFR.pgp
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]