My Profile
Active Members
TodayLast 7 Days
more...
Awards & Gifts
Online Exams
Fresher Jobs
Our fresher job section is exclusively for fresh graduates! Find jobs for freshers in major Indian
cities including Bangalore, Chennai, Hyderabad, Pune or Kochi
Resources
Find educational articles, blogs, discussion threads and other resources.
Colleges
Find details about any college in India or search for courses.
|
“AM18 GROUND CONTROL STATION
Posted Date: 25 May 2008 Resource Type: Articles/Knowledge Sharing Category: Education
|
Posted By: shirish7 Member Level: Gold
Rating:  Points: 1
|
|
|
TOPIC NAME:“AM18 GROUND CONTROL STATION
ABSTRACT
The objective of this project is developing a Ground Control Station (GCS) for multiple Unmanned Aerial Vehicles (UAVs). The GCS must be able to coordinate the takeoff, search, landing and recovery of the UAVs. The GCS is based on a laptop with wireless modem for communication.
We implemented a TCP/IP sockets code for wireless communications between two PCs. The program was built with open source TCP/IP socket code.
Subsequently, a graphical user interface (GUI) was coded with FLTK – a C++ GUI toolkit. The GUI would display the packets sent by an onboard program, UAVclient, which interfaces with the UAV autopilot. Additionally, the GUI would reproduce this information on a map image of the area of operations. The task proved challenging as there was no prior development done on FLTK or a similar GUI available which could be modified for such a purpose.
The entire GUI was built from ground up. However, only basic read functionality was possible, the UAVclient program which interfaces with the UAV autopilot could not be completed due to licensing issues with the MP2028g SDK. As a proof of concept, the GUI is able to wirelessly communicate to the UAVclient to change the RGB values of the CMUcam2, part of the Automatic Targeting System of the platform.
TABLE OF CONTENTS
1. Introduction.......................................................................................................... 5
1.1 Objectives................................................................................................. 5
1.2 Project Equipment................................................................................... 6
2. Communications Protocol.................................................................................... 9
2.1 Choice of Transport Layer Protocol........................................................ 9
2.2 Peer-to-Peer (P2P) Model...................................................................... 10
2.3 Choice of Ports....................................................................................... 11
2.4 Choice of IP Addresses...........................................................................11
3. Graphic User Interface (GUI) Design Concept and Ergonomics........................12
3.1 Map display............................................................................................ 14
3.2 Taskbar - Command Panel......................................................................15
3.3 Taskbar - Config Tab ............................................................................ 16
3.3.1 Map Calibration ........................................................................17
3.4 Taskbar – Telemetry Tab ...................................................................... 18
3.5 Taskbar – CAS...................................................................................... 18
3.6 Taskbar – ATS...................................................................................... 18
3.7 Console Window................................................................................... 19
4. Software Development....................................................................................... 20
4.1 Choice of Toolkit for GUI..................................................................... 20
4.2 Software Design for the GCS GUI ....................................................... 21
4.3 Software Design for UAVclient............................................................ 25
4.4 Software Design for UAVsim............................................................... 29
5. Field Testing ...................................................................................................... 30
5.1 Ground Test............................................................................................ 30
5.2 Flight Test ............................................................................................. 32
6. System Limitations............................................................................................ 33
6.1 Number of UAVs................................................................................... 33
6.2 Map Calibration Errors ......................................................................... 33
6.3 MP2028g SDK and the MP2128g......................................................... 34
6.4 Known Bugs.......................................................................................... 34
7. Conclusion........................................................................................................ 35
REFERENCES...................................................................................................... 35
1. INTRODUCTION
In military applications, a ground control station (GCS) is a land- or sea-based control center that provides the facilities for human control of unmanned vehicles in the air or in space. A GCS could be used to control unmanned aerial vehicles or rockets within or above the atmosphere.
This project is to support an industrial collaborative post-graduate project sponsored by DSO National Laboratories. The project has been grouped into 3 divisions
(i) The Automatic Targeting System (ATS),
(ii) The Collision Avoidance System
(iii) Ground Control System.
1.1 Objectives
The objective of this project is to develop a Ground Control Station (GCS) for multiple UAV operations. The GCS must be able to coordinate the takeoff, search, landing and recovery of the UAVs. The GCS will be based on a laptop with commercial-off-the-shelf (COTS) wireless modem for communication and video link.
The project is divided into 3 different milestones:
1. Communications Protocol – Basic 2-way communications between flight control system on robotic aerial platform and ground control system shall be demonstrated.
2. Graphical User Interface – completed with all necessary components – this includes Map display, aircraft states numerical display, mission profile graph, etc.
3. Field Testing – Ground Control Station will direct and receive feedback from aerial robotic platform on mission. A series of ground tests has a proof of concept. A flight test will be conducted to and to ascertain the effectiveness of the system onboard the aerial robotic platform
1.2 Project Equipment
The equipment used in the post-graduate project are:
1. MP2028 Micro Pilot
The MP2028g is a micro UAV autopilot designed for fully autonomous operation. Capabilities include airspeed hold, altitude hold, turn coordination, GPS navigation as well as autonomous launch and recovery. Extensive data logging and manual overrides are also supported, as is a highly functional command buffer. All feedback loop gains and flight parameters are user programmable and feedback loops are adjustable in flight[1]. The GPS module used by the MP2028g is a Trimble Lassen SQ GPS Module with compact magnetic mount antenna.
2. PC104 embedded computer
The PC104 is a small computing module typically used in industrial control systems or vehicles. It is essentially a PC with a different form factor and most of the program development tools used for PC's can be used for a PC104 system. It is compatible with common computer modules like CPUs, Serial I/O ports, and Video Controllers; but also more exotic modules like GPS receivers, vehicle power supplies, and wireless communications.
Specifications
CPU Speed: Celeron 650 MHz
RAM: 512Mb PC133-333
Storage: 2GB Flash Disk
O/S: Microsoft Windows XP
3. UAV Platform - JR Ergo 60
The flight platform used is a JR Ergo 60. The JR Ergo was developed in the 1990’s by JR/Japan. The “60” implies that it is designed for 0.6 cubic inch internal combustion engine displacement. The helicopter is rated to carry 1 lb of payload.
Figure 1: JR Ergo 60
Specifications
Overall length: 55.85”
Overall height: 18.92”
Main rotor diameter: 60.45”
Tail rotor diameter: 10.34”
Gear ratio: 9.78:1
Cruise, mph: 20
Range, statute miles: 1 (depends on RC system)
4. Linksys Wireless-B USB Network Adapter and Wireless-G
Broadband Router
The compatible Linksys Wireless-B Network Adapter and the Wireless-G Broadband Router is used to build the wireless network. Both have been tested to work well on Windows XP SP2 operating system.
Figure 2: Linksys Wireless-B and GPS module on the UAV platform fin
2. COMMUNICATIONS PROTOCOL
Using a Wi-Fi (IEEE 802.11b) wireless network system, the GCS, consisting of a laptop and a Linksys Wireless-G Broadband Router, will communicate via the TCP/IP protocol with the UAVs. The TCP/IP internet protocol suite has been selected because it can be implemented in most commercial operating systems such as UNIX, Linux, Mac OS X and Microsoft Windows and Windows Server.
2.1 Choice of Transport Layer Protocol
Within the TCP/IP internet protocol suite, there are two main protocols in the transport layer, namely the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP). The other protocols such as SCTP, DCCP and RTP are derivatives of these two main protocols.
TCP guarantees reliable and in-order delivery of sender to receiver data. The protocol also distinguishes data for multiple, concurrent applications running on the same server host.
UDP does not provide the reliability and ordering guarantees that TCP does;
Datagram’s may arrive out of order or go missing without notice. As a result, UDP is faster and more efficient for many lightweight or time-sensitive purposes. Also its stateless nature is useful for servers that answer small queries from huge numbers of clients.
TCP despite being the more robust of the two, is not appropriate for this application. TCP is optimized for wired networks. Any packet loss is considered as congestion and hence window size is reduced dramatically as a precaution. However, wireless links are known to experience sporadic and usually temporary losses due to fading, shadowing, handoff etc. which cannot be considered as congestion. The big problem is that the application cannot get at the packets coming after a lost packet until the retransmitted copy of the lost packet is received. This causes problems for real-time applications where is it is more useful to get most of the data in a timely fashion than it is to get all of the data in order. Therefore, UDP is the most suitable choice for this application.
2.2 Peer-to-Peer (P2P) Model
Initially, a client-server network model, where communication is usually to and from a central server, was used. However, due to the small number of clients having to connect to the server (based on the GCS), a hybrid peer-to-peer (P2P) network model was eventually adopted.
A P2P network model is basically one which each equal peer node function as both “client” and “server” to the other nodes on the network. Therefore, all clients provide resources, including bandwidth, storage space, and computing power. However, due to the use of the Wireless-G broadband router that keeps information on peers and responds to requests for that information, the network arrangement is a Hybrid P2P model.
2.3 Choice of Ports
From Official IANA List and the Wikipedia, port numbers 6110 and 6111 conflicts with the HP Soft bench CM and HP Sub-Process Control. As these programs are not in use, there should not be any major conflicts when these ports are used.
2.4 Choice of IP Addresses
From Internet Engineering Task Force (IETF), Request-for-Comments 1918 “Address Allocation for Private Internets”, the IP address range 192.168.0.0 to 192.168.255.255 is for private-use IP addresses within a Local Area Network (LAN). It is a Class B network with 10 leading bits, which allows for 65,536 addresses per network.
Figure 3: UDP Hybrid P2P Model
3. GRAPHIC USER INTERFACE (GUI) DESIGN CONCEPT AND ERGONOMICS
In order to control the UAV, a GUI is to be created on the GCS. The objectives of
the GUI are to:
(i) Provide a Map Display to monitor the movement of the UAV and by GPS coordinates provided the Micropilot.
(ii) Allow the user to send GPS waypoints to the UAV to autonomously fly to the designated waypoint.
(iii) Allow the user to monitor the sensor readings and telemetry from the UAV
(iv) Use information received from the ATS module to display all known targets on the Map.
NB. Provisions must also to receive and display information from the CAS and ATS modules.
In the design of the GUI for the GCS, various design considerations have been made. These considerations could be briefly summarized by Ben Shneiderman’s 8 Golden Rules of Interface Design, Jacob Nielsen’s 10 Usability Heuristics, Gestalt’s Law of Grouping and Designing Better User Interface by Dr Chui Yoon Ping.
Figure 4: GUI Display
The GUI is grouped by functionality in order for the user to access the necessary functions as quickly as possible. The Command Panel is fore grounded as it is of the highest importance and requires the fastest response during operational flight. Other relevant but less critical information are presented to the user through tabs on the taskbar. The keyboard shortcuts are also available for the buttons in the Command Panel to enable frequent users to navigate quickly. (Shneiderman’s Rule No. 2)
Additionally, the visual structure of the GUI provides visually pleasing composition with the qualities of balance, symmetry, regularity, predictability, sequentially and unity. These follow the five main laws of Gestalt groupings. The GUI program saves the prior user configurations like UAV IP addresses, scales and origins for Map calibration. A flight communications log and ATS target log is also kept. This allows for quick error recovery (Shneiderman Rule No. 5) should the GUI have a fatal error resulting in premature termination.
The program also contains a number of helpful tool tips to aid the novice user to
navigate through the various functions available in the GUI. (Nielsen’s Heuristic No. 5 and 10)
3.1 Map display
The Map display is situated at the top left hand corner for ease of programming.
The map image is taken from Flash Earth[10], developed by Paul Neave, which is an experimental application using satellite and aerial imagery from Google Local and Windows Live Local.
This has been chosen as the application of choice for 3 main reasons. Firstly, it is able to visualize key features and landmarks on the terrain, something which a street directory representation would not be able to provide. Secondly, it gives us an accurate GPS latitude and longitude of these key features. Finally, it is available at no monetary cost.
Fig: Colors used for drawing on Map
The color Cyan is used to represent the UAV. A rectangle encompassed by an arc is drawn. The arc represents the angle of heading in degrees. The color Magenta is used for the Target found by the ATS module. A rectangle without a surrounding arc is drawn. The color Red is used for the crosshairs created by the mouse click on the map area These colors are used as they are not naturally found in the environment and would therefore provide sufficient contrast against the map.
3.2 Taskbar - Command Panel
The Taskbar consists of two major sections - the Command Panel and the Information Tabs. Buttons dealing with the routine operations of the UAV are grouped into the Command Panel.
Figure 6: Command Panel
The UAV1 and UAV2 selects the UAV which they wish to wirelessly send information to. Below that is the corresponding UAV status, which gives simple feedback to the user. In the figure above, there is “No Commas” with the UAV. Other statuses include “Fly to… “Sending GPS Report…”, “Acknowledged”, etc. This feature follows Nielsen’s Heuristic No. 1 and Shneiderman’s 3rd Rule.
The East and North Input/output bars provides the user with the most recent GPS coordinates which have been clicked on the map display. The Fly to button sends these coordinates to the selected UAV. Empty space has been provided for future development of the GCS.
The Sensor Report button sends a request to the selected UAV for the sensor report. The GPS Report button sends a request to the selected UAV for the GPS report.
The Redraw button redraws the map. The Console button calls out the GCS console for detailed information of the processes which have occurred during the course of operating the program. It is for debugging purposes.
3.3 Taskbar -Config Tab
The UAV1 IP and UAV2 IP input bars and the Set IP Addr button can be used to change the IP addresses of the UAVs. The change is limited only to the program and does not affect the UAV itself
Figure 7: Config Tab
3.3.1 Map Calibration
Set Point 1, Set Point 2 and Calculate buttons are used to calibrate the map display to the GPS coordinates on the ground.
A distinct feature or landmark on the map image is selected. The corresponding GPS coordinates are physically obtained from the Micro pilot at the landmark. The coordinates are keyed into the Pt1 (GPS) E: and Pt1 (GPS) N: input bars. The values are stored by pressing the Set Point 1 button. A second point is selected and the process is repeated. The GPS to pixel scales of the x-axis and y-axis and the GPS coordinates of the origin are calculated using the formulas:
ScaleX = (East1 – East2) / (x1 – x2)
ScaleY = (North1 – North2) / (y1 – y2)
East0 = East1 – ( ScaleX * x1) and
North0 = North1 – ( ScaleY * y1)
Where East1 and North1 are the GPS coordinates of the first landmark, East2 and North2 are the GPS coordinates of the second landmark. x1 and y1 are the no. of pixels in the x-direction and y-direction from the origin of the map display. x2 and y2 are the no. of pixels in the x-direction and y-direction from the origin of the map display. North0 and East0 are the GPS coordinates at the origin of the map. And ScaleX and ScaleY are scales used to calibrate the map from pixels to GPS coordinates.
3.4 Taskbar – Telemetry Tab
The visual structure of the Telemetry tab follows Gestalts law of grouping. The tab is separated into the aircraft states of UAV1 and UAV2. Critical information such as GPS coordinates; heading, AGL and speed are presented as the larger outputs and are close to one another. And peripheral information such as roll, pitch, yaw, ailerons, rudder and throttle are presented as smaller outputs and are closer to one another.
3.5 Taskbar – CAS
The CAS tab will tentatively display the distances and time lapse of each sonar sensor onboard each UAV. The format for the CAS tab is not confirmed as the CAS module is pending integration.
3.6 Taskbar – ATS
The ATS tab displays the GPS coordinates of the last known target. It also allows the user to change the RGB values of the selected UAV.
Fig : Config tab
3.7 Console Window
A console window can be called out to aid troubleshooting and advanced users. The console provides the user with maximum visibility of system status (Nielsen Heuristic No. 9 and 10)
4. SOFTWARE DEVELOPMENT
In the course of this project, 3 projects have been developed.
(i) GCS GUI – To be run on the GCS
(ii) UAVclient – To be run on the UAV’s PC104
(iii) UAVsim – To be run on any computer with a WinXP OS and within the same wireless local area network.
The developmental process has been documented in the Software Build LogE.
Software Build Log (Appendix E). The current build has been developed with PracticalSocket.cpp and PracticalSocket.h by Michael J. Donahoo ET. al. [13]. Which is a free software and can be redistributed and/or modified under the terms of the GNU General Public License [14] as published by the Free Software Foundation. Practical C++ Sockets provides wrapper classes for a subset of the
Berkeley C Socket API for TCP and UDP sockets. It works on both the Unix (tested under Linux, Red Hat 7.3 with gcc) and Windows (tested under Win2K with Visual C++ 6.0) platforms. The purpose of this project was to develop a very simple C++ interface to sockets[15].
In the later builds of the UAVclient, the ATS module’s source code, developed by Mike Low, was used as a reference and 9 functions were used with permission for the UAVclient to interface with CMUcam2+ through the RS-232 serial connection.
4.1 Choice of Toolkit for GUI
The post-graduate project which this project supports, requires a 3D graphics UAV flight simulator. In order for this project to continue to be relevant for future development, three toolkits have been shortlisted for use:
(i) Microsoft Foundation Classes (MFC)
(ii) OpenGL Utility Toolkit (GLUT)
(iii) Fast Light Toolkit (FLTK)
FLTK has been chosen as the toolkit of choice, as it is cross-platform free software which supports 3D graphics via OpenGL and its built-in GLUT emulation. It allows for programming of GUI of reasonable complexity (double
Buffered windows, event handling, widgets, etc.) Without bloat. The syntax structure is similar to standard C++ and the learning curve involved would be reduced. Improved readability also allows for easy further development of the GUI.
4.2 Software Design for the GCS GUI
The GUI essentially uses most of the functionality of FLTK, such as double buffered windows, widgets, event handling and drawing. Additionally, FLTK also allows for multithreading. The code uses blocking sockets to receive strings from the UAVclient. As the program will freeze if there is nothing received from the UAVclient, a thread is spun to receive strings and allow the rest of the program to
Carry out its normal functions. User Event Diagrams for the GCS GUI are shown in Figure 8 and 9. The User Event Diagram depicts the user events which the GUI understands. Software Block Diagram (SBD) for the Receive Thread is shown in Figure 10. The boxes in red signify those pending integration. The boxes in blue represent elements of the
Code not programmed by the author and from an external source
4.3 Software Design for UAVclient
A UAVclient program has been created to interface through RS-232 with the MP2028g and the ATS module. The program must then send the information through UDP sockets to the GUI. The UAVclient program opens three concurrent threads – the MP_main thread to interface through RS-232 with the Micro pilot, The MP_rcv thread to receive strings through sockets from the GCS, and the ATS_main thread to interface through RS-232 with the ATS module’s CMUCam2.
The detailed software block diagrams for each thread are shown in Figures 12, 13 and 14 below.
4.4 Software Design for UAVsim
A UAVsim program been created to simulate a UAVclient onboard the UAV. It retains the overall structure of the UAVclient but is greatly simplified. The purpose of this program is to test the GUI drawing functions.
Creating a series of data into a “GPSCoord.ini” file, the UAVsim reads from this file and outputs coordinates to the GCS through sockets. This functions like a “GPS Report”.
The MP2028g sensor report has been captured into a .txt file by HyperTerminal. The UAVsim uses this “Fake Sensor Readings.ini” to produce a sensor report to be sent to the GCS through sockets. This functions like a “Sensor Report”.
The ATS is simulated more simply. Every 20 secs, the ATS_main thread will store the GPS coordinates of the UAVsim and send them to the GCS through sockets, as though the UAV has found a target.
5. FIELD TESTING
5.1 Ground Test
In order to ascertain the effectiveness of the system, a series of ground tests have been conducted to test the system with GPS coordinates from the MP2028g. Emphasis will be placed on the performance of the wireless communications and the map calibration. Unless otherwise mentioned, GPS coordinates from Flash Earth are used to calibrate the map display during the testing. Despite possible discrepancies with the exact location on the ground, calibration using the Flash Earth coordinates scales the map sufficiently well. Representation of relative motion is thus possible on the map despite inclement weather conditions.
1st Ground Test:-
Date : 6th April 2006 4pm
Weather Conditions : Clear
GPS status : “3 satellites”
Result : No communication problems. Shows relative motion of the UAV. Representation on the map has a slight error. Estimated error within 2m.
Comments : A Fujitsu Life book S6230 laptop was used to simulate the PC104, so a screen could be used to troubleshoot any problems with the MP2028g.
2nd Ground Test:-
Date : 7th April 2006 1pm
Weather Conditions : Cloudy
GPS status : “1 satellite”
Result : No communication problems. Large fluctuation from the Micro pilot GPS have resulted in inaccurate representation Of UAV position. Relative positioning could not be obtained.
Comments : Failed test. Map is calibrated with Trimble Lassen SQ coordinates. “1 satellite” lock may imply that GPS lock is insufficient for accurate GPS readings. This has been attributed to cloudy weather conditions. Therefore by
Calibrating it to the GPS module’s readings. Larger error is induced. Flash Earth should be used to calibrate the map from this point forth.
3rd Ground Test:-
Date : 7th April 2006 3pm
Weather Conditions : Cloudy
GPS status : “Valid fixes”
Result : No communication problems. Shows relative motion of the UAV. Exact location is not accurate but within rated CEP (Circular Error Probable) of 6m.
Comments : Successful test.
4th Ground Test:-
Date : 11th April 2006 6pm
Weather Conditions : Minor cloud cover
GPS status : “Valid fixes”
Result : No communication problems. Shows relative motion of the UAV. Within rated CEP of 6m.
Comments : Successful test.
5.2 Flight Test
A flight test was conducted in order to ascertain the effectiveness of the system. However, the helicopter crashed due to a power failure onboard the UAV platform. Downtime due to the crash limits the number of tests possible, but results thus far have been positive.
6. SYSTEM LIMITATIONS
During the course of this project, a number of system limitations have been noted.
6.1 Number of UAVs
Firstly, the GUI is designed to control only 2 UAVs. For the user to accommodate more UAVs, the GUI source code has to be edited. However, the current GUI is sufficient as a proof of concept for future development.
6.2 Map Calibration Errors
Secondly, the calibration of the map display has a few inherent errors: (i) Human errors (ii) GPS errors from Micropilot (iii) GPS errors from Flash Earth/Google Local.
The map display is calibrated by the user. Therefore, human error is inevitable. However, careful calibration by the author has resulted only in a difference of 0.000001 degrees latitude and 0.000005 degrees longitude which is less than a meter [16].
The Trimble Lassen SQ GPS Module has a rated CEP of 6m[17]. As shown in the 2nd Ground Test, during cloudy weather conditions, the GPS readings had large errors. Flash Earth which is derives its information from Google Local uses 2005 aerial imagery from Digital Globe [18]. Digital Globe’s Basic Imagery Package’s CEP is rated at <23m for 90% accuracy. Therefore, calibration using GPS
Coordinates from such a open source application may result in slight errors.
6.3 MP2028g SDK and the MP2128g
Thirdly, due to physical limitations, the UAVclient is only able to read sensor and
GPS information from the MP2028g. The current MP2028g is on loan from an external party, because of this, NUS does not legally own the licensing or the documentation required to use the Micropilot XTENDERmp Software Developer’s Kit (SDK). The XTENDERmp allows the developer to use a custom GCS to communicate to the MP2028g. The control laws, autopilot state fields, payload and sensor data can also be customised [19].
A purchase order has been sent for the new MP2128g package, which is currently still in development and has yet to be officially announced. The MP2128g has similar features to the MP2028g but is equipped with a more powerful processor and is more suitable for rotary wing UAVs. A Canadian-based UAV company, Aerial 51, has been developing a UAV Helicopter with the MP2128g[20]. With this new autopilot, autonomous control of the UAV can be achieved. Development of the system would then be able to continue.
6.4 Known Bugs
Fourthly, during the course of the software development, there has been one known bug. The updating of the drawings on the map is slightly inconsistent. Without user input, the drawings have been known to disappear for up to 10 seconds despite the program running and receiving information normally. However, this is not an irreconcilable problem in the design of the program, as the drawings can be updated by a simple mouse movement or keyboard input.
7. CONCLUSION & REFERENCES
Through this project, the concept has been proven and a Ground Control Station has been developed. Field testing conducted as also proven that the wireless communications do not suffer. A Graphic User Interface has been built which is robust and can be readily customised by subsequent developers for their specific use. The UAVclient program also provides a structure for future development to
continue after the MP2028g or MP2128g SDK has been obtained.
REFERENCES
1 Micro pilot (2005). MP2028g Installation and Operation Manual. Micro pilot Inc.
2 PC104 Supplier Link Page (2006). PC104 - What is a PC104? Retrieved from http://www.pc104.com/whatis.html
3 Universities of Arizona, College of Engineering, Aerospace and Mechanical Engineering (2006) NATS102 – Aeronautics: Science and People Retrievedfrom www.ame.arizona.edu/courses/nats102/download/LS-1.doc
4 Wikipedia, The Free Encyclopedia (2006) User Datagram Protocol (March 2006) Retrieved from http://en.wikipedia.org/wiki/Udp
5 Wikipedia, the Free Encyclopedia (2006) Transmission Control Protocol (April 2006) Retrieved from
http://en.wikipedia.org/wiki/Transmission_Control_Protocol
|
Responses
|
| Author: Shyni 31 May 2008 | Member Level: Gold Points : 2 | Very Nice Information
|
|
Watch TV Channels
Watch Asianet TV onlineKairali TV in InternetSurya TV onlineAmritha TV Channel
|