Searching \ for 'Start and Stop Bits' 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/index.htm?key=start+stop+bits
Search entire site for: 'Start and Stop Bits'.

Truncated match.
PICList Thread
'Start and Stop Bits'
1999\08\28@042453 by Mario Thomaidis

picon face
Hello,

Sorry for what may seem like a very naive question, but are the start
and stop bits in UART transmission both high (1). I have been testing
the USART (in Asynchronous mode) of a PIC16c73a, and have found on my
oscilloscope that start bits are high (Vdd), but stop bits are low
(Gnd). Do people have a choice as to whether stop bits are high or low
(I would imagine not for clock recovery reasons)? The more likely
scenario, of course, is that I am doing something wrong? Anyone have any
insight as to what may happening? Thanks.

Mario

--
If it wasn't for the last minute ... nothing would get done.

1999\08\28@071716 by Steve Thackery

flavicon
face
Hi Mario,

You are doing nothing wrong.  The start and stop bits must have opposite
polarity, and this requirement arises from the way in which asynchronous
serial communications work.

There are two ways to look at this.  I'll try the simple way first and then
give a slightly fuller explanation.  The start and stop bits mark the start
and end of each transmitted character, right?  Imagine a stream of
characters: you get a start bit, the character, a stop bit(s), a start bit,
the character, a stop bit(s), and so on.

If you look at that sequence it should be obvious that the stop and start
bits between the two characters must have opposite polarities otherwise you
couldn't tell them apart, right?  If they were both the same polarity you
couldn't tell when the stop bit finished and the start bit started.  In
other words, the receiver needs an "edge" or a "transition" to signal the
commencement of the start bit.  So it's gotta be of opposite polarity to the
stop bit preceding it.

Incidentally, before proceeding, I need to tell you about marks and spaces.
Basically, with serial comms you talk about marks and spaces rather than 1s
and 0s, or highs and lows.  A mark represents a logic 1, a space represents
a logic 0.  A stop bit happens to be a mark, a start bit is a space.

Just to confuse you even further, the polarity of marks and spaces on an
RS232 serial transmission line seems the wrong way round: marks are sent as
a negative voltage, spaces as a positive voltage.

I'll just summarise that again, as a sanity check: a mark represents a logic
1 and is a negative voltage, a space represents a logic 0 and is a positive
voltage.  A start bit is a space (positive), a stop bit is a mark
(negative).

In the eight bits of the transmitted character, the 1s are negative (marks)
and the 0s are positive (spaces).  I said it seemed the wrong way round!!

One more thing, which I'm sure you know.  The duration of the bits is
determined by the bits-per-second rate of the line (often, but not always
correctly, called the baud rate).  So, on a 1200 baud link each bit lasts
1/1200th of a second.  This is relevant later.

The thing about asynchronous comms is that there is, or can be, any amount
of idle time between the characters transmitted.  So the receiver can't
synchronise itself to the incoming bit stream (hence "asynchronous").  When
the line is idle, the transmitter sends out a continuous "marking"
(negative) voltage.  You might like to think of this as a continuous stream
of stop bits.  The receiver sits there drumming its fingers, having no idea
when the next character is going to arrive.

Eventually a character is transmitted.  Here is the crucial part: the start
bit is of opposite polarity, so the first thing the receiver sees is a
transition from a mark to a space.  The receiver now knows the precise
moment in time at which this transition - the leading edge of the start
bit - arrived.  It also knows how long each bit (including the start bit)
should last (i.e. 1/1200th of a second).  So, it waits
for the duration of half a bit and samples the voltage on the line again.
This puts it right smack in the middle of the start bit.  If it still sees a
'space' it knows the start bit is real (i.e. it wasn't just a noise blip on
the line).  It then waits 1/1200th of a second and samples the line yet
again.  This puts it smack in the middle of the first bit of the character.
It continues to sample at 1/1200th of a second intervals thereafter until it
gets to the stop bit(s).  Once it has registered the stop bit it then goes
into continuous monitoring mode in order to pick up the next transition to a
start bit.

You will see that the receiver's internal clock (for measuring out the
1/1200th of a second sampling intervals) doesn't need to be particularly
accurate.  All that's required is that it stays within half a bit over the
duration of the received character.  In other words, an accuracy of a few
percent if fine.  This means that asynchronous comms are cheap and easy to
implement.

