Changeset 5623 in ntrip for trunk

Timestamp:

Jan 22, 2014, 4:15:39 PM (11 years ago)

Author:

mervart

Message:

 

Location:

trunk/BNC/txt

Files:

• 100A_lat.png (added)
• 101A_lat.png (added)
• 102A_lat.png (added)
• 104A_lat.png (added)
• age1.png (added)
• age2.png (added)
• frankfurt.tex (modified) (2 diffs)
• kir0.png (added)
• monitor1.png (added)
• nrcan.png (added)
• rtnet_pod.png (added)

trunk/BNC/txt/frankfurt.tex

@@ -509 +509 @@
 
 \begin{frame}
+  \frametitle{Combination using Kalman filtering}
+  The combination is performed in two steps
+  \begin{itemize}
+  \item[1.] The satellite clock corrections that refer to different broadcast
+    messages (different IODs) are modified in such a way that they all refer
+    to common broadcast clock value (common IOD is that of the selected
+    ``master'' analysis center).
+  \item[2.] The corrections are used as pseudo-observations for Kalman filter
+    using the following model (observation equation):
+    \begin{displaymath}
+    c_a^s = c^s + o_a + o_a^s
+    \end{displaymath}
+    where
+    \begin{tabbing}
+    $c_a^s$ ~~ \= is the clock correction for satellite s estimated by \\
+               \> the analysis center a, \\
+    $c^s$      \> is the resulting (combined) clock correction for 
+                  satellite s, \\
+    $o_a$      \> is the AC-specific offset 
+                  (common for all satellites), and \\
+    $o_a^s$      \> is the satellite and AC-specific offset.
+    \end{tabbing}
+  \end{itemize}
+  The three types of unknown parameters $c^s$, $o_a$, $o_a^s$ differ in their
+  stochastic properties: the parameters $c^s$ and $o_a$ are considered to be
+  epoch-specific while the satellite and AC-specific offset $o_a^s$ is assumed
+  to be a static parameter.
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
 \frametitle{PPP -- Server-Side}
   \begin{center}
