DARPA Spectrum Challenge Q&A

Please also check ​DARPA Q&A for additional answers

Tournament Q&A

1. Q: In Hurdle 3, the bandwidth limitation was 2.5MHz. Will the restrictions be the same for the Preliminary Tournament?
   A: No, the Tournament has different limitations. The guidelines for radio designs are specified on the DARPA web page: ​http://dtsn.darpa.mil/SpectrumChallenge/DesignGuidelines.aspx
2. Q:The packet server will never send any packets during the entire 180 second experiment.
   A: In case of the packet server failure the error will be immediately shown in the output

    INFO Experiment: load system:exp:eventlib
    INFO Experiment: load system:exp:winlib
    INFO Experiment: load system:exp:dsc-test
    INFO property.freq: freq = 650000000 (Fixnum)
    INFO property.server: server = "10.17.0.10" (String)
    INFO property.port: port = 5123 (Fixnum)
    INFO property.runtime: runtime = 20 (Fixnum)
    INFO property.mode: mode = "COMP" (String)
    INFO exp: Connecting to packet server
   ERROR exp: pkt_server not available
   Exception exit INFO NodeHandler: 
    INFO NodeHandler: Shutting down experiment, please wait...
    INFO NodeHandler: 
   

   Lack of such error message suggests that the problem is with the tx/rx code execution on one of the nodes (or a problem in communicaiton between USRP and the node).
3. Q:We tried to use the zdc_framework with our code in a 64-bit kernel. The zdc_framework kept saying that the nodes (with the 64-bit kernel) were not on. We didn't have the problem when a 32-bit kernel was used. Could you help us on this?
   A: The problem is most likely related to outdated OMF Resource Controller package on the image. Just upgrading the omf-resctl-5.4 should fix the issue:

   apt-get update
   apt-get install omf-resctl-5.4 omf-common-5.4
   

   Alternatively, one can do the full upgrade:

   apt-get update
   apt-get upgrade
   

   to bring all the packages to their latest versions.
4. Q:We couldn't find the USRP on nodeX-Y. Tried uhd_find_devices, uhd_usrp_probe, and ping. None work. Is it power-on?
   A: The USRPs in ORBIT share power supply with the node so that power-cycling the node will also restart the USRP. Please use "omf tell -a offh -t nodeX-Y" followed with, after a few seconds, "omf tell -a on -t nodeX-Y" (just resetting the node "omf tell -a reset" will NOT reset the USRP).
5. Q:So the competition frequency range is only upto 1 GHz?
   A: The center frequency for the Preliminary tournament would be between 550-650 MHz.
6. Q:In what bandwidth do the monitoring coupler specifications apply?
   A: The couplers are rated for 1 to 1000 MHz with mainline loss of less than 0.6 dB.
7. Q:Is frequency and mode (COMP/COOP) the only inputs for our code? i.e., Can we hardcode the port numbers 5123, 5125 and the server "idb2" in our tx/rx codes?
   A:Yes frequency and mode are the only parameters for the grid deployment (i.e. if you want to use sandboxes for development you would need to have the packet server host name as parameter since; sandboxes are using console to run a modified packet server given that they have only two nodes; the ports are the same for all packet server instances).
8. Q:Does the final dsc-challenge.rb script need only python files as inputs? Or do they just need to be some executables? Will the format of the dsc-challenge.rb (dsc-match.rb) be the same as it is shown now in the website?
   A:The script really doesn't care what type of executable it is - as long as the filename and path stay the same (and the file is executable) the script should work.
9. Q:When is the event ALL_UP_AND_INSTALLED triggered? Is it when both the transmitters send request for packets and when both the receivers connect to the 5125 port?
   A: ALL_UP_AND_INSTALLED event is triggered when OMF frameworks receives node registration confirmation and verifies that all applications are ready to run (since we are not installing any applications dynamically but just registering them as part of the script, this really means the node booted properly and registered with OMF controller).
10. Q:What is the maximum time for the competitive and cooperative match?
    A: 180 seconds for each.
