The Global Positioning System (GPS) has developed into a useful tool with

Transcription

1 DIFFERENTIAL GLOBAL POSITIONING SYSTEM REFERENCE STATION GEORGIA INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL AND COMPUTER ENGINEERING SENIOR DESIGN PROJECT PROFESSOR ART KOBLAZ/WHIT SMITH SPRING 2004

2 TABLE OF CONTENTS GPS OVERVIEW 3 DGPS BROADCAST STATION PROJECT OVERVIEW 3 RTCM GENERATION OVERVIEW 6 TRANSFORMING MOTOROLA BINARY CORRECTIONS INTO RTCM 8 ADDITIONAL FEATURES 13 TEST RESULTS 16 AM TRANSMITTER 18 MODEM CHIPS 19 TESTING THE MODEM CHIPS 21 TESTING THE COMPLETE SYSTEM 21 IDEAS FOR THE FUTURE 23

3 The Global Positioning System (GPS) has developed into a useful tool with hundreds of uses. Limitations placed on commercial GPS receivers, however, have restricted the system s usefulness in applications that require precision greater than 10 meters. The Differential Global Positioning System (DGPS) was developed to remedy this dilemma and allow GPS receivers to be accurate to within centimeters of true latitude and longitude. DGPS solutions require a base station and an additional receiver. Both products are commercially available to the public, but start at a hefty price. GPS Overview The Global Positioning System commenced in 1994 when the Department of Defense launched a constellation of 24 satellites. The system allows a GPS receiver to calculate its location anywhere on Earth from the known positions and signal delay of the visible satellites. The GPS satellites transmit on two carriers: L1 for commercial (public) and L2 for military. The L1 carrier band is employed by all GPS receivers available to consumers and can provide a location fix to within 100 meters. The L2 carrier is more precise, but has been constrained to military use only by the Department of Defense for security reasons. When greater location accuracy is necessary in commercial and consumer applications, a Differential Global Positioning System can be employed. DGPS Broadcast Station Project Overview The design group was tasked with the project of creating a Low-Cost Differential GPS broadcast station. Several previous groups had also worked on this project in years

4 past. The group decided that it would be helpful to leverage the work of previous groups in order to make our task easier. This very idea proved to be a costly time mistake. There are two basic components to a DGPS broadcast station. The first component is the error corrections generator which provides the current error information for each visible satellite. The second component is the datalink which delivers these corrections to remote users. After reviewing documentation from the previous groups, the present group determined that an error correction generator had already been built. A previous group located a product on the internet that interfaced with a Motorola Oncore VP GPS card to produce RTCM error corrections. Therefore, the present group decided to build a wireless datalink to interface with the corrections generator as their semester project. After four weeks of testing the error corrections generator, however, the product was determined to be non-functional. The group decided to expand it s original efforts by starting from scratch and building the entire product: both the corrections generator and wireless datalink. The project was broken up into the basic components shown in Figure 1.

5 Figure 1. Broadcast station diagram. The group decided to use RTCM (Radio Technical Commission For Maritime Services) SC-104 Type 1 messages as the corrections format. RTCM is the most widely used DGPS corrections format in use today and is compatible with most DGPS-enabled GPS receivers. Generation of the RTCM messages was accomplished through an Oncore VP receiver interfaced to a desktop computer. The GPS queries and RTCM message generation were performed exclusively through software running on the desktop computer. The generated messages were then sent to a modem chip which encoded the digital signals into a two-tone string of sine waves. This signal was then broadcasted using an AM transmitter to remote AM radios. The radios fed the two tone signal into a modem chip, which decoded the signal back to its original digital form. Finally, the signal was delivered directly to a remote GPS device through a DB9 (serial) interface.

