Searching \ for '[OT] asynchronous data format' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/mems.htm?key=data
Search entire site for: 'asynchronous data format'.

Exact match. Not showing close matches.
PICList Thread
'[OT] asynchronous data format'
1999\04\13@142642 by w. v. ooijen / f. hanneman

picon face
Today I was looking for a standard which describes
the good old asynchronous data transmission format -
you know: start bit, data bits, probably a parity bit, stop
bits - and I could not find any! Don't say it is in RS232
(unless you actually have a copy and checked), it is
definitely not in v11/v28/v24 and not in RS422 or RS485.
Is there a standard definition for this at all?

The question which started my search is that our
requirements ask for a transparent end-to-end
asynchronous data service. Would transporting
a break condition be included? and transporting
strange things like fractional data bits?

regards,
Wouter.

PS this is totally PIC off-topic, but I hope putting [OT]
in the subject shields me from most flames....

1999\04\13@143536 by Dave VanHorn

flavicon
face
> Is there a standard definition for this at all?

Kinky!  It may be lost in the mists of time :)

> The question which started my search is that our
> requirements ask for a transparent end-to-end
> asynchronous data service. Would transporting
> a break condition be included? and transporting
> strange things like fractional data bits?

It COULD be done that way, basically providing a "wire" between points, but
you'd always have some minimum timeslice which would represent a maximum
bitrate.
I assume you're doing some kind of digital link here?

The break signal is, as far as I can tell, a hack. It induces a framing
error at the other end, with a byte value of 00, but there is no firm
definition of how long a break should be.  I've seen "specs" for break of
100mS, 11 bit times, several seconds.....

I would think though, that the fact that they call it out as async would
indicate that there are no fractional bits, and that there would be a
defined max bitrate, and a defined format.

1999\04\13@161349 by John Payson

flavicon
face
|The question which started my search is that our
|requirements ask for a transparent end-to-end
|asynchronous data service. Would transporting
|a break condition be included? and transporting
|strange things like fractional data bits?

There are two types of "transparent" data links: bitwise transparent and
bytewise transparent.

A bitwise transparent link will send all changes in line-state from one end
to the other within certain delay/jitter constraints.  Most antique 300-baud
modems worked this way.  The link doesn't care what baud rate you use, but
if you go too fast timing variations will cause data errors.  A typical 300
baud modem will have no problem running at 275 baud, or 10 baud, or even up
to about 350 baud.

By contrast, a bytewise transparent link will attempt to read each byte that
comes in and then pass it on.  Unlike a bit-transparent link, where signal
timing will be derived from the original source (with some delay/jitter),
a bytewise-transparent link will regenerate the signal timing on the receive
end.

Unlike bitwise-transparent links which don't need to know anything about
data rate or data format, bytewise transparent links need to know both.
The data format of a byte-transparent link needn't necessarily be 8-N-1,
though that form is also compatible with 7-(any parity)-1 or 7-N-2.  It
must be known, however; an 8-N-1 link will fail with 7-N-1, 8-(parity)-1,
or 9-N-1 data.  Preservation and retransmission of most types of framing
errors will not generally be possible, but breaks generally can be det-
ected and preserved.  Some links, when passing through a break, will rep-
lace any break with one of fixed duration; others will measure the app-
roximate length of the break and send it through.  Whether this is nec-
essary will depend upon the application.

1999\04\13@170535 by Gerhard Fiedler

picon face
At 15:15 04/13/99 -0500, John Payson wrote:
>There are two types of "transparent" data links: bitwise transparent and
>bytewise transparent.

actually, there are many types: "transparent" basically means that your
targeted communication layer gets transmitted as it would like it, that the
change of underlying or intermediate protocols doesn't change =its=
situation. in that sense, the ADC and digital transmission and DAC on a
normal analog telefon data connection are a transparent link for most
modems. or when one establishes a tcp/ip connection, the underlying
protocols are usually mostly transparent -- you don't need to know whether
you go over a direct ethernet or a PPTP or a PPP modem link (with maybe
rs232, v.42bis error correction and compression and v.34 as intermediate,
largely transparent protocols in between).

depending on the application, this influences eg. the implementation of
break detection/transmission: it is usually designed to be transparent for
a certain application (whether fixed length or measured length or ignored
or whatever). which may or not be your case...

transparency is not a characteristic of a data link, it is a characteristic
of a relationship between a targeted application protocol and a link. one
link may be transparent for one protocol but not for another, depending on
the requirements of the protocol.

ge

1999\04\13@171927 by wagnerl

picon face
Yes, the physical data link, in this case the RS232 (start/stop fashion)
has nothing to do with the "transparency itself", but how your software
would use that interface.  For example, a lot of software consider the
character hexa "0D"h (decimal 13) as carriage return, so it would return
the cursor or the print head to the left position. When you send data
0Dh to a video card memory it would be just there, it would not return
any cursor to the left of your screen, but who does that is some
software that would intercept it, understand as a "carriage return" and
execute all the necessary steps to insure a "carriage return" on your
screen.  It is a particular situation when that specific software would
use that specific byte for that purpose.  When you transfer an
executable or binary file via Internet or when you copy that file to a
diskette, no special action would be done when transferring the
character "0D"h... so you could say it is being transferred in
"transparent" mode.

In other situations, when a data link use some special characters to
control the data link, as for example, XON and XOFF, or any other
character that makes sense to the protocol software to execute some
specific action, and you need to send a program via that same datalink,
and tihs program contains those special control characters, you don't
want the protocol to understand them as real "control" since they are
just part of a program, then this characters or the whole program needs
to be transferred under "transparent mode", so the other side protocol
just treat them as "regular data characters".

