If our digital ecology were like nature, GPS would be a horseshoe crab – an ancient animal from a bygone era that somehow still exists today. The GPS satellite network went online in 1993. However, it was (and still is) the culmination of thinking and planning that began in the 1970s. Consequently, it doesn’t entirely fit in today’s devices, most notably at the COM port.
COM Port: It’s Still Got Teeth
In the early days of GPS, PC-based software that utilized it typically received streaming data from external GPS devices. When integrating GPS modules (either on a WWAN module or a dedicated GPS chip) inside the computer, manufacturers integrate these devices to use an internal COM port (aka serial or RS-232) port, another digital relic still required by many customers’ peripheral devices. Getac continues to offer serial RS-232 I/O ports for other legacy uses.
Modern Windows O/S offers attempted to solve this issue by creating “Windows Location Service” API to allow multiple applications to access GPS data. It can also use the COM port serial data and other location resources. (IP and WLAN). Legacy programs have yet to convert to this API.
There are two potential issues if you’re using serial stream-dependent GPS software (AVL, CAD, e-Citation).
One GPS Application Per Computer
If your computer only uses internal GPS, it utilizes an internal COM port to send data to the relevant software. Only one COM port and one data feed cannot be shared. This setup means multiple GPS-dependent applications can’t run simultaneously, nullifying one of the expected benefits of internalizing formerly external functions.
DTR/RTS Incompatibility
Another issue relates to Data-Terminal-Ready (DTR) and Request-to-Send (RTS) incompatibility. DTR and RTS signals are legacy protocols that initiate information exchange between physical machines. Some internal GPS models still use these signals, and some don’t.
A few GPS-dependent software applications still depend on these signals to receive data (often older software versions running on older devices), while some don’t. As such, if the software requires DTR/RTS usage and the GPS module does not offer DTR/RTS, it can’t receive GPS data.
Issues and Alternatives
A growing number of industries are becoming dependent on real-time-location data, including utilities, transport & logistics, and public safety (police, fire, ambulance). However, many still run legacy or old versions of GPS-dependent software on legacy or old-fashioned machines, creating a difficult choice.
Some enterprises buy new hardware and endure the trouble and expense of software upgrade/migration. Alternatively, some continue the “one GPS application per computer” situation they’re already facing, even though the hardware may be long past the end of its service life.
Getac has an alternative—the Virtual GPS (VGPS) Utility. This software is a valuable solution that extends the device’s lifespan while enabling users to get more productivity from legacy GPS applications running on Getac PCs.
VGPS Utility: One GPS, Multiple Applications
The VGPS Utility virtualizes and replicates the GPS signal sent out by an internal GPS via the internal COM port, multiplying what was once one data stream into as many as five.
It enables up to five GPS-dependent software applications to run simultaneously on any Windows-based Getac tablet or notebook with onboard GPS while eliminating DTR/RTS issues.
Once installed, VGPS Utility is fully integrated with your Getac PC, enabling it to automatically detect your GPS baud rate (4800, 9600, or 115200) and COM port settings and adjust them as needed.
VGPS is compatible with all internal GPS models, embedded or dedicated, currently in use on Getac Windows devices while maintaining accessible GPS sensor data provision for the Windows Location API in either scenario.
Getac’s VGPS Utility is the most accessible and affordable choice for Getac Windows customers looking to run multiple simultaneous GPS on Serial-stream-data dependent legacy applications on a single device.
Learn more about the Getac VGPS Utility.
