Error/Beep/Blink codes

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View

I have three layers of "degradation" in the event
of various degrees of system failure:

1) if just some *aspect* of the system fails (e.g.,
an application crashes, etc.) then I provide high
level error reporting with diagnostic assistance.
E.g., a "window" can appear explaining the nature
of the problem and suggested remedies, etc.
[note that I only offer that by way of an example
to which you might relate; that's *not* what I
actually do...]

2) if significant portions of the system are in
an unreliable state, I present an unadorned error
that, at least, *says* that there is an error and
what it is (accompanied by a unique identifier
that helps pinpoint where the error is raised).
E.g., this is the equivalent of the "blue screen
of death".

3) if *most* of the system appears unreliable, I need
to fall back to some sort of "if all else fails"
mechanism that is *guaranteed* to be able to convey
information (unless the processor is toast).

This last level is roughly the equivalent of BIOS
"beep codes" -- where the hardware and software required
to drive the *display* can't be relied upon, etc.

Obviously, beep/blink codes can't say much in a manner
that the casual user will be able to comprehend.  So,
the goal is to pare down the information presented to
a careful balance that addresses three classes of people:
- the casual user who knows little more than "it's broke"
- the motivated user who will look up an error code for
   more information
- service personnel who can pinpoint the exact cause
   for the signaled error "code"

[note that I also have a means of passing "diagnostic data"
out to service personnel -- but, that requires them to have
possession of the device]

So, I want a scheme that addresses all of the above without
requiring their intervention -- since that would require more
of the system to be functional than an "output only"
mechanism as well as requiring some confidence in their ability
to correctly interact with a failed device (which is an
exceptional condition so not the sort of thing they are likely
to have "practice" doing!).

Taking audible annunciators, first...

You can vary only a few characteristics of an audio signal:
- volume
- frequency
- duration/interval/rate
- count

[note that amplitude modulation and/or frequency modulation
fall into these categories]