6 A possible alternative (and one explored by previous groups) would have been to modulate the corrections signal to be used in conjection with DGPS receivers currently on the market. However, this alternative proves pricey as these recievers cost over twohundred dollars and do not conform to the idea of building a low-cost DGPS broadcast station. Furthermore, this approach would have demanded the ability to build a transmitter capable of switching between khz and 301.2kHz. The group, therefore, decided that this kind of accuracy and implementation would not be easily achievable at a low cost. RTCM Generation Overview The most basic component of any DGPS broadcast station is the generation of the corrections data. For this project, we used a Motorola Oncore VP GPS card which is capable of producing corrections data in a proprietary Motorola format. The plan was to create a piece of software that could: interface with the Oncore VP through a serial port set up the Oncore VP to produce differential corrections reformat those corrections into RTCM SC-104 output the RTCM corrections to the datalink The group decided that the software would be writen in Microsoft Visual Basic because of the built-in support for programming to the serial port. Interfacing with the Oncore VP proved to be quite easy. Commands were sent to the Oncore VP in a proprietary Motorola binary format. The format for each message was laid out in the Motorola Oncore M12 Owner s Guide Supplement. Many of the commands used for the

7 Oncore VP were also used for the M12. The only real challenge in interfacing with the Oncore VP came in correctly computing the checksums for each message, as this information was not readily available in the User s Guide. To set up the Oncore VP, a third party program, TAC32, was used. TAC32 is a program that interfaces with a variety of GPS cards to provide very accurate timing data to a desktop computer. By examining the raw data that TAC32 sent to the Oncore VP upon startup, the group determined exactly which commands were needed, and in what order to send them. The output of the RTCM corrections to the datalink proved to be equally trivial. The group used Visual Basic s built-in funcionality to interface with a second serial port. Reformatting the error corrections from the Oncore VP (in Motorola binary format) into RTCM SC-104, however, proved to be a very difficult task. The major problem was the complexity of the format and the lack of feedback from the target GPS card. The software was set up to read corrections from the Oncore VP and then apply them directly (through a serial cable) to an Oncore M12 GPS card. The M12 s status was polled to see if it was able to recognize any of the DGPS input. The M12 provided no feedback as to the status of the RTCM messages such as invalid parity bits, out of range data, et cetera. The M12 would only indicate that it was receiving differential corrections by setting the differential corrections available status bit for each affected satellite and by setting the differential fix bit in the status message. However, if less than three sets of corrections were available, none of the differential status bits were set. Therefore, the group worked on correctly formatting the RTCM messages by pouring over the RTCM documentation and testing each revision of the

8 software until the M12 finally responded with the differential fix bit set. An explanation of the transformation from Motorola binary corrections to RTCM follows. For a complete guide through the process, however, refer to the DGPSStation Visual Basic source code included with this report. Transforming Motorola Binary Corrections into RTCM In order to understand the GPS error corrections, it is necessary to understand the following terms: pseudorange o A measure of distance between the GPS antenna and the broadcasting satellite. It is termed pseudo because it is calculated from the time delay of the satellite signal and is not a true measure of distance. The pseudorange correction is the heart of the RTCM message. Rate range correction o Gives the target GPS card a rate for extrapolating pseudorange corrections between updates. Z-Count o The current time. RTCM uses a modified Z-count with a precision of 0.6 seconds and a range of one hour. It is assumed that users will not attempt to feed corrections data over an hour old into a GPS receiver. Sequence Number o An count value that increases with each RTCM word that allows the GPS card to identify missing words. This value rolls over from 7 to 0.

9 Preamble o A bit sequence (0x66) that indicates the beginning of a GPS message Message Type o For this project, the message type is always set to 1 Reference Station ID o Uniquely identifies the reference station. The DGPSStation software sets the reference station ID as 555, however this ID has not been officially registered. Station Health o An incicator of the current accuracy of the RTCM corrections. The software does not change this field. It is set to a value of 1. Length of frame o The number of words in the RTCM message. Word o RTCM words are 30 bits long Parity o Each RTCM word ends with 6 parity bits. The parity algorithm is the same as the NAVSTAR GPS parity algorithm. Fill o Alternating 1 s and 0 s added to an RTCM message to ensure that the message ends in with a complete 30-bit word

