Re: Separate ubx class from ubxclient

[Gary E. Miller]

Yo Martin!

On Thu, 15 Oct 2020 08:45:45 +0200
Martin Laabs <martin.laabs@tu-dresden.de> wrote:

> During my search I found many people exactly looking for that setup
> without having to deal with another protocol stack.

Yes, a common request, so please share your work.

> > I have been expecting someone to ask to split out the ubx class for
> > a while.  The big problem is that the output is not client
> > friendly.  Even if it was client friendly, the output is still
> > mutating pretty fast.  
> 
> Why is the output changing?

ubxtool is new, distros are just starting to ship it and users are
just now getting a look at it.  Many new opinions on what it should do.

u-blox keeps adding features.

Firmware all the way back to Anaris 4 has many quirks that we keep
finding.  Just look at the last few days git log for examples.

There are still bugs in the way ubxtool decodes the thousand plus
variables that we know about.

Then there is the stuff, like subframe decodes, that is just barely
started.

> And the alternative - parsing ubxtools
> output itself would be affected by such a change as well. So even
> more a merit for a module which could be pinned to a version.

Which comes back to my point about splitting the decode part aand the
formatting part.  Big job that is not defined at all.
> 
> > To make it work the ubx class needs to be split in two.  The
> > parsing and the output nned to be separate.  So that the output can
> > by csv, JSON, plain text, etc.  That will be a lot of work.  The
> > u-blox protocol is such a mess with special cases that the code has
> > to be hand rolled.  
> 
> If we start with the new VALSET/VALGET interface which seems to be
> the way forward for all new u-blox products the interface would be
> much cleaner - at least on the raw value interface.

Except that VALSET/VALGET/VALDEL do not live in isolation.  You still
need the packetizer/depacketizer, ACK/NAK, and the decodes of all the
TPV, SKY and SUBFRAME stuff.

> > I have been toying with making a JSON intermediate layer.  But the
> > big value to ubxtool is the verbose decoding of all those fiddly
> > fflags. How to do that in JSON?  
> 
> Why not making something like:
> 
> {
>    "Register1": {
>      "Binray Flag1": true,
>      "Binary Flag2": false,
>      "Enum Flag": "SomeEnumValue",
>      "Int Value": 3
>    },
>    "Register2": {
>      "Binary Flag1": false
>      [...]
>    }
> }

How about you give that a try and see how much work it is.  That is similar
to how the ITEMS are handled, and that is over 1,500 lines in a table.
A table where people will keep finding bugs and changes for years to
come.  Doing the old u-blox messages will triple, quadruple, or more to
handle the other stuff that way. Then add layers for verbosity.

> Of cause it would be different for each configuration register but
> that would not be a big issue as the user shall know what to expect
> from which call.

Configuration registers are the easiest part.  A small part of ubxtool.
For example, how would you do SBFRX?

> > OTOH, if all you want is the raw packets that would not be too
> > hard, but hard to use.  
> 
> Well - why not starting with that and see if it is really that pain
> in the ass.

Have at it.  Keep us in the loop.  I'd prefer that you take small chunks
at a time that are useful right away.

> > IFF all you want is setitem that would be easy.  But then there are
> > a thousand (literally!) special cases to handle.  And all to be
> > able to use a poor tool, once, for setup.  
> 
> You might be right. Maybe I make a small parser of the setitems
> instead to generate a blob of code instead of parsing that file.

Not what I was suggesting, but feel free to experiment.  I suggest that
anything with u-center is a waste.

> 1. Make a new module with the separated ubx class, leaving the
> ubxtool as it is - later the ubxtool could use the other class as
> well (but this port could be painfull as well)

I hate code duplication.  The ubx class was dessigned to be separable.
But there will be class violations in the code that need fixing.

The io class will also need to be pulled out.  Right now it is probably
tangled up with ubx class.

> 2. Make a branch of ubxtool, separate ubx class out while maintaining
> the ubxtool functional

Once again, I have code duplication.

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

pgpFZyWnkcimo.pgp
Description: OpenPGP digital signature