@@ -562 +594 @@
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
-\section{PPP AR}
-\subsection{Principles}
-
-\begin{frame}
-\frametitle{Principles of PPP with Ambiguity Resolution}
-\framesubtitle{Observation Equations}
-
-The PPPAR is in principle based on the processing the following two types of single-difference
-observations: \\
-The ionosphere-free linear combination
-\be\label{obs_IF}
-L^{ij}_3 = \varrho^{ij} - c\delta^{ij} + T^{ij} + \bar{N}^{ij}_3 ~,
-\ee 
-where the ambiguity term is given by
-\be\label{amb_N3}
-\bar{N}^{ij}_3 =  N^{ij}_3 - l^{ij}_3 
-              = \frac{c\;f_2}{f^2_1-f^2_2}\;(n^{ij}_1-n^{ij}_2) + \lambda_3\;n^{ij}_1 - l^{ij}_3 
-\ee
-and the Melbourne-W\"{u}bbena linear combination
-\be\label{obs_MW}
-L^{ij}_w = \lambda_5\;n^{ij}_5 - l^{ij}_w
-\ee
-the uncalibrated bias $l^{ij}_3$ is the corresponding linear combination of biases
-$l^{ij}_1,l^{ij}_2$, the uncalibrated bias $l^{ij}_w$ is the corresponding linear combination of
-biases $p^{ij}_1,p^{ij}_2,l^{ij}_1,l^{ij}_2$.
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\subsection{Parameters provided by Server}
-
-\begin{frame}
-\frametitle{Principles of PPP with Ambiguity Resolution}
-\framesubtitle{Parameters provided by Server}
-In addition to orbit corrections, the server(s) has(have) to provide the values
-\bdm
-c\delta^{ij} ~,~  l^{ij}_w ~,~ l^{ij}_3 ~~~ \mb{or} ~~~~ (c\delta^{ij} + l^{ij}_3) ~,~ l^{ij}_w
-\edm
-Corrections $l^{ij}_w,l^{ij}_3$ depend on the set of fixed single-difference ambiguities on the
-server-side. This set of fixed ambiguities is not unique - it depends on the constraints applied on
-the ambiguities. 
-
-There is a difference between correction $l^{ij}_w$ and the narrow-lane correction $l^{ij}_3$. The
-wide-lane correction $l^{ij}_w$ depends {\em only} on the ambiguities estimated at the
-server-side. The narrow-lane correction $l^{ij}_3$ depends on the ambiguities and {\em also} on the
-satellite clock corrections $\delta^{ij}$ estimated at the server-side.
-
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{Principles of PPP with Ambiguity Resolution}
-\framesubtitle{How many servers?}
-All three corrections
-\bdm
-c\delta^{ij} ~~~  l^{ij}_w ~~~ l^{ij}_3
-\edm
-may be estimated together by a single server run (in which case the $c\delta^{ij}$ and $l^{ij}_3$
-are indistinguishable and are combined into $c\delta^{ij}+l^{ij}_3$) Or, each of them may be
-estimated by a separate server run.
-
-\vspace*{2mm}
-Current approach:
-\begin{itemize}
-\item PPPNB server: estimates $c\delta^{ij}$
-\item PPPAR server: uses $c\delta^{ij}$ from PPPNB server and estimates $l^{ij}_w,l^{ij}_3$
-\end{itemize}
-
-\vspace*{2mm}
-Advantages: PPPAR corrections are compatible with PPPNB corrections (the client may decide between
-PPP and PPPAR).
-
-\vspace*{2mm}
-Disadvantages: additional delay
-
-\vspace*{2mm}
-An alternative approach to consider: separate server run for $l^{ij}_w$.
-
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{Principles of PPP with Ambiguity Resolution}
-\framesubtitle{How to disseminate the corrections?}
-
-\begin{enumerate}
-\item The corrections are valid (accurate) on the single- (between satellites) difference
-  level but it is more practical to send the zero-difference (satellite-specific) corrections.
-\item The corrections are specific for the observation types used for their estimation - e.g. if
-  the C/A code on the first carrier and the P-code on the second carrier have been used at the
-  server side, the client can use the $l^{ij}_w$ correction only if it uses the same two types of
-  code observations.
-\end{enumerate}
-
-The corrections $l^{ij}_w,l^{ij}_3$ are actually the combinations of the phase (and in case of
-$l^{ij}_w$ also code) biases:
-\begin{eqnarray*}
-l^{ij}_w & = & \frac{1}{f_1-f_2} \bigl( f_1~l^{ij}_1 - f_2~l^{ij}_2 \bigr) -
-  \frac{1}{f_1+f_2} \bigl( f_1~p^{ij}_1 + f_2~p^{ij}_2 \bigr) ~
-\\
-l^{ij}_3 & = & \frac{1}{f^2_1-f^2_2} \bigl( f^2_1~l^{ij}_1 - f^2_2~l^{ij}_2 \bigr)
-\end{eqnarray*}
-RTCM suggests to send $p^{ij}_1,p^{ij}_2,l^{ij}_1,l^{ij}_2$ directly ...
-
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{Principles of PPP with Ambiguity Resolution}
-\framesubtitle{How to disseminate the corrections (continuation)?}
-
-In principle there are altogether 5 values which can be sent by server(s):
-\bdm
-c\delta^{ij},p^{ij}_1,p^{ij}_2,l^{ij}_1,l^{ij}_2
-\edm
-PPPNB server estimates the $c\delta^{ij}$ and the ionosphere-free
-linear combination of the code biases
-\bdm
-p^{ij}_3 =  \frac{1}{f^2_1-f^2_2} \bigl( f^2_1~p^{ij}_1 - f^2_2~p^{ij}_2 \bigr)
-\edm
-PPPAR server estimates the $l^{ij}_w$ and $l^{ij}_3$. Assuming that we know the differential code
-bias
-\bdm
-d^{ij}_{p1p2} = p^{ij}_1 - p^{ij}_2
-\edm
-The four values
-\bdm
-p^{ij}_3 ~~~ l^{ij}_w ~~~~ l^{ij}_3 ~~~~ d^{ij}_{p1p2}
-\edm
-can be converted into four biases
-$p^{ij}_1,p^{ij}_2,l^{ij}_1,l^{ij}_2$. 
-
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-  \frametitle{Precise Point Positioning with PPP (cont.)}
-  BNC provides a good framework for the PPP client (observations, orbits, and
-  corrections stand for disposal). 
-
-  Main reasons for the PPP module in BNC have been:
-  \begin{itemize}
-  \item monitoring the quality of incoming data streams (primarily the PPP
-    corrections) 
-  \item providing a simple easy-to-use tool for the basic PPP positioning 
-  \end{itemize}
-
-  The PPP facility in BNC is provided in the hope that it will be useful.
-  \begin{itemize}
-  \item The mathematical model of observations and the adjustment algorithm are
-    implemented in such a way that they are (according to our best knowledge)
-    correct without any shortcomings, however,
-  \item we have preferred simplicity to transcendence, and
-  \item the list of options the BNC users can select is limited.
-  \item[$\Rightarrow$] Commercial PPP clients may outperform BNC in some
-    aspects.
-  \end{itemize}
-  We believe in a possible good coexistence of the commercial software and
-  open source software.
-\end {frame}
+\begin{frame}
+  \frametitle{Principle of our PPP-RTK Algorithm}
+  For a dual-band GPS receiver, the observation equations may read as
+  \begin{eqnarray*}
+  P^i & = & \varrho^i + c\;\delta - c\;\delta^i + T^i + b_P              \\
+  L^i & = & \varrho^i + c\;\delta - c\;\delta^i + T^i + b^i
+  \end{eqnarray*}
+  where
+  \begin{tabbing}
+  $P^i$, $L^i$ ~~~~~~~ \= are the ionosphere-free code and phase measurements, \\ 
+  $\varrho^i$          \> is the travel distance between the satellite 
+                          and the receiver,                               \\
+  $\delta$, $\delta^i$ \> are the receiver and satellite clock errors,    \\
+  $T^i$                \> is the tropospheric delay,                      \\
+  $b_P$                \> is the code bias, and                           \\
+  $b^i$                \> is the phase bias (including initial
+                          phase ambiguity).
+  \end{tabbing}
+  The single-difference bias $b^{ij} = b^i - b^j$ is given by
+  \begin{displaymath}
+  b^{ij} = \displaystyle\frac{\lambda_5-\lambda_3}{2}\;(n_5^{ij} + b_5^{ij})
+              + \lambda_3\;(n_1^{ij} + b_1^{ij}) 
+  \end{displaymath}
+   where
+  \begin{tabbing}
+  $n_1^{ij}$, $n_5^{ij}$ ~~~~ \= are the narrow-lane and wide-lane integer ambiguities \\
+  $b_1^{ij}$                 \> is the narrow-lane (receiver-independent) SD bias \\
+  $b_5^{ij}$                 \> is the wide-lane (receiver-independent) SD bias
+  \end{tabbing}
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+  \frametitle{Principle of our PPP-RTK Algorithm (cont.)}
+  Receiver-independent single-difference biases $b_1^{ij}$ and $b_5^{ij}$ have 
+  to be estimated on the server-side.
+  \begin{itemize}
+  \item Narrow-lane bias $b_1^{ij}$ may be combined with satellite clock
+    corrections $\Longrightarrow$ \textbf{modified satellite clock corrections.}
+  \item Wide-lane bias have to be transmitted from the server to the client
+    (this bias is stable in time and can thus be transmitted in lower rate).
+  \end{itemize}
+
+  On the client-side the biases $b_1^{ij}$ and $b_5^{ij}$ are used as known
+  quantities. It allows fixing the integer ambiguities $n_5^{ij}$ and
+  $n_1^{ij}$. The technique is called Precise Point Positioning with Ambiguity
+  Resolution (PPP~AR) or PPP~RTK, or zero-difference ambiguity
+  fixing (the latter term not fully correct because the ambiguities are
+  actually being fixed on single-difference level).
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+  \frametitle{Performance}
+  \begin{center}
+    \includegraphics[width=0.75\textwidth]{kir0.png}
+  \end{center}
+  \vspace*{-5mm}
+  \begin{block}{Standard deviations (N,E,U)}
+  \vspace*{3mm}
+  \begin{small}
+  \hspace*{2cm}
+  \begin{tabular}{l|ccc|ccc}
+  \mbox{} & \multicolumn{3}{c|}{10-60 min} & \multicolumn{3}{c}{30-60 min} \\
+  float & 0.034 & 0.026 & 0.026         & 0.010 & 0.009 & 0.011  \\
+  fix   & 0.007 & 0.003 & 0.016         & 0.007 & 0.003 & 0.012
+  \end{tabular}
+  \end{small}
+  \end{block}
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+  \frametitle{Challenges}
+  PPP~RTK works and provides mm-accuracy results, what is this symposium
+  about?
+
+  \pause
+  There are still both principal and technical problems and challenges:
+  \begin{itemize}
+  \item Principal problems:
+    \begin{itemize}
+    \item Convergence time: PPP~RTK in the form outlined above provides
+      accuracy similar (or even slightly better) to RTK but the convergence
+      time is longer.
+    \item There is a degradation in accuracy with the age of corrections.
+    \item Glonass ambiguity resolution: is it possible to resolve Glonass
+      ambiguities? (yes, it is possible but it implicates introducing new
+      parameters - does it really improve the results?)
+    \item ...
+    \end{itemize}
+  \item Technical problems:
+    \begin{itemize}
+    \item Availability of data in real time (reference network, high-precision
+          satellite orbits).
+    \item Very high CPU requirements on the server-side.
+    \item Solution robustness on the server-side 
+          (problems with reliable DD ambiguity resolution). 
+    \item ...
+    \end{itemize}
+  \end{itemize}
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+  \frametitle{Challenges (cont.)}
+  \begin{block}{Longer convergence time}
+  In case of a standard RTK the very short convergence time is being achieved
+  thanks to the combined DD ambiguity resolution on both $L_1$ and $L_2$ when
+  the differential ionospheric bias can either be neglected (short baselines)
+  or its influence is mitigated (stochastic ionosphere estimation with
+  constraints).
+
+  On the contrary, the outlined PPP~RTK algorithm is in principle based on
+  processing single (ionosphere-free) linear combination and resolving only
+  one set of (narrow-lane) initial phase ambiguities.
+  \end{block}
+  \begin{block}{Possible solutions}
+  \begin{itemize}
+  \item third carrier
+  \item multiple GNSS (Glonass ambiguity resolution?)
+  \item processing original carriers (instead of ionosphere-free linear
+    combination) and modeling the ionosphere?
+  \item ?
+  \end{itemize}
+  \end{block}
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+  \frametitle{Challenges (cont.)}
+  \begin{block}{Age of corrections 0 s}
+  \begin{center}
+    \includegraphics[width=0.6\textwidth]{age1.png}
+  \end{center}
+  \end{block}
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+  \frametitle{Challenges (cont.)}
+  \begin{block}{Age of corrections up to 35 s}
+  \begin{center}
+    \includegraphics[width=0.6\textwidth]{age2.png}
+  \end{center}
+  \end{block}
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+  \frametitle{Real-Time Data Availability}
+  \framesubtitle{IGS network: very good global coverage:}
+  \vspace*{-5.5cm}
+  \begin{center}
+    \includegraphics[width=0.9\textwidth]{map.pdf}
+  \end{center}
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+  \frametitle{Real-Time Data Availability (cont.)}
+  \begin{tabular}{cc}
+  \includegraphics[width=0.4\textwidth]{100A_lat.png} &
+  \includegraphics[width=0.4\textwidth]{101A_lat.png} \\
+  \includegraphics[width=0.4\textwidth]{102A_lat.png} &
+  \includegraphics[width=0.4\textwidth]{104A_lat.png}
+  \end{tabular}
+
+  Gaps in reference network data may degrade the PPP~RTK server performance
+  considerably!
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+  \frametitle{Technical issues}
+  \begin{block}{CPU-requirements on the server-side}
+  Processing a global reference network is a very CPU-intensive
+  task. Numerically stable forms of the Kalman filter (square-root, UDU
+  factorization etc.) require very fast hardware. 
+
+  Possible solutions:
+  \begin{itemize}
+  \item Processing optimization (estimating various kinds of parameters in 
+        different rates)
+  \item Parallel processing 
+  \item Advanced hardware (GPS Solutions uses GPU-accelerated library)
+  \end{itemize}
+  \end{block}
+  \begin{block}{Reliable DD ambiguity resolution on the server-side}
+  Reliable double-difference ambiguity resolution on the server-side remains
+  the crucial issue of the PPP~RTK technique.
+  \end{block}
+  \begin{block}{Dissemination of PPP~RTK corrections}
+  \begin{itemize}
+  \item data links
+  \item formats (standardization?)
+  \item optimization of correction rates (bandwidth)
+  \end{itemize}
+  \end{block}
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+  \frametitle{Satellite orbits}
+
+  Predicted part of the IGS ultra-rapid orbits (available in real-time) is
+  sometimes not sufficient for the processing of a global reference network
+  (with narrow-lane ambiguity resolution). We have been forced to implement
+  the real-time orbit determination capability in our main processing tool
+  RTNet (Real-Time Network software).
+  \begin{center}
+    \includegraphics[width=0.75\textwidth]{rtnet_pod.png}
+  \end{center}
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+  \frametitle{Regional versus global PPP~RTK services} 
+  Currently we are routinely running both regional and global PPP~RTK service
+  demonstrators in real-time (some of the results will be shown below).
+  \begin{itemize}
+  \item in principal there is no difference between a global and regional
+    service as far as the data processing, algorithms etc. is concerned
+  \item global PPP~RTK service has at least the following two advantages
+     \begin{itemize}
+     \item[1.] a single correction stream can serve all users
+     \item[2.] all satellites are tracked permanently (helps ambiguity 
+               resolution)
+     \end{itemize}
+  \item global PPP~RTK service is much more challenging (data availability,
+    CPU-requirements on the server-side, DD ambiguity resolution on long
+    baselines, the highest requirements for the accuracy of the satellite
+    orbits)
+  \end{itemize}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+  \frametitle{Services monitoring} 
+  Reliable, production-quality PPP~RTK service requires sophisticated
+  monitoring tools.
+  \begin{tabular}{cc}
+  \includegraphics[width=0.6\textwidth]{monitor1.png} & \\[-1.5cm]
+  & \hspace*{-3cm} \includegraphics[width=0.6\textwidth]{monitor2.png}
+  \end{tabular}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+  \frametitle{Results}
+  \begin{center}
+    \includegraphics[width=0.9\textwidth]{tsunami.pdf}
+  \end{center}
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+  \frametitle{Results (cont.)}
+  \begin{center}
+    \includegraphics[width=0.9\textwidth]{nrcan.png}
+  \end{center}
+\end{frame}
+
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%