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 utilised it typically received data from external GPS devices. Manufacturers designed these devices to use the COM (serial or RS-232) port. This digital relic is no longer found in many of today’s PCs.
The GPS data may come from an internal GPS if you use GPS-dependant software (AVL, CAD, GIS). It is either embedded or a dedicated module, creating two potential issues.
One GPS Application Per Computer
If your computer only uses internal GPS, it utilises an internal COM port to send data to the relevant software. But only one COM port and one data feed cannot be shared. This setup means multiple GPS-dependant applications can’t run simultaneously, nullifying one of the expected benefits of internalising 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-dependant 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 doesn’t have GPS in terms of DTR/RTS usage, it can’t receive GPS data.
A growing number of industries are becoming dependant on real-time-location data. This includes utilities, transport & logistics, and public safety first response (police, fire, ambulance). However, many still run legacy or old versions of GPS-dependant 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. This is regardless if 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. It users to get more productivity from legacy GPS applications running on Getac PCs.
VGPS Utility: One GPS, Multiple Applications
The VGPS Utility virtualises 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 five GPS-dependant 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.
It is also compatible with all internal GPS models, embedded or dedicated, currently in use on Getac Windows devices, enabling accessible GPS sensor data provision for the Windows Location API in either scenario.
Getac’s VGPS Utility is an accessible and affordable choice for Getac Windows customers looking to run multiple simultaneous GPS-dependant legacy applications on a single device.
Learn more about the Getac VGPS Utility.
