why sdr

SDR TRANSCEIVER Operating Manual Version 1.0.3

Table of Contents Introduction……………………………………………………………………...…….2 General Description………………………………………………………...…..........3 Why Use SDR……………………………………………………………………..….5 Specifications………………………………………………………………………....5 Installation and Setup………………………………………………………………....6 Checklist………………………………………………………………………………..8 GUI Features…………………………………………………………………………..9 Mode Features: AM……………………………………………………………………….........11 CW…………………………………………………………………………….13 FM……………………………………………………………………………..15 SSB………………………………………………………………………...….17 Advanced Features:………………………………………………………………....19 Low-Pass Filter Setup………………………………………………...……..19 Miscellaneous Changes in the Code……………………………………....19 Frequently Asked Questions………………………………………………………..21

1

Introduction The Software-Defined Radio (henceforth abbreviated as SDR) Transceiver project is created by the students at the California State University, Northridge (CSUN) as their senior design team project. Six students compose this team:

Jack Sun (Project Manager) Youssef Chedid Kaveh Hajimohammadreza Efrain Mendoza Silvestre Sanchez Kinal Vachhani

There are three faculty advisors who worked alongside the students for this project:

Dr. Sharlene Katz (Head Advisor) Prof. James Flynn Dr. David Schwartz

The project is sponsored by Edwards Air Force Base to research in the field of SDR and the various applications surrounding it. The application, in this case, is to use SDR to achieve equivalent or better results than commercially sold hardware transceivers. The project is hosted freely on SoureForge, and is licensed by GNU General Public License (GPL). The address for the website is at the following:

http://sourceforge.net/projects/sdr/

The project and the website are maintained by Jack Sun for as long as there is interest from the community or the industry. To contact Mr. Sun, please email him here:

[email protected].

2

General Description The SDR Transceiver is a flexible and multifunctional system capable of high performance on both the transmitter and receiver. The purpose of the SDR Transceiver is to replace as many components on the hardware transceiver as possible. For the simplest operation (receive), two hardware components are required: an antenna, and the Universal Software Radio Peripheral (USRP). The USRP allows a computer to function as a general-purpose software radio capable of many various applications. In this project, the purpose is to design a software transceiver. On the software side, the main library toolkit used is GNU Radio, which is free and open source. More information about Ettus Research, the maker of the USRP, and GNU Radio can be found here:

http://www.ettus.com http://gnuradio.org

To transmit over-the-air, the operator may require a license. Please consult the laws in the respective country/region on what is legal and acceptable. Local transmission is typically allowed if it is not over-the-air, but again please consult with the laws in the respective country/region. Furthermore, a hardware amplifier is most likely required due to the specifications of the USRP (more details in the Specifications section) transmitting at an average of about 10 to 20 mW. For this research design project, an amplifier is used to increase the transmitter gain to a maximum of 140 Watts. The SDR Transceiver is designed to work in the High Frequency (HF) range of 1.8 to 29.7 MHz. However, due to the flexibility of software and this being an open source project, the range can easily be expanded or adjusted to match the operator's desire (assuming compatible daughterboards are used in the USRP). The following modes of operation have been designed and integrated into the overall system: 

Amplitude Modulation (AM)



Continuous Wave (CW, which in this case is Morse Code)



Frequency Modulation (FM)



Single Sideband (SSB, both upper and lower)

For each of the four implemented modes, the following features have been implemented: 3



S-meter (receiving signal strength indicator)



Power meter (transmitting signal strength indicator)



Volume controls for transmitter (TX) and receiver (RX)



Simplex or duplex operation



Display of the frequency spectrum via FFT

Lastly, compose and create an operating manual such that any operator new to SDR will be both comfortable and familiar. For AM and SSB, there are two receiving channels because it is a highly desired feature among amateur radio operators – capable of listening to the transmitted frequency while tuning to nearby frequencies.

4

