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 | [email protected]
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 [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
_______________________________________________
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
