[FOSS-GPS] RE: Post-processing RINEX to simulate RTK
afsm.pestana at gmail.com
Wed Oct 26 13:35:03 EDT 2011
2011/10/26 Mauro Ugarte Avilés <mauro.ugarte at cefop.udec.cl>
> I've read that you are not a *nix user, so I'll assume you are a windows
> one (it is not impossible to collect RTCM, by the way).
Yes, I'm a Windows user. Regarding RTCM collecting: it is impossible (I
think) when using my combination of receptor and software (Leica Spider).
> I do not know Spider, but it seems to me that by the nature of its
> functions is possible that it can get the inputs in more than one fashion
> (serial, tcp client (in this case you could configure directly on Spider the
> tcp client to get the stream provided by the distant receptors at the tcp
> servers generated), logs, etc).
Yes, Spider can get inputs in various ways. I could not use this capability
because I did not managed to connect all the receivers to the same PC
running the Spider software.
> If only serial inputs are available, then you could use null-modem virtual
> serial ports (don't remember right now which tool i've used for that, but
> there are some available on the net), or instead use a "real" null-modem
> cable to output every distant stream received, by a serial interface (all
> the output options are available on the same STRSVR instance you would use
> for every tcp client) and redirect it by the null-modem cable as an input to
> another serial interface (by serial interface I mean the good old DB-9 COM
> serial port, or it's some times buggy replacement USB-to-serial adaptor) and
> configure that serial input in Spider. In order to simplify the TCP
> configurations and assure a fast connection, the processing PC should be
> ideally in the same local area network that the one/ones sending the
> real-time code and phase observations by placing a wi-fi AP/router between
> them. If the wireless network is not possible, then you still could use some
> GSM/GPRS modems on each PC, take note of the IP's assigned to them on each
> PC, and cross your fingers to find a clear path through internet between the
> stream providers PC's and the processing one, because sometimes GPRS/GSM
> internet providers forbid the provision of tcp services between clients,
> filtering ports, shaping traffic, etc. In that odd case, a medium or high
> power AP at the middle of the separation distance and some wifi USB adaptors
> with detachable antennas (replaced with some directional ones pointing to
> the AP) on every PC, should do it. For more details you should review this
> chapter of RTKLIB manual:
> "3.3 Configure Input, Output and Log Streams for RTKNAVI"
That is invaluable information for me. I'm becoming a RTKLIB fun but I'm a
civil engineer with no knowledge of data network technology.
> Regarding the RINEX files you have logged, it seems to me that RTKLIB is
> again the way to go (for post-processing only). You can't use RTKNAVI to
> simulate real-time navigation, because RTKNAVI can't use as input the RINEX
> files logged. But, you could use RTKPOST to generate a .POS file with one
> position for each epoch of observation, and configure the filters as you
Precisely. That is the path I'm taking for now.
All the options and configuration for RTKPOST and RTKPLOT are described and
> exemplified on RTKLIB manual.
Well... At that point I have to disagree with you. The options (and there
are many options) are listed and very briefly described. Almost never
exemplified and never explained. You must have a strong background on GNSS
positioning techniques to fully understand most of the options at user
diposition. I'm having trouble in learning the differences between position
modes (Options - Setting 1, namely static, moving-base and fixed) and
between integer ambiguity resolution (Options - Setting 2).
> Feel free to ask, I've used RTKLIB many times the last year and I still
> remember at least its features (sometimes not the details, though). I'm not
> having much time these days, but I'll try.
> Excuse my english, I'm a native spanish speaker, from Chile.
Thanks. Your english is far better than mine.
Departamento de Engenharia Civil
Instituto Superior de Engenharia
Instituto Politécnico do Porto
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the FOSS-GPS