10 Since the Oncore VP was capable of tracking eight satellites, and the corrections message only held six, the card responded with two of these messages when polled. The target RTCM Type-1 format is listed below [1]: First Word of Each Message MESSAGE REFERENCE STATION PREAMBLE PARITY TYPE ID Second Word of Each Message SQN LENGTH STN MODIFIED Z-COUNT NUMB OF PARITY HTH ER FRAME Words 3, 8, 13, or SATELLITE SF UDRE PSEUDRANGE CORRECTION PARITY ID Words 4, 9, 14, or RANGE-RATE ISSUE OF SF UDRE SATELLITE PARITY CORRECTION DATA ID Words 5, 10, 15, or RANGE-RATE PSEUDORANGE CORRECTION PARITY CORRECTION Words 6, 11, 16, or PSEUDORANGE ISSUE OF SATELLITE SF UDRE CORRECTION PARITY DATA ID (UPPER BYTE) Words 7, 12, 17, or PSEUDORANGE CORRECTION (LOWER BYTE) RANGE-RATE CORRECTION ISSUE OF DATA PARITY Words num_sats + 2 if num_sats = 1,4,7 or RANGE-RATE ISSUE OF FILL PARITY CORRECTION DATA

11 Words num_sats + 2 if num_sats = 2,5,8 or ISSUE OF FILL PARITY DATA All of the data needed to calculate the RTCM Type-1 message was provided by the Motorola binary corrections message, the format of which can be seen in Figure 2 below. The first word of every generated message was constant. The Issue of Data field was copied directly from the Motorola binary format. Both the pseudorange corrections and the rate range corrections were rescaled. Also, special care was taken when these corrections values were negative since the RTCM format demanded signedmagnitude representation as opposed to two s complement representation. A pseudorange correction of negative three, for example, would be represented with 0x8003. Any mistake in the parity bit, the length of frame, or modified Z-count fields caused the target GPS card to ignore the entire data][sat data][sat data][sat data][sat data][sat data][c][0xd][0xa] [sat data] = [3 byte Z-count][1 byte satellite ID][3 byte pseudorange correction][2 byte rate range correcion][1 byte issue of data] [C] = [1 byte checksum] Figure 2. The Motorola binary error corrections format. Parity bit generation was fairly tricky. The algorithm is complex and was provided in the GPS signal specficiation. The initialization value of D29* and D30*, however, was not provided. The group found that they were both set to zero for parity generation of the first word. The GPS signal asserted that D29* and D30* were the last

12 two bits from the previous word in the current subframe. However, the group s experience showed that they were the last two bits from the previous word regardless of subframe boundaries. One must understand that the given RTCM format is normally broadcast over radio frequencys to remote DGPS receivers. DGPS receivers collect this signal and break up the bits into six-bit bytes. The receiver then reverses the order of the bytes (since transmission occurs most-significant bit first), logically-ors these bytes with 0x40, and then sends the data to a UART (see Figure 3). Figure 3. Final Bit Manipulations However, in order to simplify the decoding of this signal at the receiving end, all of these signal manipulations were completed on the frontend and then broadcast across the datalink. By manipulating the signal in this way, the receiver captured the signal and sent it directly to the serial interface of the target card. The final corrections signal was then output from the PC using the data transmission line of a serial port.

13 Additional Features The entire program was accessed via the creation of a user-friendly GUI that displayed the current satellite error data for the operator as shown in Figure 4. Figure 4. DGPSStation Software Interface.

14 The original GUI displayed the RTCM output, however, this output was deemed to be unnecessary. Instead, the RTCM output was written to a log file. The program also allowed the user to easily set the reference location of the broadcast station. This feature was useful for using the station in a variety of locations. One of the most advanced applications of the created DGPS software is its ability to act as a TCP (Transmission Control Protocol) server. The server is capable of supporting up to ten remote clients. Clients can request error corrections by registering their IP addresses with the server by sending a connect for RTCM message to the server. The server then sends the RTCM messages to each of the connected clients (see Figure 5), and lists each of the connected clients in the GUI. Figure 5. TCP Client Interface.

15 Clients can feed the error corrections out to an available serial port and into a GPS device. Using this tool, a remote client without access to the wireless datalink can still make use of the broadcast station via the internet. Source code for the server was built into the DGPSStation software. Source code for the client is also provided with this report. Originally, the client/server software was tested using the UDP (User Datagram Protocol). UDP was the intended protocol because of its light traffic load. Using UDP, the server was able to support more clients than with TCP. For testing purposes, two clients (one through a residential broadband connection in Morrow, GA and one through Emory University s ResNet) connected to the server (located on Georgia Tech s ResNet). The Morrow, GA client received roughly eighty percent of the data, while the Emory client received only fifty percent. The group determined that reliabile transport of the RTCM data was more important than the number of clients supported, so the group switched to a TCP protocol. Test Results In order to prove that the DGPSStation software was working correctly, it was necessary to show: the RTCM messages were correctly formatted the corrections data were accurate For the first part, an Oncore M12 card was set up and monitored via the TAC32 software. The card was able to obtain a 3-D fix. Output from the DGPSStation software was then connected directly to the RTCM port on the card. After several seconds, TAC32 reported a 3-D fix, DGPS, indicating M12 card had set the differential

