Documentation updates.

Author: hvandermarel

docs/UbxLogger_GL-iNet_Installation_Guide.md

@@ -66,7 +66,7 @@ The GL-iNet router has three main user interfaces
 
 1. GL-iNet Web Admin Panel (http://192.168.8.1)
 2. OpenWrt LuCI web user interface (http://192.168.8.1/cgi-bin/luci)
-3. SSH to the router BusyBox ash shell ()`ssh root@192.168.8.1`)
+3. SSH to the router BusyBox ash shell (`ssh root@192.168.8.1`)
 
 The first is a Grafical User Interface (GUI) for standard settings
 and firmware upgrades. The second is a GUI to do more advanced settings with `OpenWrt LuCI`. Many
@@ -77,6 +77,11 @@ which will be used for setting up regular Linux stuff and `UbxLogger`.
 
 Plug-ins can be installed from the `GL-iNet Web Admin Panel -> Applications -> Plug-ins`,
 or from `OpenWrt LuCI -> System -> Software`, or from the CLI using  the `oplg` package manager.
+At this time it is a good idea to update the package list and install `usbutils` (for the `lsusb` 
+command)
+
+> opkg update\
+> opkg install usbutils
 
 A few plugins need to be installed to be able to use MicroSD card storage and to install some
 prerequisites for `UbxLogger`.These are described in the next section
@@ -104,10 +109,9 @@ Next, in `OpenWrt LuCI -> System -> Mount points`, in the section on `Moint Poin
 select the device, click on the `Edit` button, and enter as mount point `/mnt/sda1`,
 and click on `Save`. Then click on `Save and Apply` to complete the process.
 
-Now you should be able to see the mounted SD card under Mounted file systems and the
+Now you should be able to see the mounted SD card under `Mounted file systems` and the
 SD card is ready to be used. 
 
-
 ## Download and install `UbxLogger` software
 
 To install the `UbxLogger` software download the installation script, run and follow the instructions
@@ -117,7 +121,7 @@ To install the `UbxLogger` software download the installation script, run and fo
 
 The script will guide you step by step through the installation process providing sensible defaults. When the script
 finishes the software and executable are installed on the micro SD card, and the user is provided with some
-guidance on how to preceed with the second part of the installation.
+guidance on how to proceed with the second part of the installation.
 
 The second part of the installation is done by a separate script that is installed along with
 the software. To run the second part of the install
@@ -127,7 +131,7 @@ the software. To run the second part of the install
 
 For other platforms replace *openwrt-mips* with one of the architectures provided in the `ubxdir/sys` folder.
 
-Thi script will create symbolic links to the executable and scripts installed during the first step, install 
+This script will create symbolic links to the executable and scripts installed during the first step, install 
 necessary packages, enable crontab and add a service (`cronatreboot`) to resume logging after a reboot. 
 
 The script will provide you with the option to install RTKLIB's `str2str` using an OpenWrt package or 
@@ -183,7 +187,7 @@ To configure `UbxLogger`
    Replace `identifier` with the value(s) that you selected. If you don't plan on logging navigation data - something that we recommend not to do - then you need to enter also the 
    approximate coordinates of the station in the configuration file.   
 
-In this phase of the installation process the software is fully functional and can be started and stopped manually, as is decribed in the [software manual][2]. 
+In this phase of the installation process the software is fully functional and can be started and stopped manually, as is described in the [software manual][2]. 
 
 ## Starting and stopping the software
 
@@ -207,7 +211,7 @@ Crontab on OpenWrt does not support the `@reboot` directive. This directive must
 The `cronatreboot` service that is installed during the second part of the install will use the commented out
 directive to start logging after a (re)boot.
 
-Note that `crontab` works with local time. To have this synchronized with `UTC` make sure that you're local time is set to `UTC`.
+Note that `crontab` works with local time. To have this synchronized with `UTC` set local time to `UTC` or account for the time difference in the crontab (which can be tricky with daylight saving time).
 
 ## Remote connections
 
@@ -218,7 +222,7 @@ To access the router remotely through the 4G LTE interface some additional setup
 ### GL-iNet GoodCloud
 
 The easiest way to achieve remote connectivity over the 4G or WAN network is via GL-iNet's [GoodCloud](https://www.goodcloud.xyz/#/login) 
-Cloud Management Software. *GoodCloud* uses reverse `ssh` to set up a long lasting connection. The connection is initiated by the 
+Cloud Management Software. *GoodCloud* uses something similar to reverse `ssh` to set up a long lasting connection. The connection is initiated by the 
 router, so as long as the router can connect to the Internet your are okay. No hassle with firewalls, dynamic DNS, etc.
 
 First, enable GoodLife in the admin Web interface on the router. Then, create an account on *GoodCloud*, and bind the device
@@ -230,18 +234,12 @@ GoodCloud is free software with unlimited number of devices. There is a paid ent
 
 ### Dynamic DNS (DDNS)
 
-Dynamics DNS (DDNS) is not needed with GoodCloud. The ip number can be retrieved from the GoodCloud interface. 
-
-However, it is a good idea to setup a dynamic DNS as backup, so that you can use a webbrowser and ssh to access the
-router remotely over the 4G network (except when CG-NAT is used by the telecom provider). If you do this, it is
-a good idea to limit the ip-range with access by setting the appropriate firewall rules.
-
-You also need to enable access from the WAN to ports 80 and 22 . 
+Dynamics DNS (DDNS) is not needed with GoodCloud. The ip number can be retrieved from the GoodCloud interface. However, if you want, setup dynamic DNS as backup, so that you can use a webbrowser and ssh to access the
+router remotely over the 4G network (except when CG-NAT is used by the telecom provider). If you do this, you must set an ip-range with appropriate Firewall rules and enable access from the WAN to ports 80 and 22 . 
 
 ### Firewall settings
 
 No modifications in the firewall settings are needed when *GoodCLoud* is used. 
-
 In case Dynamic DNS (DDNS) is used, or, if the system has a public ip, and ssh and/or web access are enabled, then it will be definitely necessary to add firewall rules to limit access to certain ip-ranges. 
 
 ### Reverse ssh and other cloud platforms
@@ -262,8 +260,8 @@ and stopping the `ubxlogd` deamon and automated conversion and file transfer.
 [2]. H. van der Marel (2024), UbxLogger Software Manual, TU Delft, September 2024.
 
 
-[1]: <UbxLogger_Hardware_manual.md> "H. van der Marel (2024), UbxLogger Hardware Manual, TU Delft, September 2024."
-[2]: <UbxLogger_Software_manual.md> "H. van der Marel (2024), UbxLogger Software Manual, TU Delft, September 2024."
+[1]: <UbxLogger_Hardware_Manual.md> "H. van der Marel (2024), UbxLogger Hardware Manual, TU Delft, September 2024."
+[2]: <UbxLogger_Software_Manual.md> "H. van der Marel (2024), UbxLogger Software Manual, TU Delft, September 2024."
 
 ## Appendices
 

docs/UbxLogger_Hardware_Manual.md

@@ -45,7 +45,7 @@ must first be configured to send raw measurement data to the USB port. We use u-
 the proper COM port.
 2. Open `View->Messages View`, select `UBX-MON-VER` in the left pane, and check that the firmware version is `1.32` or higher. If not, upgrade
 the firmware to version 1.32.
-3. Open `View->Generation 9 Configuration View`, deselect `SBAS` and `QZSS` (unless you really want this data), and send configuration to
+3. Open `View->Generation 9 Configuration View`, deselect `SBAS` and `QZSS` if not needed, and send configuration to
 RAM+BBR+Flash
 4. Open `View->Configuration View`
 
@@ -76,18 +76,18 @@ OpenWrt saves the raw receiver data to the router's MicroSD card, optionally con
 optionally send it to an upstream server using the 4G connection. 
 
 <figure>
-    <img src="20240915_162004.jpg" width="800" 
+    <img src="20240915_162004.jpg" width="600" 
          alt="GL-iNet basic GNSS logger">
-    <figcaption>GL-iNet basic GNSS logger with a single U-blox ZED-F9P.</figcaption>
+    <figcaption><em><small>GL-iNet basic GNSS logger with a single U-blox ZED-F9P.</small></em></figcaption>
 </figure>
 
 \
 With an additional USB hub the router can log data from more than one receiver. 
 
 <figure>
-    <img src="20240915_161440.jpg" width="800" 
+    <img src="20240915_161440.jpg" width="600" 
          alt="GL-iNet dual GNSS logger">
-    <figcaption>GL-iNet dual GNSS logger with two U-blox ZED-F9P's.</figcaption>
+    <figcaption><em><small>GL-iNet dual GNSS logger with two U-blox ZED-F9P's.</small></em></figcaption>
 </figure>
 
 \
@@ -115,10 +115,7 @@ installation manual.
 
 ## Raspberry Pi with Teltonika RUT240 4G router
 
-This setup is now obsolete as the *GL-iNet X750* is our preferred platform because of the
-lower power requirements and ease of installation and use. Some description may be added
-at a later time for historical reasons. We use the hardware setup with Raspberry Pi also as
-a reference benchmark for comparisons.
+This setup on a Raspberry Pi is pretty standard and not further discussed (The *GL-iNet X750* is our preferred platform because of the lower power requirements). 
 
 ## UbxLogger software
 
@@ -147,33 +144,25 @@ upstream server, desktop or laptop using the same scripts.
 
 All data files follow the RINEX3 file naming convention
 
->    SITExxST#_YYYYDDDHHMM_FFU_DDU_MO.{ubx|rnx|crx}[.gz] 
+>    SITE9CHAR_YYYYDDDHHMM_FFU_DDU_MO.{ubx|rnx|crx}[.gz] 
 
 All elements are fixed length and are separated by an underscore “_” except 
 for the file type (`ubx`, `rnx` or `crx`) and optional compression field (`.gz`)
 that use a period “.” as a separator. 
 
-The 9 character station name `SITExxST#` consists of a 4-character site name `SITE` (e.g.
-'ZEGV', 'ROVN', ...), a fixed separator `xx`, and an instrument sub-identifier `ST#`. 
-Note that we cannot use `_` or `-` as separators or in the names, as `_` is reserved for 
+The 9 character station name `SITE9CHAR` consists usually follows the convention `SITEMRCCC` with a 4-character site name `SITE` (e.g.
+'ZEGV', 'ROVN', ...), two decimals `MR` for the monument and receiver number, and the country code `CCC`. 
+However, you can use any naming convention as long as the total length does not exceed 9 characters, and you don't use `_` or `-` in the name, as `_` is reserved for 
 separating fields in the RINEX name, nor can we use `-` as this is very
