HowToFixComputers.com

edocnekorb@aol.com · Guest

When I attempt to configure a USR modem (33.6 F/M) to use 8E1, I get
garbage from the AT commands. Does this USR modem support
communicating with 8E1? Do any USR modems support 8E1?
Thanks,
Ed.

Aaron Leonard · Guest

Ed,

I would bet that very few modems (or serial ports) nowadays support
anything other than 8 bit character formats (i.e. anything other than
7S/7E/7O/7M or 8N).

I think I have only once in 10+ years of supporting modems ever come
across an application that actually required 8E (some oddball SCADA
app used in mining operations in Canada, as I very dimly recall it.)
Do you REALLY require 8E? Can you tell us more why you think you need this?
Does your DTE really support 8E? What kind of DTE is this?

Just now for grins 'n' giggles (well, I didn't really want to start work
today; that's why I got into Usenet), I configured a Cisco 2511 line for
8E, and tried out a few modems ... two Sportsters (a V.90 one from circa
'97, and a 28.8k V.34 one from maybe '94). Neither could parse an AT
transmited in 8E. Then I dusted off my oldest modem, a Practical Peripherals
Bell212A - and it couldn't parse 8E either.

Checking the docs on a USR V.Everything from '00, it definitely indicates
parity support only for 7 databits.

Aaron

---

~ When I attempt to configure a USR modem (33.6 F/M) to use 8E1, I get
~ garbage from the AT commands. Does this USR modem support
~ communicating with 8E1? Do any USR modems support 8E1?
~ Thanks,
~ Ed.

Moe Trin · Guest

On 7 Feb 2007, in the Usenet newsgroup comp.dcom.modems, in article
<1170897229.709317.54880@a34g2000cwb.googlegroups.com>, edocnekorb@aol.com
wrote:

Aaron Leonard · Guest

Pedantic followup:

~ >When I attempt to configure a USR modem (33.6 F/M) to use 8E1, I get
~ >garbage from the AT commands. Does this USR modem support
~ >communicating with 8E1? Do any USR modems support 8E1?
~
~ 1. Modem commands are ASCII. They are normally sent in 7N1 in the
~ command mode. That's not selectable.

The async character framing format (# of databits + parity flavor if any)
*is* configurable on some modems (USR Courier for example), and/or it
may be autodetected from the "AT" by the modem's command parser.

7N (7 databits, no parity) is very rarely seen or supported. Most common
is 8N, which (for the ASCII character set, which is a 7-bit code) is the same
as 7S (7 databits, space parity.)

Perhaps here would be a good place to dump out the section on async framing
from my stillborn modem book project ... I suppose this could do someone some
good.

Cheers,

Aaron

---

3.2. Async character framing
[ start bits, stop bits, data bits, parity ]
All data transmission requires that the receiver somehow synchronize
with the transmitter in order to know when to detect symbol state
changes. In synchronous framing, the receiver maintains a clock that
is kept in sync with the transmitter’s clock – this synchronization can
be maintained either by some external hardware signal (e.g. a timing
circuit in sync RS-232) or by some recurring framing pattern in the
received signal (e.g. the framing bits in a T1 ESF frame.) In
asynchronous framing, the receiver synchronizes anew with some
pattern seen at the front of each frame. Examples are Ethernet
(where the receiver synchs to the frame’s preamble) and async
character framing.

Async character framing is used on both async RS-232 links as well as
in modem links where an error control framing protocol isn’t used. In
this scheme, each character (of 5, 6, 7 or 8 databits) is encapsulated
in a separate frame, which frame begins with a start bit (a space bit),
the payload containing the databits and an optional parity bit, and 1,
1.5 or 2 stop bits (mark bits.) While the async link is idle, the
transmitter sends mark bits. The receiver – which must be
preconfigured knowing the payload length – will synchronize on the
start bit for each frame.

[ picture of async frame – see fig 5 in
http://www.beyondlogic.org/serial/serial1.htm#40 ]
3.3. Parity.
Parity is one of the worst-conceived features in data networking
history. When standard 7-bit ASCII characters encountered 8-bit-wide
storage and transmission systems, the leftover bit had to be set to
some value. An obvious approach is always to set that bit to some
“don’t care” value – 1 (“mark parity”) or 0 (“space parity”.) In true
parity, however, the bit is computed as a binary checksum of the
databits – i.e. for the parity bit is set such that there is an even (for
“even” parity) or odd (“odd parity”) number of mark bits in the
payload.

It appears that parity may have been bequeathed to data
communications from paper tape (see ITU V.4.) In any case, the
method lingers, typically in legacy systems that have been permitted
to exist undisturbed.

3.3.1. Examples of calculating parity

Consider the ASCII word cat, where c is 0x63 (1100011), a is 0x61
(1100001) and t is 0x74 (1110100). Here the binary depictions of
the characters are big-endian – msb first. However, RS-232 transmits
data in a little-endian manner – lsb first.
* 8 databits, no parity. 7-bit ASCII values are transmitted with
the high bit clear – so cat is 11000110 10000110 00101110 (in
little-endian notation.) With one start bit (space) and one stop
bit(mark) per word, cat becomes 0110001101 0100001101
0001011101
o Note that, for 7-bit ASCII payload, 8 databits, no parity is
identical to 7 databits, space parity.
* 7 databits, mark parity. The high bit in each octet is always lit,
so cat is 11000111 10000111 00101111 (little-endian, minus
the framing bits)
* 7 databits, even parity. The high bit is lit iff the number of lit
databits is odd – in other words, the high bit is set such that an
even number of bits in (databits+parity bit) is lit. Thus the ASCII
word cat is 11000110 10000111 00101110.
Note: you can see the actual waveforms of the ASCII character set (using 8N1
framing at http://oraserve.cse.buffalo.edu/~borkman/projects/serialspy/rs-
232/index.php.

The main problem with using the parity bit is that it prevents an
arbitrary 8-bit value from being transmitted in an async-framed word
– thus, an application like PPP can’t work over a link that uses parity.
Nor can characters with the high bit set (e.g. `ñ’) be transmitted. To
transmit 8-bit data over a 7-bit path, a coding scheme (such as MIME’s
base64) must be used.

In any case, computing a “do care” parity bit value has little or no
worth, as a) the parity bit provides very poor error detection (it can’t
detect the case where an even number of bits in a frame are inverted),
and b) in the cases where it does detect an error, there is no
mechanism to recover from the error anyway. Rather than providing
any significant error protection, then, parity instead delivers a great
harvest of mischief; mismatched parity settings at various points in a
communications path have wasted man-years of technicians’ time in
troubleshooting.

Some general remarks on async framing:

* Very old equipment may have required more than one stop bit, but
such equipment is very rarely seen now. However, a transmitter’s
being configured for excess stop bits won’t cause communications
problems, only reduced payload transfer rate, as the extra stop bits
will just be interpreted by the receiver as idle bits. (ITU V.4
recommends two stop bits only for transmission speeds of 200bps
or less; however it continues to be the default for Cisco async
physical interfaces.)
* Very rarely encountered:
o 5 or 6 databits
o 7 databits with no parity
o mark parity
o 8 databits with any parity
* In other words: by far the most prevalent async character frame
formats encountered now are: 7 databits, 1 parity bit (typically
even), 1 stop bit (“7E1”); or 8 databits, no parity, 1 stopbit
(“8N1”). In both of these cases, the payload size is 8 bits, which
meshes nicely with the standard byte size used on contemporary
computers and in octet-oriented transmissions protocols. (ITU V.4
recommends 7E for async communications and 7O for sync.)
* With 1 start bit, 8 payload bits, and 1 stop bit, async framing has
20% overhead … thus a 115200 bps 8N1 async framed link will
have a payload throughput rate of 92160 bps. Relative to sync
transmission, this is rather high overhead. For RS-232 DTE links,
where the DTE speed is significantly higher than the DCE rate (e.g.
when using a 115200 bps DTE link for a 28800 bps V.34 link), this
overhead is not especially costly; however, for the relatively
precious bandwidth on the DCE link, this overhead can be
considered to be excessive, which is one of the motivations for
using EC framing on the DCE link instead (see chapter X below.)

Reed · Guest

snip