Re: Separate ubx class from ubxclient

[Martin Laabs]

Hi Gary et all,

first of all - thank you for the fast reply. I can spend a few days on 
coding on this - either a quick&dirty solution or something that could be 
reused from others as well. But for the latter case it would be helpful to 
get some further feedback.

> > I am going to implement a RTCM base station with a u-blox receiver. >> Most work is done in the ubxclient already - e.g. sending commands,>> 
parsing the SET/GETVAL arrays and so on.> > I imagine a short ubxtool 
script could do that.
Yes - it certainly could be implemented that way but I prefer a more robust 
approach especially because:

> > [...]
> > - Stream RTCM data to (another) gpsd
>
> You don't want to just use NTRIP?

I like to have one blob without introducing even more deamons and layers 
into my already quite complex system. I have a simpel 1:1 or 1:2 setup 
without the need  of NTRIP. And as it has to work in the field without 
internet access I can not afford too much complexity. I wanna power it on 
and it shall work within a few minutes.

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

> > For that I would propose to separate out the ubx class from the
> > actual ubxtool e.g. into the gps python module. So everyone could use
> > it in its own code without making duplicates.
> >
> > What do you think about that proposal?
>
> 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? 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.

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

> 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
    [...]
  }
}

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.

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

> > I also think about a parser that can handle the files created by the
> > u-blox GUI. 

> IMHO u-center is such a mess that there is no reason, other than
> firmware updates, to ever use it.
[...]
> 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.

I see two ways forward:

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)

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


Best regards,
 Martin