add Algotithms time and coordinate

STA8100_firmware.rst

@@ -0,0 +1,50 @@
+STA8100 firmware loader and upgrade with the Teseo-Suite
+========================================================
+
+- The Teseo-Suite should be installed first.
+- Get Teseo-Suite Pro v6.2.3 tool from the website: https://www.st.com
+
+Run Teseo-Suit and get a license to active the tool. 
+Select menu Help>Activate Teseo-Suit Pro>Rquest full version and send email to ST. 
+You can get a license from ST and Activate the Teseo-Suite.
+
+Push the “Boot Mode Switch” side, and connect USB Cable to PC.
+Select menu Tools > T5 X-Loader and run.
+
+T5-X-loader Teseo allows to load boot & firmware. Configuration as below.
+
+* **Port Settings:** 
+
+  * **Port**: define UART port number. The fourth serial port of your OpenRTK330_EVB.
+  * **Loader baud rate**: define programming baud rate 115200. 
+
+
+* **Option:**
+
+  * **Erase NVM**: erase settings of Teseo.
+  * **Restore default product**: erase settings of Teseo.
+  * **Variant**: Cut2.
+
+
+* **Memory:** Choose SQI.
+
+  * **Binary**: Press Binary button to browse your binary file.
+    **START** initiates programming. **STOP** cancels programming sequence.
+
+  * **Erase only**: erase firmware area.
+  * **Program only**: load firmware without perform erase (only available if flash is previously erased).
+  * **Destination**: Start address of firmware. Modify memory type to get default one.
+  * **Entry point offset**: Start address to run program.
+  * **GPIO Reset**: Generate a glitch with a period of “Timing” on DTR or RTS. Helpful, in case of recovery procedure.
+  * **Dump memory**
+
+    * **Address**: location of first byte to read.
+    * **Size**: **size** of memory to read from 'address'.
+  * **Set memory**
+
+    * **Address**: location of interger to write.
+    * **Data**: value of integer to write.
+
+When you configurate all the item above, you can click the “Start” to burn the bootloader and firmware. 
+
+The follow figures show the bootloader and firmware burning process.

algorithms.rst

@@ -36,8 +36,8 @@ another, as follows:
     :maxdepth: 3
     :hidden:
 
-    algorithms/CoordFrames
-    algorithms/AttitudeParameters
+    algorithms/TimeSystem
+    algorithms/CoordinatesSystem
     algorithms/Sensors
     algorithms/KalmanFilter
     algorithms/StateTransitionModels

algorithms/CoordinatesSystem.rst

@@ -0,0 +1,98 @@
+Coordinates System
+==================
+
+The receiver or satellite positions in RTKLIB are internally represented as the X, Y, Z 
+components in an ECEF (earth center earth fixed) coordinates system. What ECEF frame used 
+is not explicitly defined but depends on the satellite ephemeris and the predefined 
+base station position. For example, with GPS signals and navigation data, the single point positioning 
+results are obtained in WGS84. The baseline analysis with the base station with the position 
+in an ECEF frame basically brings the rover position in the same ECEF frame. Practically, 
+all of usually used ECEF frames in GNSS navigation processing like WGS 84, PZ90.02 and ITRF, 
+are identical within the accuracy of broadcast ephemeris or single point positioning. However, 
+more strict and careful handling of the coordinates system is needed for the baseline analysis or PPP. 
+The unified coordinates system is desirable to minimize the processing error in these cases. 
+
+Transformation from geodetic position to ECEF XYZ position
+----------------------------------------------------------
+
+The geodetic position are defined based on a reference ellipsoid. The geodetic latitude :math:`\phi_r`, 
+longitude :math:`\lambda_r` and the ellipsoidal height :math:`h` can be transformed to ECEF XYZ position
+:math:`{\pmb r}_r = {(x,y,z)^T}` as follows:
+
+.. math::
+  
+ e^2 = f(2-f)
+
+ v = \frac{a}{\sqrt{(1-{e}^{2}sin{\phi_r}^2)}}
+
+ r_r=\begin{pmatrix}
+ {(v + h)cos\phi_{r}cos\lambda_r}\\ 
+ {(v+h)cos\phi_{r}sin\lambda_r}\\
+ {v(1 - e^2)sin\phi_r}
+ \end{pmatrix}
+
+where:
+
+   :math:`a`: major radius of the earth reference ellipsoid (m)
+
+   :math:`f`: flattening of the earth reference ellipsoid
+
+OpenRTK uses the following values for a and f of the reference ellipsoid provided by the WGS84 datum.
+
+   :math:`a` = 6378137.0 (m)
+
+   :math:`f` = 1.0/298.257223563
+
+.. image:: media/ReferenceEllipsoid.png
+    :scale: 50%
+    :align: center
+
+
+Transformation from ECEF XYZ position to geodetic position
+----------------------------------------------------------
+
+To transform the XYZ position :math:`{\pmb r}_r = {(x,y,z)^T}` in ECEF to the geodetic position, 
+the following procedure is applied. The geodetic latitude is derived by an iterative method in the procedure. 
+
+.. math::
+
+  r = \sqrt {x^2 + y^2}
+
+  \phi_{r,0} = 0
+
+  \phi_{r,i+1} = arctan(\frac{z}{r} - \frac{ae^2tan\phi_{r,i}}{r\sqrt{1 + (1 - e^2){tan}^2\phi_{r,i}}})
+
+  \phi_r = \lim_{i \to \infty}\phi_{r,i}
+
+  \lambda = ATANA(y,x)
+
+  h = \frac{r}{cos\phi_r} - \frac{a}{\sqrt{(1-e^2){sin}^2\phi_r}}
+
+
+Azimuth and elevation angles of satellite direction
+---------------------------------------------------
+
+The unit LOS (line‐of‐sight) vector from the receiver to the satellite 
+can be expressed in the ECEF coordinates as: 
+
+.. math::
+
+  {\pmb e}^s_r = \frac{{\pmb r}^s(t^s)-{\pmb r}_r(t_r)}{\left \| {\pmb r}^s(t^s)-{\pmb r}_r(t_r) \right \|}
+
+In the equation, the earth rotation effect is neglected. The azimuth and elevation 
+angles :math:`Az_r^s` and :math:`El_r^s` of the satellite direction from the receiver 
+site can be derived from: 
+
+.. math::
+
+  {\pmb e}_{r,enu}^s = {\pmb E}_r{\pmb e}_r^s = {(e_e,e_n,e_u)}^T
+
+  Az_r^s = ATAN2(e_e,e_n)
+
+  El_r^s = arcsin(e_u)
+
+where :math:`\pmb E_r` is the coordinates rotation matrix from ECEF to the local coordinates at the receiver position.
+
+.. image:: media/Azimuth.png
+    :scale: 50%
+    :align: center