-awkward for shell scripting. The `xx` sets it also apart from the IGS naming convention.
-
-The instrument identifier `ST#` can basically be anything as long as it is 3 characters, so 
-that the total length of the station name does not exceed 9 characters. A sensible
-naming scheme could be the following: two characters `ST` (for stratum) identifying the 
-foundation depth followed by a number `#` to indicate the location at a site (to cover 
-situations when there are multiple instrument locations at a site). The stratum `ST` can either 
-be *TS* an instrument embeded in the top soil, *DF* for a deeply founded instrument, or *SA*, 
-*SB*, *SC*, etc., to indicate a specific stratum in the soil layers.  
+awkward for shell scripting.     
 
 The software is managed through the `ubxlogd` script. The syntax is
 
 >    ./ubxlogd.sh [start|stop|check|restart|status] 'identifier'\
 >    ./ubxlogd.sh status\
 >    ./ubxlogd -h
 
-The 9 character station name `SITExxST#` is used for `'identifier'`.  
+The 9 character station name `SITE9CHAR` is used for `'identifier'`.  
 
 For more details and other commands see the [UbxLogger Software Manual][1].   
 
@@ -263,9 +252,9 @@ meter is used. For the 5 V circuit a USB 3.0 *AT35 3.7-30V 0-4A* digital Multime
 Both instruments measure instantaneous Voltage (V), Amperes (A) and Power (W) and the consumed energy (Wh) over time. 
 
 <figure>
