summaryrefslogtreecommitdiff
path: root/gr-digital/examples/README
diff options
context:
space:
mode:
authorTom Rondeau <trondeau@vt.edu>2011-10-19 09:58:03 -0700
committerTom Rondeau <trondeau@vt.edu>2011-10-19 09:58:03 -0700
commit7e985e7f553a863df37cf39bfd2bd958d82ea46c (patch)
tree5bdc21a7c1ab3290b6bd283f699befd77f23bc0f /gr-digital/examples/README
parent792e9780cd48177a13416e5926b77f30526ae3ec (diff)
digital: fixed digital narrowband examples to use args instead of address and better default.
Diffstat (limited to 'gr-digital/examples/README')
-rw-r--r--gr-digital/examples/README153
1 files changed, 0 insertions, 153 deletions
diff --git a/gr-digital/examples/README b/gr-digital/examples/README
deleted file mode 100644
index 1c50ad69b8..0000000000
--- a/gr-digital/examples/README
+++ /dev/null
@@ -1,153 +0,0 @@
-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.
-
-