[[Include(WikiToC)]] == Getting Started with COSMOS SDR Resources == === Description === In this tutorial we'll demonstrate how to run a basic wireless experiment using software defined radios in the COSMOS testbed. Two COSMOS nodes will be used: one to transmit a signal, and the other to receive it. This tutorial will also give some information about the basic orbit workflow, so be sure to read to the end. === Prerequisites === All tutorials on the COSMOS wiki assume that you have already created a user account through [https://www.orbit-lab.org/userManagement/register the new user registration form]. In order to access the test bed, create a reservation on [https://wiki.cosmos-lab.org/cPanel/controlPanel/start the online scheduler] and have it approved by the reservation service. Access to the resources are granted after the reservation is confirmed. Please see the page describing [wiki:CosmosOverview/Workflow the COSMOS work flow page] for more information. === Resources required === For this example we used two USRP 2974 SDRs on [wiki:Architecture/Domains/cosmos_sb1 sandbox 1]. These SDRs have an onboard SOM with an i7 processor, which is the device you're loading the orbit image onto and connecting to over ssh. They also have an fpga connected to the four antennas. We won't have to worry about the specifics of the USRP for this tutorial but you can look at the links on [https://www.ettus.com/all-products/usrp-2974/ this page] for more information. === Tutorial Setup === Follow the steps below to gain access to this console and set up your node with an appropriate image. 1. [GettingStarted#MakeaReservation Create a resource reservation] for sandbox 1. 2. Once your reservation is approved, [wiki:GettingStarted#LogintoyourReservation login into the console] using ssh. Since you are using sandbox 1, you will ssh to {{{#!shell YOUR_USERNAME@console.sb1.cosmos-lab.org }}} 3. Use OMF commands to load the baseline-uhd.sdr image on your resources. OMF is a command line utility that is run from the console in order to manage nodes: turn them on and off, save the contents of the hard disk as an "image", and load saved images back onto them. In this case, we're loading the "baseline-sdr.ndz" image, which is a pre-built image provided for researchers to use as a starting point. The image contains UHD 3.15 and Gnuradio 3.8 and uses Ubuntu 18.04. {{{#!shell omf load -i baseline-sdr.ndz -t sdr2-s1-lg1,sdr2-md1 }}} This is a good opportunity to look at the output of the image loading process. At first glance, it can look like a lot of text, but there is some useful information there to help you understand what is going on. Here is the output of running the above command: [[Image(image-save.png)]] We can see from this output that the image loading process has two phases: the first, noted in red, in which OMF is waiting for the nodes to boot up and load a client which will receive the omf image data and write it to disk; and the second, noted in blue, in which OMF actually performs the imaging process. This output shows a successful imaging process-- we can tell because of the text noted in pink, which says that the imaging process is done and there were two nodes successfully imaged. The filename displayed there will contain a list of all the nodes which were successfully imaged. Once in a while, you may see an imaging process where some or all of the nodes fail to image. This can happen because something goes wrong either in the first step (a node fails to boot up and register with the imaging process) or in the second step (the node fails to load the image onto its hard disk). If there is a failure, it will be noted in the output at the end of the imaging process-- there will be additional files listed for nodes that fail to check in, and nodes in which imaging failed. Always check the output to make sure that your nodes were successfully imaged. 4. Once the nodes are successfully imaged, turn them on and check the status {{{#!shell omf tell -a on -t sdr2-s1-lg1,sdr2-md1 }}} {{{#!shell omf stat -t sdr2-s1-lg1,sdr2-md1 }}} 5. After waiting for the nodes to power up and boot, you will be able to ssh to them from the console: {{{#!shell ssh root@sdr2-s1-lg1 }}} NOTE: for some nodes, such as the server machines, it can take several minutes for a node to finish the booting process. This is normal, and you'll have to wait until the nodes is fully booted before you can ssh to it. 6. Once you have an ssh session on either machine, you can verify that it is the proper type of node by looking at the output of {{{lshw}}}: [[Image(lshw.png)]] === Experiment Execution === ==== Configure and detect the radio ==== NOTE: The USRP 2974 requires a PCIe driver to control the FPGA with the embedded PC. In the provided images, this will load automatically on boot. If it has issues, you can run it manually via {{{ systemctl restart niusrprio.service}}}. Detailed steps for driver installation and radio detection are on the [Resources/Notes/KryptonUsage Krypton usage page]. There is also a trouble shooting section at the bottom on that page to update the Krypton's internal firmware if necessary. 1. Use {{{uhd_find_devices}}} to make sure that the onboard x310 SDR is detected: [[Image(find_devices.png)]] Notice that running this command with no arguments will sometimes detect other SDR resources in the testbed which are reachable over the network. We can ignore those for now and focus just on the onboard x310. 2. Use the {{{uhd_usrp_probe}}} command to get more details on the x310. Specifying {{{resource=rio0}}} ensures only the directly connected radio is probed, instead of the radios on the network. [[Image(uhd_probe.png)]] NOTE: if you are running this experiment on another sandbox in which the USRPs are connected to the nodes over an ethernet interface, you can make the USRP accessible by following the instructions on [https://www.orbit-lab.org/wiki/Tutorials/k0SDR/Tutorial27#PreparenetworksetupforUSRPaccess this page] under "Prepare network setup for USRP access". === Run the experiment === For this demo, we'll be running some of the demo applications that are installed with uhd. Source code for all of the samples can be found here: [https://github.com/EttusResearch/uhd/tree/UHD-3.15.LTS/host/examples] 1. ssh to sdr2-md1 and start the rx_ascii_art_dft demo with the following command: {{{#!shell /usr/lib/uhd/examples/rx_ascii_art_dft --args "resource=rio0,type=x300" --freq 2400e6 --rate 5e6 --frame-rate 10 --gain 10 --ref-lvl -30 --dyn-rng 70 }}} Note that we are looking at the frequency band around 2.4GHz. You should see an output like this: [[Image(rx-ascii-no-sig.png, width=1000px)]] 2. ssh to sdr2-s1-lg1 and start the tx_waveforms demo with the following command: {{{#!shell /usr/lib/uhd/examples/tx_waveforms --args="resource=rio0,type=x300" --wave-freq 1e6 --wave-type SINE --freq 2400e6 --rate 5e6 --gain 10 --ampl 0.2 }}} As we can see from the arguments passed to the application, we are transmitting a 1MHz sine wave as a signal using 2.4GHz as the carrier frequency. On the DFT visualization on sdr2-md1, you should see a peak representing the transmitted signal: [[Image(rx-ascii-sine-sig.png, width=1000px)]] We can generate a different type of signal by changing the {{{wave-type}}} argument. For instance, if we transmit a square wave: {{{#!shell /usr/lib/uhd/examples/tx_waveforms --args="resource=rio0,type=x300" --wave-freq 1e6 --wave-type SQUARE --freq 2400e6 --rate 5e6 --gain 10 --ampl 0.2 }}} We can see that the spectrum of the received signal now contains multiple peaks. This is the result of the spectral characteristics of a square wave. [[Image(rx-ascii-square-sig.png, width=1000px)]] Both {{{tx_waveforms}}} and {{{rx_ascii_art_dft}}} can take {{{--help}}} as a command line argument, which will display the lists of arguments that you can provide and what each argument does. There are also a number of other demo applications in the {{{/usr/lib/uhd/examples}}} directory, which you can take a look at.