Wagner

Gerhard Fiedler wrote:
> transparency is not a characteristic of a data link, it is a characteristic
> of a relationship between a targeted application protocol and a link. one
> link may be transparent for one protocol but not for another, depending on
> the requirements of the protocol.
>
> ge

1999\04\13@180920 by William Chops Westfield

face picon face
   The question which started my search is that our
   requirements ask for a transparent end-to-end
   asynchronous data service. Would transporting
   a break condition be included? and transporting
   strange things like fractional data bits?

The only way to find out is to ask your customer what they mean by
transparent.  It can mean anything from ascii only to 8 bits plus
transmitted parity plus transmitted signal state changes (RTS/CTS DTR/CD
for fax modem manipulation, for instance), plus relative timing between
bytes (Some host software can distinguish between function keys and user
typein of the same sequence based on timing.  A real bitch.)  Even
"break transport" needs a tighter definition - I've used equipment where
there is a distinction between "short" and "long" breaks (but I don't
think I've seen a requirement for that sort of transparency in quite
some time...)

BillW

1999\04\13@194510 by Gerhard Fiedler

picon face
At 20:23 04/13/99 +0200, w. v. ooijen / f. hanneman wrote:
>Today I was looking for a standard which describes
>the good old asynchronous data transmission format -
>you know: start bit, data bits, probably a parity bit, stop
>bits - and I could not find any! Don't say it is in RS232
>(unless you actually have a copy and checked), it is
>definitely not in v11/v28/v24 and not in RS422 or RS485.
>Is there a standard definition for this at all?
>
>The question which started my search is that our
>requirements ask for a transparent end-to-end
>asynchronous data service. Would transporting
>a break condition be included? and transporting
>strange things like fractional data bits?

i guess there is no standard per se, you have to find out what the protocol
you're trying to transmit expects. the reason many such details are left to
the implementation (in eg. v.24) is that the many application protocols
define their own requirements.

(like the difference between modbus ascii and modbus rtu, both on eg.
rs485: the ascii version is completely time-insensitive, so if the timing
of the bytes is not preserved, it still may be transparent. and it only
needs 7 bits, so if your link provides 7 bits, that's transparent. but the
rtu version is timing sensitive with respect to inter-character times, and
needs 8 bits per character -- so you have to fulfill these two requirements
to be transparent.)

ge

1999\04\13@201550 by Gerhard Fiedler

picon face
At 13:34 04/13/99 -0500, Dave VanHorn wrote:
>The break signal is, as far as I can tell, a hack. It induces a framing
>error at the other end, with a byte value of 00, but there is no firm
>definition of how long a break should be.  I've seen "specs" for break of
>100mS, 11 bit times, several seconds.....

i guess the usual minimum is around 1.5 byte times, to be able to
distinguish it from a normal framing error. something like this is built
into some uarts. but in order to be on the safe side, many application
protocols define a longer break -- this doesn't mean that a shorter break
is no break condition, but it doesn't trigger the "break state" of the
application protocol.

one has to realize that even with a simple serial link you have at least
three protocol layers: the physical layer, that is the signals on the
lines, when they are considered high or low, the data link layer, which are
the start, data, parity and stop bit definitions, and the application
layer, which defines stuff such as minimum number of data bits, minimum
break times and such, and which tells you what the lower links have to be
able to provide to be "transparent" to it.

for example, if an application layer protocol defines 7 data bits, all data
link layer which provide 7 or more bits are transparent (with respect to
this requirement). and the application layer doesn't care whether you use
an additional parity bit or better line driver to get down to the max.
allowed error rate. sometimes one gets confused with this scheme, because
you might find application protocols which require parity bits, because
they handle them. but then these are just additional data bits to the data
link layer.

ge

1999\04\13@205351 by Lee Jones

flavicon
face
> Today I was looking for a standard which describes
> the good old asynchronous data transmission format -
> you know: start bit, data bits, probably a parity bit, stop
> bits - and I could not find any!

I'd check the following:

EIA-363 Standard for Specifying Signal Quality for
      Transmitting and Receiving Data Processing Terminal
      Equipment Using Serial Data Transmission at the
      Interface with Non-Synchronous Communications Equipment.

EIA-404-A, Standard for Start-Stop Signal Quality for
      Non-Synchronous Data Communication Equipment.

I don't have copies handy today, so I'm not sure if they are the
right standards.  (I believe EIA-334-A is for synchronous systems.)
I may be able to lay my hands on 363 and/or 404 tomorrw -- I'll see.


> Don't say it is in RS232

The above specs are referenced in EIA/TIA-232-E, page16,
section "4.3  Signal Characteristics, General".


> requirements ask for a transparent end-to-end
> asynchronous data service.

This sure sounds like something you should get clarified
with the customer _before_ you accept the contract.


> Would transporting a break condition be included?

I've always heard that a break should be 300 milliseconds.
This happens to be 3 character times at 110 baud using the
old KSR/ASR-33 teletype's 11 bit (start, 7 data, parity,
and 2 stop bits).  But the break state varies in length
(and, as BillW mentioned, some old equipment distinguished
between short breaks & long breaks).

                                               Lee Jones

-------------------------------------------------------------------
Jones Computer Communications             spam_OUTleeTakeThisOuTspamfrumble.claremont.edu
509 Black Hills Dr, Claremont, CA 91711         voice: 909-621-9008
-------------------------------------------------------------------

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...