[Top][All Lists]

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

Re: Separate ubx class from ubxclient

From: Martin Laabs
Subject: Re: Separate ubx class from ubxclient
Date: Thu, 15 Oct 2020 08:45:45 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

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,

reply via email to

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