11. Q:Will there be other interference sources besides the House radio bot?
    A: During the Wildcard matches the only interference that teams will encounter will come from the house radio bots that they will face. During the Preliminary Tournament, teams will not compete against the house radio bots. Instead teams will face each other, and will also experience the injection of small amounts of intermittent interference. This interference will be designed to impact all teams equally. In order to ensure that teams build radios that are general and are not designing for a specific interference type, the exact specifications of this interference will not be provided.
12. Q:Can the sink radiate for doing feedback or other purposes?
    A: Yes, the sink node may also transmit in order to engage in feedback, or for whatever purpose the team's feel appropriate.
13. Q: For each team's sink node in the DARPA Spectrum Challenge tournaments, will the USRP SBX daughtercard have an antenna connected to the "TX/RX" port, the "RX2" port or both?
    A: Each node has both antennas attached as shown in the image below.
    
14. Q: I realize that the configuration is referred to as "tentative", but I am hoping to receive confirmation for the USRP2's tagged as Team A and Team B as to whether they are the source or sink.
    A: Each team gets two nodes with a source in the lower-left corner and a sink in the upper-right corner (tournament node assignment figure below). Please note that only sources are allowed to draw packets from the packet server and that only sinks nodes are allowed to submit packets to the packet server for scoring. The team nodes are:
    • Team A: node20-19 is a source; node2-1 is a sink
    • Team B: node19-20 is a source; node1-2 is a sink
    • Team C: node19-19 is a source; node1-1 is a sink
15. Q: We just want to make absolutely certain what those constraints are in terms of physical hardware specs so that when we log into ORBIT to test our designs, we know if we're using the "target" systems that will be used in the tournament. We also want to make certain that all teams in a cooperative or competitive match will have *identical* hardware for their pairs of transceivers so that all teams are operating under identical constraints.
    A: Both cooperative and competitive matches will have identical hardware (i.e. GLV-67G based nodes with USRP N210 and SBX). The actual nodes that will be used for the tournament are shown in the figure below. Also, the nodes in SB2, SB3 and SB7 are identical to the tournament nodes in the grid and are intended for code development and testing.
    

Hurdles Q&A

H3

1. Q: Is there any problem with simply removing oml-cli process invocation? Do we need to keep OML logging code found in benchmark_[tr]x3.py?
   A: Given that the only settable parameter in H3 is frequency, oml-cli (OML code) is not required and can simply be removed.
2. Q: How can I save my image? We are having problem saving our image, can you please advise?
   A: You have to use Fully Qualified Domain Name (FQDN) of the node as an argument i.e. if you have a reservation for DCGNUR14 and want to save image from node3-13 you have to issue a command:
   NOTE: All nodes used in DARPA SPectrum Challenge are part of grid.orbit-lab.org domain.

      omf save -n node3-13.grid.orbit-lab.org
   

3. Q: Why are we seeing read-only/corrupted file system when we boot our image (after saving our image from one of the nodes on zDCXX and loading it on the nodes in another domain)?
   A: It is possible that older nodes are having a disk issue and that is why it is essential that you check your saved image by loading it on a pair of nodes (preferably on DCGNURXX). Also, quite often older nodes have much smaller size disk and it is safer to re-size partitions during both load and save (on zDCXX) i.e. for target partition of 15GB:

      omf load -i darpahurdle23.ndz -o 1500 -r 15 -t system:topo:all
      ...
      ...
      omf save -r 15 -n nodeX-Y.grid.orbit-lab.org
   

4. Q: Why is my imaging timing out? Why, after imaging zDC09 with darpahurdle23.ndz, can't I ssh into my nodes?
   A: Trying to put large images (especially) on the older nodes (zDCXX domains) will quite often take longer than the default timeout. In order to extend it, one should use the -o option i.e.

      omf load -i darpahurdle23.ndz -o 1500 -t system:topo:all
   

5. Q: Can you provide a description for how interference will spill into the adjacent 1.25MHz band?
   A: During moments of 1.25MHz interference, the spill over into the adjacent non-interfered 1.25MHz band will be such that the average SNR over that band will at least be 10dB better than the SNR in the interfered band.
