diff --git a/README.md b/README.md
index f7b7a4daa6c0f7474c79f7613669aa296d7570e0..ec0e126d289760099ea58fa182fe9430d9168a3f 100644
--- a/README.md
+++ b/README.md
@@ -1,18 +1,18 @@
-The Scan Operator (SO) is an integration tool for scan data and DCS data, which is meant to be used during the QC procedure of the Quad Rd53a modules. These are its main features:
+The Scan Operator (SO) is an integration tool for scan data and DCS data, which is meant to be used during the QC procedure of the Quad Rd53a modules. It uses multiple localDB scripts as well as some integrated tools to achieve these features:
 
   - Calls Yarr repeatedly to **run a sequence of scans on Rd53a**.
-  - Retrieves the config files from Prod. DB if the module is registered; creates them offline in other case.
+  - Gets the config files from Prod. DB if the module is registered there; creates them offline otherwise.
   - **Monitors the Power Supply** (PS) powering the ASIC and storing the DCS data in **InfluxDB**
   - Synchronizes the DCS data and the scan data in **LocalDB**.
   - Makes very easy to edit chip-by-chip config parameters (trims, chip name, rx and tx, ...)
 
-All the DCS-related functionality is optional. If you want to enable it, we strongly encourage you to **use labRemote**. No previous experience with labRemote is required.
+All the DCS-related functionality is optional. If you want to enable it, we encourage you to **use labRemote** if you don't have your own DCS controller. No previous experience with labRemote is required.
 
 # Quick Tutorial
 
 ## 1. Get the code