-    <img src="./20240915_150119.jpg" width="800" 
+    <img src="./20240915_150119.jpg" width="600" 
          alt="GL-iNet dual GNSS logger">
-    <figcaption>Power test measurement setup with GL-iNet dual GNSS logger with two U-blox ZED-F9P's.</figcaption>
+    <figcaption><em><small>Power test measurement setup with GL-iNet dual GNSS logger with two U-blox ZED-F9P's.</small></em></figcaption>
 </figure>
 
 #### GL-iNet X750V with two ZED-F9P receivers

docs/UbxLogger_Software_Manual.md

@@ -73,11 +73,13 @@ The command `./ubxlogd.sh status 'identifier'` only writes to the console. It do
 anything in the log file. It is intended to be used from the command line to inspect the
 status of the deamon. It can be used with and without optional `'identifier'`.
 
-The `'identifier'` is the name of the stream. It typically consists of a four letter sitename, 
-followed by 'xx', and then a three letter instrument code. Two examples are *ZEGVxxTS1* and
-*ZEGVxxDF1*, for a site in Zegveld, one instrument on the top soil (*TS1*) and the other
-deeply founded (*DF1*). The number is used when there are more instrument locations on the
-same site. See also the sections on naming conventions.
+The `'identifier'` is the name of the stream. It is usually the same as the 9 character 
+RINEX-3 station name `SITEMRCCC`, with `SITE` a four letter sitename,  followed by two
+digits `MR` for the monument and receiver number, and country code `CCC`. Other naming
+conventions are also possible, as long as the total length does not exceed 9 characters, 
+and you don't use `_` or `-` in the name, as `_` is reserved for 
+separating fields in the RINEX name, nor can we use `-` as this is very
+awkward for shell scripting. 
 
 The raw ubx data is written to hourly files in the `run/` directory following the RINEX3 naming 
 convention, with `ubx` as file extension (instead of `rnx`) and `'identifier'` as station