16 fix bit in its status message (see Figure 6). Thus, it was concluded that the RTCM messages were correctly formatted. Figure 6. TAC32 DGPS Fix. In order to verify the accuracy of the corrections information, the group decided that the positioning information from the stationary M12 card could be monitored over a period of time. Without the DGPSStation running, the M12 s position would vary much more than with the software enabled. SAWatch (a program which maps current position from GPS cards) was interfaced with the M12 card. When not receiving error corrections, SAWatch indicated that 95% of the M12 positions were within 46 meters. After turning on the error corrections, this number dropped down to 11 meters. This test was run for approximately 2 hours. However, due to problems with the SAWatch software, the results could not be saved. The group attempted to repeat this test importing the M12 position data into Microsoft Excel (see Figure 7). The test was rerun

17 for only ten minutes, and resulted in 95% of the M12 positions being within a 3-meter radius. Figure 7. DGPS accuracy. The improvement over the first test was most likely a result of conducting a shorter test, which did not allow give the Selective Availability error (intentional DOD error) sufficient time to wander. The data used to generate these graphs is provided with this report. As a result of these tests, it was concluded that the DGPSStation software worked as intended. AM Transmitter In order to transmit the DGPS corrections without a direct connection, the group purchased an AMT3000 AM Transmitter kit from SStran. The transmitter s circuit diagram can be seen in Appendix C. The group assembled the kit using the step-by-step instructions provided by the manufacturer. The AM Transmitter was said to broadcast any AM frequency between 530 Khz and 1700 Khz by setting a series of dipswitches located inside the AM transmitter [3]. The group chose to broadcast the DGPS signal at

18 1700 Khz at the high end of the band because the antennae operated more efficiently at higher frequencies [3]. Once the kit was fully assembled and the frequency was set using the dip switches, the group tested the AM transmitter. An audio input source was connected to the RCA inputs, and a handheld AM radio was used to intercept the transmitted AM signal. The broadcasted signal was heard through the headphones concluding that the transmitter was functioning properly. Modem Chips In order to transmit the DGPS corrections using the AM transmitter, two FFSK modem chips were needed. The group was fortunate to receive three CMX469A modem chips for free from Consumer Microcircuits Limited. These modem chips were configurable in 1200, 2400 and 4800 baud rates. Using one of these chips in two different circuits, the group was able to transmit data using the AM transmitter. For our particular application, we chose to use the 4800 baud configuration in order to have a choice between transmitting data at 1200, 2400, or 4800 bps. Even though each of these chips was able to operate at full-duplex, the group only needed a one-way communication link. The first CMX469A chip was configured to transmit data only at a rate of 4800 baud. Under this configuration, logic 1 was simply one half cycle of an output frequency of 2400Hz, and logic 0 was one cycle of an output frequency of 4800Hz. The DGPS corrections were be fed into the transmitter circuit through the serial data cable. The RS-232 voltage levels were converted into TTL voltage levels of 0 to 5V through a RS-232 to TTL converter. After being converted into TTL levels, the data was connected to the input pin on the CMX469A chip. The output of the chip was then

19 connected to a two-channel RCA cable. The RCA cable was then input into the AM transmitter, and the signal was broadcasted. A diagram of the transmitter circuit is shown in Figure 8. The diagram shows a general circuit for an unconfigured chip that can be configured to be a transmitter, receiver, or both simultaneously. In the transmitter circuit, the transmitter was enabled while the receiver was disabled. Values for CMX469A chip parameters are shown in Appendix B. To achieve a baud rate of 4800, the clock rate (pin 19) and 4800 baud select (pin 18) were tied to VDD, while the 1200/2400 baud select (pin 16) was tied to VSS. Figure 8. Diagram for the general modem circuit used by both the transmitter and receiver. [2] The second CMX469A chip was configured to be a receiver. The receiver was also configured to receive data at the 4800-baud rate. The receiver circuit was

