2011/10/26 Mauro Ugarte Avilés <[email protected]> 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
_______________________________________________ This message is sent to you from [email protected] mailing list. Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage your subscription For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS
