1 files changed, 153 insertions, 0 deletions
diff --git a/gr-digital/examples/README b/gr-digital/examples/README
new file mode 100644
index 000000000..1c50ad69b
--- /dev/null
+++ b/gr-digital/examples/README
@@ -0,0 +1,153 @@
+Quick overview of what's here:
+
+* benchmark_tx.py: generates packets of the size you
+specify and sends them across the air using the USRP.  Known to work
+well using the USRP with the RFX transceiver daughterboards.
+You can specify the bitrate to use with the -r <bitrate> command line
+parameter.  The default is 500k.  Some machines will do 1M or more.
+You can select the modulation to use with the -m <modulation> command
+line argument.  The legal values for <modulation> are gmsk, dbpsk and dqpsk.
+
+* benchmark_rx.py: the receiver half of benchmark_tx.py.
+Command line arguments are pretty much the same as rx.  Works well
+with a USRP and RFX transceiver daughterboards.  Will also work
+with TVRX daugherboard, but you'll need to fiddle with the gain.  See
+below.  Prints a summary of each packet received and keeps a running
+total of packets received, and how many of them were error free.
+There are two levels of error reporting going on.  If the access code
+(PN code) and header of a packet were properly detected, then you'll
+get an output line.  If the CRC32 of the payload was correct you get
+"ok = True", else "ok = False".  The "pktno" is extracted from the
+received packet.  If there are skipped numbers, you're missing some
+packets.  Be sure you've got a suitable antenna connected to the TX/RX
+port on each board.  For the RFX-400, "70 cm" / 420 MHz antennas for ham
+handi-talkies work great.  These are available at ham radio supplies,
+etc.  The boards need to be at least 3m apart.  You can also try
+experimenting with the rx gain (-g <gain> command line option).
+
+Generally speaking, I start the rx first on one machine, and then fire
+up the tx on the other machine.  The tx also supports a discontinous
+transmission mode where it sends bursts of 5 packets and then waits 1
+second.  This is useful for ensuring that all the receiver control
+loops lock up fast enough.
+
+* tunnel.py: This program provides a framework for building your own
+MACs.  It creates a "TAP" interface in the kernel, typically gr0,
+and sends and receives ethernet frames through it.  See
+/usr/src/linux/Documentation/networking/tuntap.txt and/or Google for
+"universal tun tap".  The Linux 2.6 kernel includes the tun module, you
+don't have to build it.  You may have to "modprobe tun" if it's not
+loaded by default.  If /dev/net/tun doesn't exist, try "modprobe tun".
+
+To run this program you'll need to be root or running with the
+appropriate capability to open the tun interface.  You'll need to fire
+up two copies on different machines.  Once each is running you'll need
+to ifconfig the gr0 interface to set the IP address.
+
+This will allow two machines to talk, but anything beyond the two
+machines depends on your networking setup.  Left as an exercise...
+
+On machine A:
+
+  $ su
+  # ./tunnel.py --freq 423.0M --bitrate 500k
+  # # in another window on A, also as root...
+  # ifconfig gr0 192.168.200.1
+
+
+On machine B:
+
+  $ su
+  # ./tunnel.py --freq 423.0M --bitrate 500k
+  # # in another window on B, also as root...
+  # ifconfig gr0 192.168.200.2
+
+Now, on machine A you shold be able to ping machine B:
+
+  $ ping 192.168.200.2
+
+and you should see some output for each packet in the
+tunnel.py window if you used the -v option.
+
+Likewise, on machine B:
+
+  $ ping 192.168.200.1
+
+This now uses a carrier sense MAC, so you should be able to ssh
+between the machines, web browse, etc.
+
+* run_length.py: This program takes a single argument '-f FILE' and
+outputs the number of runs of similar bits within the file. It is
+useful as a diagnostic tool when experimenting with line coding or
+whitening algorithms.
+
+
+
+**********************************************************************
+**********************************************************************
+
+
+BERT testing example scripts
+
+benchmark_tx.py
+
+This sets up a BPSK transmitter that is modulated with a pseudorandom
+sequence of bits.  The PN code is generated by sending an all 1s
+sequence through a 7-bit scrambler. The transmitter performs the BPSK
+modulation, then passes the complex baseband waveform through a
+root-raised-cosine filter and onto the USRP.
+
+The --sps parameter controls how many baseband samples per symbol
+are created and passed through the RRC filter, prior to going to the
+USRP over the USB for interpolation to the final DAC rate.
+
+The baseband bit rate is controlled by -r or --rate.  This value, when
+multiplied by the --sps parameter, must result in valid interpolation
+rate for the USRP.  For example, if the baseband rate is 250k bits/sec,
+and the samples per symbol is 4, then the final rate is 1M samples/sec,
+which results in an interpolation rate of 128.  The valid interpolation
+rates for the USRP are multiples of 4 between 16 and 512.
+
+Finally, the RRC excess bandwidth may be specified by --excess-bw.
+(See ./benchmark_tx.py -h for additional parameters.)
+
+
+benchmark_rx.py
+
+This sets up a BPSK receiver to demodulate the received waveform.  It
+accepts a similar set of parameters as the transmitter, except that one
+specifies the USRP decimation rate desired.  The resulting sample stream
+rate must be an integral number of baseband symbols.  For example, the
+parameters corresponding to the above transmitter would be to use a
+decimation rate of 8 (32 sps), 16 (16 sps), 32 (8 sps), 64, (4 sps), or
+128 (2 sps).  The lower the USRP decimation, the more CPU is required to
+demodulate the signal, so not all valid decimation rates will work.
+
+The baseband signal from the USRP is first passed through an AGC to
+establish an average power of 1.0.  It is then passed through a matched
+filter (another RRC), a Costas phase-locked loop, and a Mueller and
+Muller bit timing recovery loop.  The resulting constellation has an SNR
+estimation probe attached, and is then sliced into a bit stream.
+
+The recovered bits are then passed through a 7-bit descrambler.  If
+there are no channel errors, the all 1s sequence is recovered. In the 
+event of a channel error, there will be a 0 in the bit stream for each
+feedback tap in the descrambler.  In this case, the CCSDS descrambler is
+using 3 feedback taps.
+
+Finally, the signal is passed into a bit density measurement probe. The
+channel BER is measured by dividing the 0s density by three.  This
+measurement is inaccurate at high BER rates (>10%) as the error 0s
+begin to overlap.
+
+The benchmark script will, once per second, output the Costas loop
+frequency offset, the recovered timing error, the estimated SNR, and the
+average BER.
+
+NOTE: The particular SNR estimator used is inaccurate below about 7dB,
+and will report erroneously high values even for random noise.
+
+There are a variety of Costas and M&M loop parameters one can adjust.
+See ./benchmark_rx.py -h for the full set.
+
+