20 transplanted from the original breadboard on which the circuit was tested to a printed circuit board for portability. To receive the data at a remote location, a handheld AM radio was needed. The radio was tuned to the frequency at which the AM transmitter was broadcasting the signal. The portable receiver circuit was put inside the casing of the handheld AM radio. The leads going to the audio jack output of the handheld radio were soldered and connected to the input of the receiver circuit. The output signal of the receiver was converted to RS-232 levels using the same TTL to RS-232 converter as used in the transmitter circuit. The signal conversion allowed for a serial connection between the DGPS receiver and the handheld radio enclosure. The entire handheld radio enclosure operated using the two 1.5V batteries powering the AM radio. This 3V power supply enabled the CMX469A chip to run over its minimum voltage requirement that was 2.7V. The two batteries powering the radio also met the current requirements of the chip and the receiver circuit. Testing the Modem Chips The transmitter and receiver modem circuits were tested with square wave inputs to determine if they were functioning correctly. In this test, both of the circuits were assembled on the same breadboard with the output of the transmitter circuit directly connected to the input of the receiver circuit. A square wave input was then connected to the input of the transmitter circuit and compared with the output of the receiver circuit. The two square wave signals, input and output, matched perfectly, which conclusively confirmed the successful assembly of both the transmitting and receiving circuits. Testing the Complete System

21 After the modem chips were determined to transmit and receive the data correctly, one end of a serial cable was connected to the input of the transmitter, and the other end was connected to a Windows PC. Using the software created for this project and described earlier in the report, a dummy RTCM packet was sent through an RS-232 to TTL converter to the serial cable to test the transmitter and receiver circuits for functionality. The dummy RTCM packet output of the receiver circuit matched the dummy packet input through the serial cable confirming once again the successful implementation of the modem chips. The group then proceeded to transfer the two circuits to separate printed circuit boards. Once transferred to their respective circuit boards, data transmission over radio was tested. For this test, the group again sent dummy RTCM packets from the Windows PC through an RS-232 to TTL converter to the input of the transmitter circuit. The output of the transmitter circuit was then connected to the RCA inputs of the AM transmitter. The input to the receiver circuit was connected to the output of the handheld AM/FM radio. A DC power supply was used to provide +5V to both the transmitter and receiver circuits. The data output of the receiver circuit (pin 13) was monitored on the oscilloscope, along with the serial output from the pc. Upon viewing the output of the oscilloscope, the group concluded that the dummy RTCM packets were successfully being transferred from the PC to the modem receiver circuit and through the AM radio link. In order to make sure that the data transferred was actually the same at the transmitting and receiving ends, the group used a second serial port on the pc to connect the output of the receiver through a second RS-232 to TTL converter. HyperTerminal

22 was used to capture the incoming serial data stream from the receiver circuit. The incoming serial data was converted to hexadecimal for comparison to the original sent dummy packet. The dummy packet on the output of the receiving circuit viewed in HyperTerminal was an exact replica of the dummy packet sent through the transmitting circuit confirming that the AM data-link and complete system functioned as intended. Ideas for the Future In the future, design teams might try to improve the signal strength of the AM transmitter by amplifiing the output from the transmitter and building a larger antenna. Another significant improvement to the current system could be made by porting the Visual Basic error corrections code to an embedded platform. Porting the corrections code would allow the entire system to be housed in a much more compact area and would significantly increase the stability of the correction software, as well as reduce the cost of the entire product. [1] Radio Technical Commission for Maritime Services, RTCM Recommended Standards for Differential Navstar GPS Service: Version 2.1, Washington, D.C., 3 Jan [2] Consumer Microcircuits Limited, CMX469A 1200/2400/4800 Baud FFSK/MSK Modem [Online Document], 2001, Available HTTP: /cmx469ad.pdf

23 [3] SSTran, AMT3000: Low Power AM Braodcast Radio Transmitter Kit Assembly and Operating Instructions [Online Document], 2004, Available HTTP: