[Top][All Lists]

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

Re: InertialSense uINS Support

From: Isaac Gutekunst
Subject: Re: InertialSense uINS Support
Date: Mon, 8 Jun 2020 17:11:10 +0000

Hi Gary,

Thanks for the response! Based on all your responses, it looks like this is too 
much effort for me at the moment. I'll keep hacking on it and see if I can make 
some progress, but I don't think I have the time to rewrite the parser not 
using packed structs just yet. I'll reply to some specifics inline anyway.


> On Jun 5, 2020, at 8:15 PM, Gary E. Miller <> wrote:
> 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?

They sell bare chips, and also very small modules with a few connectors. That's 
what I have.
>> 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
> GitLab.
> 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
> data.
>> 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.

Luckily the parts I want are all C. The C++ pars are unnecessary. 
> 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.
I'll have to see if the part I need uses packed structs. If so, like you said, 
it's a no go.

>> 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.

It might be possible. I haven't looked deeply at either packet body, but the 
main differences I've found are:

InetialSense: 0xFF [0x01-0x32] .. 0xXX 0xXX 0xXX 0xXX 0xXX ... .. 0xFE
Zodiac: 0xFF, 0x81, 0xXX, 0xXX, 0xXX....

To support both, there need to be a few extra states in the state machine. 
>> 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.
This might be beyond my abilities, since it's in the nitty gritty of GPS. We'll 
> 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:
Oh yeah, I know. I'd need to add a few more states here, so if 0xFF is 
detected, it could be either an InertialSense or Zodiac packet. If the second 
byte is 0x81, then it is a Zodiac. If it is a value between 1 and 32 (decimal), 
then it is an InertialSense binary packet. I would propose that if it is a 
InertialSense packet, then the entire chunk from 0xFF to 0xFE  is sent to the 
code from InertialSense. Of course this brings in all the duplicated code, so 
perhaps that's not going to fly! Maybe I'll get it working as a private build, 
and we (this means mostly me), can slowly hack it towards being mergeable. 
>            if (c == 0xff) {
>                lexer->length = 0;
>                return character_pushback(lexer, INERTIAL_SENSE_SOF);
>                break;
>            }
>        if (c == 0xff) {
>            lexer->state = ZODIAC_LEADER_1;
>            break;
>        }
> #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

reply via email to

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