6. Q: How can we make sure our image is not left on the node after our slot expires? A: Re-imaging nodes at the end of your slot (with say baseline.ndz which is typically much smaller than GNURadio based images) will ensure that. Even just starting the imaging process (after the point when the nodes check in) will be enough to render the disk reasonable unreadable.
7. Q: Is it true that the distances between the nodes that will be used for hurdle 3 evaluation same as the distance between the nodes that we have access to, during the qualification period?
   A: The topology will be similar to DCGNURXX configurations.
8. Q: Can we install a 64-bit environment on the ORBIT node and make our own image of it?
   A: You can customize/use any environment (as long as FPGA is not changed); please don’t forget that we will use only benchmark_tx3 and benchmark_rx3 found in gnuradio/gr-digital/examples/narrowband to run the evaluation and that it is your responsibility to have them there.
9. Q: USRP2 on nodeX-Y is not responding to uhd_usrp_probe - can you please help? Why is USRP2 on nodeX-Y not responding to ping?
   A: In most cases all that is needed is to power-cycle the USRP which is achieved by power-cycling the node (turning the node off turns off the attached USRP2 also). For example, to power-cycle the USRP2 on node16-5:
   

       omf tell -a offh  -t node16-5.grid.orbit-lab.org
       # ... wait for 10-20 seconds
       omf tell -a on  -t node16-5.grid.orbit-lab.org
   

10. Q: Can we assume that the nodes will be stationary?
    A: Yes, the nodes will be stationary.
11. Q: What can we assume for the available processing power for Hurdle 3? Can we assume that the hardware will be the same as the DCGNUR nodes? Are all these nodes identical?
    A: Yes, it will definitely be a pair of DCGNURXX nodes; unfortunately nodes are not all identical (even though they all have a variant of Quad Core i7 CPU). As for the actual CPUs that we plan to use for the evaluation, it will be a pair of (output of lshw): Intel Corp. Intel® Core™ i7-2600 CPU @ 3.40GHz 6.10.7
    Again, no guarantees that any particular one (of the existing 18 DCGNURXX) will be used…
12. Q: Would it be possible to know the maximum frequency offset between the transmitter and receiver?
    A: It will be consistent with standard for SBX front-ends.
13. Q: How do we interpret the given frequency, passed in as —freq to benchmark_[rt]x3.py?
    A: Frequency specified with —freq is the center frequency and the channel extends ± 1.25MHz around it.
14. Q: How is 2.5 MHz bandwidth measured?
    A: It is a 3 dB bandwidth (of 2.5 MHz max).
15. Q:How is noise being added to the environment? What is meant by: "received SNR might range from 0dB SNR to 10dB"?
    A: Real noise is being injected into the environment (i.e. affecting both ends of the link). The injected noise level will be adjusted so that SNR measured by the receiver will be somewhere between 0-10 dB when the transmitter is transmitting at the maximum power (100 mW for SBX front-end). Further, the noise level will be fixed for all time slots that include interference, i.e., N1 and N2 slots.
16. Q: Can we assume that the nodes are time synchronized (e.g., using NTP)? If not, is it allowed to install something like NTP on the hosts?
    A: Nodes are synchronized with the NTP server at boot time. However, once the testing starts the nodes can only talk to the packet server service over the Ethernet and thus NTP synchronization can't be maintained.
17. Q: Is the packet source an "infinite" source or is the packet source a fixed-length with known maximum number of bytes? Is it permissible to refactor the packet get/put code? Does the order of received packets matter?
    A: The packet source/sink is a TCP based packet server that generates an infinite number of random packets on request (i.e. each packet has to be requested separately by the sending application). Packet receiver is going to compare against sent packets however, packet ordering or lost packets does not matter in calculating performance. During the Qualification Period, the test server will send a report to experimenters on one of the 3 triggers: a.) 5 min. timeout is reached, b.) transmitter closed the TCP connection or c.) receiver closed the connection. Packet get/put can be changed but has to work with the existing packet server and it is experimenters responsibility to test their code against the Hurdle 3 test server (python code in the banchmark_tx3 and banchmark_rx3 is there just as a template).
