I’m setting up a GPS signal feed for my field team’s work. The receiver exposes one serial connection, but two desktop applications need the live data at the same time. I tried opening the port in both applications. The first connects, and the second reports that the port is unavailable. I also tried capturing the serial output to a file and replaying it, but that removes the live position updates we need.
Are there any serial slitter apps that can duplicate one GPS serial stream into separate virtual ports without changing the incoming data? What should I try next, and are there specific compatibility or timing issues I should check before putting this into our workflow?
If the GPS outputs a one-way NMEA stream, a software splitter should work without modifying the sentences. I’d use Virtual Serial Port Driver to map the physical COM port to two virtual ports. This COM splitter can be used for the GPS. Before deployment, confirm both applications expect the same baud rate, data bits, parity, stop bits, and NMEA or proprietary format. Disable hardware flow control unless the receiver requires it, and test reconnect behavior, buffering delay, and what happens if either application sends commands back to the GPS.
Don’t use a passive Y-cable or keep forcing both programs to open the physical COM port. Windows normally grants one process exclusive access, and a cable split can create electrical problems if either application transmits.
I’d put Virtual Serial Port Driver between the receiver and the software, using the app to create separate endpoints. The GPS feed can then be copied to each program without either program owning the real port directly.
The catch is the return path. If both applications send polling or configuration commands, decide which one gets write access and leave the other read-only. Two programs changing the receiver setup can produce failures that look like bad GPS data rather than a serial conflict.
Expect a little setup friction even after the splitter is installed, mostly because GPS applications can be picky about when they detect COM ports. Create the virtual ports in Virtual Serial Port Driver before launching either application, then select a different virtual COM port in each program.
Match the receiver’s baud rate, data bits, parity, and stop bits exactly. Leave hardware flow control disabled unless the receiver documentation specifically requires it. If data appears in one application but not the other, check whether the second program only scans for ports during startup or expects complete NMEA sentences rather than arbitrary serial data.
@vectorexplorer3421 is right about controlling outbound commands. For a field setup, I would configure the receiver separately, then run both desktop applications as listeners so a restart cannot quietly change the GPS output format.
For ordinary map display, a software splitter is usually enough; for surveying or precise time synchronization, it is not equivalent to having separate receiver outputs.
Virtual Serial Port Driver can duplicate the NMEA byte stream, but Windows buffering may make the sentences reach each application at slightly different times. It will not duplicate a separate PPS timing signal either. That rarely matters for tracking vehicles or plotting field locations, but it can matter if either application calculates timing or precision from serial arrival time.
I would test the setup while the PC is under normal workload, not just sitting idle. Compare each application’s displayed GPS timestamp and watch for growing lag after several hours. If timing accuracy is important, use receiver hardware with multiple outputs or distribute the feed through a dedicated GPS/network service rather than relying entirely on virtual COM ports.
The annoying failure usually appears after a reboot or after somebody unplugs the USB receiver, not during the initial setup. Windows may assign the receiver a different COM number, or the splitter may start before the USB serial device is ready. Everything then looks configured correctly, but neither application receives a position.
A serial splitter is still the right type of software for this. Virtual Serial Port Driver can own the receiver’s real port and expose two virtual ports, with each application opening its own endpoint. I would avoid giving either application the physical COM port, since that makes startup order matter and can bypass the splitter entirely.
For a field machine, make the setup survive normal abuse:
- Assign the receiver a fixed COM number in Device Manager.
- Configure the splitter to start automatically.
- Check that it reconnects after USB removal and insertion.
- Start the desktop applications only after their virtual ports exist.
- Make sure a crashed or frozen application cannot block delivery to the other port.
- Save the splitter configuration somewhere the team can restore it.
That fifth point is easy to miss. Some serial-sharing tools maintain independent buffers for every client, while others behave badly when one program stops reading. Leave one application paused or hung for a while and confirm the other continues receiving fresh fixes rather than delayed sentences.
If the applications support GPS input over TCP or UDP, I would seriously consider a small GPS service instead of virtual COM ports. It reads the receiver once and republishes the stream to multiple clients. That tends to recover more cleanly and makes logging or remote access easier. If both programs insist on COM ports, though, the virtual splitter approach is the practical answer.
I would finish by testing the exact failure cases your field team will create: cold boot, application restart, laptop sleep, USB disconnect, and loss of GPS lock. A splitter that works only while everything starts in the perfect order will become a support problem pretty quickly.
Check the USB latency timer before you blame the splitter for lag. Most USB-serial receivers ship with the driver’s latency timer set high, so Windows sits on incoming bytes until that timer expires or the buffer fills up. Drop it to 1 or 2 ms in Device Manager under the port’s advanced properties and a lot of the drift @bytegadget13 described shrinks. It still won’t hand you real PPS, he’s right there, but it stops the software layer from making the timing worse than the hardware already is.
On the two-programs-writing problem, I’d go a step past just marking one port read-only. If neither app genuinely needs to reconfigure the receiver during normal work, strip the write path out completely. Set the receiver up once with the manufacturer’s utility, commit the config to its flash if it supports that, then run both desktop apps as pure listeners. No outbound path means no write conflict to chase down at 6am in the field.
Virtual Serial Port Driver duplicates the stream without fuss, and if you’d rather not spend anything, com0com paired with a small forwarder gets you close for free, though you pay the difference back in fiddly setup. Whichever you land on, the part that actually bites field laptops is what @omeganinja6093 called out: boot order and the receiver landing on a new COM number after a reboot. Fixed COM assignment plus autostart matters more than which splitter has the nicer interface.
Honestly though, if both apps can take GPS over TCP, quit fighting COM ports. One reader republishing over the network shrugs off a yanked USB cable without anyone touching the machine, and you get logging thrown in. Keep the virtual ports only if one of your apps flat out refuses anything but a real serial number.
Automatic recovery is something to test, not something to promise just because the feed uses TCP, @serg2000. Before switching away from a serial splitter, I’d want to see the proposed forwarding service recover the receiver connection while both desktop applications remain open. Restarting the service and getting data again wouldn’t pass that test for an unattended field setup.
A splitter still fits the original requirement. My acceptance test would focus on what the operators see during an interruption: unplug the receiver while both applications show a position, and check whether each clearly marks that position as stale. Then reconnect it without touching either application and watch for fresh timestamps. Getting the bytes flowing again is only half the job. A screen that keeps showing an old location without an obvious warning is the failure I’d be more concerned about.
Both applications still have to live with the same receiver output. A serial splitter solves access to the port, but it doesn’t give each program its own GPS configuration. Before paying for software, compare their required sentence types and update rates, not just their COM settings. I’d check whether you can configure a single output that both accept. Otherwise, you’re copying an incompatibility to another port.