algorithms/TimeSystem.rst

@@ -0,0 +1,88 @@
+Time System
+===========
+
+OpenRTK internally uses GPST (GPS Time) for GNSS data handling and positioning algorithms. 
+The time of input data expressed in other time systems like UTC  (Universal Time Coordinated) 
+is converted to GPST before internal processing or the GPST of the internal data is converted 
+to the appropriate other time system before output. One of the reasons why using GPST is to avoid 
+leap seconds handling. UTC, which is the most generally used time system, is not a continuous 
+time system with a second jump by the leap second insertion or deletion. 
+
+The GPST is often expressed as a GPS week number and TOW (time of week) in seconds 
+since the start epoch of 00:00:00 UTC on January 6, 1980. RTKLIB, however, does not 
+use such a convention. In GNSS data processing, we often need to convert a time to 
+a range or a range to a time. The TOW even expressed as a double precision has only the 
+resolution of :math:`1.3 \times 10^{-10}` s in time, which is equivalent to the resolution of 0.04 m in range.
+
+GPS Time and Universal Time Coordinated
+---------------------------------------
+
+The rough conversion of GPST to UTC (Universal Time Coordinated) or UTC to GPST can be 
+expressed simply as:
+
+.. math::
+
+  t_{UTC} = t_{GPS} - \Delta t_{LS}
+
+  t_{GPS} = t_{UTC} + \Delta t_{LS}
+
+
+where :math:`t_{UTC}` and :math:`t_{GPS}` are the time expressed in UTC (s) and the time in GPST (s). 
+:math:`\Delta t_{LS}` is the delta time (s) between UTC and GPST due to the cumulative leap seconds since January 6, 1980. 
+
+The accuracy of the approximation in formula above is within several 10 ns. By using the UTC parameters in GPS navigation messages, 
+we can convert GPST to UTC or UTC to GPST more accurately as:
+
+.. math::
+
+  t_{UTC} = t_{GPS} - {\Delta t_{LS} + A_0 + A_1(t_E - t_{ot} + 604800(WN - WN_t))}
+
+where :math:`A_0, A_1, t_E, t_{ot}, WN are WN_t` are the UTC parameters provided in GPS navigation messages. 
+More strictly, UTC in formula above is UTC(USNO), which is the US local implementation of UTC. 
+The difference between UTC and UTC(USNO) can be obtained in Circular T provided by BIPM [72]. 
+The difference is usually several ns level. 
+
+
+GLONASS Time
+------------
+
+GLONASST (GLONASS Time) is based on UTC(SU) and includes leap second insertion or deletion. 
+GLONASST is also aligned to the local time. So, roughly, the time :math:`t_{GLONASS}` (s) in GLONASST 
+can be converted to the time :math:`t_{UTC}` (s) in UTC.
+
+.. math::
+
+  t_{UTC} = t_{GLONASS} - 10800
+
+More accurately, the UTC parameters for GLONASST in GLONASS navigation message should be 
+used similar to the GPST and UTC conversion. Ignoring the leap seconds and the 3 hour offset, 
+the difference between GPST and GLONASST is usually 100 or several 100 ns level. 
+
+Galileo Time
+------------
+
+GST (Galileo System Time) is composed of week number from the origin of the Galileo time 
+and the TOW (time of week) in seconds. The GST start epoch is 00:00:00 UTC on August 22, 
+1999. At the start epoch, GST shall be ahead of UTC by 13 seconds. The GST is continuous 
+time without leap second insertion or deletion. So, the GST is aligned to GPST except for 
+the 1024 weeks difference of the time system origin and a small time offset (GGTO). Note that 
+the Galileo week number is provided as equal to the GPS week number in the RINEX convention. 
+
+BDS Time
+--------
+
+BDT (BeiDou Navigation Satellite System Time) is a continuous time system without 
+leap second insertion or deletion. The start epoch of BDT is 00:00:00 UTC on 
+January 1, 2006. The offset of BDT with respect to UTC is controlled within 100 ns 
+(modulo 1 second). So, the time :math:`t_{GPS}` (s) in GPST can roughly be converted to the 
+time :math:`t_{BDT}` (s) in BDT within the accuracy of 200 ns as: 
+
+.. math::
+
+  t_{BDT} = t_{GPST} - 14
+
+More accurately, the UTC parameters for BDT in BeiDou navigation messages 
+should be used similar to the GPST and UTC conversion. 
+
+
+

