Today, SkyView does not do any cross-checking of GPS or AHRS data.
For GPS, there is a priority order. It uses POS1, then GPS1, GPS2, GPS3, GPS4, POS2, POS3, POS4.
GPS devices report their own lock status. If the GPS is telling us it has a lock, we believe it and use it. So if POS1 (99% of the time the Dynon GPS puck) is saying it has a lock, we use that and ignore all others.
For GPS, being 1000 miles off is obvious to the user, but it would also be easy for us to detect. Being 1 mile off is a lot more insidious, but also much, much harder for us to detect. When you have two GPS units, they will never agree perfectly, so you can't just see if they are the same or not. Giving false positive reports is really bad since a user will get used to them and ignore them, so it's a challenge to do something like that right.
When you fly a glidepath approach from a GPS, that is fully sourced by the certified GPS driving us, so you are trusting that GPS to not tell us that it's OK when it's not, which is part of the reason certified GPS units cost so much.
As for AHRS units, today, you choose one, and the system uses that until it totally disappears from the system, and then the system will switch to a backup unit if you have one. However, one of our software guys is currently working on AHRS cross-checking and we expect this will be in our next software release. This will be an automated, background check that will then warn the user if the two AHRS units disagree and allow the user to see both at once and vote for the one they trust. Given that there are almost always only two AHRS units for us to look at, we can't vote 2 against 1, so the pilot will need to be the tiebreaker.
Since there has been discussion around these parts about documentation, I'd like to point out that this is all in our SkyView documentation already. Dynon firmly believes that you don't release software without documentation, and this type "how does the system behave" data is critical to safe operation of an EFIS system.
--Ian