Just a couple of odds and sods.  It is not uncommon to transmit two stop
bits.  Interestingly, in this case you can configure the receiver to expect
either one or two and it will still work.  If you tell it to expect just
one, it simply assumes there is a slight gap between the characters.
Remember, the stop bit - a mark - looks like the line idle condition.
Sometimes a parity bit is transmitted.  What this means is that, according
to how you set things up, a character may be anything from 10 to 12 bits
long.

At one time some systems were set up to transmit just seven bits for the
character, that being sufficient for the entire ASCII character set.  So
these could be as short as 9 bits in length.

You might be interested to know that the worldwide telex standard uses a
five bit code, with a stop bit one-and-a-half bits long!  This gives 7 1/2
bits per character.

Phew!!  Sorry for the awesome length of this email.  I hope you will find at
least some of it of use.

Regards,

Steve

Steve Thackery
Suffolk, England.
Web Site: http://www.btinternet.com/~stevethack/

1999\08\28@073129 by Quentin

flavicon
face
Steve Thackery wrote:

> Phew!!  Sorry for the awesome length of this email.  I hope you will find at
> least some of it of use.
>
> Regards,
>
> Steve
No, Thank you. Best explanation for serial comms I've ever seen. I've
saved your email.

Quentin

1999\08\28@081120 by Peter van Hoof

flavicon
face
Excellent piece of work Steve.

Though I'm very familiar with serial communications I could not have done
such an easy to follow and clear explanation.

thumbs up

Peter


{Quote hidden}

1999\08\28@121814 by Wagner Lipnharski

picon face
Steve made a great explanation.

About the stop bits, 1 or 2:

When transmitting a string of data, the sender just pump data
(encapsulated with start and stop bits) in sequence. The receiver needs
to save or do something with each received byte, it demands some time,
and normally this is done right after sensing (and during) the stop bit
time. Old and slow machines sometimes needs an extra time.

Remember that old machines are not so easy to program or change
parameters, so to increase the delay between transmitted bytes they
choose to program the length of the stop bit.  Standards were created,
so you can program 1, 1¸ or 2 stop bits.  In real, it doesn't matter how
long the stop bit takes. If the receiver can wait without complains, the
transmitted stop bit can be as long as you want, since the next byte
will starts only with the next start bit.  A long time in the same level
can be identified by some protocols as special condition of "HALT", and
it is a way the transmitter has to tell the receiver to close the
reception section, or something like that.

It doesn't make sense to program the receiver with more than one stop
bit, since with ONE STOP BIT it will works with data arriving with 1, 1¸
or 2 stop bits, always.

The stop bit (space, RS232=High or TTL=Low) is required to the receiver
to make sure it still in sync with the transmitter.  The receiver
*expects* the space level at the stop bit sample time, if a "mark" level
(RS232=Low or TTL=High) is sensed at the stop bit time, a "Framing
Error" will be posted, it means that something is wrong and the stop bit
was not there, so the received byte *should* be incorrect.  

The start bit is the same level of any other "1" bit in the data byte,
so if the receiver awakes in the middle of a byte being send and
consider any "1" data bit as being the "start bit", it will sync out of
order, it will sample and count 7 or 8 bits time, but what should be the
stop bit will happens in the middle of the next byte, and it could be a
"1" bit, so it gives you "framing error".  This can also happens if the
transmitter is using a different baud rate, happens more often if the
transmitter is using a baud rate lower then the receiver.

The synchronization problems with slightly different baud rates can be
observed in a text and graphic representation I did months ago here:
http://www.ustr.net/8051pc/starting.htm go to the middle of the page,
"Talking about Synchronization".

--------------------------------------------------------
Wagner Lipnharski - UST Research Inc. - Orlando, Florida
Forum and microcontroller web site:  http://www.ustr.net
Microcontrollers Survey:  http://www.ustr.net/tellme.htm

1999\08\28@144921 by piclist

flavicon
face
Quentin wrote:

> Steve Thackery wrote:
>
> > Phew!!  Sorry for the awesome length of this email.  I hope you will find at
> > least some of it of use.
> >
> > Regards,
> >
> > Steve
> No, Thank you. Best explanation for serial comms I've ever seen. I've
> saved your email.
>
> Quentin

I'll be in line to purchase your book Steve =)

Tim H.

1999\08\28@233011 by paulb

flavicon
face
Bravo!  Steve Thackery wrote a tremendous synopsis.  I'm saving it
too.  A few clarifications just in case:

> I'll just summarise that again, as a sanity check: a mark represents a
> logic 1 and is a negative voltage, a space represents a logic 0 and is
> a positive voltage.  A start bit is a space (positive), a stop bit is
> a mark (negative).

 Just note that Mario mentioned that his marks (stop) were positive and
his "space"s negative.  The UART or MCU sees things this way.  It
connects to the line via an inverting transceiver which inverts incoming
and outgoing voltage levels.  On the RS-232 line then, marks are
negative and "space"s positive.  OTOH, the "status" lines are positive-
true on the RS-232 line and inverted as the UART/ MCU sees them.

 Now, according to the RS-232 standard, in a stable state the RS-232
(AKA EIA-232) line is at least 3V either positive or negative, but not
more than 15V (or is that 18V?).  That is what the 1488/ 1489
transmitter/ receiver chip, or any other equivalent, provides.  In
practice, designers of peripheral devices, e.g. mice, frequently cheat
and use a mark of 0V and a space of 3 to 5V.

 The 1489 line receiver threshold unless its adjustment feature is
used, is at 1.5V, so these voltages are fine for non-critical (short-
range) applications.  This is quite convenient, as you see 0V is
interpreted as a marking or idle condition allowing hot-switching of
circuits (minimizes glitches) and all sorts of other tricks.  On the
status lines, an open or grounded line is OFF.

 This leads to mention of the "break" condition.  Where unipolar
current loop switching was used (in those Telex machines), mark meant
current on and space meant current off.  The original meaning of the
words in fact relates to paper tape markers using an ink roller.  A
telex machine in continuos mark sits quietly (sort of!) idling.  If the
line "breaks" however, it makes a terrific racket as without its magnet
holding at all, the mechanism continuously acts on dummy characters.

 This is used as a fault indication.  On UARTs, it is detected if the
stop bit is absent and most implementations thereafter lock out until an
apparent stop bit eventuates.  This then is the "break" condition and
there are deliberate ways of sending it.  You do have to be careful of
interpretation of the character detected (NUL) as the break was being
received.

> It is not uncommon to transmit two stop bits.  Interestingly, in this
> case you can configure the receiver to expect either one or two and it
> will still work.

 In most implementations, the UART is set *as a whole* for one or two
(or 1¸) stop bits.  While the extra stop bits were needed for the
mechanical implementations, UARTs only look for the first, so this
setting actually affects only the transmitter; the receiver sees the
extra merely as an inter-character delay.  If you expect any problems at
all, two stop bits is a good setting as, should the receiver get out of
synch due to noise pulses during a burst of characters, the extra delays
will pull it back into synch within about 8 "bad" characters at the
most.

> You might be interested to know that the worldwide telex standard uses
> a five bit code, with a stop bit one-and-a-half bits long!  This gives
> 7 1/2 bits per character.

 I have a SAGEM electronic telex, hopefully well-covered, in my
repository.  AFAIK, the Telex service became obsolete about 8 years ago.
(The FAX machine killed it!)  Some variants still operate on HF radio
though, and Amateurs still play with it.  Anybody know of residual
land-line use?

 I can imagine the Telex version of the recent Morsecodian thread...

Wagner Lipnharski wrote:

> The receiver needs to save or do something with each received byte, it
> demands some time, and normally this is done right after sensing (and
> during) the stop bit time.  Old and slow machines sometimes needs an
> extra time.

 That's talking about *machines*, but the significance is that "bit-
banging" implementations on MCUs may also need that extra time,
particularly at high baudrates.  Interrupt-driven and hardware
implementations generally don't.

> It doesn't make sense to program the receiver with more than one stop
> bit, since with ONE STOP BIT it will works with data arriving with 1,
> 1¸ or 2 stop bits, always.

 It's not significant.  You aren't programming the number of stop bits
in the receiver, only the transmitter.
--
 Cheers,
       Paul B.

1999\08\29@164332 by Eric Oliver

flavicon
face
Ditto. Quentin beat me to the punch. That was an excellent down to earth explana
tion.

Eric

On Saturday, August 28, 1999 6:31 AM, Quentin [SMTP:spam_OUTqscTakeThisOuTspamICON.CO.ZA] wrote:
{Quote hidden}

1999\08\29@181553 by Dennis Plunkett

flavicon
face
At 13:29 29/08/99 +1000, you wrote:
{Quote hidden}