useOpenRTK.rst

@@ -4,7 +4,10 @@ How to use OpenRTK?
 The OpenRTK module acts as a NTRIP client fetching GNSS corrections data
 from a NTRIP server of a GNSS correction service provider. This connectivity
 requires the OpenRTK module sending out its current position via NMEA GGA 
-every one second to the NTRIP server over the internet.
+every one second to the NTRIP server over the internet. The relevant configuration of
+data transmission depends on the moblie APP/PC platform. In addition, OpenRTK (includes 
+moblie APP and PC platform) can show trajectory in map.
+
 
 **Mobile** is OpenRTK Android APP, **PC** is OpenRTK platform.
 

useOpenRTK/APP.rst

@@ -1,9 +1,8 @@
 Mobile
 ======
 
-OpenRTK works for Aceinna OpenRTK app. APP get RTCM/NMEA data
-via Bluetooth from RTK device, and then send to Aceinna server on Internet,
-calculation results to be sent to the device. The RTK device will calibrate according to the data.
+Aceinna OpenRTK app connects to OpenRTK module and server with Bluetooth and Internet, respectively, 
+to configure parameters during data transmission. Finally, APP shows trajectory in map
 
 .. image:: ../media/Mobile_APP.png
 
@@ -69,6 +68,8 @@ Configuration
 
      - RTK: get NEMA(GPGGA) from device,get RTCM from Aceinna server. 
      - cloudRTK: get RTCM from device, get NEMA(GPGGA) from Aceinna server. 
+
+   For more details, please refer to `RTK/Cloud RTK <https://openrtk.readthedocs.io/en/latest/Network/rtk_cloudrtk.html>`__.
   - *Use Local Service*:
 
      - ON: you can use other service, and you need input its URL and Port.

useOpenRTK/PC.rst

@@ -1,11 +1,18 @@
 PC
 ===
 
-OpenRTK acts as NTRIP client connects with NTRIP server to fetch
-RTCM/NMEA data from ethernet in RTK, and then send to Aceinna server,
-after the calculation of the server, the data is returned, and then
-written to the device. The RTK device will calibrate according to the
-data.
+.. OpenRTK platform acts as NTRIP client
+   connects with NTRIP server to gets/sends RTCM/NMEA data via ethernet. For more
+   details, please refer to RTK/Cloud RTK.
+
+OpenRTK PC platform acts as an auxiliary tool, connected to the OpenRTK module via USB to 
+configure parameters during data transmission. Finally display trajectory in map.
+
+.. OpenRTK acts as NTRIP client connects with NTRIP server to fetch
+   RTCM/NMEA data from ethernet in RTK, and then send to Aceinna server,
+   after the calculation of the server, the data is returned, and then
+   written to the device. The RTK device will calibrate according to the
+   data.
 
 .. image:: ../media/PC_tool.png