[FOSS-GPS] RE: Post-processing RINEX to simulate RTK

[António Pestana]

2011/10/26 Mauro Ugarte Avilés <mauro.ugarte at cefop.udec.cl>

Dear Antonio:
>
> 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
> wish.


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.


Best regards

Antonio Pestana
Departamento de Engenharia Civil
Instituto Superior de Engenharia
Instituto Politécnico do Porto
Porto
Portugal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/foss-gps/attachments/20111026/6750acdf/attachment-0001.html