Hi George,
Accuracy is important, of course, but confidence in the reliability, trustworthiness, and validity of the calculated solution is crucial. I’d argue that those things are more important than absolute accuracy.
For example, I can have reasonable confidence that a solution calculated using the GPS L1 C/A, Galileo E1, and BeiDou B1 bands will be correct and valid (if we exclude extenuating circumstances like spoofing or jamming, of course) since the receiver only uses signals from satellites marked “healthy” by their respective control segments. “Unhealthy” signals are not used by the receiver, and the user can verify this by observing the output of the receiver. The control segments for those services monitor the health of the satellites and update their health status as needed.
Similarly, GPS L2 (but not L5), Galileo E5a, and Beidou B2a all have their health status updated as needed by their control segments, and the health status for each satellite is used in the receiver when calculating a solution just like with the L1, E1, and B1 signals. Unhealthy satellites transmitting those signals are not used.
However, all of GPS L5 is marked unhealthy by the control segment, so a receiver that follows the standard and expected receiver behavior should not use those signals as they are being transmitted today. So long as GPS L5 signals are marked unhealthy there is no way for a receiver to know if the L5 signal from any particular GPS satellite is correct and will produce a trustworthy solution (it could be correct, but it could also be invalid due to the satellite being repositioned, having a fault, etc.), so no receiver should use GPS L5 at all so long as the signals are marked unhealthy.
Of course, people – including myself – may want to use GPS L5 for various reasons such as testing even though the signals are marked as unhealthy. For that reason, some vendors such as, for example, u-blox have their receivers default to honoring the health status (that is, not using L5 since the signals are unhealthy) but give users the option to use L5 signals at their own risk by sending a documented command to enable them by applying the L1 C/A signal’s health status to the L5 signal.
They also provide a command to disable that behavior and return to the default behavior if that is desired (e.g. when being used in “real world” situations where reliable, valid solutions are important for safety or other reasons and “use at your own risk” is not appropriate). The default behavior and the behavior when the exception to enable L5 is used are both well-defined, well-documented, and user-configurable.
On the other hand, the behavior of the LC29H relating to its use of GPS L5 signals is not well-defined, well-documented, or user-configurable. The user of an LC29H has no way of knowing if solutions calculated by the receiver when using GPS L5 signals are valid or correct in any way since the signals are marked unhealthy but the receiver still uses them. The documentation (and responses in this thread) do not provide any clear explanation as to how it determines if an “unhealthy” L5 signal is usable or not.
LC29H’s software algorithm will process abnormal satellite signals
How does it know they are abnormal or invalid, since all L5 signals are marked as unhealthy? That is the key question I’m asking.
Does the LC29H use the GPS L1 C/A health status to override the L5 health status so it can use L5 signals? Does it simply ignore the health status entirely, and so might be using actually-unhealthy satellites? The user has no way of knowing, and so cannot have confidence that the solution being calculated in trustworthy or valid.
You say that the same method, which is not documented, is used for other GNSS services. Does this mean the LC29H correctly uses the Galileo E5a and BeiDou B2a health status for those services as it should be doing, or does it use the E1 and B1 health status to override the E5a and B2a health status? Again, this is not clearly defined and the user cannot have confidence that the solution using GPS L5, Galileo E5a, or BeiDou B2a is valid.
If the behavior was clearly documented, that would increase confidence in the trustworthiness and validity of the solutions the LC29H produces using those signals.
For example, a statement like “The LC29H receiver uses the broadcast GPS L1 C/A health status to override the broadcast health status of the GPS L5 signal so L5 signals can be used. The receiver uses the broadcast health status for all other GNSS services and signals and does not override them with the status from other signals: for example, the receiver uses the B2a broadcast health status when processing B2a signals and does not override the B2a health status with the B1 health status. In the future when the GPS L5 signal starts transmitting its actual health status, Quectel will provide a firmware update to use the GPS L5 broadcast health status instead of overriding them with the GPS L1 C/A status.” would clearly define the behavior of the receiver and allow the user to have confidence in its solutions.
Of course Quectel would need to update it to explain the actual behavior and whether or not Quectel would provide such an update in the future.
customers do not need to pay attention to this issue, but only to the accuracy
This is not reassuring. If the user does not know how the receiver is using satellites marked as “unhealthy”, especially when it’s clearly using GPS L5 satellites (all of which are marked “unhealthy”), the user cannot have confidence that the solution or its accuracy are correct. A clear explanation of how the receiver handles this situation is needed for the user to have confidence in the solutions.
I hope I’m clear. If some aspect of my message or my reasoning is unclear, please let me know and I’ll do my best to clarify it.
Thank you!