I can't take credit for this idea; a neighbor did a project for a local utility involving RF meter reading and he used 2 GPS units in the vehicle.
Anyway, I put a couple of GPS units on a breadboard and wired them to an Arduino Fio (odd choice, but I got it not realizing how low power it was and so the xBee interface is worthless to me as it won't power a 900 Pro and a GPS at the same time). I used NewSoftSerial for both units, freeing up the hardware serial for programming/diagnostics while developing and reporting the consolidated result to main controller when complete.
The first thing I ran into is a problem with NSS - switching back and forth between GPSes caused lost bytes and no good sentences. So for an initial test, I made it time based and processed one and then the other for 1500 msecs at a time and fed each into its own TinyGPS object. This works. I am planning to change the logic to swap sooner that 1500 msec if I receive and process a full set of NMEA strings before the timeout expires.
OK, so now I have 2 TinyGPS objects with data. There are 2 issues to resolve - how to consolidate their information and how to report it. I will go into those in reverse order, mostly because the second one is easy.
This is a custom component for use in my projects. I can define the protocol to be whatever I want that meets my needs. I need location, speed and course. I would also like "confidence" - an indication of whether the value is exactly what both are reporting, a consolidation of 2 very close readings, a consolidation of 2 fairly close readings or digital Ouija (aka BS). I will make it a short packet, possibly only in response to being queried for it. Besides giving the main controller better data, this will offload a lot of processing so the main controller will have more time to dedicate to that global domination thing...
So, how do I consolidate them? Here is what I think...
If both units report a speed and course within 5% (just a guess; will do a lot of testing), I will use those values and report confidence in them. I will return -1 when I cannot resolve them, probably indicating no motion or spinning.
If I am in motion, I will make myself crazy trying to resolve the position readings. Those have been really good readings in testing and not the problem I am trying to resolve. I will just accept the last position read.
If I am not in motion, it gets tricky. I have some doubt about whether using both readings buys me a whole lot here, other than knowing with some reliability when I am moving again. The easy answer is to compute the midpoint and return that, but I am not sure that is a good answer. Thoughts are definitely welcome.