Why Use SDR The concept of Software Defined Radio (SDR) is to move as many components from traditional hardware into the world of software. For this transceiver project, an antenna, an amplifier (for transmit), and the RF front-end (USRP) have to be used. There are various reasons to use SDR. They will be highlighted below. Reason 1: Flexibility. Imagine building an AM transceiver and put it in your car. Now a month later you want a FM transceiver as well. Traditionally, you would have to build the hardware for the FM from scratch. With SDR, the hardware components are the same, making upgrading (hardware-wise) a thing of the past. Furthermore, this makes adding new modes (and patching existing modes) very simple. Reason 2: Space. For the example illustrated above, space was already allocated for the AM transceiver. However, with the addition of FM, new space have to be obtained before one could add the FM hardware components in. With SDR, one set of hardware components is all that is needed. Reason 3: Efficiency. As more and more channels are being used in the air today as well as limited channels, a more efficient use of the available bandwidths today is critical. There is better precision with software (digital technology) than hardware (analog). Furthermore, testing is more efficient because if an xth order filter is not good enough, change the value and now it becomes x+1 order without ever having to pick up a soldering iron. SDR makes design, implementation, and testing more efficient. Reason 4: Near-ideal filters. Any hobbyist or engineer knows building hardware filters can be a pain, especially as one increases the order. A 7th order low-pass filter, for example, can take up an entire breadboard. SDR, however, takes advantage of the fast CPU that is commonly available in the consumer market today. As a perfect example, the Hilbert tap filter used in SSB has an order of 380. Try building a 380th order filter in analog! Reason 5: The future. Whether one likes it or not, SDR is the way of the future. For all the reasons above, it is where research is being done today (as evident by this research design project), and where the market will inevitably follow. Many corporate markets are already heading towards SDR, such as Edwards Air Force Base, who funded this project, and the JTRS project (Joint Tactical Radio System), which will be in the U.S. military in the near future.

5

Specifications SDR Transceiver RX Frequency Range: TX Frequency Range: Undesired Sideband Suppression: 3rd-order IMD:

1.8 MHz to 29.7 MHz 1.8 MHz to 29.7 MHz At least 70 dB below peak output* -35 dB @ 100 Watts PEP*

*result may vary depending on the hardware amplifier used

USRP Hardware ADC: 4 x 64 MS/s 12-bit DAC: 4 x 128 MS/s 14-bit High-Speed USB 2.0 Interface: Up to 480 Mb/s Daughterboards: Available boards ranging from DC to 5 GHz (For HF, use BasicTX/RX – DC to 30 MHz)

Input Sample Rate: Resolution: SFDR:

64 MS/s 12 bits 85 dB

Output Number of Output Channels: Sample Rate: Resolution: SFDR: Output Average Power:

4, or 2 I-Q pairs 128 MS/s 14 bits 83 dB ~10 to 20 mW (measured experimentally in laboratory setting)

6

Installation and Setup The installation consists of two main sections: The installation of the operating system and subsequently GNU Radio/GNU Radio Companion (GRC), and then the setup for SDR Transceiver. The installation of the operating system is limited to Linux-base currently. It is not a USRP limitation; rather, it is a GNU Radio and GRC limitation. All implementation and integration are completed in the operating system Ubuntu. For the purpose of this build guide, Ubuntu will be used. The first step is to go to Ubuntu's website here: http://www.ubuntu.com From there, download the Ubuntu software, which at the time of writing is offered in CD images. The image file will need to be burned into a CD and then boot the computer from the CD. Following on-screen instructions for the installation process. The process for installing GNU Radio and GRC depends on the build of the operating system. Please ensure the operating system is Linux-based, and if possible, Ubuntu, since the project is entirely built in the Ubuntu environment. Go to GNU Radio's website located here: http://gnuradio.org/trac/wiki/BuildGuide Please follow the build guide provided by GNU Radio according to the operating system and the build. The most time-consuming portion will be while the system is making and building the GNU Radio source files. It may take anywhere from a few minutes to an hour, depending on the computer being installed on. To run the SDR Transceiver software, please download the tarball (like a zip file, which has all the source code) located on the project webpage located here: http://sourceforge.net/projects/sdr Extract the tarball to any directory (the recommendation is either on the desktop or in the home directory). Open the terminal in applications  accessories  terminal. Locate the directory where the project is extracted. For the Ubuntu system, an example is shown below with the project extracted to the desktop. Open the terminal and type in the following: cd Desktop cd sdr ./gui.py 7

There are two notes of importance here. The first is that ./ is used to open the Python file. Any of the other commands capable of starting Python is also accepted, such as "python gui.py" without the quotes. Note that if there is a permission rights issue, please type in chmod +x without the angle brackets to allow permission.The second note is that in Linux systems, the terminal is case sensitive. Therefore, one has to type Desktop rather than desktop, and gui.py rather than GUI.py. If a GUI window appears, then this process has been completed successfully. The USRP does not have to be started and connected to the computer when starting the GUI, but it is needed prior to selecting the mode.

8

Checklist Before starting the software, please make sure you have the following at your disposal: 1. USRP (with Basic TX and RX daughterboards). 2. Antenna. 3. Amplifier (for TX only, RX should be okay with just USRP and antenna if antenna is good). 4. Linux operating system installed (Ubuntu recommended). 5. SDR Transceiver tarball downloaded.

9