Unipolar?
Let me see a Telex machine is a two wire device correct! No! It is actualy
a three wire device with an earth return (I may get this wrong it has been
a very very long time). At the exchange a set of relays are used to swap
over the nominal battery sense on one side of the line. These things had
what is known as a Claire relay (Yes as the name suggests that is where
they started), another verision is in the telex machine, except this has a
set of mercruy wetted contacts (Stop contact bounce) So an attempt to
measure votage accros telex wires is fruitless, as both are with respect to
earth. This was done to provide an effective 100V swing so that the relays
(These where not the slug type ones like normal K and M relays as these are
too slow) would operate on longer lines.

As for mark being current on, yes this is correct with current flowing in
the -ve direction (Hense why we have make as negive!) but the space is
current flow but in the +ve direction. A break being no line current is
correct indeed, but as for the things chattering because of this, no, the
Claire relay is centre stable, the chattering is the telex machine
electromechanicals resetting itself to the start of every expected frame
period (10 times per second!) Only the older machines that has fault
currents flowing used to see dummy characters.

The stop bit was required to fire off the character received, and the start
bit is used to arm the system.

Again, been a long time, so flame me if I am wrong


Dennis




{Quote hidden}

1999\08\29@185157 by Steve Thackery

flavicon
face
Dennis wrote:

>> Unipolar?
Let me see a Telex machine is a two wire device correct! No! It is actualy
a three wire device with an earth return (I may get this wrong it has been
a very very long time). <<

I think we may be in a bit of a mix-up here.  "Telex" is an international
service, which is delivered at the customer's premises using a
"teleprinter".  But teleprinters are used for purposes other than telex.  In
particular they were used on point-to-point circuits and broadcast services.
For example, in the UK there was a continuous newsfeed service which most
radio stations and newspapers subscribed to.  Also the weather bureau and
police had their own private teleprinter networks.

Many of these ran at 75 Baud, rather than the international standard of 50
Baud for telex.

To the very best of my knowledge, all genuine "telex" circuits are two wire.
In recent years audio frequency tones - to represent the marks and spaces -
have been transmitted over the local loop.  But until the 80's telex was
always delivered using DC signalling on a *two* wire circuit.

At least, that's the way it was in the UK.

