Continuing on from the discussion here - https://github.com/ArduPilot/ardupilot/issues/6137
Surely the 2nd EKF should be using the secondary baro, as there is little point in flying around a 2nd barometer if its used as nothing but a logged parameter?!
Being unable to disarm your aircraft with Alt hold as your most manual fall back flight mode, and not having a mavlink connection, which would be a configuration that many fly with, could be a little problematic!
Why surely? The EKF cores run with data from different IMUs, if all other sensors are different too then comparing the cores loses value.
It is a backup, if the primary fails, you have another.
Most manual fall back flight mode? The reason for not allowing disarm without being landed is pretty simple: you could easily disarm in the air. In manual modes, disarming means you are at zero throttle so you are already asking to stop the motors, while in non-manual modes, disarm is maximum descent with yaw (but it’s not zero throttle) - it may not be a common maneuver but is a possible one.
You have, at least, three options to disarm if landed isn’t properly detected: change to a manual mode, use motor interlock switch or use emergency stop switch - in 3.5, there is a fourth option, use arm/disarm switch. You can also try to takeoff and land again.
If they are using different IMUs, and different GPS, why not different baros?? Both are the same sensor, so both should result in the same data, within tolerance at least.
I couldnt see any code that allows it to change baro on the fly, once primary baro is determined on boot it looks to be set for the remainder of flight? So its a back up, in the sense that you can change the param file to assign the secondary as the primary, but thats not exactly something one would do in flight so isnt really redundancy
I totally understand not being able to disarm if the machine thinks its in flight, and the DJI hilarity that happened, the issue is that it still thinks its flying when its not, and the baro height is continuing to drift! The IMUs knew it wasnt descending, GPS alt wasnt descending, the throttle was at minimum for a few minutes, , but the code appears to look at baro height (and the Z axis thump) to determine if landed. No error or EKF switch happened, the code didnt see the significant fault with a sensor. FWIW I took off again and gave it a good solid landing, and it still would not disarm as the baro alt continued to fall after touch down.
I would bet 90% of users do not use Stab, Acro, etc, nor do they use the motor kill functionality. Should they? Yes, totally, but in the real world thats not the case (particularly with large commercial machines), Even having a flight mode that is independent of GPS is getting really rare! So its a bit of a band aid solution, when the actual solution is better handling of a baro failure
They don’t use different GPS. The GPS handling is exactly the same as baro.
Then why would you use a different sensor for each? The point of running separate cores is detecting when something is off with one and switching to the other good one.
We are open to better approaches and improvements. Just remember that a landed false positive is way worse than a false negative.
I would bet 90% of users have Stab in their flight modes even if they don’t use it.
Again, if you have suggestions on how we can better detect a baro failure we are all ears.
I swear 3.4 Assigns GPS 1 to EK1 and GPS 2 to EK2? Maybe I misread/heard that message. Will pay more attention next time! 
If a difference sensor is used for each the odds of both EKFs having seperate bad sensors is pretty slim! Currently all it compares is IMU data? (off topic, but kind of same vein, how is the PH2’s 3rd IMU on the FMU used?)
Again, im no coder (aircraft engineer), but as far as I can see what determines if a baro is healthy is that is has reported in the last 0.5s? So if its reporting nonsense figures, as long as it reporting something, its considered good? It boots up, looks at the param file and see its primary is assigned to #1, it sees data coming off that baro and then considers it good until it stops providing data?
It never did.
It doesn’t exactly compare the IMU data, it compares the fitness (by lack of a better term) of the estimation of each core.
It’s not only that, but yes, I agree the check is basic, but I think there is no way to better determine if the sensor itself is failing. Maybe one possible improvement is to do in EKF what is already done for compass - if it doesn’t look correct (in comparison to IMU data for example), change the used baro. I’m not an EKF expert though, so I’m not sure how feasible it is to do this.
Comparing it to IMU data at least sounds like a good idea, this is the first time ive seen this mode of baro failure (continually falling reported Alt) out of many many hours of pixhawk flights and machines, so its not exactly common, but it seems to (at least to me) there must be a better way of dealing with baro failures now that we have hardware that has multiple baros.
Is it worth me starting a github request for someone to look at how Ardupilot deals with it?
Thanks for your help and sharing your knowledge of how it works by the way, appreciated.