Wireless-robot

Transcript

Wireless Robot Communication Project June 20, 2013 Charles McIntosh Advising Faculty: Elizabeth A. Thompson, Ph.D. James Isaacs, Ph.D. Exelis Engineers Advising: Ross Sneary Eric Harmison Abstract: This work represents the initial phase of an effort to support an on-going project by characterizing the wireless communication link of a teleoperated robot. The purpose of this effort is to get the robot system up and running using its new 802.11n technology, to make preliminary network measurements using the new standard, and to define measurement and experiment procedures for testing network performance. (The 802.11n standard is said to have better multipath performance than previous 802.11x standards.) By installing network performance software on both the robot and its base station, the current wireless communication link is tested for throughput and packet loss rate. These tests are performed in both line-of-sight (LOS) and non-line-of-sight (NLOS) environments. It is found that the existing wireless configuration provides LOS communication with relatively high throughput and minimal packet loss over at least 400 feet, while in NLOS environments, the signal can fade completely in a much shorter distance. The groundwork is laid for further testing using 900 MHz wireless technology. 1 Table of Contents Introduction .................................................................................................................................................. 3 Procedure...................................................................................................................................................... 4 Testing Setup ................................................................................................................................................ 7 Determining Iperf Test Commands ............................................................................................................... 8 Characterizing the 2.4 GHz Spectrum ......................................................................................................... 11 Equipment ................................................................................................................................................... 14 Results ......................................................................................................................................................... 15 Conclusions ................................................................................................................................................. 17 Future Testing ............................................................................................................................................. 18 Appendix ..................................................................................................................................................... 22 2 Introduction The robot to be tested (Figure 1) was originally built by Eric Harmison and Robert Carper in 2004 as a project between IPFW and ITT Exelis. The original robot could be controlled wirelessly in real-time. A 2010 IPFW senior design team improved the robot, upgrading the computer and adding its current open source operating system OpenSUSE, a GPS device, sensors, and a more stable base. A 2012 IPFW senior design team further modified the robot, making the ultrasonic range sensors operational, the camera able to be controlled be a remote user, and the robot semi-autonomous (i.e., able to navigate to specified coordinates.) Figure 1: The robot has been modified by two successive design teams after its original build, now featuring auto navigation capability with its GPS and sensors that allow the robot to detect and avoid obstacles, as well as its original teleoperation capability. In its past history, the performance of the robot’s communication link has been evaluated using the IEEE standard 802.11b and 802.11g wireless network cards as well as the proprietary MeshNetwork cards (Thompson et al., 2006). The robot’s current wireless link technology, which had not been tested, is an 802.11n standard router (ASUS RT-N16 Multi-functional Wireless N Router) installed on the robot and a USB wireless card (Linksys WUSB300N) on the base station. This new standard is thought to be an improvement over the previous 802.11 standards, so testing of this new technology would provide insight into how well it actually performs in both line-of-sight (LOS) and non-line-of-sight (NLOS) environments, while also allowing an updated assessment of the robot’s current capabilities. Standard 802.11b/g/n technology uses the 2.4 GHz industrial, scientific, and medical (ISM) radio band. This band, although ideal for most applications of the technology due to its free price tag and relatively short-range applications, is crowded with countless devices including, besides other 802.11 devices, baby monitors, cordless phones, and Bluetooth devices. This could make high throughput on this band difficult to achieve consistently. Additionally, because of its shorter wavelength, 2.4 GHz radio does not travel as far or deal as well with obstructions as do lower-frequency radios. For robotics applications, the 900 MHz ISM band is of interest due to its favorable propagation characteristics. In particular, an 3 orthogonal frequency division multiplexing (OFDM) waveform at 900 MHz is thought to be optimal to provide the desired range, the bandwidth required for video streaming, and a rugged waveform designed for NLOS applications. Procedure Network Monitoring Software: In order to test the wireless communication link between the robot and its base station, a network monitoring program is necessary. Several alternatives, including Qcheck, PathTest, and Iperf, are tested. Qcheck is a tool based on the well-known and reputable software IxChariot, which allows the user to monitor and troubleshoot large networks (“Qcheck - Free Network Benchmark Utility”). Qcheck is a utility much smaller than IxChariot that allows testing of basic network properties, such as Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) throughput, network delay, and UDP bit error rate. It is installed by configuring an “endpoint” at one end of a network path, and then using the Qcheck utility at the other end of the network path to run tests by communicating with the endpoint. It is not necessary to have a physical presence at the computer with the endpoint in order to run tests. IxChariot has many versions of the Qcheck endpoint software designed for installation on different operating systems. PathTest is a free tool from AppNeta, a company that also focuses on providing network management and performance monitoring software (“Free Accurate Network Performance Testing Tool”). Its PathTest software is a network capability testing, (network load testing) utility similar in purpose to Qcheck, although with more limited options. Iperf (Figure 2) is an open-source software that measures the maximum TCP bandwidth of local area networks (LAN), allowing the tuning of various parameters (“Iperf”). It can also measure UDP characteristics including bandwidth, delay jitter, and datagram (packet) loss. Iperf is cross-compatible with multiple operating systems, including a wide range of Linux offshoots as well as Windows XP. The full software must be installed on both computers at the ends of the network path to be tested. Once installed on each system, Iperf is run (via command line) by setting up one computer as a server (Figure 2(a)) and the other computer on the network as a client (Figure 2(b)). A link is established in Iperf between the two computers and tests can then be run between them. The client sends data, while the server receives data. Physical presence at each computer is required in order to run the necessary commands. 4 2(a):Server 2(b): Client Figure 2: These are two screenshots of Iperf, the top (2(a)) from the base station and the bottom (2(b)) from the robot. In the example documented here, the base station is set up as the server and is receiving a UDP data stream in 1000 byte packets. The robot is set up as the client and is sending a data stream of 1.05Mbps (default) in 1000 byte datagrams for ten seconds. Each of the three software solutions is tested. The latest applicable versions of Qcheck are installed on both the robot and the base station. Though apparently installing successfully on both computers, Qcheck is able only to achieve partial, error-riddled communication between the two computers in a lab environment, and consequently is unable to run the desired tests. PathTest cannot be installed on the robot’s OpenSUSE operating system, and so cannot be used for testing. Iperf installs correctly on both the robot and the base station; version 2.0.4 is used for both systems. It functions correctly, and is consequently used as the means of testing the network performance of the robot’s communication link. 5 Figure 3 shows the Iperf commands necessary to measure TCP throughput. The base station command is run first; it establishes the base station as the server (-s) so that the robot is sending data to the base station. It also disables Nagle’s algorithm (-N), which restrains the sending of TCP data until a significant amount is ready to send; the disabling of this algorithm allows greater throughput. The robot command is run after the base station has begun “listening” for a client. The robot command establishes the robot as the client (-c) and disables Nagle’s algorithm (-N) on the robot computer as well. To connect with the base station, the IP address of the base station is specified. The command also sets up the datagram size (-l) as 1472 bytes and the sending time (-t) as 30 seconds. Figure 3: These are the Iperf commands to measure TCP throughput. The base station is set up as the server and the robot as the client. The effect of this command is that the robot sends a TCP stream of data as large as it can to the base station for 30 seconds, all in datagrams of 1472 bytes. (By using Wireshark, a free tool for analyzing network packets, it is found that the actual size of these packets is 1514 bytes; the extra data is due to the several headers from the different network layers.) Iperf then reports the total data transferred and the throughput of the test. Each test is performed once at ten-foot intervals until the wireless signal is lost. The base station command (Figure 4) is run first; it establishes the base station as the server (-s) and instructs Iperf to listen for a UDP stream (-u) rather than a TCP stream. It also establishes the datagram size (-l) as 1472 bytes. (Testing using Wireshark shows that datagram sizes above 1472 bytes on the robot’s wireless communication link are fragmented.) The robot command is run after the base station has begun “listening” for a client; it specifies the IP address of the base station, instructs Iperf to send UDP data, and specifies a datagram size (-l) of 1472 bytes. The command also specifies a sending date rate (-b) of 8Mbps and a sending time (-t) of thirty seconds. Figure 4: These are the Iperf commands to measure UDP packet loss. The base station is set up as the server and the robot as the client, as with the TCP tests. The result of these commands is that the robot sends a UDP data stream to the base station at a constant rate of 8Mbps for thirty seconds in datagrams of 1472 bytes (which translate to packet sizes of 1514 bytes). Iperf records the total amount of data transferred, the packets lost and the total number of packets, and the packet loss rate as a percentage. Each test is performed at 10-foot intervals until the packet loss rate exceeds ten percent. 6 For future tests, in addition to UDP packet loss, response time and UDP throughput may also be measured. Response time can be assessed using the Windows ping utility. UDP throughput (Figure 5) can be measured by employing the same commands that are used for measuring UDP packet loss rate. Figure 5: These commands may be used for UDP throughput testing. As in the TCP throughput and UDP packet loss tests, the base station is the server and the robot is the client. The difference in testing procedure for UDP throughput as opposed to packet loss is that the tests are repeated at the same distance with the data rate increased or decreased by 5Mbps intervals until the packet error rate rises above ten percent. Then the results of the test at the highest bandwidth that is below ten percent packet loss are recorded, the distance is increased by ten feet, and the procedure is repeated for the new distance. Testing Setup Both LOS and NLOS testing routes are determined. For indoor LOS testing, a straight path from the east entrance on the 3rd floor of the ETCS building on the IPFW campus down the hallway to Room 311 is used (segment AB of Figure 6). (This indoor “LOS” environment is actually only partially LOS; because of the walls and irregularities of the path, it is somewhat a NLOS environment.) Indoor NLOS testing (Figure 6) is performed by keeping the robot at the east entrance (identified as point A in Figure 6) and moving the base station down the hallway through three turns toward the elevator and stairs. Outdoor LOS testing is performed using the sidewalk north of the main IPFW campus west of the tennis courts (Figure 7); this choice of location ensures an environment relatively free of other 2.4 GHz activity. Figure 6: This describes the indoor testing setup. The robot is positioned at A throughout testing. The base station is consecutively moved from A to B, from B to C, from C to D, and from D to E. AB is 115 feet, BC is 52.5 feet, CD is 10 feet, and DE is 10 feet. 7 Figure 7: This depicts the testing setup for the outdoor LOS testing. The actual robot is in the bottom left. The base station is on the light-colored cart. Note the generator far in the background on the right side of the sidewalk. The physical setup and components of the base station and client are as follows. The base station is a desktop PC with a monitor, keyboard, and mouse set up on a portable metal cart about three feet high. The wireless USB adapter is positioned on top of the cart behind the monitor (which faces away from the robot) so that there is a clear line of sight between the wireless adapter and the robot. The robot is placed on the ground about two to three feet away from another metal cart on which are a monitor, mouse, and keyboard, all connected to the robot computer. The robot is oriented so that the router’s three antennas are on the side of the robot closest to the base station for maximum signal strength. The robot’s router is powered by its two twelve-volt batteries, while its computer, for testing purposes, is powered via AC power. For indoor testing, the robot computer and the base station computer are powered from wall sockets; however, for outdoor testing, a generator is used to supply power to both the base station and the robot (Figure 7). Determining Iperf Test Commands To determine the packet size to use for Iperf testing, a free tool called Wireshark is used. Wireshark is a free, open-source packet analyzer that allows the viewing, capturing, and examination of packets being sent across a network stream. It is necessary to uncheck “Capture packets in promiscuous mode” before viewing the network contents (Figure 8). 8 Figure 8: Unchecking “Capture packets in promiscuous mode” allows Wireshark to view Iperf’s traffic across the network. Notice in the background that the correct network adapter must be selected. To determine the datagram size to use for testing, Iperf is set up and run across the network in UDP mode. The packet size is initially set at a low value, and increased until the packets are fragmented in the network. Figure 9 shows the difference between a packet that is too small to be fragmented and a packet that is too large to escape fragmentation. The largest packet size that is not fragmented by the network is 1514 bytes, which encapsulates a datagram size of 1472 bytes. Consequently, a datagram size of 1472 bytes is used for testing. BELOW: Packet Stream when Iperf is sending: iperf –c -u -N -b 50m -l 1500 –t 30 BELOW: Packet Stream when Iperf is sending: iperf –c -u -N -b 50m -l 1472 –t 30 Figure 9: Iperf UDP data stream as viewed in Wireshark. Note that a datagram size of 1472 bytes does not fragment the packet, but that a datagram size of 1500 bytes does. Testing shows that a datagram size as small as 1473 bytes produces results similar to those in the top screenshot. To determine the UDP data rate, a Windows program called NetLimiter (Figure 10) is used. NetLimiter allows the user to monitor the network usage of each application that is running (“NetLimiter - The Ultimate Bandwidth Shaper”). For testing, the IP camera is accessed using Internet Explorer, and set alternately to send video using the H.264 and MPEG-4 standards. NetLimiter 3 Pro, version 3.0.0.11, is 9 then opened on the base station and the download rate of Internet Explorer – or the throughput of the IP camera - is then measured. Figure 10: NetLimiter is a program that allows users to control, or “limit” the bandwidth of certain programs across a network. However, it can also be used to measure the bandwidth of specific programs across a network. Here, Internet Explorer is currently downloading 3.306 Mbps, since the IP camera is the only tab open in Internet Explorer, this is a good approximation for the IP camera throughput. Notice also that the x-axis of the chart is in minutes and the y-axis is in kBps. Maximum throughput of the IP camera is experimentally determined (Figure 11) by moving a manycolored object back and forth in front of the camera at a high frequency. It is found that both MPEG-4 and H.264 video streams have a maximum throughput of just over 1 MB per second (8 Mbps). Consequently, a UDP date rate of 8 Mbps is used for UDP testing. 10 Figure 11: These are the throughputs in megabytes of the IP Camera, as viewed in NetLimiter. It is set in H.264 mode on the left and in MPEG-4 mode on the right. The drastic fluctuations are due to the rapid waving of a multi-colored object in front of the camera. Notice that the maximum throughput is just over 1 MB. The x-axis is in minutes, while the y-axis is in MBps. To determine the time over which to run each test, TCP tests are run at several different time lengths and their averages compared (Table 1).For these tests, the time length is varied between 10 and 60 seconds, in 10 second increments. For each designated time length, 10 tests are run, and the average throughput as well as the sample standard deviation of the 10 throughput values are also computed. Table 1: TCP Tests Notice that the sample standard deviation is not reduced even when testing times are pushed to one minute each. This indicates that for testing times of one minute or less, longer testing times do not produce more reliable results. Consequently, a standard testing time of thirty seconds is chosen. Sometimes, Iperf UDP commands fail for no apparent reason, with the client reporting no ACK received from the server. In one instance, after several unsuccessful attempts to run UDP tests, a TCP test was run successfully. The next UDP test attempted completed successfully, as well as all ensuing tests. Characterizing the 2.4 GHz Spectrum 11 Table 1 shows significant fluctuation in the TCP throughput of the robot’s wireless communication link. Significantly varying throughput is also detected when running UDP tests (Figure 12). Thus, both Iperf’s TCP and UDP results show unexplained fluctuation in the throughput of the wireless link between the robot and the base station. Interestingly, UDP tests below a data rate of about 50Mbps are usually (but not always) consistent, while higher data rates produce inconsistent results. TCP tests, which always seek the highest throughput, are inconsistent as a rule. These tests purely measure the bandwidth generated by Iperf, not the IP camera, which is not run during the Iperf tests. Figure 12: This screenshot of Jperf (an optional frontend to Iperf) shows major fluctuation in four identical Iperf UDP throughput tests. The server command is [iperf –s –u –i 1 –l 1472], while the robot command is [iperf –c -u –l 1472 –b 100m –t 10]. The graph on the top is important, with a vertical axis of megabit throughput and a horizontal axis of time in seconds. Notice that these are four separate but identical tests each over ten seconds conducted within a period of one or two minutes. As shown in Figure 12, extending the testing time does not make the results more consistent. Rather, looking at the results second by second shows that the network is experiencing more dramatic fluctuation than the averages of its performance initially show, especially for UDP tests. The lab in which these tests are run is just ten feet from an IPFW wireless access point. Consequently, broadcast is disabled on the robot’s router to make it virtually invisible to any other access points. After this change, another UDP test (Figure 13) shows that there is little change in the significant variance of throughput. The Rohde & Schwarz FSV digital signal and spectrum analyzer (Figure 14) is used to analyze the wireless 2.4 GHz spectrum in the lab to assess any other wireless activity that may be disrupting the Iperf data stream. This stream includes only the bandwidth generated by Iperf; the IP camera is not run during the Rohde & Schwarz measurements. Parameters used include a resolution bandwidth of 2 MHz, a virtual 12 bandwidth of 5 MHz, a semi-orthogonal wavelet transform of 2.5 ms, a reference level of -20 dBm, and a 25 dB attenuation. The analyzer is using an antenna to detect the 2.4 GHz signals. Figure 13: This screenshot of Jperf when broadcast ability is disabled on the robot’s router shows that this change did little to improve the throughput consistency of Iperf’s UDP tests. The commands are exactly the same as in Figure 8. Figure 14: This is a stock photograph of a Rohde & Schwarz FSV Signal and Spectrum Analyzer. It is a digital spectrum analyzer that has expanded features compared to the traditional analog spectrum analyzer. A waveform that has a measured power of -40dBm (Figure 15) is clearly visible on the 2.4 GHz band. The waveform undergoes frequency hopping, jumping from one location on the 2.4 GHz spectrum to another, although it keeps fairly close to the center of the spectrum. The waveform has a large bandwidth (10-15 MHz). Due to these characteristics, it is extremely likely that the waveform is from an 802.11 standard device, most probably the wireless access point near the testing location. Additional potential causes of this throughput variance may include the 802.11n algorithms that the router employs, as well as the native hardware layer buffers and constraints of the Asus router and the Linksys wireless adapter 13 Figure 15: The above screenshot is from the spectrum analyzer. The center frequency is 2.4 GHz and the interval width is 10 MHz. The waveform has a 40 dB power and a 13-14 MHz bandwidth. Equipment The router installed on the robot is an Asus RT-N16. It has three antennas and an output power of 12 to 17 dBm in n-mode. The router can transmit on any of the first seven channels in the 2.4 GHz band; the user can choose a specific channel, or choose “Auto” to allow the router to automatically pick the best band. Testing at each of the channels provides inconsistent results, although some channels performed worse than others. For the purposes of testing, the Auto setting is chosen. Other router settings used in final testing include a hidden SSID (disabling broadcast), a wireless mode of “n only,” a channel bandwidth of 20/40 MHz (as opposed to 20 MHz), and a system setup of “Router,” as opposed to “Broadband Share” and “Access Point.” 14 The wireless adapter installed on the base station to communicate with the robot is a Linksys Wireless-N USB Network Adapter with model number WUSB300N. Its output power and receive sensitivity in nmode (draft 802.11n) are 14±1 dBm and -62 dBm, respectively. It has two antennas with MIMO technology, and is plugged into a USB 2.0 port during testing. The computer installed on the robot is an ARK-6310-3M04E. During testing, power to the computer was occasionally inadvertently cut due to a loose connection. After several such occurrences, the computer would not completely start up again. This issue was resolved by clearing the computer’s Real Time Clock (RTC) RAM in CMOS; by opening the case and locating the CMOS JBAT1 jumper, placing it in the “clear” position for 10-20 seconds, and replacing the jumper, the computer was enabled to resume normal operation. This procedure is described in Section 2.7.1 of the ARK-6310 User Manual. Results Indoor TCP testing (Figure 16) reveals a visibly decreasing throughput as a function of distance. From 10 feet to 115 feet, the base station moves in a straight line away from the robot (segment AB in Figure 3). From about 120 feet to 169 feet, the robot moves down another hall to the left at a 90 degree angle (segment BC in Figure 3). From 169 feet to 177.5 feet, the robot moves down a short hall to the left in a direction opposite to which it had begun (segment CD in Figure 3). From 177.5 feet to 197.5 feet, the robot moves down another hall to the right at a 90 degree angle (segment DE in Figure 3). Past 197.5 feet, a connection is no longer able to be established between the robot and the base station. 70 Throughput (Mbps) 60 50 40 30 20 10 0 0 20 40 60 80 100 120 Range (feet) 140 160 180 200 Figure 16: Indoor TCP throughput testing is depicted in this graph. Notice that the rapid drop in throughput of the link even while the robot is within sight of the base station (before 120 feet). Indoor NLOS UDP testing (Figure 17) also reveals worsening signal, evidenced by the large packet loss after about 170 feet. This drop in signal reception is further pronounced by the complete inability of the signal to reach the base station after 189 feet. Although indoor testing provides good NLOS testing 15 paths, it is limited by lack of space; consequently, outdoor tests are run to determine the LOS capabilities of the robot’s network. 40 35 Packet Loss (%) 30 25 20 15 10 5 0 0 20 40 60 80 100 120 Range (feet) 140 160 180 200 Figure 17: Indoor UDP packet loss testing shows a generally consistent very low packet loss until 179 feet. After 189 feet, no accurate tests can be achieved. Outdoor LOS TCP testing (Figure 18) shows a decrease of TCP throughput over distance, as expected, but the slope is less sharp and the link retains a throughput somewhat higher than indoor TCP throughput testing at all levels. This better performance of the robot network link outdoors is expected due to better propagation conditions; less interference, no corners, and no obstructions contribute toward a better signal. 70 Throughput (Mbps) 60 50 40 30 20 10 0 0 50 100 150 200 Range (feet) 250 300 350 Figure 18: Outdoor line-of-sight TCP testing shows a decreasing of throughput, but more gradually than indoor TCP testing results. Equipment constraints prohibit testing past 350 feet. Outdoor UDP testing (Figure 19) evidenced none of the high packet loss from the indoor UDP tests. 16 40 35 Packet Loss (%) 30 25 20 15 10 5 0 0 50 100 150 200 250 Range (feet) 300 350 400 Figure 19: Outdoor LOS UDP testing shows a very low packet loss consistently through 300 feet, and afterwards as well with only two exceptions. Equipment limitations prevent testing further than 400 feet. After obtaining the Iperf test results, which demonstrated the plausibility of quality video transmission at 300-400 feet, it was verified by actual trial that the robot, using its IP camera, can successfully transmit quality video to the base station at a distance of 400 feet. This is in agreement with the Iperf UDP packet loss measurements, which at a distance of 400 feet show a loss of just over one percent at a data rate of 8 Mbps, which would allow for the transmission of a good-quality video stream. Conclusions The 802.11n technology obtains significantly higher throughput, lower packet loss, and a much longer range when in line-of-sight environments than when in non-line-of-sight environments. Consequently, the 802.11n standard’s OFDM modulation, though it may help increase message completion and range, does not completely overcome NLOS obstacles. TCP throughput does not drop below 10 Mbps until after 140 feet from the robot in an interior hallway NLOS environment, and it never drops below 10 Mbps in a LOS outdoor environment as far as it has been measured – to 350 feet. This indicates that the ability of the robot to send and receive commands may be impaired in an indoor or NLOS environment much sooner in terms of distance than in an open LOS environment. Indoor UDP packet loss tests indicate that the ability of the robot to transmit video to the base station is significantly impaired by NLOS conditions such as corners and narrow paths. Indoors in a NLOS environment, UDP packet loss jumps to 15% or more after about 170 feet, while UDP packet loss outdoors in LOS conditions never exceeds 4% for at least 400 feet. 17 Future Testing Future testing of the wireless link of this robot may be performed by replacing the current 2.4 GHz 802.11 router and adapter with two 900 MHz radios that use OFDM. The performance of these radios could then be measured and compared to the 802.11n technology, since both use OFDM. (However, the 900 MHz radios may not have MIMO (multiple-in, multiple-out), as does the current 802.11n router.) A suitable radio must employ OFDM modulation, transmit and receive on the 900 MHz band, be able to interface in terms of hardware with both the robot and the base station, and be compatible with the Linux OpenSUSE operating system installed on the robot as well as with Windows XP. At least four commercially available radios (Table 2) seem to fit these criteria. All of the radios operate at 900 MHz, use OFDM, and as a bonus, have Ethernet (RJ-45) interfaces. All appear to have web-based control panels. The Orion 900 may be found at www.wirelessinteractive.com, the FastLinc FLC910E may be found at www.data-linc.com, the WaveRider EUM8001 may be found at www.streakwave.com, and the Tranzeo SL9/TR-902 may be found at www.tranzeo.com. Table 2: Summary of 900MHz OFDM Radios Name Cost (2 ct.) Discount? Loan? Contact(s) Interface with Linux Range & Windows XP? Data Rate Orion 900 $1450.00 Michael Avramidis Yes Throughput: 5.5-22 Mbps FastLinc FLC910E $2842.99 ? ? Yes Jack DeLee; 30 day-trial Eduardo Yes Giancristofaro <70km RF Data Rate: 6-54 Mbps 10 mi. LOS Data Throughput: 1-20 Mbps WaveRider NCL8000 ~ $1200.00 Yes No Hazam (ext. 2133) Yes Signaling Rates: 1.5-13.5 5 mi. NLOS Mbps User Data Rate: 8Mbps Tranzeo TR-902i $792.00 No Brent Thrift Yes -- Yes Data Rate (g-mode): 48/54 Mbps A free, 30-day trial of two FLC910E radios has been confirmed with a representative from FastLinc (Figure 20). Testing of the FLC910E would not require any extra hardware purchases. Each radio (according to the product page at http://www.data-linc.com/fastlinc/fastlinc910e.htm and included in the Appendix) comes with a 2.15 dBi bench test antenna, an Ethernet cable, a power supply, and a wall mounted transformer. Longer testing distances would likely be required to measure the full capabilities of the FLC910E. If longer indoor LOS tests are required, a large building such as Kettler, Walb, or the athletics center could suffice. For example, the indoor walkway from the library to Walb or from Walb to the athletics center may be of some use. 18 Figure 20: This screenshot from an email sent to the author by a representative from FastLinc confirms the availability of a free 30-day trial of two FLC910E radios. These radios are worth over $3000 together. An outdoor LOS path up to 700 feet long can be obtained in the large parking lot southeast of the engineering building, and an even greater distance can be achieved in the parking lot north of the athletics center. The campus sidewalks provide even greater distances. The sidewalk to student housing that starts at Helmke Library provides a 1000 foot LOS path, for example. Figure 21 documents these potential paths. Figure 21: Campus LOS paths are illustrated here. Notice that the areas surrounding these paths are relatively free of obstructions. These paths are 700 to 1000 feet long. A good NLOS path on the IPFW campus is more difficult to identify, since there are varying degrees of NLOS that may be tested. One potential scenario (Figure 22) would be to keep one endpoint at Neff, and move the other down the main IPFW pathway, taking side trips behind Helmke, Walb, and the athletics center in turn. This scenario would put not only more obstructions but also more distance 19 between the endpoints at each step. A simpler route would be to simply adhere to the main IPFW pathway from Neff to Parking Garage #3; because of the many buildings and obstacles beside the path, this pathway is not LOS. Figure 22: Campus NLOS paths are shown by the yellow lines. The engineering building is the bottom left rectangle. Although the detours behind the buildings are valuable NLOS paths, the long straight path can also be considered NLOS after a distance because there are so many obstructions on either side. 20 Works Cited “Free Accurate Network Performance Testing Tool.” TestMyPath.com. AppNeta, n.d.. Web. 23 May 2013. . “Iperf.” SourceForge.net. Dice Holdings, Inc., n.d.. Web. 23 May 2013. http://sourceforge.net/projects/iperf/. “NetLimiter - The Ultimate Bandwidth Shaper.” NetLimiter.com. Locktime Software, n.d.. Web. 23 May 2013. . “Qcheck - Free Network Benchmark Utility.”IxChariot.com. Ixia, n.d.. Web. 23 May 2013. . Thompson, E. A., Harmison, E., Carper, R., Martin, R., and Isaacs, J. “Robot teleoperation featuring commercially available wireless network cards.” Journal of Network and Computer Applications 29.1 (2006): 11-24. Print. 21 Appendix 22 Go Wireless, Fast Plug the Wireless-N USB Adapter into your computer and get ready to accelerate your wireless network connectivity with fast speed and wide coverage for your computer. The Fast Lane Enhance your laptop or desktop computer with the incredible performance power of Wireless-N and experience fast throughput and expansive, rock-solid coverage. Offers optimal performance when accessing Wireless-N networks, but works with Wireless-G and –B networks as well. DATASHEET Wireless networking at incredible speeds Reach all areas of the home or office Easy Set Up Conveniently compact adapter plugs into your computer’s USB slot. Step-by-step Setup Wizard makes it easy to configure to your network’s settings. Surf, work, or play without running wires Powerful Protection Rest secure—industrial-strength encryption helps keep your communications and information private. Wireless-N USB Network Adapter Model: WUSB300N Features • High-speed Wireless-N (draft 802.11n) networking for your desktop or notebook PC • MIMO technology uses multiple radios to create a robust signal that travels up to 4 times farther and reduces dead spots • Up to 12 times faster than Wireless-G, but can also connect to Wireless-G and -B networks • Performance Investment Protection: Compatibility with Wireless-B (802.11b) and Wireless-G (802.11g) Standards • Easy to use Setup Wizard • Supports up to 256-bit WEP, WPA and WPA2 Encryption Security • USB 2.0 Hi-Speed Interface • Plug-and-Play Operation Provides Easy Setup • Compatible with Microsoft Windows 2000, and XP Specifications Model Standards Ports LEDs Modulations RF Pwr (EIRP) in dBm Receive Sensitivity in dBm Power Consumption Security features Security key bits WUSB300N IEEE 802.11b, IEEE 802.11g, Draft IEEE 802.11n, USB 1.1, USB 2.0 USB Port Power, Link/Act 802.11b: CCK, QPSK, BPSK 802.11g: OFDM Wireless-N: BPSK, QPSK, 16-QAM, 64-QAM 802.11b: 14±1dBm (Typical) 802.11g: 14±1dBm (Typical) Wireless-N: 14±1dBm (Typical) 11Mbps @ -86dBm (Typical) 54Mbps @ -68dBm (Typical) Wireless-N @ -62dBm (Typical) TX: <480mA (Maximum) RX: <390mA (Maximum) WEP, WPA and WPA2 Encryption Security Up to 256-bit encryption Environmental Dimensions Weight Certification Operating Temp. Storage Temp. Operating Humidity Storage Humidity 2.24˝ x 0.39˝ x 3.98˝ (57mm x 10mm x 101mm) 1.02 oz (29 g) FCC, Wi-Fi (802.11b/g) 32 to 131°F (0 to 55°C) -4 to 176°F (-20 to 80°C) 10 to 85% Noncondensing 5 to 90% Noncondensing Package Contents • Wireless-N USB Network Adapter • USB Extension Cable • USB Extension Base • Setup CD-ROM with User Guide • Quick Installation Minimum Requirements • 600 MHz or Faster PC • 256 MB of RAM Memory • CD-ROM Drive • Available USB Port (USB 2.0 port required for fastest speeds) • Windows 2000 with Service Pack 4 or XP with Service Pack 2 (or later) Cisco Consumer Business Group 121 Theory Irvine, CA 92617 USA www.linksys.com Linksys, Cisco and the Cisco Logo are registered trademarks or trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries. Copyright © 2008 Cisco Systems, Inc. All rights reserved. Other brands and product names are trademarks or registered trademarks of their respective holders. The maximum performance for wireless is derived from IEEE Standard 802.11 specifications. Actual performance can vary, including lower wireless network capacity, data throughput rate, range and coverage. Performance depends on many factors, conditions and variables, including distance from the access point, volume of network traffic, building materials and construction, operating system used, mix of wireless products used, interference and other adverse conditions. Specifications are subject to change without notice. 8121010A-ST Model: WUSB300N ASUS RT-N16 Multi-functional Wireless N Router Technical Details: Specifications Ethernet ports Antenna USB Power adapter Size Weight Operating Frequency Data rate Output power Hardware WAN x 1, LAN x 4 RJ-45 for 10/100/1000 Base-T Supports Ethernet and 802.3 with max. bit rate 10/100/1000 Mbps and auto cross-over function (MDI-X) 3 x external antenna 2 x USB port AC input 100V ~ 240 V; DC output 12V with max. 1.25 A current 216mm x 161.9mm x 40.5 mm 470g Wireless LAN 2.4~2.5 GHz • 802.11n Draft up to 300Mbps • 802.11g 6, 9, 12, 18, 24, 36, 48, 54Mbps • • • 802.11b 1, 2, 5.5, 11Mbps n mode: 15.8~19.5dBm g mode: 15.5~16.5dBm • b mode: 15.8~19.5dBm At 54Mbps data rate Receiver sensitivity ANT0 -75dBm (at normal temp. range) ANT1 -75dBm • Supports 64/128-bit WEP • WPA-PSK, WPA2-PSK • WPA-Enterprise, WPA2-Enterprise Encryption/Authentication • Radius with 802.1x • • Management • • • Software EZQoS (Easy Quality of Service): Allows multiple network activities (FTP, Gaming, P2P) to work smoothly at the same time DHCP Server: Supports up to 253 IP addresses; Changeable DHCP lease time, IP pool, domain name; Static mapped IP Web-based administration: Supports IE 5.5 or later, Firefox 2.0.0.1 or later; Managed from LAN and Internet; Password Setting System Event Log Firmware Upgrade: Web Interface, Bootloader • Save/Restore Configuration File Internet connection Automatic IP, Static IP, PPPoE (MPPE supported), PPTP, L2TP type • Firewall: NAT and SPI (Stateful Packet Inspection), intrusion detection including logging • Logging: Dropped packet, security event, Syslog Security • Filtering: Port, IP packet, URL keyword, MAC address w e N FastLinc FLC910E Industrial High-speed FLC910E Ethernet 900MHz OFDM Ethernet 900MHz OFDM High-speed Modem Features • Adapts to high-noise conditions • Supports AES encryption • Reduces LOS issues Applications Security/surveillance audio/video with SCADA High-noise environments: • Arc welding • High voltage • Plant floor • Variable frequency drives Data-Linc Group’s FLC910E, part of the FastLinc Family of high-speed wireless, industrial Ethernet modems, utilizes OFDM technology, a new option in data transmission— Orthogonal Frequency Division Multiplexing. It is an ideal data communication option for installations requiring exceptionally high data rates, as well as for noisy RF environments. The FLC910E offers greater speeds than other 900 MHz products by combining the 900 MHz band and OFDM technology. Its long-range capability—up to 10 miles line-ofsight (LOS), farther with Repeaters— along with its exceptional speed (up to 54 Mbps) supports data transfer on a single network for real-time security/surveillance networks where SCADA is also required. Additionally, it provides the user with data prioritization through QoS (Quality of Service), permitting user-adjusted preferen- • Minimizes multi-path fading • Offers long range data transfer (up to 10 miles LOS, farther with Repeaters ) • Provides exceptionally high data rates (up to 54 Mbps) • Enhances plant floor performance tial data service for reduced data latency— the transmission time for a data packet to travel from point A to point B. The combination of these outstanding features has produced a data communication product with exceptional performance. The FLC910E is extremely robust and reliable. The broadband and OFDM greatly enhance plant floor performance by reducing LOS issues and multi-path fading caused by RF reflection that can be particularly troublesome for plant-floor data transfer— conditions that constrain data rates and reliability in typical high-speed data systems. The FastLinc FLC910E also supports modern encryption standards (AES, TKIP, WEP) for enhanced security. For long distances, challenging plant-floor LOS issues and high data rates, the FastLinc FLC910E is the ultimate solution. FLC910E Specifications FLC910E Dimension Operating Frequency License-free, 902-925 MHz ISM band Included. CD User Manual Antenna. Test Antenna Other. Ethernet Cable, Power Supply, Quick Start Guide Power Supply. Wall mounted transformer. 120- 240 VAC. 50/60 Hz Transmitter Distance. 10 miles (16 km) LOS with Yagi antennas RF Output Power. 316 mW (25 dB) Modulation. CCK, OFDM Spreading Code. Direct Sequence Channels: 3 Occupied bandwidth. 5 MHz, 10 MHz or 20 MHz Receiver Sensitivity -72 dBm @ 54 Mbps -92 dBm @ 6 Mbps RF Data Transmission RF Encryption. AES, TKIP, WEP, WPA, WPA2 RF Data Rate. 6, 9, 12, 24, 36, 48 or 54 Mbps Operating Modes Base Station, Station Adaptor, and Interbuilding with Repeating Data Throughput 1 Mbps to 20 Mbps (depending on range and link quality) Power 10-28 VDC max 250 mA @ 24 VDC max 1100 mA @ 12 VDC Connections Antenna. SMA connector (female), 50 Ω Ethernet. 10/100Base-T Auto-MDIX Power. 10-28 VDC, 3-pin pluggable terminal block. Indicators­­— Status LED’s including Power Status LAN (Link-Act) LAN (100) WLAN RSSI* in SA mode (5 stages) About Data-Linc Group Since 1988, Data-Linc Group has provided reliable communication solutions for industrial automation systems. Data-Linc Group, an alliance partner with most major PLC manufacturers including Rockwell Automation, Siemens, Schneider Electric, GE Fanuc, and Omron, as well as others, provides expert technical support and communications consultation. Data-Linc’s industry proven RF technology has been successfully implemented in all major industries including automotive plants, paper mills, consumer goods manufacturing/packaging, steel mills, mines, oil and gas refineries, utilities and transportation systems. Data-Linc offers a line of industrial wireless modems for the European Union. Its products are available worldwide. Alliance Partnerships Operating Environment Temperature. -40 to 167˚F (-40 to 75˚C) Humidity. 0 to 95% non-condensing humidity Enclosure Standard. 18-gauge steel with mounting flanges Dimensions. 7.6 x 5.6 inches (19.3 x 14.3 cm); 9.4 x 5.6 inches (23.9 x 14.3 cm) with mounting flanges Optional. DIN rail mounting Shipping Weight. approx 1.8 lb (0.82 kg) *Receiver Signal Strength Indicators Specifications subject to change without notice. FastLinc is a trademarks of DATA-LINC GROUP. ©2012, DATA-LINC GROUP. All rights reserved. GE Fanuc Corporate Headquarters 3535 Factoria Blvd. SE, Suite 100 Bellevue, WA 98006 USA [email protected] Tel: (425) 882-2206 Fax: (425) 867-0865 www.data-linc.com P/N 155-09862-003A rev 04/12