Re: InertialSense uINS Support

[Gary E. Miller]

Yo Isaac!

On Mon, 8 Jun 2020 17:11:10 +0000
Isaac Gutekunst <isaac@safe7y.com> wrote:

> Thanks for the response! Based on all your responses, it looks like
> this is too much effort for me at the moment.

Maybe, depending on the asnwer to my previous questions.  But if you
aren't interested in doing the work, it will not happen.

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

Good thing most of that stuff was alreeady done a long time ago.

> >> I just purchased a nice, tiny, GPS+INS module from InertialSense:
> >> https://inertialsense.com/%C2%B5ins-dual/#DUAL-sensors  
> > 
> > Cool.  Looks like a bare chip?  
> 
> They sell bare chips, and also very small modules with a few
> connectors. That's what I have.

Anyway one of us could get one?

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

a) I'm sure it does.  Those are the binary messages you need.
b) gpsd knows how to fix those, so you don't.

> > Is that really Zodiac?  gpsd already does Zodiac.

You failed to answer my questions: Is it really Zodiac?

I dug a bit deeper, and no, it is not Zodiac, it is u-blox.  So
that part is done in gpsd.

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

Too early to look in the packet body, the important part, for packet.c,
is the framing.

Zodiac is:

0xff, 0x81, ID1, ID2, LEN1, LEN2, FLAG1, FLAG2, CHK1, CHK2, data...

Looking at the doc for your part:

https://docs.inertialsense.com/user-manual/com-protocol/binary/

Yours is:

0xff, ID, CNT, UNK, data, CHK1, CHK2, CHK3, 0xfe

So, nothing at all like Zodiac.  And no length.  You need know the packet
ID to get the legnth of the data, which makes adding new packet types
very hard.

> To support both, there need to be a few extra states in the state
> machine. 

Closer to 10.

The real fun part will be handling their 0xfd "Special Bytes".

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

Which breaks the packet state machine.  Not gonna happen.  Adding the 10
states to the state machine is not hard.  Not using our state machine
breaks thing like autobaud.  Their code is too yucky to live.  Things like
their MSL calc where not correct even at the end of the last millennium.

Too bad their protocol can't be fixed too.

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

Have at it, but you'll need to use our state machine, and our backend
functions, to be merged.  Instead of the flawed ones in their code.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@rellim.com  Tel:+1 541 382 8588

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

pgpmnPH5_RYDD.pgp
Description: OpenPGP digital signature