Thank you for the detailed and quick response. This is exactly the kind of technical feedback I was hoping for, and it sounds like there is not necessarily a fundamental hardware limitation preventing the concept. The larger questions seem to be implementation complexity and whether there is enough professional-market demand to justify it.
On the pricing question, yes, I do think there is a professional surveying market that would be prepared to pay $4,000 or more for an FP if the additional cost provides a meaningful increase in confidence under difficult conditions.
For context, professional GNSS receivers such as the Carlson BRx7 and newer Viking are sold in roughly the five-figure-per-rover market. Current dealer pricing puts a BRx7 network rover around $13,000 and a Viking rover around $16,000, with complete base/rover systems costing considerably more.
That is the market against which I am comparing this concept, rather than primarily the hobby or GIS receiver market.
Even if a premium Facet FP ultimately cost $4,000–$5,000, a professional surveyor could still be looking at a receiver costing a fraction of the price of some traditional professional GNSS heads.
There is also precedent in the professional surveying market for going beyond the conventional idea that “RTK Fixed” by itself is sufficient indication that a position should be trusted.
Carlson has used its SureFix architecture in the BRx7 for years, where additional processing evaluates the GNSS information and RTK solution to provide another level of confidence in the result.
Their newer Viking takes that philosophy considerably further with dual GNSS RTK modules and three RTK engines in its Triple-Fix architecture, specifically aimed at increasing solution confidence and reducing false fixes.
I mention those products not because I think SparkPNT should duplicate anyone else’s architecture, but because I think they demonstrate that professional surveyors place real value on additional integrity checking beyond a single RTK Fixed indication.
That is also what led me to this idea based on my own field experience.
I currently use a SparkFun Torch. Under difficult tree canopy, I can regularly obtain an RTK Fixed solution where the receiver is indicating what appears to be a tight position, but repeated occupations or checks against known ground positions can sometimes be off by approximately ±0.20 ft.
That is the failure mode that concerns me.
The receiver is not telling me that the solution is uncertain. It is reporting Fixed and often showing tight precision indicators, while the actual ground position can still be wrong enough to matter for professional boundary or construction surveying.
By comparison, when I use the Facet with the Septentrio mosaic-X5 in similar conditions, the results are generally much better and usually remain within approximately 0.10 ft in my experience.
The mosaic-X5’s multipath mitigation and integrity features appear to work extremely well.
In fact, the X5 may already solve enough of this problem that a second engine is unnecessary in most situations.
That changes how I would frame the dual-engine idea.
I would not necessarily use two engines to produce two competing coordinates, average the results, or attempt to determine which engine is “right.”
I would let the mosaic-X5 remain the positioning engine.
The second engine could simply function as an independent gatekeeper.
The normal architecture would effectively be:
mosaic-X5 position → verification gate → existing FP output → field controller
The second GNSS engine would independently calculate its own RTK solution in parallel.
As long as both engines satisfy the agreed verification criteria, the gate remains open and the normal mosaic-X5 NMEA output passes through exactly as it does today.
The field controller never needs to know that a second engine exists.
If the engines no longer agree within the specified criteria, the gate closes.
At that point the FP could stop outputting a valid RTK position, intentionally downgrade the reported solution state, or otherwise prevent the field software from accepting what appears to be a normal Fixed solution.
That seems much simpler to me than requiring GIS or survey software to interpret a new custom verification sentence.
The field software already understands what to do when it does not have a valid Fixed position.
The second engine therefore would not need to provide another position to SurvCE, FieldGenius, SW Maps, QField, or any other application.
Its entire purpose would be to answer one question:
“Do I have sufficient independent evidence to allow the mosaic-X5 position to leave the receiver as a trusted solution?”
For example, the verification gate could require:
-
mosaic-X5 = RTK Fixed
-
verification engine = RTK Fixed
-
correction age acceptable on both
-
reported precision acceptable on both
-
horizontal position difference below a configurable threshold
-
vertical difference below a configurable threshold
-
agreement maintained for a configurable number of consecutive epochs
If all conditions are met:
Gate OPEN → mosaic-X5 output passes normally
If any critical condition fails:
Gate CLOSED → trusted Fixed output is withheld
The FP itself could still provide a red LED, distinctive audible warning, or Web UI status explaining why the gate closed, but third-party field software would not need to understand anything new.
That would seem to substantially reduce one of the concerns you raised about custom NMEA sentences and application compatibility.
From my perspective, I also do not need the system to determine which engine is correct when there is disagreement.
If the mosaic-X5 says one thing and the independent verification engine says something meaningfully different, I do not want the receiver trying to intelligently pick a winner.
I simply want it to stop and tell me:
“Independent verification failed. Do not trust this position yet.”
Then I can change the observation conditions, wait longer, disable tilt, move slightly, take another occupation, switch to conventional methods, or otherwise deal with the questionable point as a surveyor.
This also makes me think two engines may actually be preferable to three for this particular architecture.
Three engines become extremely interesting if the objective is majority voting and automatically selecting a solution.
But I am not necessarily trying to create a voting system.
I am proposing a permission system.
The mosaic-X5 creates the position.
The second independent engine decides whether sufficient agreement exists to allow that position through the gate.
For that purpose I would deliberately choose a different receiver architecture for the verification engine.
For example:
Primary positioning engine: Septentrio mosaic-X5
Verification/gatekeeper engine: u-blox ZED-X20P
The use of two manufacturers would be intentional because their tracking, multipath handling, satellite weighting, ambiguity resolution, integrity monitoring, and RTK quality algorithms have been developed independently.
If both arrive at essentially the same coordinate under difficult conditions, the mosaic-X5 output is allowed through.
If they diverge, the gate closes.
Obviously, because the engines share the same antenna and correction stream, correlated errors remain possible. This would not replace check shots, repeated occupations, conventional surveying procedures, or professional judgment.
It would simply add another independent layer between:
RTK Fixed
and
position allowed to leave the receiver as trusted data.
I also think this framing could simplify the processor architecture.
If the existing FP ESP32 has sufficient capacity and can communicate independently with both GNSS engines, I would prefer the main FP processor to own the verification logic.
That keeps the logic in the main firmware and may eliminate the need for another sophisticated decision processor on the Flex module.
The Flex module would primarily provide the two GNSS engines and whatever basic interface hardware is required to expose both receivers to the main processor.
The FP firmware could then implement the gate criteria and evolve those criteria over time.
Regarding configuration, I would expect the mosaic-X5 to retain all of its normal configuration because it remains the primary receiver.
The second engine could potentially use a much smaller standardized configuration because its role is narrower. It primarily needs:
-
the same correction stream
-
matching constellation/band configuration where practical
-
position output
-
solution status
-
estimated accuracy
-
correction age
-
whatever quality metrics are useful for comparison
It may not need to duplicate every user-facing setting available on the primary X5.
That could reduce some of the configuration burden you mentioned.
The reason this remains attractive to me even if the module becomes physically larger and more expensive is the economics of the professional surveying market.
Professional users routinely purchase GNSS receivers in the $10,000–$16,000-per-head range.
At perhaps $4,000–$5,000 for an FP containing a mosaic-X5, a second independent professional-grade GNSS engine, tilt compensation, LoRa, batteries, communications, and an onboard verification gate, I would still consider it an exceptional value.
And importantly, I am not suggesting the second engine because I think the mosaic-X5 is inadequate.
My experience so far suggests almost the opposite.
The X5’s multipath handling seems to remove a large percentage of the questionable fixes I encounter with less sophisticated receivers.
The second engine would be there for the remaining edge cases—the rare but potentially costly situations where even a very good primary engine reports a convincing Fixed solution that deserves additional scrutiny.
To me, that is where the modular Facet FP architecture creates an interesting opportunity:
Keep the mosaic-X5 as the trusted positioning engine, and use a completely independent second RTK architecture as a simple gatekeeper that decides whether the X5’s position is allowed to pass to the field controller.
That seems like a potentially simpler product than a true multi-engine fused positioning system while still delivering much of the integrity benefit I am looking for.
