<br><br><div class="gmail_quote">2011/10/26 Mauro Ugarte Avilés <span dir="ltr"><<a href="mailto:mauro.ugarte@cefop.udec.cl">mauro.ugarte@cefop.udec.cl</a>></span></div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Dear Antonio:<br>
<br>
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). </blockquote><div><br></div><div><br></div><div>Yes, I'm a Windows user. Regarding RTCM collecting: it is impossible (I think) when using my combination of receptor and software (Leica Spider).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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). </blockquote>
<div><br></div><div>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.</div><div><br></div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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:<br>
<br>
"3.3 Configure Input, Output and Log Streams for RTKNAVI"<br></blockquote><div><br></div><div>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.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
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. </blockquote>
<div><br></div><div>Precisely. That is the path I'm taking for now. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">All the options and configuration for RTKPOST and RTKPLOT are described and exemplified on RTKLIB manual.<br>
</blockquote><div><br></div><div>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).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
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.<br>
<br>
Excuse my english, I'm a native spanish speaker, from Chile.<br></blockquote><div><br></div><div> Thanks. Your english is far better than mine.</div><div><br></div><div><br></div><div>Best regards</div><div><br></div>
<div>Antonio Pestana</div><div>Departamento de Engenharia Civil</div><div>Instituto Superior de Engenharia</div><div>Instituto Politécnico do Porto</div><div>Porto</div><div>Portugal</div></div><br>