-**If you are planning to monitor your PS**, start by cloning and building labRemote. *You don't need to do it in other case*. 
-We recommend working on the devel branch if Master hasn't been updated in a long time. Also, make sure to enable the Python bindings using cmake's `-DUSE_PYTHON=on` flag
+*If you want to monitor your PS, but you don't have any dedicated software to do it*, start by cloning and building labRemote.
+You might need to work on the devel branch if Master hasn't been updated in a long time. Also, make sure to enable the Python bindings using cmake's `-DUSE_PYTHON=on` flag
 
 ```bash
 git clone https://gitlab.cern.ch/berkeleylab/labRemote.git
@@ -32,70 +32,68 @@ git clone --recursive https://gitlab.cern.ch/YARR/utilities/scan-operator.git
 ## 2. Basic configuration
 The Scan Operator uses up to four configuration files, depending on the functions you want to make use of. All of them are placed under `configs/`. The following is the only required one.
 
-### General Scan-Operator configuration file
+### General configuration file
 
-Under `scan_operator/configs/`, this [`config.json`](configs/config.json) file contains YARR's basic configuration and some general dcs-related settings.
+Under `scan_operator/configs/`, this [`config.json`](configs/config.json) file contains YARR's basic configuration, some module details and some general dcs-related settings.
 
 Most of the items are self-explanatory. Here are the ones that may require some indications to fill.
 
-  - **`.YARR.scan_list`**: Place here the sequence of scans that you want to run. For a threshold / tot tuning, the second argument of the list represents the target threshold / tot (e.g. `["diff_retune_pixelthreshold", 1000]` will retune the pixel threshold of the differential FE to 1000 e), whilst `["diff_tune_globalpreamp", 7]` will tune the ToT to 7). The target charge for ToT tuning / scan is specified under `.YARR.scan` and it's assumed to be the same for all the ToT-related scans.  
+  - **`.YARR.scan_list`**: Place here the sequence of scans that you want to run. For a threshold / tot tuning, the second argument in the bracket represents the target threshold / tot (e.g. `["diff_retune_pixelthreshold", 1000]` will retune the pixel threshold of the differential FE to 1000 e), whilst `["diff_tune_globalpreamp", 7]` will tune the ToT to 7). The target charge for ToT tuning / scan is specified under `.YARR.scan` and it's assumed to be the same for all the ToT-related scans.  
 
-  - **`.modules`**: Write here the configs for as many modules as you want. The file comes with an example for a SCC and an example for a quad. You will chose between the modules you have defined here in the command line. Notes:
+  - **`.modules`**: Write here the configs for as many modules as you want. The file comes with an example for a SCC and an example for a quad. You will choose between the modules you have defined here in the command line. Notes:
     - The name of each module (e.g. `moduleid_quad`) should match the Serial Number of the module.
     - For each chip:
       - `"connectivity"` accepts these entries: "`rx`", "`tx`", "`enable`" and "`locked`".
       - For any key written in `"GlobalConfig"`, the Scan Operator will:
         - Look for it in Yarr's general chip config file (e.g. `rd53a_test.json`) under `.RD53A.GlobalConfig`. 
-        - If found, change the value to the one specified by the user.
+        - If found, change the value to the one specified by you.
         - If not found, throw a warning and continue.
       - The same goes for the `"Parameter"` section.  
   
-  - **`.dcs_control`**: *Fill this only if you are planning to monitor your PS while running the scans.*
-    - under `.dcs_control.channels`, write one entry for each channel you want to monitor (`name`, `voltage` and `current`). You will associate them with your hardware later 
+  - **`.dcs_control`**: *Fill this only if you are planning to use the S.O. to monitor your PS while running the scans.*
+    - Under `.dcs_control.channels`, write one entry for each channel you want to monitor (`name`, `voltage` and `current`). You will associate them with your hardware later 
       - The `voltage` and `current` keys will be ignored if you don't use "`-o`" in the command line (see [below](#dcs-related)). 
       - Different channels have to have different names.
 
 
-### LabRemote configuration file
+### Powersupply  configuration file
 
 *Skip this section if you don't want to use the SO to monitor DCS data.*
 
-[The `powersupply.json`](configs/powersupply.json) config file contains the actual information to establish communication with the PS. These are the fields you may want to change:
+[The `powersupply.json`](configs/powersupply.json) config file contains the actual information to establish communication with the PS. These are some fields you may want to change:
 
 - **`.devices`**: Write here the PS / PSs you want to use. A list of supported "`hw-model`" and "`protocol`" is available in [labRemote's README.md](https://gitlab.cern.ch/berkeleylab/labRemote#python-bindings). To find the port your PS is connected to, look at the output of `ls -l /dev/serial/by-id/`.
   
-- **`.channels`**: You can have here as many channels as you want. Only the ones appearing in `config.json` will be used though. Under `.channels`, `"device"` should be one of the ones in the upper section, and `channel` is the actual output channel number of the PS (e.g. from 1 to 4 for the R&S HMP4040).  TODO: Move here all the DCS config?
-  
-
+- **`.channels`**: You can have here as many channels as you want. Only the ones appearing in `config.json` will be used though. Under `.channels`, `"device"` should be one of the ones in the upper section, and `channel` is the actual output channel number of the PS (e.g. from 1 to 4 for the R&S HMP4040).
 
 ### InfluxDB connectivity configuration file
 
 
-*Skip this section if you don't want to use the SO to monitor DCS data.*
+*Follow this section if you want to synchronize the DCS data and the scan data in localDB*
 
-This file contains the basic information needed to stablish connection with InfluxDB.
-Also, it merges various files localDB needs to retrieve DCS data from InfluxDB, which is the reason why there are some duplicated fields here. 
+This file contains the basic information needed to establish connection with InfluxDB.
+Also, it merges various files localDB needs to retrieve DCS data from InfluxDB.
 
-Setting up this file is easy. There are the fields that need a short explanation:
+Setting up this file is easy. These are the fields that need a short explanation:
 
-  - `influxdb_cfg`: If you are planning on monitoring the DCS, but you are not interested in synchronizing the data with any scan in localDB, that's the only section you should worry about in this file.
+  - `.influxdb_cfg`: Contains the configuration needed to connect to InfluxDB
   
-  - `influxdb_cfg.measurement`: The measurement (data table) where to upload data to in InfluxDB.
+  - `.influxdb_cfg.measurement`: The measurement (data table) where to read data from in InfluxDB.
 
   - `.environment`: List here the title of every set of data you want to upload to localDB, *as you want it to appear in localDB*. (e.g. vdda, temperature, HV, ...)
 
   - `.environments.measurement`: The measurement where to read data from in InfluxDB
 
   - `.environments.dcslist[i].key`: Lives in localDB; has to match one of the ones declared in `.environment`
-  - `.environments.dcslist[i].data_name`: Lives in InfluxDB, the title of the column where to read data from. `data_name` is not a free parameter. It is named as `AX_C`, where:
+  - `.environments.dcslist[i].data_name`: Lives in InfluxDB, the title of the column where to read data from. If you are using your own DCS tool to fill localDB with data, write here the name of the column in influxDB where to take the data from. If you are using the S.O. for that, please follow this scheme: `AX_C`, where:
     - `A`: `meas` for the measured value and `sett` for the setting value
     - `X`: `V` or `I`
     - `C`: PS Channel, as you named it in the main config file. 
-    E.g. `measV_LV` will contain the sense values of V read on the channel name "LV"
+    E.g. `measV_LV` will contain the sense values of V read on the channel named "LV"
 
 ## 3. Run the Scan Operator
 
-```s
+```
 $ ./ScanOperator.sh
 Help:
   -j [str, path] : path to json configuration file
@@ -109,39 +107,47 @@ Help:
   -q [int]       : "quiet" mode (cleaner output), 0, or 1. Default 0
 ```
 