18. Q: For Hurdle 3, timing and evaluation are handled by the server. Should the TX/RX modules continuously until the 10 minute RX timeout is reached?
    A: Yes, you should continuously transmit packets until the timeout. We will evaluate on a 5 minute chunk of time during your run. A performance monitoring server will be running during the Qualification Period and will send you an email with number of packets that were successfully received in the 5 minute period.
19. Q: Are there any requirements to maintain any of the existing structure of the tx/rx modules, as long as the rx timeout and packet server source/sinks remain unchanged?
    A: The requirements are that you must retain the packet structure reading from the packet source, and the packet structure going into the packet sink. Failure to do this will mean that you will not pass the checking mechanism. You must also keep the same “center frequency” argument structure on the command-line of your program since we will use this to launch your code for evaluation (and keep corresponding logging functions). Generally, you may do whatever else you wish with the radio (without touching the FPGA or stepping outside of the 2.5MHz baseband - we will check to make certain you stay in the band). Please note that your radio module must automatically set many of its own parameters (such as gain) since the evaluators will not try to optimize parameter selection for teams.
20. Q: Are we set up for full-duplex communication, i.e., can we have a return path for ACKs, etc.?
    A: The final evaluation for Hurdle 3 will be done on a pair of nodes with the SBX front-end. Bi-directional communications is allowed as long as it is done within the 2.5 MHz channel. Teams are advised to be aware of their schedule assignment during the development period since some USRPs have the XCVR front-end. Teams are advised to fully understand the limitations of the SBX front-end when trying to implement sophisticated protocols, as well as the limitations that might be faced when developing on the XCVR for eventual testing with the SBX.
21. Q: May we modify GNURadio code on the node? Can we use C++ blocks? Can we use custom code? Can we use OFDM modules? May we encapsulate packets with FEC in the transmitter and then strip the FEC in the receiver?
    A: You may do anything with the code as long as packet source/sink communication is maintained and command line option for setting frequency ( -f ) is maintained. It is experimenters responsibility to test their code against the Hurdle 3 test server. Teams are reminded that they are NOT allowed to change the FPGA code.
22. Q: Is it correct that the final transmitter and receiver scripts must reside in /root/gnuradio/gr-digital/examples/narrowband/
    A: Yes you have to keep this path - it will be used by us to run your transmitter/receiver.
23. Q: Why are we getting repeated connection timeouts when running benchmark_tx2.py?
    A: There is a hard limit on number of sessions that the packet source can handle at a time, and when you witness connection timeouts this is due to too many teams making simultaneous requests to the packet source.
24. Q: Is there some recommended image to use which combines in some way ath5k or ath9k devices and gnuradio? Can we use exisitng WiFI radios for feedback channel?
    A: Teams are not allowed to use communication interfaces other than USRP (whether wired or wireless). In other words, you can't use WiFi/Bluetooth/ZigBee/Ethernet devices to talk between the two nodes.

H2

1. Q: Given that they don't have USRP hardware, what is the purpose of zDCXX domains?
   A: The zDCXX domains are general purpose only, and can't be used for USRP testing. However, they might be useful for other functions, such as working with images, debugging, working with omf (useful tool to get familiar with), etc.
2. Q: I would like to find out the procedure to access a specific domain when I have been assigned two domains which overlap in time.
   A: All omf commands accept -t flag which specifies a set of resource (nodes). That set can be specified as either list of nodes or a path to file containing a resource set. So if you have multiple virtual domains reserved, system:topo:all would refer to all nodes contained in all domains. If you just want to work with a subset of nodes, you could simply list them on a command line. For example, if you have approved reservation for zDC01 and DCGNUR01 and wanted to say image only nodes in DCGNUR01 you would issue

       omf load -i darpahurdle1.ndz -t node1-1.grid.orbit-lab.org,node3-3.grid.orbit-lab.org
   

H1

1. Q: Are the resource times for our schedule in EST or in our team's local time which is MST?
   A: All the resource times in the schedule email are in EST (Eastern Standard Time).
2. Q: Is it permissible to test the ssh public key mechanism prior to the reservation time?
   A: Please feel free to test the keys against gw.orbit-lab.org