GUI Features The GUI, as stated in this operating system, represents the main GUI when the SDR Transceiver software is first opened. The top half is mode selection. The pull-down menu has the four modes of operation implemented: AM, CW, FM, and SSB. To confirm the choice, the user has to explicitly click on the select button. The selected mode will appear as a new window, and will be discussed in more details in the Mode Features section. The bottom half of the GUI is the parameter display. The S-meter is the receiving signal strength indicator while the power meter is the transmitting signal strength indicator. The S-meter is displayed in decibel (dB) scale, which is why the labels are not aligned linearly. The power meter is, however, displayed linearly. The unit of the power meter is shown in watts. Both meters use the same gauge for display because the transceiver does not work in full duplex. Therefore, only the TX or RX can run at any given time.

Near the top of the window are the menu bars. The file menu currently only has exit, but the code is there to support other features such as saving and opening user 10

configuration settings. In the help menu, the top selection is the instruction manual, which when clicked on the instruction manual will appear on screen in the form of a pdf (portable document format) file. The second option will open a text file with the most common questions regarding running the software and the USRP – an FAQ page for the user. The bottom option is the about page, which will reveal more details for the user regarding the software and the GPL license. The next section will discuss the various features and functionalities of each mode, accompanied by a figure showing the layout of the mode GUI.

11

Mode Features: Amplitude Modulation

AF Gain:

Controls the volume for its corresponding receiving channel.

Filter BW:

Adjusts the cut-off frequency for the low-pass filter on the receiver.

Carrier:

Adjusts the carrier level for transmission. 12

Mic. Gain: RX 1 Freq.:

Adjusts the microphone gain for transmission. Adjusts the primary receiving frequency.

RX 2 Freq.:

Adjusts the offset from the first frequency to select the second frequency. (Note: By default, this value is set to zero, meaning both receiving channels are on the same frequency).

TX Freq.:

Adjusts the transmitting frequency.

VFO:

In simplex, the RX and TX frequencies move together, or "locked." In split operation, RX and TX may be on different frequencies.

Band:

Selects different frequency bands.

PTT:

Push-to-talk button. Clicking on this button toggles between RX and TX. In addition, if the PTT button is left-clicked once, the space bar may be used to toggle between RX and TX. (Note: if other sliders or menus are selected, the PTT button must be left-clicked again before the space bar may be used to toggle).

Save User Settings:

Saves the current values (frequency, gain, etc) to an external file for storage. The external file is labeled in the folder as config_mode where mode is AM, CW, etc. When that particular mode is opened the next time, the saved values will automatically be set in the mode window.

Frequency Spectrum:

Displays the receiver frequency spectrum.

13

Mode Features: Continuous Wave (Morse Code)

AF Gain:


Key Volume:

Routes transmission to operator's speakers so the operator is able to hear his/her keying.

RX 1 Freq.:

Adjusts the primary receiving frequency. 14

TX Freq.:


VFO:


Band:


PTT:


Save User Settings:


Frequency Spectrum:


15

Mode Features: Frequency Modulation

AF Gain:


TX Drive:

Controls the Amplitude of the transmitted signal.

Squelch:

Controls the background noise so that the signal above this background noise is heard. 16

Mic. Gain:

Adjusts the microphone gain for transmission.

RX 1 Freq.:

Adjusts the primary receiving frequency.

TX Freq.:


VFO:


Band:


PTT:


Save User Settings:


Frequency Spectrum:


17

Mode Features: Single Sideband

AF Gain:


Filter BW:

Adjusts the cut-off frequency for the low-pass filter on the receiver.

Mic. Gain:

Adjusts the microphone gain for transmission. 18

RX 1 Freq.:

Adjusts the primary receiving frequency.

RX 2 Freq.:

Adjusts the offset from the first frequency to select the second frequency. (Note: By default, this value is set to zero, meaning both receiving channels are on the same frequency).

TX Freq.:


VFO:


Band:


PTT:


Save User Settings:


Frequency Spectrum:


19

Advanced Features The advanced features section is an ongoing guide on the different aspects that the advanced users, or "power users," may take advantage when using SDR Transceiver.