-### Example - Hello world
+#### Example - Hello world
 
 ```bash
-./ScanOperator.sh -j configs/config.json -m module_id -c
+./ScanOperator.sh -j configs/my_config.json -m module_id -c
 ```
 
 This will just run in series the scans you specified in `scan_list` (in `config.json`). All the DCS / LocalDB / InfluxDB functionality is disabled here.
 
-### Example - QC procedure
+#### Example - QC chain
 
-If you are using the Scan Operator during the QC procedure of any of your modules, you should call it by enabling all the QC / LocalDB Features. (`-Q` and `-W` respectively). You don't need to monitor any DCS data.
+If you are using the Scan Operator during the QC procedure of any of your modules, you should enable all the QC / LocalDB Features. (`-Q` and `-W` respectively). In principle, you don't need to monitor any DCS data.
 
 ```bash
-./ScanOperator.sh -j configs/config.json -m module_id -c -Q -W
+./ScanOperator.sh -j configs/my_config.json -m module_id -c -Q -W
+```
+
+#### Example - Monitoring DCS and uploading the data to localDB
+
+This one will monitor the DCS (`-d`) and sync everything in localDB (`-t`) while running the scans.
+
+```bash
+./ScanOperator.sh -W -j configs/my_config.json -m module_id -d configs/my_powersupply.json -t configs/my_influxdb_connectivity.json
 ```
 
 ### List of arguments
 
 #### Required
 
-- `-j:` Path to `config.json`
+- `-j:` Path to your `config.json`
 - `-m:` Serial Number of the module. Chose from the ones you have defined in `config.json`
 
 #### Optional
 
-- `-c:` Create Yarr config files. Necessary files such as the `controller` or `connectivity` **config files will be created or overwritten** if `-c` is specified. Use this option after making any change in `config.json`, or if you are using the software for the first time. All the files are created in the Scan Operator folder, so everything you have under Yarr's one remains untouched. Summarizing, "-c" does the following.
-  - Retrieves the files from localDB if the module is already registered and the connection is good. Creates them offline otherwise. (*TODO*: Use createConfig for that)
+- `-c:` Create Yarr config files. Necessary files such as the `controller` or `connectivity` config files will be created or overwritten if `-c` is specified. Use this option after making any change in `config.json`, or if you are working with any module for the first time. All the files are created in the Scan Operator folder, so everything you have under Yarr's one remains untouched. Summarizing, "-c" does the following.
+  - Retrieves the files from localDB if the module is already registered and the connection is good. Creates them offline otherwise.
   - Edits them based on `config.json`
-  - if -W is used, reuploads them to localDB, associated to every scan.  
+  - if `-W` is used, reuploads them to localDB, associated with every scan.  
    
 - `-q:` Quiet mode: Reduces the terminal output to two different levels:
