Re: [gpsd-dev] RoyalTek REB-5216 gnss module and some questions

[Eric S. Raymond]

William Smith <address@hidden>:
> Hi,
> 
> I just registered recently, and was a bit shocked to see my password
> mailed to me as plain text. In 2019, stuff like that should simply
> not happen. Savannah looks like it is stuck in the 1990's.

We can't argue the point.  Savannah is pretty archaic and undermaintained.
GPSD got tied to it at a time when more modern forges did not yet exist.

> Something like SourceForge, GitHub, CodeAurora, etc. would be
> definitely more approachable for a wider audience of potential
> contributors to the project.

We agree.  (I'm the GPSD lead.)
 
Unfortunately, I and the GPSD core devs have mostly directed their
attention towards NTPsec for the last three years.  We've had little
alternative but to leave GPSD in maintainance mode, fixing bugs but
not attempting anything as major as a hosting move.

Fortunately, GPSD is mature and stable enough that it can survive long
periods of relative neglect pretty nicely. Unfortunately, it means
we're occasionally going to get a justified complaint like yours.
Until we can budget time for all the hassles that go with a hosting
move, we can't fix it.

> REB-5216 SirfStarV module
> Anyhow, I have a RoyalTek REB-5216, and it does indeed work with gpsd.
> gpsd does not recognize what it is, but it is recognized as Sirf. (gpsmon,
> gpsctl) xgps does not work with it at all. I would like to gradually start
> working on it. It looks like it could be fairly easy to get it fully 
> supported.
> Another thing is that, although I see satellites, it has a fix, etc., gpsmon 
> is
> not showing time from the gnss module.
> "Time:  -219246529-80-00T08:29:5 Leap: ??"
> GPS Time is empty.
> I am reading through the wiki, but any extra advice would be welcome.

Sounds like SiRF has mucked with the binary protocol again.  This
happens every few years. Likely they're now shipping time in a new
packet format with a new type number and our SiRF driver needs to know
to interpret it.  Time reporting has been particularly unstable, more
so than the rest of the protocol; this is about the least surprising
possible place for things to go pear-shaped again.

It shouldn't actually be difficult to fix. If you can get your hands
on a current version of their binary-protocol documentation, the right
packet to parse will probably jump out at you.  Otherwise, if you can
get gpsmon to run at all (it wan't clear from above) it's easy to use
that to see what packet types are being shipped in each cycle and find
whatever time report our driver is not covering.

Then, after reading a couple of the existing packet handlers, writing
a new one should be trivial.

If you run into serious trouble, yell for help here.  We think AOSP is
important and want to back you up.

Alternateively, if you C skills aren't up to the job, follow the procedure
for sending us a properly annotated dump of SiRF V output - note that it
*must* include a span with a fix - and we'll see what we can lash up.

> Building in Android:
> SCons is something I have not used before. It works fine in a normal Linux
0> environment, but I am trying to build gpsd inside an Android AOSP. SCons
> does not seem to pay any attention to my environment variables inside the
> AOSP. I build it, but get an X86-64 binary, but Makefile projects in the
> same build environment give me aarch64 binaries. SCons is the normal
> one from the Ubuntu repository running on the host machine (Ubuntu
> 16.04). Any advice? Or is there any way to easily make it into a normal
> makefile project?

When I inherited this code it had a truly horrifying autoconf-based
build system.  It could not then, and can't now. be changed to pure
makefiles because it requires a fairly complex config phase.

The scons manual says:

       scons does not automatically propagate the external environment used to
       execute scons to the commands used to build target files. This is so
       that builds will be guaranteed repeatable regardless of the environment
       variables set at the time scons is invoked.

It goes on to explain how to modify the build to pull in specific enviroment
variables.

We don't have an AOSP environment to test in here, so we don't know what
variables are crucial.  We welcome your patch once you figure it out.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.