We built a handheld device with only a few LEDs as a UI and found that people can easily tell solid from blinking and they can count groups of blinks up to maybe 3 or 4. Using blinking frequency did not work out well at all.
The WiFi LED was blue and there were lots of coverage problems at the customer sites . We wrote a blues song "The Blinking Blues" about it and performed it at our offsite. One of the lines was something like "I don't know if it's blinking fast or slow."
Is this the case even with a large difference between fast and slow? I would imagine that there's a large intuitive difference between 1 Hz and 5 Hz, for example.
Even if you don't understand it, if you stick to a reasonably low words per minute, you can write down dots and dashes and simply look them up in a table. Unless you're pretty dense you only have to look up the two letters "dash dot dash dot (pause) dash dash dot dash" about 20 times before you memorize it for life. I did something like this with some Russian ham radio satellites, um, quite a long time ago. It turns out their telemetry stream didn't use the entire morse alphabet which caused me some trouble later on LOL.
Back in the "old days" PCs that failed their BIOS boot had a whole symphony of weird beeps to indicate which failure mode applies. So two short low pitched beeps and one long high pitched beep meant "video bios missing" or something (specific example made up, general idea does apply). I always thought morse code would be an infinitely better user interface. Although I had internet access, this was before widespread adoption of it and well before the invention of the www so you can imagine how much more useful plain english morse code would be for error codes vs seemingly random beep patterns.
I also used to own a pre-ODB2 car which output its "code failures" by a light flashing method very much like the article describes. Three flashes short pause 4 flashes long pause meant engine computer undervolt failure aka its time to replace the five year old battery, or at least it was something very similar.
If you wanted morse code for entire messages, that would require a much larger storage ROM just to hold them. Instead of a two-byte error code holding the entire failure indication, those same two bytes now only hold maybe a word in the error message at most. And when you're troubleshooting an error, now you have to sit through the entirety of the word "Missing " after trying a fix before you can tell whether it's the same error or something different this time.
Besides, you didn't need the internet to look up the error codes when you typically had the dead-tree edition of the same information.
True, but you could compromise and instead of having a randomly selected pattern of seemingly random beep patterns for every motherboard bios ever made to indicate video bios missing, you could just have an industry standard to send morse code "v". It would require similar to less code, definitely less docs, and somewhat less training.
I don't text but my phone had a "ringtone" to announce SMS messages that simply beeped out "sms". I agree that it could have beeped out "GSM 03.41 Short Message Service Cell Broadcast" but "sms" did just as well, much faster.
Morse code was the standard for single-channel binary communication for centuries. It's still used in some applications. Obviously it's not particularly useful for communication with an untrained user, but it's a pretty proven method for single channel communication with a good balance of complexity and data transmission rates. I suppose its use in an application ultimately depends entirely on what you're trying to communicate and why you're constrained to 1 bit.
Is it still a 1-bit interface if you add time to the mix?
Strictly speaking, a 1 bit interface is on or off and nothing else. There is no timing in there, no blinking or anything. It's 1 or 0.
If you add time, you suddenly end up with a discrete or even a real function which maps time values to 1 bit. That's however a lot more than 1 bit to encode in total.
If you just think about it, if your device changes state precisely every second for 128 seconds, the entire communication between you and your device is 128 bit even though the lamp itself only outputs 1 bit per time. That's not a 1 bit interface anymore.
I've used a hobby brushless motor controller which was configured with a single button and a single blinking LED forming a kind of menu system. It was a fiddly process which required reading the manual carefully and a good memory of what state you were in. Thankfully it's only something which you need to do once in this case.
Laptop 'power' lights convey a couple of different states with a single light. Besides the typical on/off, there's also the 'sleep' fadeup/fadedown sequence.
One could also add a few blinking states. Slow blink = charge, fast blink = problem, two quick blinks = alert, etc.
I find it incredibly annoying that laptop lights blink when they're on standby - I often put my laptop on standby when I sleep and then I have a light either blinking or "waxing/waning" in my face (I like to sleep in complete darkness). My improvised solution is to throw an item of clothing over the laptop now.
The WiFi LED was blue and there were lots of coverage problems at the customer sites . We wrote a blues song "The Blinking Blues" about it and performed it at our offsite. One of the lines was something like "I don't know if it's blinking fast or slow."