Changes between Version 8 and Version 9 of DSC/QandA

Timestamp:

Feb 19, 2013, 9:39:12 PM (12 years ago)

Author:

seskar

Comment:

—

DSC/QandA

@@ -29 +29 @@
     A: Yes you have to keep this path - it will be used by us to run your transmitter/receiver.
  1. 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?''' [[BR]]
-    A: You may do anything with the code as long as packet source/sink communication is maintained and command line option for setting frequency 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.
+    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.
  1. Q: '''Are we set up for full-duplex communication, i.e., can we have a return path for ACKs, etc.?''' [[BR]]
     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.
@@ -38 +38 @@
  1. 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?''' [[BR]]
     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). 
- 1. 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?'''
+ 1. 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?''' [[BR]]
     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. 
- 
+ 1. Q:'''How is noise being added to the environment?''' '''What is meant by: "received SNR might range from 0dB SNR to 10dB"?''' [[BR]]
+    A: Real noise is being injected into the environment (i.e. affecting both ends of the link). The SNR range is being calculated relative to the maximum transmit power (measured by the receiver) of the SBX front-end (maximum transmit power for SBX is 100 mW). 
+ 1. Q: '''How is 2.5 MHz bandwidth measured?''' [[BR]]
+    A: It is a 3 dB bandwidth (of 2.5 MHz max).