-  - `-q 0:` No reduction at all
-  - `-q 1:` Shows only Yarr's main results + Scan Operator logs  
+  - `-q 0:` No reduction at all (default)
+  - `-q 1:` Shows only Yarr's main results + a few Scan Operator logs  
   
 - `-W:` This one is equivalent to the `-W` option used when calling Yarr's ScanConsole  
 - `-Q:` This one is equivalent to the `-Q` option you use when calling Yarr's ScanConsole
@@ -152,15 +158,35 @@ If you are using the Scan Operator during the QC procedure of any of your module
 
 - `-d:` Monitor the PS and store **real-time DCS data in InfluxDB**.
 
-- `-t:` After each scan, retrieves the DCS data from InfluxDB and uploads it to LocalDB, synchronized with each scan. Remember to tell the databases how to talk to each other in the [InfluxDB-LocalDB connectivity file](#influxdb-connectivity-configuration-file).
+- `-t:` Retrieves the DCS data from InfluxDB and uploads it to LocalDB, synchronized with each scan. Remember to tell the databases how to talk to each other in the [InfluxDB-LocalDB connectivity file](#influxdb-connectivity-configuration-file).
+
+
+### Monitoring DCS with an external tool
 
+A few notes about synchronizing DCS data on localDB in this case:
 
+- If your tool uploads DCS data to influxDB in real-time, you can always use `-t` to perform the transfer after every single scan.   
+
+- If you prefer to synchronize all the DCS data for every single scan at once, don't use `-t` and you will see a message like this at the end of the sequence of scans:
+
+```
+[ info ][so] If you want to upload to localDB the DCS data associated
+             to all the scans you have just run (assuming you have it
+             stored in InfluxDB), you can do it in one command:
+             
+                 bash /home/me/scan-operator/data/200923_017/moveDCStoLocalDB.sh path/to/influxdb_connectivity.json
+```
+
+That script is automatically generated and contains one call to localdb's dbAccessor per scan ran in the last SO call.
 
 # Troubleshooting
 
 These are a few issues you might encounter when using this software.
 
 ## 1. How do I know the code of my institution?
+
+You might ask yourself this quesiton if you run into the following error message:
+
 ```
 [ error  ][   Local DB    ]: Not found site data {'institution': 'localhost.localdomain'} registered in Local DB.
 [ error  ][   Local DB    ]: Please set your institution correctly in
@@ -170,17 +196,23 @@ These are a few issues you might encounter when using this software.
 
 ### so, how do I know the code of my institution?
 
-    1. Go to your Yarr folder
-    2. `./localdb/bin/localdbtool-retrieve list site`
+1. Go to your Yarr folder
+1. Run `./localdb/bin/localdbtool-retrieve list site`
 
 *Note: You might need to switch to devel-localdb to run the above command*
 
-## 2. How do I register my module in localdb?
+## 2. My module is registered in iTk PD, but it doesn't appear in my localDB
+
 
+The following error will terminate the program if running on `-Q` mode:
 ```
-[ error  ][   Local DB    ]: Not found component data { "serialNumber": "peanut", "componentType": "module" } registered in Local DB.
-[ error  ][   Local DB    ]: Please set the serial number of the QC parent component correctly in
-[ error  ][   Local DB    ]: {{ "module": {{ "serialNumber": "xxx" }} }} in connectivity file.
-[ error  ][   Local DB    ]: Invalid configs for uploading data, aborting...
+[ error  ][   Local DB    ]: Not found component data in Local DB: 20UPGM20000002
 ```
 
+To solve it, you need to have [localdb-tools](https://gitlab.cern.ch/YARR/localdb-tools) installed somewhere on your computer. Then you can retrieve the module from iTkPD to localDB, following this:
+
+1. `cd localdb-tools/viewer/itkpd-interface/`
+1. `source authenticate.sh`
+2. `./bin/downloader.py --option Module`
+
+See `./bin/downloader.py -h` for more information about this retriever tool.