From 43887597d457488d725897186ca51fd52ab1a139 Mon Sep 17 00:00:00 2001 From: "Matthias P. Braendli" Date: Mon, 14 Sep 2015 07:56:27 +0200 Subject: Update README and such --- AUTHORS | 2 + README.md | 22 +++++++---- doc/README-SFN | 112 ------------------------------------------------------ doc/README-SFN.md | 100 ++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 116 insertions(+), 120 deletions(-) delete mode 100644 doc/README-SFN create mode 100644 doc/README-SFN.md diff --git a/AUTHORS b/AUTHORS index 6da1706..daf9713 100644 --- a/AUTHORS +++ b/AUTHORS @@ -13,6 +13,8 @@ Matthias P. Braendli - 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 -Pascal Charest +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 deleted file mode 100644 index abfcf5d..0000000 --- a/doc/README-SFN +++ /dev/null @@ -1,112 +0,0 @@ -README About 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 -works, and how to set it up. - -This feature is a prerequisite for the creation of a single-frequency -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 -required to synchronise two USRPs: -- 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 - 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. - -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 -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 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. - -The tool eti_tcp.py can be used to send the ETI stream over TCP. -An example invocation is: -odr-dabmux | ./eti_tcp/eti_tcp.py 54540 - -Each modulator then receives the ETI stream through a TCP 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 - -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. -It is therefore important to synchronise computer time using NTP. - -When a frame arrives with a timestamp that is in the past, the frame is dropped. -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. - - -Hardware requirements ---------------------- -The following hardware is required to test the SFN patch to the CRC mmbTools: -- Two USRPs ; -- One or two computers with the mmbTools installed ; -- A network connection between the two computers ; -- A 10MHz refclk source ; -- 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 diff --git a/doc/README-SFN.md b/doc/README-SFN.md new file mode 100644 index 0000000..4c988cf --- /dev/null +++ b/doc/README-SFN.md @@ -0,0 +1,100 @@ +On the Usage of ODR-DabMod for Synchronous Transmissions +======================================================== + +Summary +------- +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 +network. + + +Concept +------- +The goal of this functionality is to synchronise the transmission for +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 + 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 + 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 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 +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 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. + +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 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. +It is therefore important to synchronise computer time using NTP. + +When a frame arrives with a timestamp that is in the past, the frame is dropped. +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. 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 build a SFN with the ODR-mmbTools: +- Two USRPs ; +- One or two computers with the mmbTools installed ; +- A network connection between the two computers ; +- A 10MHz refclk source ; +- A 1PPS source synchronised to the 10MHz ; +- An oscilloscope to check synchronisation. + +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. + + +########### +june 2012, initial version, Matthias P. Braendli +feb 2014, renamed crc-dabXYZ to odr-dabXYZ, mpb +sep 2015, overhaul, talk about GPSDOs, mpb + -- cgit v1.2.3