[Top][All Lists]

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

Re: InertialSense uINS Support

From: Gary E. Miller
Subject: Re: InertialSense uINS Support
Date: Fri, 5 Jun 2020 20:15:09 -0700

Yo Isaac!

On Fri, 5 Jun 2020 19:33:20 +0000
Isaac Gutekunst <> wrote:

> I just purchased a nice, tiny, GPS+INS module from InertialSense:

Cool.  Looks like a bare chip?

> I'd love to use it with GPSD, and have taken the first steps to hack
> in support for it. I wanted to reach out and ask for help and
> guidance in getting my code in a good state for merging with the
> gpsd. 

One good way is to put the code you have so far as a merge Reqquest on

Looking at the doc, there are some NMEA extentions that don't look
to hartd to add.

The binary protocol is a bit funcky.  I doubt it can coexist with
other binary protocols in gpsd.  Could be handled with a special
build, but not in the standard build.

> I have read through, and I
> apologize if I missed something.

That is OK, no one understands it all.

> I plan on adding test coverage, and
> re-reading before submitting a formal patch.

No need.  gpsd has built in regression tests, all it needs is sample

> Before then, I have a few questions:
> 1. Do you think it will be possible to merge in some MIT licensed code
> from InertialSense? 

I have been told by those supposed to know that our BSD 2-Clause is
essentially the same as the MIT License.  As long as we keep the
copyright and license notices.  You should also ask them.

> There licence is standard MIT: 

A bigger problem is they used C++.  There is no, and will not be, c++
in the gpsd daemon.  OK for clients, just not the daemon.

Prolly be easier just to re-write in C, using gpsd internals, than
try to port that.

Worse, the code is written non-portably.  It assume endianness as well
as structure packeting.  It has to be re-written.  Nothing on their
GitHub is useable.

> Assuming I fix it and split the state machine to also handle Zodiac
> packets (0xFF, 0x81,...), vs Inertial Sense (0xFF, [0-32],...0xFE),

Is that really Zodiac?  gpsd already does Zodiac.  If the GPS stuff
is rodiac, and the IMU is kinda sorta almost Zodiac, then shoehorn it
into the Zodiac driver.

> since their driver maintains
> it's own state machine.

That also has to go.  gpsd can handle many simultaineous conenctions:
PPS, NTRIP, clients, receivers, TCP, RDP, etc.  You have to use
the existing state machine.

> Here's the code as is if you want to take a look (I don't necessarily
> recommend it yet): 

That's gonna need a lot of work.  Just removing the duplicate functions,
like RTCM (ISComm.c) and ecef (ISEarth.c) stuff, will take real work.

Some of the stuff is just wrong, like the E_SQ define.

The code style is not the kinda-sorta Linux Kernal style that gpsd
uses. Things like 80 char lines, brace placement, etc. seem simple,
but are tedious to fix.

Code like this is just broken:

            if (c == 0xff) {

                lexer->length = 0;
                return character_pushback(lexer, INERTIAL_SENSE_SOF);

        if (c == 0xff) {
            lexer->state = ZODIAC_LEADER_1;
#endif /* ZODIAC_ENABLE */

The second c == -xff test is totally masked by the first one.  It needs
a major rethink.  If the GPS is kinda sorta Zodiac, than stuff like that
gets merged together.

I do not see in packet.c where you handle byte stuffing.  That will also
be a PITA.

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: pgpQEOPmMdO42.pgp
Description: OpenPGP digital signature

reply via email to

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