One wire was always at earth potential, the other switched between +75V
and -75V.  (I think 75V is correct; it's certainly pretty near).

In other words, I don't think current loop signalling was used on the telex
service in the UK (at least not in recent decades), although it was most
certainly used in some of the other teleprinter-related services I mentioned
above.

Incidentally, I believe the telex service is still plugging away, albeit
with precious few subscribers these days.  There were two things which kept
it going longer than you'd expect.  Firstly, even the most undeveloped of
countries had a telex service, so it really did have the widest reach of any
data (as opposed to voice) service.  Secondly, because of the difficulty of
faking, telex messages had a special status legally.  I don't know much
about law, but basically a telex message was considered to be a legally
binding document.

Of course, all this is long before any one had heard of the Internet!

Steve

Steve Thackery
Suffolk, England.
Web Site: http://www.btinternet.com/~stevethack/

1999\08\29@192556 by paulb

flavicon
face
Dennis and Steve wrote.

 Let me clarify.  I was referring to the machine loop, which is
generally unipolar (i.e., on/ off), not the (external) line.

 One advantage of a unipolar loop was always the ability to plug
machines (e.g. tape readers and perfs) together using plugs and shorting
jacks.
--
 Cheers,
       Paul B.

1999\08\29@214238 by Dennis Plunkett

flavicon
face
At 23:49 29/08/99 +0100, you wrote:
>Dennis wrote:
>
>>> Unipolar?
>Let me see a Telex machine is a two wire device correct! No! It is actualy
>a three wire device with an earth return (I may get this wrong it has been
>a very very long time). <<
>
>I think we may be in a bit of a mix-up here.  "Telex" is an international
>service, which is delivered at the customer's premises using a
>"teleprinter".

Telex is a service correct, but it does specify a format that it provides,
and the teleprinter prints out "TELEX MESSAGE". In Australia it is known as
Telex now just like names are associated with other things.

>But teleprinters are used for purposes other than telex.  In
>particular they were used on point-to-point circuits and broadcast services.
>For example, in the UK there was a continuous newsfeed service which most
>radio stations and newspapers subscribed to.  Also the weather bureau and
>police had their own private teleprinter networks.

Yes, but still printed on paper that says "Telex message"

>
>Many of these ran at 75 Baud, rather than the international standard of 50
>Baud for telex.

Simply a speed increase as the machines got better.

>
>To the very best of my knowledge, all genuine "telex" circuits are two wire.
>In recent years audio frequency tones - to represent the marks and spaces -
>have been transmitted over the local loop.  But until the 80's telex was
>always delivered using DC signalling on a *two* wire circuit.
>

Yes we here are a *two* wire circuit with an earth return. You don't call
AC power distrobution 1 wire do you?

>At least, that's the way it was in the UK.
>
>One wire was always at earth potential, the other switched between +75V
>and -75V.  (I think 75V is correct; it's certainly pretty near).
>

In this case it is a 72V battery, the old ones that used to be used for the
valve equipment in the long line rooms. The equipment that youre describing
does not require an earth stake as does ours. I was going to put up this
type also but did not wish to confuse people. Note that in this case the
same lines will work on either telex machine, just add a diode!

The +/- 72V is not something that is liked by exchanges as this means that
the battery is floating nominaly somewhere above/below ground for some
peroid, and makes it a hazard that is unknown (VS a known hazard). It
creates other problems when fautlts occur in that some lines are at -ve and
others are at +ve, and means that the battery banck can not be tied to the
exchange earth grid.

To say that one line is at earth potential all the time is not entirly
correct, this is the return line for the battery, thus +ve for marks and
-ve for a space.

Dennis



>In other words, I don't think current loop signalling was used on the telex
>service in the UK (at least not in recent decades), although it was most
>certainly used in some of the other teleprinter-related services I mentioned
>above.

Current loop signaling was used until the early 90s as exchanges received
work orders on them

{Quote hidden}

There are also other factors, one little unknown is that a fixed copy can
be generated at both ends. If you use the service correctly you generate
the puch tape to create the file to send off line, then run it through at a
latter period (So the sender has a transcript!). The other is that it
created more than one copy (A carbon copy as well). But you are right about
the far reaching bit of the service, this format would almost go through
mud, and the human can decipher the words with errors whereas modem could
not (OK so you can flame me on that I know that there are some holes in it)


>Steve
>
>Steve Thackery
>Suffolk, England.
>Web Site: http://www.btinternet.com/~stevethack/
>
>

Dennis

1999\08\30@062701 by Steve Thackery

flavicon
face
There are a number of points in Dennis's note that I disagree with.
However, we are as far away as can be from PICs, so I'm going to resist the
temptation to carry on the debate further!

Regards,

Steve

Steve Thackery
Suffolk, England.
Web Site: http://www.btinternet.com/~stevethack/

1999\08\30@184234 by Dennis Plunkett

flavicon
face
At 11:22 30/08/99 +0100, you wrote:
>There are a number of points in Dennis's note that I disagree with.
>However, we are as far away as can be from PICs, so I'm going to resist the
>temptation to carry on the debate further!


Prey, tell me more...

Dennis

1999\08\31@123545 by Anne Ogborn

flavicon
face
Since it's likely that my incoming data will be 180 deg phase inverted,
I'm using a different scheme to transmit data.

I transmit 500 uSec of '+1' followed by 500uSec of '-1' for
a 1. I transmit 250uSec of '+1' followed by 250uSec of '-1' for
a 0.

Then I just send bits - I check some 380 uSec after seeing a positive
transition and if the pin is 1, it's a 1.

I transmit about 1K of data, which ends with a CRC. After recording the unit res
ets.

Sooo... my question is, anybody have any opinions on the advisability
of making some sort of sync pulse every 8 or 16 bits?

It's a 1 way channel, so I really
can't do a retransmit request, hence complex error detection is
irrelevant. If the CRC (16 bit) doesn't match, I flash an LED and
the user tries again.


--
Anniepoo
Need loco motors?
http://www.idiom.com/~anniepoo/depot/motors.html

1999\08\31@125005 by Wagner Lipnharski

picon face
Anne Ogborn wrote:
>
> Since it's likely that my incoming data will be 180 deg phase inverted,
> I'm using a different scheme to transmit data.
>
> I transmit 500 uSec of '+1' followed by 500uSec of '-1' for
> a 1. I transmit 250uSec of '+1' followed by 250uSec of '-1' for
> a 0.
>
> Then I just send bits - I check some 380 uSec after seeing a positive
> transition and if the pin is 1, it's a 1.
>
> I transmit about 1K of data, which ends with a CRC. After recording the unit r
esets.
>
> Sooo... my question is, anybody have any opinions on the advisability
> of making some sort of sync pulse every 8 or 16 bits?
>
> It's a 1 way channel, so I really
> can't do a retransmit request, hence complex error detection is
> irrelevant. If the CRC (16 bit) doesn't match, I flash an LED and
> the user tries again.

Well, it looks like you already have the clock included into the data
itself, why not use it? You have a 0 to 1 transition for every bit
sent...  if instead of 250us of -1 for a 0 you hold it for 750us, you
will ahve a bit for each 1ms, and the 0 to 1 transition will happens
always for each bit, 0 or 1, it could resync your receiver for every bit
received.

There is another easy way, the old NRZ/NRZI, just make a transition from
0 to 1 for bits 1 and a transition com 1 to 0 for bits 0, so your
receiver would work in edge sensitive mode, expecting it in a narrowed
window time (to avoid noise). Using this technique you transmit embedded
clock, and can increase speed and see what happens.

Wagner

1999\08\31@125414 by Anne Ogborn

flavicon
face
>
> There are also other factors, one little unknown is that a fixed copy can
> be generated at both ends. If you use the service correctly you generate
> the puch tape to create the file to send off line, then run it through at a
> latter period (So the sender has a transcript!). The other is that it
> created more than one copy (A carbon copy as well). But you are right about
> the far reaching bit of the service, this format would almost go through
> mud, and the human can decipher the words with errors whereas modem could
> not (OK so you can flame me on that I know that there are some holes in it)

One reason one finds telex popular in middle-of-nowhere situations is precisely
that in such situations there's an increased need for cheap extremely long dista
nce
communication.

It's hard to remember now, but there was a time (I'm showing my age) when a long
distance phone call
was a special event, and an international phone call a near miracle.

In a remote place, almost everything comes from far away. So there's a greater n
eed to carry
on commerce, especially, over distances.

So, a cheap method of sending messages was and is vital in such places. I know I
still
depend on the Telex and the 'S.T.D' (long distance) phone system when I'm in Ind
ia.



--
Anniepoo
Need loco motors?
http://www.idiom.com/~anniepoo/depot/motors.html


'Start and Stop Bits'
1999\09\06@001638 by paulb
flavicon
face
Anne Ogborn wrote:

> Since it's likely that my incoming data will be 180 deg phase
> inverted, I'm using a different scheme to transmit data.

> I transmit 500 uSec of '+1' followed by 500uSec of '-1' for
> a 1. I transmit 250uSec of '+1' followed by 250uSec of '-1' for
> a 0.

 Kansas City Standard, with some modification to the bit rate.

> Then I just send bits - I check some 380 uSec after seeing a positive
> transition and if the pin is 1, it's a 1.

 OK, in doing so, you are making use of the data contained in only one
transition of each cycle, sending two transitions (of opposite polarity)
where one is effectively redundant.  You are however wasting the
redundancy rather than using it for increased reliability.

 To actually make use of it, you would have to make the receiver
determine first the correct polarity, then it could time both halves of
the pulse and average them.  Another way of looking at that is to time
the whole pulse and measure its period.  You need to seek out the
polarity first as otherwise, you would be averaging half of adjacent
data bits and actually cancelling the data.

> I transmit about 1K of data, which ends with a CRC.  After recording
> the unit resets.  Sooo... my question is, anybody have any opinions on
> the advisability of making some sort of sync pulse every 8 or 16 bits?

 Well, if you send it as asynchronous data, that is exactly what you
do, and a preamble or postamble of "stop" bits would be continuous 1
kHz.  If you want to send it synchronously, then you need a "flag"
(%01111110) to define byte-synchronization, plus "zero-stuffing" to
avoid apparent flags in the data.  As in HDLC.  At 750 baud as you
propose, that's not too difficult.

 But as was pointed out, it is much easier to use NRZI coding of some
sort whereby a zero represents a transition and a one, no transition.
Like asynchronous serial, if you have a halfway decent timing reference
(crystal), you can go many bits without a transition, or alternatively,
interrupt on every transition and read a master clock counter.

 Either continuous flags in idle, or bit-stuffing in data, guarantees
sufficient transitions for clock synchronization and also constrains the
bandwidth to a ratio of five-to-one (and thus excludes a DC component).

 Happy to discuss it further.  I'm getting dŽjˆ v here, I'm *sure*
Anne was discussing the same proposals some time ago?
--
 Cheers,
       Paul B.

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