In safety industries, particularly aviation, "alarm fatigue" is a really big deal. You recognize that pilots have limited situational bandwidth, and you REALLY don't want to be bugging them about things you can avoid. I worked in collision avoidance systems (TAS/TCASI/TCASII), and spent nearly a whole year just working on figuring out when and how we could avoid warning pilots in cases where "we're not sure exactly what is going on, so tell the pilot just in case" could potentially annoy pilots in cases like take off and landing (where they have important OTHER things to be doing!)
It's a fun balance between "possibly don't warn the pilot about something they should know about", and "don't warn them if they are busy doing something important".
But alarms drive engagement. Also, display a company logo and complete product name™
More seriously, I have a garmin watch that displays notifications for things, but they automatically disappear and you cannot figure out what they were.
I think being overwhelmed by alarms should be matched with the confidence that you can find the alarm if you accidentally dismiss it or something important comes up.
Chemical companies could allow vendors to sponsor various alarms in their plants: "the Flowserve(tm) High-Level alarm on T102 is active!"..."the Flowserve(tm) High-Level alarm on T102 is active!". Then there could be a contractual minimum for the number of times that ad needs to be served to operators and engineers, otherwise the chemical plant would need to refund Flowserve for the unused ad campaign credits. Lowering the threshold of the high-level alarm would optimize ad revenue!
Uhm, my recent washing machine purchase involved actively looking for not needing an app. They did try hard though, for example by offering 3 more years of warranty when you install the app.
Either the cost or repair/replacement during those extra 3 years is really low or your data is really valuable. Adds flavor to the challenge in designing it to last just long enough to leave warranty.
Data is probably not the only advantage they get from the app. For example, you are more likely to purchase other appliances from the same vendor so that you can have them all in the same app.
My washing machine doesn't beep when it is done. My dryer does. So I some times don't time the emptying of the washing machine and have to wait a couple of minutes and the dryer annoyingly beeps when done.
How about an alarm with a mute button. Then everyone can be happy.
That's why the first thing I do on my new phone is disable the Google app.
It does absolutely nothing useful for me, but never sleeps, eats resources and shows you advertisements.
I also hate the mobile apps that designed to be always on, always listening or nagging.
So, I have the policy: if the app is only useful occasionally and it is active but I didn't start it - I disable it. And I'll enable an app when I need it, not whenever it wants me to use it.
I consider any notification for something I did not explicitly sign up for an ad. So if I get a notification like "use Gemini" or "heres a tip:", that's an ad.
Unfortunately that makes, like, half the default notifications on Android ads. But you can disable all of it.
Which one contributes more to alarm fatigue, spoken announcements like "bank angle" or beeps and buzzes like the autopilot disengage theme tune? Why is the latter so prominent?
If it's something that happens often (like on every trip or most days), a spoken announcement is more tiresome. If it happens rarely, the beep-encoded one is way more tiresome and can reduce situation awareness.
Curious if there's research - I'm sure there's tons, I just don't know that literature - but personally, in my experience as a professional aviator and as a spacecraft operator, the fatiguing alarms are the ones that are triggered in normal situations. If you start blinking red and squawking at me when I'm doing something nominal, you are training me to ignore you.
Autopilot disengage is heard every single flight and is completely benign... unless neither pilot was expecting it in which case it is very effective at getting our attention.
Squelch is a dial that changes a threshold below which analog radio signals are silenced so you can ignore noise. The dial allows you to dig into the noise when you want or be more conservative and only pass strong signals through.
Not quite. More like signal-to-noise-ratio gate. In radio transmissions, there is white noise when no active signal is received. Radios mute themselves when there is white noise, as to not annoy the user. On 2 way radios this is very important otherwise the radio will be hissing at you most of the time.
The squelch setting determines the threshold of signal to noise allowed through. If the incoming transmission signal strength is really bad, the radio might not unmute itself. So you turn down the squelch, which might completely open the radio bringing in white noise, but you can then receive the transmission.
Isn't they exactly what a noise gate does? You set a level of loudness below which it mutes all sound. If sounds levels go above that then it plays whatever sounds goes above it.
Nordic's nRF family is the major other vendor I've seen doing this, almost all peripheral can be on any pin. It's definitely a big help for designing boards.
Hey, I'm James! I have my company (OneVariable), and have 7+ years of embedded Rust experience, and 10+ years of embedded experience. I've been helping teams start using Rust, or scale up their use of Rust, through advising, training, and development assistance, as well as "Senior as a service" to help teams that are ramping up but still need help with questions around embedded/rust. Happy to help customers in EU and NA time zones.
Let me know if you need any help getting big computers talking to smaller computers!
Thanks for Sublime Text! It's been my daily driver for over 15 years :). 10 of those developing Rust, and making heavy use of the Rust Analyzer/LSP plugin infra.
I also want to thank you for having such a reasonable licensing model, I'm launching my own desktop app in the next week or so, and I plan to have a very similar model to Sublime (free to use with nags, license is good for any personal usage, inclusive of updates for X period of time).
For each release of Ferrocene, this is kept up to date, and the same as C or C++, what is specified and stable can be relied upon, and implementation details are implementation details, the same as it would be if you switched from LLVM w/ SolidSands' SuperTest suite to IAR or GreenHills' toolchains which may have varying impl details but still maintain conformance with the specification.
The majority of safety critical teams will snapshot a single toolchain for the entire development lifecycle (sometimes updating if necessary, very rarely), but Ferrocene is releasing updates that are approaching the full Rust cadence (IIRC they've discussed going to every other release, so once every 12 weeks vs Rust's 6 week cadence), with all of the verification required to ensure the specification is still complete, and all tests are passing.
There's still work to specify and test more/all of the core/alloc/std library components, as well as third party crates, but from a toolchain perspective, it is much closer than you are giving them credit for. Unlike many proprietary C/C++ toolchains or verification suites, the majority of safety justification artifacts are publicly browseable here: https://public-docs.ferrocene.dev/main/index.html.
(I am a former founder of Ferrous Systems, and one of the people that pushed for the Ferrocene project to happen, but haven't worked there for a couple years and have no monetary stake in them anymore - I think they are just still doing the right thing, and doing it well.)
I bridged my bluesky account, if you're on mastodon and want to talk to me here, you're welcome to. Not sure if you need to opt-in on the mastodon side to be bridged to bluesky.
It's a fun balance between "possibly don't warn the pilot about something they should know about", and "don't warn them if they are busy doing something important".
More devices should have a "squelch" switch!