GPS Library for Proteus

Hello friends! Today, we will install the GPS Library for Proteus and use it to understand how a microcontroller receives GPS data. We will start with the library files, connect the module to a Virtual Terminal and then work through the information carried by its serial messages.

This original library provides a simulated GPS data source. It repeatedly transmits predefined NMEA sentences, allowing us to develop a receiver without connecting a physical GPS module. Its coordinates do not describe your computer's location, and moving the computer will not change them.

Once the basic circuit works, we will examine coordinate conversion, message checksums and the difference between receiving text and obtaining a valid position. The original download, circuit images and video are included so you can follow the installation and compare your setup at each stage.

What Does the GPS Library Simulate?

A physical GPS receiver obtains signals from satellites and calculates navigation information. A microcontroller normally receives the resulting position, time and related data through an interface such as UART. Our Proteus example begins at that serial interface: the library supplies messages for the receiving circuit to process.

That distinction explains why this module is useful even though it does not calculate a satellite fix. We can inspect characters, develop a sentence parser, display coordinates and exercise application decisions using repeatable input. We cannot use this model to measure antenna performance, satellite visibility, receiver sensitivity or positioning accuracy.

You can use the output with an Arduino, PIC or 8051 receiving program, provided that the selected processor and serial peripheral are supported by your Proteus installation. The sensor library and the microcontroller simulation are separate pieces; installing one does not add every possible processor model.

Download the GPS Library for Proteus

Download the original package below and extract it into a normal folder. Keep the extracted files together until you have identified the device library, index and support program. Do not attempt to select a program from inside the compressed archive.

The three files used by this tutorial are GpsTEP.LIB, GpsTEP.IDX and GpsTEP.HEX. The first two make the component available in the device selector. The HEX file supplies the behavior used by the simulated GPS component.

Use a project folder with a short, stable location for the support firmware. If you later move or rename that folder, the schematic may still refer to the old path. Keeping a copy of the firmware alongside your simulation makes the project easier to reopen and share.

Install the library files

1. Close Proteus before changing its library files.
2. Locate the library directory configured for your Proteus installation. Its location can differ between versions and installation choices.
3. Copy GpsTEP.LIB and GpsTEP.IDX into that directory.
4. Keep GpsTEP.HEX in your extracted project or another permanent folder.
5. Open Proteus, create a schematic and use Pick Devices to search for the GPS component.
6. Place the module on the sheet and save the project.

If the component is absent, first check the destination folder and exact filenames. A second, unused Proteus installation may have its own library directory. Restarting the program only helps if the files were placed in the directory that this installation actually reads.

Assign the GPS support firmware

Open the GPS component properties and select GpsTEP.HEX in the Program File field. Confirm the selection before starting the simulation. The following image shows the original configuration step.

This firmware belongs to the GPS component. If you subsequently add an Arduino, that board needs the HEX compiled from your Arduino sketch in its own Program File field. Loading the GPS firmware into the Arduino, or the Arduino firmware into the GPS component, exchanges two programs that perform entirely different jobs.

Connect the GPS Module to a Virtual Terminal

We will first inspect the output without adding a parser. Place a Virtual Terminal from the instruments available in your Proteus installation, then connect the GPS transmit pin to the terminal receive pin. Pin names describe the direction from the device's perspective: TX sends and RX receives.

Start the simulation and open the terminal window. The library may print an introductory line before the repeated navigation sentences. Treat that line as explanatory text, not as a GPS sentence. A receiving program should wait for a sentence start character instead of assuming that the first received byte belongs to a position report.

The original output is illustrated below. Repeated coordinates are expected for this version. They demonstrate that the stream is reproducible; they do not indicate that the simulation has located satellites or measured a stationary receiver.

If nothing appears, stop and check the GPS program path, TX-to-RXD connection and terminal settings. If unreadable characters appear, examine the baud rate and framing before changing any parsing code. A parser cannot recover meaningful fields from consistently misdecoded UART characters.

Understand the NMEA Message Structure

NMEA sentences carry text fields separated by commas. In a typical navigation sentence, a dollar sign marks the beginning, an identifier specifies the message type and an asterisk introduces a two-character hexadecimal checksum. The line then ends with carriage return and line feed. The u-blox receiver protocol specification documents this structure and its checksum rule.

