This was a near the top end model at the time, and after complaining Garmin support owned up that this was a firmware bug impact all sensors of that generation and it would take 2+ months to fix (took like 5).

But they did send me a HRM for free and I've been using that. So I am grateful that and using it since. But for short rides (like 90 min or less) I don't always remember to think to bring the HRM.

Prior to that I had two lower end Garmin watches, and despite having theoretically lower end HR sensors they did not experience such bugs or drop outs (an unexpected blip every once in a while).

But I think the main point still stands, their software/firmware/UX has not moved in relation with the hardware. Next time I'm in the market I will be consider all the options. Feels like Coros and others have come a long way.

Prob the biggest thing keeping me in their ecosystem is multi sport (variations of bike riding types -- I do all), hiking, strength training, erg, winter sports. But even there the list of strength exercises has not been updated in like a decade.

The chances of colliding with anything else would be tiny. In case of other commercial jets zero, thanks to TCAS at the least.

Personally, you couldn't pay me enough to do the latter and I'd be more than happy to do the former (but I'm not exactly looking for a job).

For safety regulators, the incentives are all on the side of limiting acute downside (e.g. a plane crashing), not maximizing potential aggregate upside (e.g. millions of tons of fuel saved per year and millions of tons of C02 not in the atmosphere).

Society punishes regulators that approve products that kill people, so regulators adapt to this and as a result tend to be very conservative.

Regulators don't capture any of the upside (reputational or otherwise) when a new product enters the market and cures disease, makes cars more efficient, helps planes land on their own in an emergency, etc.

I don't know what "right" should be here, but you've hit on a good point. It's complicated.

High integrity computing is full of pain staking processes, exactly because no one trusts C developers to do the right thing.

Tesla isn’t that. Nor Ford. Nor GM. Nor anyone else. Waymo is closest, but they limit the domain and clearly still have issues. Stick a Waymo in snow on rural roads is it good to go? Doubt it.

If the captain could figure it out, so could the computer.

I recall another crash, not so long ago, of a commuter plane where the wings iced up a bit and the airplane stalled. The crew kept trying to pull the nose up, all the way to the ground. They could have recovered if they pushed the stick forward - failing basic stall recovery training.

There are many others - I've watched every episode of Aviation Disasters. Crew getting spatially disoriented is a common cause of crashes.

BTW, my dad taught instrument flying in the AF. He said it was simple - look at the instruments. Bring the wings level, then the pitch level. Although simple, your body screams at you that it's wrong.

He carried with him a steel pipe, so he could beat a student unconscious who panicked and would not let go of the controls. This was against regulation, but he wasn't going to let a student pilot kill him.

When JFKjr's crash was on the evening news, he said two words - "spacial disorientation". Months later, that was the official cause.

So, "Columbia traffic, Cessna november one two three alfa bravo [N123AB], three mile final, full stop, runway one eight, Columbia traffic"

At a towered airport, you'd say "Columbia tower" instead, and you don't have to repeat it at the end of your message.

On the other hand, it sounds like the company you mentioned is worth imitating where possible. They sound awesome. Are you allowed to name them? Is there any writeup on how they balanced velocity and regukatory approval?

The pitot tubes had differential icing, and didn't all read 0kts – they reported different velocity against each tube, such as 40kts or 60kts (against an expected baseline of ~ 275kts). The computer correctly recognised the data was invalid and rejected it.

It's a common narrative that the captain immediately figured out the issue. The report and transcript of the cockpit recording[2] notes that the captain's interventions showed that he had not identified the stall, nor had the copilots.

         ~ cockpit recording ~
    0:00 autopilot disconnects
    0:01 [copilot right] "I have the controls"
    0:11 [copilot right] "We haven't got a good display of speeds"
    1:26 captain enters cockpit
    1:30 [copilot right] "I don’t have control of the airplane at all"
    1:38 [captain] "Er what are you doing?"
    3:37 [captain] "No no don't climb"
    4:00 [captain] "Watch out you’re pitching up there"
    4:02 [copilot right] "Well we need to we are at four thousand feet"
    4:23 ~ recording stops ~



    [1] https://www.faa.gov/sites/faa.gov/files/AirFrance447_BEA.pdf
    [2] https://bea.aero/uploads/tx_elyextendttnews/annexe.01.en.pdf

There is no engineering fix to AF447. You cannot protect a plane from what is essentially a rogue pilot who is not restrained.

It would have happened exactly the same in a Boeing. The problem was a supposedly trained and tested pilot responding to a somewhat normal event (loss of awareness and disorientation) by freaking the fuck out and throwing a plane into the ocean from 30k feet. The copilot knew what was going on with 3 minutes left until impact, and was trying to fix things, and was using the feature to override dual input, and was still being hampered by a pilot who was refusing to do the only safe thing he should have: Sit back and shut the fuck up.

The actual solution is regular testing of pilots in stressful simulations to ensure they react predictably in bad situations. That can never be perfect though.

The flight system could identify a stall and prominently alert the pilots. That's one of the recommendations from the report: to implement a dedicated stall warning. The stall warning was actually active, but disregarded/unrecognised by the pilots because of the number of other simultaneous alarms and extraneous information, including an intermittent recommendation from the Flight Director system to pitch up at 12°.

In general, Airbus aircraft don't have a dedicated AOA indicator visible to the pilots; instead AOA is visualised to the pilots by proxy via the airpeed indicator.

For AF447 the flight avionics probably had enough information to bring the aircraft back to straight and level flight without pilot input.

On the other hand the 737 Max crashes were attributed to MCAS overriding the pilot input and lowering the nose, in response to incorrect/faulty AOA sensor data.

Both were extreme examples, and the recommendations probably coalesce somewhere in the middle: better information (and alert prioritisation) for pilots and redundancy in sensors and logic.

Air Astana Flight 1388 also comes to mind. I'm not sure how a flight control system would deduct cross-connected aileron controls and adapt accordingly (without introducing other risks or failure modes). Given the glacial pace of change and approval in aviation, we're probably 20–50 years away from that level of autonomy.