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

Wed Oct 26 11:06:27 EDT 2011

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). Even in windows, 
there are some tools you can use to emulate the serial connection you 
are needing between rover, reference and processing computer. RTKLIB has 
a GUI tool called STRSVR that for me has proved to be some sort of swiss 
knife of serial-tcp-ntrip-logging connections for windows. It has a 
compact, clean and really clear interface, divided in: ONE input (with 
many choices), and THREE outputs (with many choices each one too). You 
could use that in each of the PC's that are connected to the receptors 
and generate a TCP server as output (on some port of your choice) for 
the serial input coming from the receptors (at this stage you could use 
RTKNAVI on the processing PC if you were using receptors supported by 
RTKLIB (http://www.rtklib.com/rtklib_releasenote.htm), and configure its 
inputs to directly connect to the distant stream/streams and/or the 
local serial data). To use Spider, on the processing PC you should use 
the same tool (STRSVR) and configure a tcp client as input (for each 
distant stream) connected to the IP of the distant tcp server and to the 
same port selected on the previous stage. At that time, you should have 
all the streams available on one PC, but now depends on Spider how it 
get its inputs. 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). 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"

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. The .POS file generated will provide you the option 
to review the "ground track" of your distant receptor and many more 
graphs of it's position variation over time, acceleration, velocity, 
etc. on RTKPLOT. All the options and configuration for RTKPOST and 
RTKPLOT are described and exemplified on RTKLIB manual.

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.

Best regards,

Mauro Ugarte A.
Ingeniero Electrónico
División de Tecnologías de Teledetección
Centro de Óptica y Fotónica
Universidad de Concepción
F/Fax: 2204740 | mauro.ugarte at cefop.udec.cl

On 26/10/11 08:29, Antonio Pestana wrote:
> Dear Thomas:
>
>> Who is the manufacturer of your GPS equipment that you used to collect the
>> Rinex data?
> AS10 antennas, GMX 902 GNSS  receptors and software GNSS Spider, everything
> from Leica. I want do the tests in real-world situations, and I already have
> one that set that spans for two months at 20 MHz, almost without
> interruptions.
>
>> Please define ‘very demanding’ in terms of horizontal and vertical
>> accuracy requirements
> We want to test GNSS near real-time positioning techniques in the monitoring
> of large structures (mainly bridges and tall buildings). Better than 1 cm is
> mandatory; better than 0.5 cm is what I would like to get. Our baselines are
> not long: usually less than 2 km. We want near real-time (real-time with a
> constant, and small, time delay) because we want to plot the behavior of the
> structures under dynamic loads.
>
>> RTK by it’s very nature does not utilize a intermediate PC.
> The GMX 902 receptors are just dummy receptors: they don't have processing
> capacity apart from the one that is needed to get the code and phase
> observations. So we need PC's to do the configuration of the receptors
> (elevation mask, rate of observations, etc.), defining the data to be logged
> if any (and the formats to use) end do the positioning computations. In my
> setup I used a PC for each receptor. I could not do the displacement
> analysis in real-time using Spider because I could not connect both rover
> and reference to the same PC running Spider. That's why I decided to store
> the observations (rover and reference) in RINEX files. No I want do process
> these files as if they were being collected just now.
>
>> The rover applies a correcting factor that was developed by the base and
>> broadcast in some fashion.
> I am aware of these techniques mostly used in large-area RTK network for GIS
> and Surveying. The  observations made by the reference stations belonging to
> the network are used to build model of the errors for all the area of the
> network. Then there are two main "ways of doing the things": a) the rover
> sends is approximate position to the network and the network returns to the
> rover the corrections computed for the position of the rover; b) the network
> sends to the rover the parameters of the error model and the rover computes
> the actual values to his position.
>
> Given that my baselines are small I think that in my case the best approach
> is to use plain-old double-differences. As you stated the use of
> ionospheric-free combination of observations may prove to be disadvantageous
> (theoretically these linear combinations have the potential to increase the
> noise): clearly this is one aspect that needs to be tested. But I need to
> get one position for epoch, that is to say, I want to get positions at a 20
> MHz rate.
>
>
>> To answer your question, the processing software that come with your GPS
>> units should be able to do the work depending on the features that were
>> licensed with it
> Yes, Spider could to the job. But as I have already written it needs to be
> connected to the two receivers at the same time. This connection proved to
> be impossible in site.
>
> Regards
>
> Antonio
>
>
>
>
> --
> View this message in context: http://open-source-gps-related-discussion-and-support.1099874.n2.nabble.com/Post-processing-RINEX-to-simulate-RTK-tp6926010p6932334.html
> Sent from the Open Source GPS-related discussion and support mailing list archive at Nabble.com.
> _______________________________________________
> This message is sent to you from FOSS-GPS at lists.osgeo.org 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
>