@@ -272,6 +274,7 @@ The default directory stucture for `UbxLogger` is
 >        |   |    |- doy
 >        |   |    v
 >        |   v
+>        |- docs
 >        |- log
 >        |- run
 >        |- scripts
@@ -308,22 +311,17 @@ The default directory structure can be changed in the configuration file.
 
 All data files follow the RINEX3 file naming convention
 
->    XXXXMRCCC_R_YYYYDDDHHMM_FFU_DDU_MO.{ubx|rnx|crx}[.gz] \
->    XXXXMRCCC_R_YYYYDDDHHMM_FFU_MN.rnx[.gz] \
->
->    SITExxST#_YYYYDDDHHMM_FFU_DDU_MO.{ubx|rnx|crx}[.gz] 
+>    SITE9CHAR_R_YYYYDDDHHMM_FFU_DDU_MO.{ubx|rnx|crx}[.gz] \
+>    SITE9CHAR_R_YYYYDDDHHMM_FFU_MN.rnx[.gz] \
 
-All elements are fixed length and are separated by an underscore “_” except 
+All elements are fixed length and are separated by an underscore "_" except 
 for the file type (`ubx`, `rnx` or `crx`) and optional compression field (`.gz`)
-that use a period “.” as a separator. The individual elements are:
+that use a period "." as a separator. The individual elements are:
 
-Station/project name `XXXXMRCCC` or `SITExxST#` 
-:   This is a 9 character station or project name. The IGS convention is to use 4 characters 
-    `XXXX`for the site/station, two digits `MR` to indicate the monument respectively receiver number,
+Station/project name `SITE9CHAR` 
+:   This is a 9 character station or project name. The IGS convention is to use `XXXXMRCCC` with 
+    `XXXX` 4 characters for the site/station, two digits `MR` to indicate the monument respectively receiver number,
     and the ISO country code `CCC`, but this is not mandatory for other projects. 