The checksum is calculated by XORing the characters between the dollar sign and the asterisk. Neither delimiter is included. It helps detect a damaged sentence, but a correct checksum does not prove that its position is current or valid. Your application must also interpret the navigation status fields.

For example, RMC messages include a data-status field, while GGA messages include a fix-quality field. Consult the definition of the particular sentence before accepting its coordinates. Also identify messages by their sentence type rather than assuming that every real receiver uses the same talker prefix as this demonstration.

Convert coordinates correctly

One common beginner mistake is to read an NMEA coordinate directly as decimal degrees. A latitude value such as 4807.038 represents 48 degrees and 7.038 minutes. Longitude uses an additional degree digit, so the field width is different even though the conversion principle is the same.

Decimal degrees = whole degrees + minutes / 60

For that illustrative latitude, the result is 48 + 7.038 / 60 = 48.1173 degrees. For an illustrative longitude of 01131.000, the result is 11 + 31 / 60 = 11.5166667 degrees. Apply a negative sign for south or west after performing the conversion.

These are teaching examples, not a promise that your copy of the library prints those exact coordinates. Read the actual sentence in your terminal before comparing results. Preserve enough precision during conversion and round only for display; rounding the minutes first introduces unnecessary error.

Keep units and time explicit

A position display should include hemisphere or signed decimal degrees, and a speed display must name its unit. Do not assume that every numeric field represents kilometers per hour. Conversion belongs at a clearly identified boundary between the parser and the display, not scattered across several unrelated functions.

Likewise, distinguish the time reported in a navigation message from the local clock on your computer. If your application presents local time, perform that conversion deliberately and account for the date boundary. For a fixed demonstration stream, the transmitted time can remain unchanged while the simulation continues running.

Receive GPS Text with an Arduino

After the terminal test succeeds, connect the GPS TX pin to an Arduino receive input. For a simple UNO exercise, SoftwareSerial can provide a separate receiver while the hardware serial output remains available for debugging. The following sketch uses D4 as the GPS receive pin and D3 as an unused transmit pin.

Connect UNO D1/TX to another Virtual Terminal RXD and configure that terminal for 9600 baud. Load the compiled Arduino sketch into the UNO and keep GpsTEP.HEX assigned to the GPS component. Select the UNO target and matching processor clock when compiling and configuring the simulated board.

#include <SoftwareSerial.h>

SoftwareSerial gpsPort(4, 3); // RX, TX; TX is unused here.
char sentence[96];
uint8_t used = 0;
bool collecting = false;

void setup() {
  Serial.begin(9600);
  gpsPort.begin(9600);
}

void loop() {
  while (gpsPort.available()) {
    char c = gpsPort.read();
    if (c == '$') {
      used = 0;
      collecting = true;
    }
    if (!collecting) continue;
    if (c == '\n') {
      sentence[used] = '\0';
      Serial.println(sentence);
      collecting = false;
    } else if (c != '\r') {
      if (used < sizeof(sentence) - 1) {
        sentence[used++] = c;
      } else {
        collecting = false; // Discard an oversized line.
        used = 0;
      }
    }
  }
}

This is a bounded line-capture example, not a complete navigation parser. It ignores startup text, begins again at a new dollar sign and discards a line that exceeds the buffer. It does not validate checksums, interpret fix status or convert coordinates. Add those functions before using received values in application decisions.

The receive loop has no deliberate delay, but printing a complete sentence can still block when the outgoing serial buffer fills. This small example is suitable for inspecting a modest demonstration stream. For a demanding receiver, separate capture from reporting, use a hardware UART where available and avoid repeatedly printing every raw character alongside formatted results.

Calculate the serial data budget

With 8N1 framing, each byte occupies ten serial bits: one start bit, eight data bits and one stop bit. At 9600 baud, the theoretical maximum is therefore 9600 / 10 = 960 bytes per second. A 75-byte sentence takes about 75 × 10 / 9600 = 0.0781 seconds on the wire.