Low-Pass Filter: The first topic of interest is the low-pass filter, or the filter bandwidth slider and textbox. The filter bandwidth is really just a low-pass filter, and it is adjustable instantaneously. The sampling rate is down-sampled for the majority of the signal processing in order to conserve processing resources, as long as it meets the NyquistShannon sampling theorem (or simply just the Nyquist theorem). In the Nyquist theorem, fs > 2*B where fs = sampling frequency and B = bandwidth. The only two modes that have the option to adjust the filter badnwidth are AM and SSB. When the user adjusts the filter bandwidth, he/she is actually adjusting the cutoff frequency, which by default is 3k. The filter bandwidth should not exceed 4k, or distortion/aliasing may begin to occur. Likewise, the filter bandwidth should not be set too low, or the audio coming out of the speakers may not be intelligible (AM's bandwidth is usually 3 to 5 kHz, and SSB is 2 to 3 kHz).

Changes in Python Code: It is good to be familiar with the Python code, especially the GRC-generated portions of Python code. The first topic of relevance is the adjustment for the S-meter and power meter settings. Because the signal (in terms of amplitude) is really miniscule in the USRP, the signal read, for the most part, becomes really small as well. Due to the sinusoidal nature of the signal, negative values may occur if the signal is particularly strong. This is why there are multiply constants and add constants to adjust the amplitude level so it becomes a readable and understandable value. The constants specified in the code are through calibration in the laboratory; these constants are unique to the amplifiers used in the project, and are likely to vary user-to-user. These constants may be changed near the bottom portion of a mode's Python code, in the definition for TX and RX switching. The second topic of importance is the audio rate in the NBFM Transmit block. In the block's Python code, the comments specified that the minimum audio rate has to be at least 16k, and it must be an integer multiple of the quadrature rate. Since the quadrature rate is 48k, 16k works the best since it is the lowest value possible while still 20

conforming to the specifications of the NBFM block. However, 16k did not work through experimenting with the block. At 16k, overruns/underruns occurred, dramatically reducing the performance. Therefore, the next step is to make the integer multiple 2, or 24k for the audio rate. This change made all the overruns and underruns disappear. During the time of this writing, it is unsure why 16k does not work even though the comments in the Python code stated it would. There may be a guide on how to calibrate the constants for the S-meter and power meter in the near future.

21

Frequently Asked Questions Q: How do I get started? A: Please refer to the "Installation and Setup" section. Q: I started a mode but the sliders and values are all out of place/gone! What do I do now? A: Go into your directory, and find config_xx.txt where xx is your mode in question. Every mode has different number of features, but follow the template similar to below: For AM: RX1 Freq RX2 Freq TX Freq RX1 Volume RX2 Volume TX Carrier LPF1 BW LPF2 BW Mic Volume ("TX Drive") Meter Band RX Freq Min RX Freq Max Simplex/split choice Last Saved Timestamp So for example: 14200000 0 14200000 0.7 0.7 2.0 3000 3000 2 5 14000000 14350000 0 Wed Dec 2 19:44:16 2009 22

This should restore the mode to working condition. Note that the variable declarations at the beginning of a mode's Python file are declared in the order the values are read in the configuration file. The values don't have to be realistic or accurate; the file just needs to have the correct number of values so the Python script may run.

Q: The GUI/FFT Window feels very laggy, why? A: The GUI takes up very little processing power. The majority goes into mode processing such as FFT, calculating raw data, etc. The code has been streamlined, but inefficiency is likely due to the CPU, inherent lag from GNU Radio/USRP, or just too much code per mode.

Q: I tried to close the GUI/FFT Window, but I can't! How can I get out? A: For FFT Window, try alt + F4; for GUI, go to your command prompt that started the GUI and do ctrl+c. If all else fails, then as a last resort do alt+F2, type in xkill, then click on the window you want to close.

Q: What are all the uUuU/uOuO stuff in the command prompt? A: Simply put, that is GNU Radio's way of saying underrun and overrun. From GNU Radio's website: "u" = USRP "a" = audio (sound card) "O" = overrun (PC not keeping up with received data from usrp or audio card) "U" = underrun (PC not providing data quickly enough) aUaU == audio underrun (not enough samples ready to send to sound card sink) uUuU == USRP underrun (not enough sample ready to send to USRP sink) uOuO == USRP overrun (USRP samples dropped because they weren't read in time. For more information, please visit: http://gnuradio.org/trac/wiki/UsrpFAQ/Gen. If the link is dead, go to gnuradio.org and navigate to the USRP section.

Q: I can't switch between TX and RX using PTT anymore. What's going on? A: Click on the PTT button. What happens is when you do things like scroll the slider or change a value in the textbox, you lose "focus" and PTT button will not be binding to the TX/RX switching. Clicking on the button will allow you to regain control of the switching.

23

Q: When I tried running SDR Transceiver software, I get a permission denied error. A: Type chmod +x abc.py where abc is the name of the file in question (most likely gui.py). Typing chmod +x will give the permission the file requires to be fully functional. In the future, a bash script may be provided so the user will not (hopefully) run into this issue. Q: I got a an error on "bash: ./gui.py: /usr/bin/python^M: bad interpreter: No such file or directory": A: It is an issue with CR and LF. You can use dos2unix gui.py (if the command is available in your operating system variant), or you can do the following: Open gui.py. The first line will be "#!/usr/bin/env python." Put your cursor over to the next line (2nd line, which should be empty). Now hit backspace so the cursor is on the first line (the usr bin line). Now hit enter. The issue should now be resolved.

24

why sdr

Recommend Documents