-    For subsidence monitoring and geodetic extensometer applications the following naming 
-    convention for the 9 character station name is proposed,`SITExxST#`, see also the next
-    section.
     This element is also used as `UbxLogger` stream/receiver identifier `'identifier'`. 
 
 Data source `R` 
@@ -355,28 +353,6 @@ Data type and format `{MO|MN}.{ubx|rnx|crx}[.gz]`
 It is standard to archive the files in a layered directory structure `./YYYY/DDD/` with `YYYY`
 the year and `DDD` the day number of the year.
 
-## Station naming convention
-
-For subsidence monitoring and geodetic extensometer applications the following naming convention
-for the 9 character station name, used for the first element in the file name (see above) and used 
-as identifier in `UbxLogger`, is proposed:
-
->    SITExxST#
-
-with `SITE` the 4-character site name (e.g. 'ZEGV', 'ROVN', ...), `xx` a fixed separator, and 
-`ST#` the instrument identifier at the site. Note that we cannot use `_` or `-` as separators or in the names,
-as `_` is reserved for separating fields in the RINEX name, nor can we use `-` as this is very
-awkward for shell scripting. The `xx` sets it also apart from the IGS naming convention.
-
-The instrument identifier `ST#` can basically be anything as long as it is 3 characters, so that the
-total length of the station name does not exceed 9 characters. A sensible
-naming scheme could be the following: two characters `ST` (for stratum) identifying the 
-foundation depth followed by a number `#` to indicate the location at a site (to cover situations when
-there are multiple instrument locations at a site). The stratum `ST` can either be *TS* an instrument
-embeded in the top soil, *DF* for a deeply founded instrument, or *SA*, *SB*, *SC*, etc., to
-indicate a specific stratum in the soil layers.  
-
-
 ## USB port number assignment
 
 The device name (ttyACM0, ttyACM1, ..), which is needed by `ubxlogd`, is assigned more or 
@@ -391,25 +367,25 @@ serial id that otherwise can be used to distinquish between receivers.
 between receivers using the USB device path.**
 
 The device path must then be specified in the configuration file for each receiver.
-An example for setting the device paths in the configuratuin file is given below: 
+An example for setting the device paths in the configuration file is given below: 
 
->    devpath_ZEGVxxTS1=1.3.2 \
->    devpath_ZEGVxxDF1=1.3.4
+>    devpath_ZVTS00NLD=1.3.1 \
+>    devpath_ZVDF00NLD=1.3.2
 
-The identifier (e.g. `ZEGVxxTS1`) must preceeded by `devpath_`, the value is the USB 
+The identifier (e.g. `ZVTS00NLD`) must preceeded by `devpath_`, the value is the USB 
 device part (think of this a kind of port number) with variable name `${devpath}`.
 
 These settings are used by a function 'get_dev', also defined in the configuration file, 
-which uses the instrument identifier `${identifier}` variable (e.g. "ZEGVxxTS1") to 
-find the corresponding device path, set `${devpath}` (e.g. "1.3.2"), and then resolve 
+which uses the instrument identifier `${identifier}` variable (e.g. "ZVTS00NLD") to 
+find the corresponding device path, set `${devpath}` (e.g. "1.3.1"), and then resolve 
 the device name (e.g. ttyACM0) and return this in the variable `${dev}`. 
 
-The logic is to look for the USB device path `${devpath}` in the system directory
+The logic is to look for the USB device path `${devpath}` in the system directory 
 `/sys/bus/usb/devices/1-${devpath}:1.0/tty)`, which points to the tty device `${dev}` (e.g. ttyACM0)
 that is used for the USB serial device.
 
 The value of `${devpath}` must be set in `devpath_${instrument}=${devpath}`, e.g.
-`devpath_ZEGVxxTS1=1.3.2`. The actual value, in our case '1.3.2', depends on the USB port 
+`devpath_ZVTS00NLD=1.3.1`. The actual value, in our case '1.3.1', depends on the USB port 
 that we are using. In this case it is the second port on a USB hub which itself has 
 device path '1.3'. The actual numbers are different for each system.