[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Separate ubx class from ubxclient
Re: Separate ubx class from ubxclient
Thu, 15 Oct 2020 08:45:45 +0200
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.
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:
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,>>
- 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:
"Binray Flag1": true,
"Binary Flag2": false,
"Enum Flag": "SomeEnumValue",
"Int Value": 3
"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
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
- Re: Separate ubx class from ubxclient,
Martin Laabs <=