You can't control "absolute" volume -- there are no controls
in the device that you can count on as functioning (it's broke,
remember??).  So, in practical terms, you pick *a* volume
level that you expect to be audible without alarmingly so
(too loud is worse than too soft since a user realizing the
device to be broken will pay closer attention to listen to
"soft" sounds whereas a *loud* device report may be inappropriate
for the current environment (e.g., a business meeting).

And, a user can't probably resolve more than two relative volume
levels.  And, since they are *relative*, EVERY error code mapping
would have to employ both levels for the user to judge between

The same sorts of arguments apply to frequency and duration et al.

All of these "relative" indicators require the user to remember
past sounds in order to qualify them based on *future* sounds.
I.e., "Was that LOUD LOUD LOUD or SOFT SOFT SOFT?"  The answer
isn't known until the user has been exposed to all variations.

With that in mind, any error code format should ensure that
these variations are in expected places.  For example, beginning
each error with a LOUD SOFT preamble lets the user *know* what
loud and soft levels are *before* he has to "listen to the DATA".

IMO, the format should be fixed so the user knows what to expect
and when to expect it.  E.g., preamble, value, postamble.  So,
this implies all error codes should be the same number of "digits".

Further, the number of different *types* of digits should be
small.  So, perhaps three groups of 1 to 4 beeps.  Or, a series
of three different beeps (LONG, SHORT, SHORT vs. LONG, SHORT, LONG).

Obviously, there are lots of ways of encoding data with these
different attributes.

I'm pretty convinced that varying amplitude (two levels) is
The Wrong Way to go about encoding things.

In my opinion, the classic "beep COUNT" approach, takes a fair
bit of time to emit a complete "error code" (e.g., imagine three
groups of 1-4 beeps at 1 second intervals with a 2 second pause
between groups -- 64 possibilities taking as much as 15+ seconds
to issue).  This requires the user to "remember" what has come
before while concentrating on what is happening *now* (i.e.,
"There were 3 beeps, followed by 2 beeps and now this is the
first beep in the third group of beeps...")

I *think* a better approach may be to alternate between a set
of frequencies.  E.g., 64 codes can be expressed with a set
of six tones -- ~8 seconds for the entire code to be emitted.
I think even those folks who need a bucket to carry a tune
could "remember" something like "dah dee dee dee dah dee".

OTOH, it's not intuitive to map dah's and dee's to "symbols"
so a non-techy would never think of translating this to
the more memorable ABBBAB or 011101 or ...

Argh... tired of typing.  Hopefully, this is enough to get
some initial comments on various approaches.  Let's avoid
the visual analog of all this for the time being -- unless
your argument relates to a duality that is or is not present
in different encoding schemes...


Re: Error/Beep/Blink codes

Quoted text here. Click to load it
Quoted text here. Click to load it

What about morse code? Nokia did it on the old cellphones for SMS.
 dit-dit-dit  dah-dah-dah  dit-dit-dit
Our microwave would give the sound of a heart monitor flatlining when
it finished.
blip --- blip --- blip --- beeeeeeep

Re: Error/Beep/Blink codes

Quoted text here. Click to load it

The Morse code is a nice idea and those interested in what the error
actually is should get used to reading the code easily enough provided it
was, at most, kept at about 6 to 7 words per minute rate. Faster rates need
more concentration on the part of the listener.

Tiered error-state fall-backs are sensible depending on the remaining
capability of the system to function. Less easy to arrange in single
processor systems but in the latest multi-core devices there is no reason
why one of the cores couldn't be programmed to monitor and give the last
ditch provision of useful debug information. Having used several processors
in a system (each programmed for their own specific tasks) it nearly always
made sense to have a robust system status monitor processor to communicate
what was going on in the rest of the system.

We've slightly trimmed the long signature. Click to see the full one.
Re: Error/Beep/Blink codes
Hi Paul,

Quoted text here. Click to load it

Gack!  I, for one, don't have the "auditory acuity" (?) for
such tasks (one reason I never took the Ham exam when I was

Quoted text here. Click to load it

The same sorts of mechanisms can be applied in single processor
devices *if* you plan for it from the start.  Much harder to
try to retrofit that capability into an existing system ex
post factum -- unless you get lucky!  :>  It also is a lot
easier if you design the hardware with this issue in mind.

E.g., to return the to laptop analogy I mentioned elsewhere...

If you can't control power to the disk drive, then a "low
battery" will cause the entire system to "refuse to start"
(because of the load placed on the battery by the disk
trying to spin up dragging the power supply down *as* the
processor is trying to report a failure, etc.)

"Reliability" is a wee bit harder to fit into designs, eh?  ;-)

Re: Error/Beep/Blink codes
Quoted text here. Click to load it

[ OT
Being on intensive care a couple of weeks ago, I can testify that
a heart monitor doesn't bleep, except in films. It would keep you
awake all night. In films it is a nice dramatic touch if you have
an actor who doesn't know how to die. ]

Quoted text here. Click to load it

In my ciforth systems (also on Renesas and 6809) it works like this.
Each error situation is identified by a number. On error always
the text "ERROR " and the number in decimal is output *immediately*.
Then an attempt is made to get a one line description from the back
ground device, and if that succeeds that is printed.
If a user is clever enough to note the number, he can find information
pertinent to what could cause the error in the documentation.
I could be called weakly tiered ...

Groetjes Albert

Economic growth -- being exponential -- ultimately falters.
We've slightly trimmed the long signature. Click to see the full one.
Re: Error/Beep/Blink codes
Hi Albert,


Quoted text here. Click to load it

Presumably, you didn't take that opportunity to "expire"  ;-)
(hope you are well)

Quoted text here. Click to load it

ROTFL!  Yes, good point!

Actually, most of the "sound" is that from medical staff.
One wonders if they've ever *thought* about how noisey
their activities really are -- especially to a patient
who may be having trouble getting sleep as it is (hourly
wellness checks, etc.)!

Quoted text here. Click to load it

This is similar to many common protocols:  error number (which can
be parsed by a piece of code) followed by a terse "description"
(which often sheds very little light on the problem *or* remedy).

Quoted text here. Click to load it

In my "top tier" (for want of a better term), each *point* in the
code that can generate an error is "tagged" (even if more than
one point can "signal" the "same" error).  These are then mapped
through a database/expert system to a "likely cause".  This, in turn,
produces an index into the device's documentation (all documentation
resides *in* the device).

So, instead of a one-liner, the user is treated to a description of the
problem and likely remedies (this is available in increasing level
of detail -- no need to bother an experienced user with a verbose
description of an error that he may already be familiar with).

The "unique tag" for each error "point" in the code gives me
extra information (i.e., it was this *line* of code that signaled
the error) about the cause which can further refine "exactly"
the nature of the problem (or, at least the code's delusions!)

But, for all this to work, *lots* of stuff has to work!  I.e., the
"manual", the interpretive agent (expert system), the error
signaling mechanism, etc.

So, if parts of this "reporting system" aren't operational, I
fall back to cruder means of conveying information to the user.
If all else fails, beep/blink codes (as they impose the least
dependencies on the remaining system).  I.e., I trade off the
amount of assistance I can provide to the user for the guarantee
of being able to "get the word out".

Re: Error/Beep/Blink codes
Hi Robert,

Quoted text here. Click to load it

Wrong audience.  :>  I doubt "GrandMa" is going to know Code!
And, any implementation like that would be too "rich" for the
information content it carried (unless you restricted yourself
to all symbols of, e.g., 3 tones -- in which case, being able
to map those tone sequences to "letters" doesn't really buy you

I think it is important that the format of the "error code" be
rigidly constrained.  If, like Morse, a symbol can have different
numbers of elements (e.g., dit vs. dah-dah-dah), then you run the
risk of a user failing to perceive/remember a portion of the
code and effectively morphing one code into another.  E.g.,
there is a reason you say "code 001, code 142, etc." and not
"code 1, code 142, etc."

Quoted text here. Click to load it

Re: Error/Beep/Blink codes
On Sun, 01 May 2011 19:56:40 -0700, D Yuniskis

Quoted text here. Click to load it

At least make sure the modulation goes nicely through various cellular
codecs. For instance some kinds of amplitude might be defeated by the
a.g.c. in the telephone signal chain.

For repeatable errors (such as power up errors), it would be handy to
tell the customer to put the cellular phone close to the device and
repeat the error. The support person could then listen for the
sequence him/herself and not rely on the end user interpretation of
the error code.

Quoted text here. Click to load it

Do you really have that much error situations, in which a more
expressive error method can't be used.

If the problem is not repairable by the end user or local
representative, is there much point in going into too much details in
the error codes ?

Re: Error/Beep/Blink codes
Quoted text here. Click to load it

Wow!  What an *obvious* idea -- and one that I would have *completely*
overlooked!  This makes even more sense than the other "more expressive"
mechanisms that I use *before* things deteriorate to this point!!

I.e., use something like the phone company uses for status messages
-- preceding each spoken message with a series of tones that tell
you what the message really contains (in abbreviated form).  Much
like prefacing a text message with a numeric code (that can be
easily parsed by a piece of software).

Hmmm... I will need to rethink this approach with this in mind!

Quoted text here. Click to load it

The problem is that the "remedy" beyond this point is very
expensive -- factory service.  This is 24 hour turnaround (!).
Just the shipping costs alone (forget the labor to troubleshoot
and repair) can eat you alive!

So, you want to be able to get as much information from the
device *without* having it in your possession.

E.g., consider a laptop and a "casual user":  "It doesn't work".
- is the battery discharged?
- is the battery incapable of holding a charge?
- is the device *actually* running off AC power?
- is the disk spinning up?
- is something in the BIOS configuration hosed?
- is the backlight dead?
- has the disk image been corrupted?
- is the CPU/GPU overheated (fan failure)?

You *could* try to talk the user through this sort of diagnosis
over-the-phone.  *Maybe* he can hear a spinning disk.  *Maybe*
he can feel airflow from a cooling fan.  Maybe he is telling the
truth when he says the battery has been charging for 6 hours.  etc.

But, that effort costs you time/money.  And, it will aggravate
the user when he has invested EVEN MORE TIME "doing YOUR work
for you" (over the phone) only to face the possibility of
being told, "Gee, we don't know what the problem is... send the
unit in to us..."

All of these are worthwhile bits of information to have
*before* resorting to "ship the 'defective' unit to us *while*
we are 'overnighting' a replacement to you".  Having a way to
get information from the device itself without relying on
the user's "interpretation" of symptoms, etc. is a big win.

Quoted text here. Click to load it

The device *may* be "fixable" (not necessarily "repairable")
by the user.  E.g., if you can verify that the problem is a faulty
battery, then you can just ship a replacement battery to the
user for far less cost and EFFORT (yours as well as the user's)
than replacing the entire device.

A "local representative" requires you to *have* folks in the
field to support the devices.  That imposes a big fixed cost
"just in case" things *might* break.  Easier if *you* can just
give the user an answer and a remedy in short order.

E.g., apparently, a *huge* percentage of "returned" disk drives
test as "No Defect Found".  So, the manufacturer absorbs a
big cost for testing and replacing those devices needlessly.
And, runs the risk that the "replacement" device may be regarded
as "similarly defective" (i.e., the first error was apparently
user related or a consequence of some other aspect of the
application that used the drive -- "software bug"?) which
reflects badly on the disk manufacturer.  (people remember
returning the drive and might not remember that the real
problem was proven as "elsewhere")

If, OTOH, the drive manufacturer could talk to the drive
*without* having to rely on all the other bits of the
"system" in which it was employed, then many of these
problems could be avoided.

Re: Error/Beep/Blink codes
Emitting DTMF maybe a good one, so an automated right department switchboard
thing could happen.

Re: Error/Beep/Blink codes
Quoted text here. Click to load it

Fails big time when a phone is *not* involved:

"Could you please tell me what the error tone was?"

"Well, it kind of made a bunch of beepy-boppy noises..."

Re: Error/Beep/Blink codes
On Mon, 02 May 2011 00:58:53 -0700, D Yuniskis

Quoted text here. Click to load it

When multi megapixel pocket cameras are common and cellular phone
cameras reach at least VGA or even megapixel resolution, why not
generate static error code displays and ask the customer to use a
camera or cell phone to send a picture of that situation. We have been
able to detect missing terminators and other wiring problems this way.

I mostly work for a company with offices in quite a few countries all
over the world, unfortunately most of the countries, in which English
is not the native language (including the HQ).

If you have time (at least a few days) to be familiar with the English
dialect spoken by the other person in a different country, the
communication starts to be productive.

However, in problem solving situations, people usually meet for the
first time and the problem has to be solved in an hour or so, so there
is no time to learn the dialect of the other partner.

For this reason, we try to encourage e-mail (and other written
communication) to avoid the problems with dialects. Asking to take
pictures is often more productive than trying to ask someone to do
complex sequences, if we do not have a common language.

Re: Error/Beep/Blink codes
Quoted text here. Click to load it

Fine -- *if* you have a visual "display" to photograph!  :>
The point of my beep/blink query was to try to come up with a
scheme that could treat visual and audible "indicators"

Re: Error/Beep/Blink codes
Quoted text here. Click to load it

If you can do amplitude and frequency modulation, why not just speak
the error codes?  Of course that means you have to pick a language.

Re: Error/Beep/Blink codes
Hi Robert,

Quoted text here. Click to load it

Speech (crude) takes about 40KB (or are you just suggesting
something like canned saydigit(digit)?)

Re: Error/Beep/Blink codes
Quoted text here. Click to load it

Simple as you like.  Say "System error, please call support, write
down this number: 1..2..3..4..5..6..7".  That one canned message plus
the digits needs about 10 seconds of recording time, and you don't
need to process anything more complex than the waveform files.  A
crude text-to-speech (probably synthesized phoneme based) is also
possible, if a bit more work up front, and gives you a great deal of
output flexibility.  Since you're generating all the messages, you can
code them as the required phonemes rather than normal text (that kind
of synthesizer can be quite small, but will definitely sound
artificial).   Shorten it if you have space limitations, you could
just do the digits.  You could even just do four digits, and output
the code in base-4.

It doesn't have to sound fantastic, after all, just intelligible to a
user with an otherwise dead system.  It would certainly be friendlier
than beep codes.

Re: Error/Beep/Blink codes
Hi Robert,


Quoted text here. Click to load it

But 10 seconds at even 32Kb/s (the low end for "phone quality
audio"?) is already more than an entire (crude) synthesizer!
Plus, you need to add the *code* to run the CODEC (decoder).

Quoted text here. Click to load it

Yes.  Eliminating the "text-to-phoneme" portion of the code
saves you a few (5?) KB.  IMO, not really worth the hassle as
it forces you to limit what you can "say", artificially.  And,
the computational load required for this phase is pretty
trivial (esp if you restrict the vocabulary that you use)

Quoted text here. Click to load it

Understood.  But, doesn't help in applications that don't have
audio (or, don't have a "full range" audio driver/speaker).
And, is a bit heavy on computational requirements (for low end

I am hoping for a scheme that doesn't care (need to know) what
the actual representation of the "code" will be at presentation.
E.g., blinks and beeps *can* have an inherent duality.

Re: Error/Beep/Blink codes
Quoted text here. Click to load it

Plus, you still have the multiple language problem.

I still think a sweep UP (maybe lasting a few hundred milliseconds)
follwed by the 'tens' digit in beep-code, then a freq sweep DOWN
followed by the 'ones' beep-code is doable. It has at least some logic
to it, probably works over the phone, and could easily give 99 codes -
maybe more. It doesn't translate well to visual directly, but you
might be able to alter the duty cycle going to an LED to get a similar
effect. long pause, UP brightness short pause, flash-code, long pause,
DOWN brightness, short pause, flash-code.

Re: Error/Beep/Blink codes
On Thu, 5 May 2011 00:08:47 -0700 (PDT), ""

Quoted text here. Click to load it

This is good as long all your users understand English :-).

If you ship your products world wide, either make regional versions of
it or have some means of selecting the language _before_shipping_. Of
course the language selection DIP switches/flash may also fail .....

I am not quite sure what the OP is actually trying to do.
In practice, if the system suffers a catastrophic failure, the most
likely user action would be to restart the device (based on past
experience of bad devices locking up :-).

Thus, the problem is simplified to the Power Up Self Test (POST)
sequence. If it is a persistent failure, then the problem will
reappear during the POST and indicated by means available at that
particular phase of boot sequence.

The POST sequence should initially only check for resources that are
needed by the following stages (and reporting error in them), thus the
number of errors that needs to be reported with a single flashing LED
is quite small (such as missing or faulty RAM, run the check code from
ROM and use only internal registers).

In the next stage some speaker/sounder can be driven with PWM from a
binary output pin and then to check the availability of sound card or
display adapter etc. and if verified good, use these for more
expressive error messages.

Re: Error/Beep/Blink codes
Quoted text here. Click to load it

Rather than use just one LED to blink a fault code, I wonder if the product
has more than one LED attached. If so, a fault code can be written out in
binary to the LEDs. If the product has just 3 LEDs, that's 7 different
fault codes available right there.

To distinguish from normal operation, the code driving the LEDs can just
flash the binary 1 LEDs at a rate of, say, once per second.

All you need to do then is ask the end user which LEDs are flashing without
having to worry about asking them what pattern they are flashing.


Simon Clubley,
Microsoft: Bringing you 1980s technology to a 21st century world

Site Timeline