Is 0x9B (155decimal) a special control character? Why is it missing from ascii tables?

I'm working on an embedded system, and i'm having dramas getting it to send a certain chunk of data across the serial port. I narrowed it down and found that if a 0x9B is present in the message, it corrupts the message.

So i then look up 0x9b (155) on http://www.asciitable.com/, and it's missing! Isn't that a bizarre coincidence!

Any ideas, is this a special character or something?

-edit- Okay sorry guys, it wasn't the 0x9b causing this, it was an 0x11 character. Which...drumroll... is an XON/XOFF character. I mistakenly had flow control as xon/xoff on the computer开发者_开发问答, and no flow control on the device! Thanks for the help anyway.

In ANSI escape sequences, 0x9B is the one-character Control Sequence Introducer (the multi-character version which is more familiar is ESC-[.

0x9B is the CSI or "Control Sequence Introducer" its part of the C1 set of control codes, see here: http://www.search.com/reference/C0_and_C1_control_codes

Assuming the data is passing through a layer that processes C1 control codes it not surprising that there are a few bytes missing after this character as it is used to indicate the beginning of an ansi escape sequence. The bytes are disappearing because some layer is pealing them off as part of an instruction. More info on that here: http://en.wikipedia.org/wiki/Control_Sequence_Introducer

Obviously can't guarantee this is your problem but its where I would start digging in the api documentation based on the symptoms you described.

If the character before 0x9B is 0x10 (DLE - data link escape character) that might explain the lost characters you see. Some devices use DLE as a control command indicator and the subsequent character is the command. If DLE characters aren't escaped, the usual sign is a loss of 2 characters in the stream, or strange behavior from the device. Escape DLE characters with DLE. So, in your case if your data stream includes:

... 0x10 0x9b ...

you would have to write

... 0x10 0x10 0x9b ...

I'm guessing this is a 0x1B, i.e. the ASCII escape character, with a parity bit in the 8th bit position (it coming from serial communication and all).

Technically, the characters in the ASCII set are all smaller or equal to 0x7F, characters between 0x80 to 0xFF are part of the extended ASCII. The meaning of the codes above 0x7F typically varies, allowing one of multiple characters sets to be handled with codes exactly one byte in size. This capability unfortunately introduces ambiguity for one needs to know the particular extra character set in use (the "code page" if you will).
For example the "ASCII" table referenced in the question doesn't appear to have any character associated with 0x9B, while many other extended ASCII set use this for a "plain" / displayable character (ex: a > looking character in ISO-8859-1, the cent sign (a c-like character) with another set etc.

The possible meaning of the 0x9B character could therefore depend on the [implied] character set in use with the underlying application. But as said, earlier, it looks more like the characters are encoded on 7 bits (hence are likely "pure" ASCII characters) with one parity bit.

For anyone coming to this question just because of the title: 0x9B / 155 is missing from ASCII tables because it isn't an ASCII character. ASCII characters are only 7 bits wide, meaning there are only 128 of them, there simply is no character 155.

[Community Wiki because it doesn't actually answer the question, only the title.]