1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
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.
|
