Update README and such

3 files changed, 53 insertions, 57 deletions

diff --git a/AUTHORS b/AUTHORS
index 6da1706..daf9713 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -13,6 +13,8 @@ Matthias P. Braendli <matthias [at] mpb [dot] li>
     - ZeroMQ I/Q output
     - I/Q conversion to signed 8-bit
     - ARM support
+    - GPSDO monitoring on USRPs
+    - TII
 
 Jörgen Scott
     - ZeroMQ remote control
diff --git a/README.md b/README.md
index cab4637..6836589 100644
--- a/README.md
+++ b/README.md
@@ -1,11 +1,15 @@
 OVERVIEW
 ========
-ODR-DabMod is a DAB (Digital Audio Broadcasting) modulator compliant
-to ETSI EN 300 401.
+ODR-DabMod is a *DAB (Digital Audio Broadcasting)* modulator compliant
+to ETSI EN 300 401. It is the continuation of the work started by which was
+developed by the Communications Research Center Canada on CRC-DabMux, and
+is now pursued in the
+[Opendigitalradio project](http://opendigitalradio.org).
 
-ODR-DabMod is a fork of CRC-DabMod, which was developed by the
-Communications Research Center Canada and whose development has ceased.
-The Opendigitalradio association now continues this project.
+
+ODR-DabMux is part of the ODR-mmbTools tool set. More information about the
+ODR-mmbTools is available in the *guide*, available on the
+[Opendigitalradio mmbTools page](http://www.opendigitalradio.org/mmbtools).
 
 Short list of features:
 
@@ -18,8 +22,9 @@ Short list of features:
   - Tested for B200, B100, USRP2, USRP1
   - With WBX daughterboard (where appropriate)
 - Timestamping support required for SFN
+- GPSDO monitoring (both Ettus and ODR LEA-M8F board)
 - A FIR filter for improved spectrum mask
-- Improvements in logging (log to file, to syslog)
+- Logging: log to file, to syslog
 - ETI sources: file (Raw, Framed and Streamed) and ZeroMQ
 - A Telnet and ZeroMQ remote-control that can be used to change
   some parameters during runtime
@@ -44,8 +49,9 @@ See the files LICENCE and COPYING
 
 CONTACT
 =======
-Matthias P. Braendli <matthias [at] mpb [dot] li>
-Pascal Charest <pascal [dot] charest [at] crc [dot] ca>
+Matthias P. Braendli *matthias [at] mpb [dot] li*
+
+Pascal Charest *pascal [dot] charest [at] crc [dot] ca*
 
 With thanks to other contributors listed in AUTHORS
 
diff --git a/doc/README-SFN b/doc/README-SFN.md
index abfcf5d..4c988cf 100644
--- a/doc/README-SFN
+++ b/doc/README-SFN.md
@@ -1,11 +1,10 @@
-README About the Usage of ODR-DabMod for
-Synchronous Transmissions
-========================================
+On the Usage of ODR-DabMod for Synchronous Transmissions
+========================================================
 
 Summary
 -------
-ODR-DabMux and ODR-DabMod have a basic support for timestamped transmission,
-when the UHD output is used.  This README explains how this functionality
+ODR-DabMux and ODR-DabMod offer support for timestamped transmission
+when the UHD output is used. This README explains how this functionality
 works, and how to set it up.
 
 This feature is a prerequisite for the creation of a single-frequency
@@ -15,64 +14,41 @@ network.
 Concept
 -------
 The goal of this functionality is to synchronise the transmission for
-several transmitters.  This has been tested with the USRP B100 and the
-USRP2, that both have the necessary REFCLK and 1PPS inputs.  Both are
+several transmitters. This has been tested with the USRP B100, B200 and the
+USRP2, that both have the necessary REFCLK and 1PPS inputs. Both are
 required to synchronise two USRPs:
-- The REFCLK is used in the USRP for timekeeping.  If we want two
+- The REFCLK is used in the USRP for timekeeping. If we want two
   USRPs to stay synchronised, they both must have a precise 10MHz
   source at the REFCLK, otherwise their internal clocks will drift
   off.
-- The 1PPS signal is used to set the time inside the USRPs.  The rising
+- The 1PPS signal is used to set the time inside the USRPs. The rising
   edge of the 1PPS signal has happen synchronously for all transmitters.
   Usually, GPS is used to drive this 1PPS.
 
 For such a system, there will be one multiplexer, which will send the ETI
 stream to several modulators. The ETI stream, in this case, is transported
-over a TCP/IP.
+over the ZMQ interconnection.
 
 Each modulator receives ETI frames that contain absolute timestamps, defining
-the exact point in time when the frame has to be transmitted.  These in-band
+the exact point in time when the frame has to be transmitted. These in-band
 timestamps are composed of two parts:
 - The TIST field as defined in the ETI standard, giving an offset after the
   pulse per second signal;
 - A time information transmitted using the MNSC, representing the precise time
   when the frame must be transmitted, with one-second resolution.
 
-When ODR-DabMux is called with -s, the TIST is defined in each frame. The
-Time is always encoded in the MNSC.
+When ODR-DabMux is configured accordingly, the TIST is defined in each frame.
+The time is always encoded in the MNSC.
 
 When the ETI stream is sent to several modulators using non-blocking I/O, it
 is not possible to rely on a modulator to back-pressure the Ensemble multiplexer.
-It is therefore necessary to throttle multiplexer output.  ODR-DabMux takes an
-additional parameter -r to output one ETI frame every 24ms.
+It is therefore necessary to throttle multiplexer output.
 
-The tool eti_tcp.py can be used to send the ETI stream over TCP.
-An example invocation is:
-odr-dabmux <lots of options> | ./eti_tcp/eti_tcp.py 54540
-
-Each modulator then receives the ETI stream through a TCP connection. Each frame
+Each modulator then receives the ETI stream through a ZMQ connection. Each frame
 contains the complete timestamp, to which an per-modulator offset is added.
-The sum is then given to the USRP. The offset can be specified in two ways:
-
-using -o delay:
-Adds a constant delay specified on the command line (see example 1 below).
-
-using -O delayfile
-Adds the delay specified in the given file. The file must contains a single
-line containing a floating point number. This file is read each 50 frames, and
-the modulator delay is updated.
-
-In both cases, the units are seconds.
-
-Example modulator invocation (for a B100 USRP supporting 2048Msps and with a
-fixed delay of 2.3 seconds)
-nc localhost 54001 | odr-dabmod /dev/stdin -g2 \
-   -o 2.3 -l -u "master_clock_rate=32768000,type=b100" -F 234208000
-
-Example modulator invocation (for an USRP2 requiring resampling and with a delay
-specified in a separate file "moddelay")
-nc localhost 54001 | odr-dabmod /dev/stdin -g2 \
-    -O moddelay -l -r 4000000 -u "type=usrp2" -F 234208000
+The sum is then given to the USRP. The offset can be specified in the
+configuration file of ODR-DabMod, and can be modified on the fly using
+the remote control interface.
 
 ODR-DabMod uses the UHD library to output modulated samples to the USRP device.
 When started, it defines the USRP time using the local time and the PPS signal.
@@ -83,12 +59,28 @@ If the timestamp is too far in the future, the output module waits a short
 delay.
 
 Synchonisation can be verified by using an oscilloscope and a receiver. It is
-very easy to see if the null symbols align.
+very easy to see if the null symbols align. Then tune the receiver to the
+ensemble, and alternatively lower the tx gain of each modulator to see if the
+receiver is still able to receive the ensemble without hiccup.
+
+Time and frequency references
+-----------------------------
+In addition to the 10MHz refclk and 1PPS inputs on the USRP, some USRPs also
+support an integrated GPSDO. For the B200, there are two GPSDOs modules that
+can be used: The Ettus GPSDO (Jackson Labs Firefly), and the u-blox LEA-M8F on
+the [Opendigitalradio board](http://www.opendigitalradio.org/lea-m8f-gpsdo).
+
+To use the LEA-M8F, some modifications in the UHD library are necessary, because
+the module outputs a 30.72MHz refclk instead of a 10MHz. The changes are
+available in the [ODR repository of UHD](https://github.com/Opendigitalradio/uhd),
+with branch names called *lea-m8f-UHDVERSION*.
 
+When using the integrated GPSDO, ODR-DabMod will also monitor if the GPS
+reception is ok, and if the time reference is usable.
 
 Hardware requirements
 ---------------------
-The following hardware is required to test the SFN patch to the CRC mmbTools:
+The following hardware is required to build a SFN with the ODR-mmbTools:
 - Two USRPs ;
 - One or two computers with the mmbTools installed ;
 - A network connection between the two computers ;
@@ -96,17 +88,13 @@ The following hardware is required to test the SFN patch to the CRC mmbTools:
 - A 1PPS source synchronised to the 10MHz ;
 - An oscilloscope to check synchronisation.
 
-When more than one USRP is plugged to one computer, the device string for the
--u option for ODR-DabMod must specify the device. (e.g.  -u "type=b100",
--u "type=usrp2" or -u "serial=ABC123")
-
 It is possible to use signal generators as REFCLK source and 1PPS, if there is
 no GPS-disciplined oscillator available. It is necessary to synchronise the
 1PPS source to the 10MHz source.
 
-The UHD Output module (C++) has to be modified if the USRP internal GPSDO option
-is used.
 
 ###########
 june 2012, initial version, Matthias P. Braendli
 feb 2014, renamed crc-dabXYZ to odr-dabXYZ, mpb
+sep 2015, overhaul, talk about GPSDOs, mpb
+