The 1-bit interface(justindunham.net)
justindunham.net
The 1-bit interface
http://justindunham.net/2013/06/the-1-bit-interface/
8 comments
For kite aerial photography, I've used a really tiny altimeter that only has one LED: http://wingedshadow.com/howhigh.html
So it makes series of different blinks for a particular message?
Morse code could work pretty well with a single LED.
On the picture it looks like a row of 10 leds, you could do some binary also.
Technically? Yes. Practically? You're kidding :)
He probably isn't. Morse code is really quite usable, provided that you understand it.
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.
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.
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.
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.
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.
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.
Black gaffer's tape is great for almost all the annoying "hey, I'm here!" LEDs in the office. The blue ones are especially gruesome.
He could spin the LED strip and make a POV display. They're surprinsingly readable even with just a few LEDs.
Some work pretty well by waving, if spinning isn't going to work. The adafruit POV kit (I believe its on version 3 now) is a classic in that genre.
Reminds me of BIOS status beeps
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."