Now suppose a receiver sends six such sentences each second. That is 450 bytes per second before adding any other messages. This calculation helps explain why changing an update rate without checking the enabled messages can overload a serial link. It also shows why a long delay in your main loop can lose data even when the average message rate appears low.

Build a Reliable GPS Application Around the Parser

Keep reception, validation and application behavior separate. The receiver collects a complete sentence; validation checks its structure and checksum; the parser extracts fields; the application decides whether those fields are acceptable. This arrangement makes a fault easier to locate than a single large function that reads characters and immediately changes outputs.

1. Accept only complete sentences that fit within the chosen buffer.
2. Reject malformed checksums and missing required fields.
3. Check navigation validity before accepting a position.
4. Record when an accepted message was received.
5. Mark the display stale when an application-defined timeout expires.
6. Keep the last known position visibly distinct from a fresh valid position.

There is an additional lesson in this fixed-output model: receiving the same valid-looking sentence repeatedly proves that the UART is active, but it does not prove that the navigation solution is advancing. A real application may need to monitor both arrival time and the time carried inside the message.

Choose timeout behavior according to the task. A classroom coordinate display can show a stale-data label. A logging system can record a missing-fix condition. Neither should silently substitute zero latitude and zero longitude, because those values describe a real geographical location rather than an error marker.

Exercise failure cases deliberately

A repeating sample stream is excellent for a first successful run, but it cannot demonstrate every failure your receiver should handle. Create a separate parser exercise using copied sample text, then change one condition at a time. Keep this exercise separate from the supplied firmware so the original demonstration remains reproducible.

First, remove the final part of a sentence and check that the application does not publish a partial position. Next, insert a new dollar sign before the incomplete line ends. A receiver that resynchronizes at a new sentence start can recover without requiring a processor reset.

Then alter one character without updating the checksum. The sentence should be rejected even if the altered field still looks numeric. After that, supply a correctly checksummed sentence whose fix-status field indicates invalid data. These two tests distinguish transport integrity from navigation validity, which are often incorrectly treated as the same condition.

Finally, stop supplying characters. Record how long the display continues to show the last position and whether it eventually identifies that position as stale. A timeout should depend on elapsed time rather than the number of times the main loop happens to execute, because additional display or logging work changes that loop rate.

For coordinate conversion, include north, south, east and west examples, a value close to a whole-degree boundary and a field with missing minutes. Check that minutes remain below sixty and that hemisphere signs are applied only once. These small arithmetic cases are easier to inspect than a long route containing many unrelated changes.

Write down the input, expected decision and observed output for each case. This creates a useful distinction between a demonstration that prints plausible numbers and a receiver whose handling of incomplete, invalid and stale data has been examined systematically.

Troubleshooting and Practical Review

My recommendation for this original library is to use it as a small, repeatable serial-data exercise. Its strength is that a beginner can observe the same input while changing a receiving program. Its limitation is that realistic navigation behavior, changing satellite conditions and receiver configuration are outside the demonstration described here.

For further projects, see interfacing the GPS module with Arduino in Proteus. Newer receiver-specific libraries are also available for NEO-6M, NEO-7M and NEO-M8N. Read each version's supported behavior before choosing one. The SIM808 library covers a different combined-module workflow.

The original video below demonstrates the library installation and terminal output. Use it alongside the written steps, particularly when identifying the component properties and the correct direction of the serial connection.

Frequently Asked Questions

Does this GPS library show my current location?

No. This original model transmits predefined navigation data. It does not access your computer's location services or receive satellite signals.

Why does the GPS component need a HEX file?

The supplied HEX implements its simulated behavior. The LIB and IDX files make the component available, but you must also assign its support firmware as shown in the installation steps.

Can I change its output by sending GPS configuration commands?

Do not assume that the presence of an RX pin implements a real receiver's command set. This tutorial documents the fixed transmitter behavior; use a model with explicitly documented command support for configuration experiments.

Can I use the same receiving code on real hardware?

The parsing approach can transfer, but check the physical receiver's voltage levels, baud rate, enabled sentences and startup behavior. Test invalid fixes and lost reception as well as normal data before relying on the result.

Is a valid checksum enough to trust the position?

No. It checks the received sentence for certain transmission errors. Fix validity, message age, required fields and application-specific limits still need their own checks.