gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] [PATCH] Using GOODTIME_IS for UBX_MODE_TMONLY.


From: Fred Wright
Subject: Re: [gpsd-dev] [PATCH] Using GOODTIME_IS for UBX_MODE_TMONLY.
Date: Sun, 27 Mar 2016 09:32:36 -0700 (PDT)

On Sun, 27 Mar 2016, Paul Fertser wrote:
> On Sat, Mar 26, 2016 at 02:45:28PM -0700, Fred Wright wrote:
> > With receivers that make raw observation data (and ephemeris data)
> > available, features like the "T variant" could be implemented purely in
> > software, though it would involve duplicating the fairly complex
> > position-solution calculations.  In principle, this could be done in GPSD,
> > though that would be a pretty severe case of mission creep.  In any case,
> > it doesn't make sense to implement code to process raw observations before
> > it even has code to make raw observations available to clients. :-)
>
> For the reference, there's an RTKLIB project[1] that implements many
> different modes of processing raw data, but it's not obvious what
> exactly the "T variant" corresponds to.

Yes, I'm somewhat familiar with RTKLIB, and have the code here.  A while
back, I got parts of it to build for OSX (needing a number of fixes), and
tried out its RINEX converter on data from one of my Geneq SxBlue
receivers.  These use Hemisphere's OEM hardware, and a modified version of
Hemisphere's firmware, so the "Hemisphere" support in RTKLIB is
applicable.

What I found is that the results had significant numerical errors.  This
is really bizarre, since there's no "fancy math" involved in converting
from the binary format to RINEX.  The only mildly complicated thing (and a
bit more complicated for GLONASS than for GPS) is the conversion from the
way it reports carrier phase to a more normal representation.  There's no
excuse for errors beyond maybe one LSb or so.  The fact that it can't do
something that simple accurately doesn't give me a lot of confidence in
its postprocessing accuracy.

Even the factory RINEX converter (either from Hemisphere or Geneq) has at
least one significant bug, but it's only in a corner case that probably
doesn't occur in normal practice.

> Also, there's a repository[2] that has code that enables output of raw
> data from a cheap ANTARIS ATR062x receiver[3].

My time server uses a Navika-based BeagleBone Black cape from Yantrr:

        http://www.yantrr.com/products/m2m-cape-for-beaglebone/vayup

Somewhere it says that this is capable of outputting raw observations, but
neither Yantrr's website nor Navika's has any adequate documentation, and
I haven't gotten around to bugging them about it.

Fred Wright



reply via email to

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