START/STOP Sync pattern

Hi all,


I am implementing some logic in FPGA(Transmit/Reveive).


On the receive data first i look for a 8- bit pattern to detect the
START pattern.Now my question is in the data also i may get the same
START pattern how to distinguish between the START /STOP pattern and
data.


Any comments are appreciated.


Regards,
Prav

 

[Kryten]

Use Google!

Here is a start:
http://en.wikipedia.org/wiki/HDLC
http://en.wikipedia.org/wiki/Bitstuffing

 

[Mochuelo]

On 9 Aug 2005 04:01:22 -0700, praveen.kantharajapura@gmail.com wrote:

Hi all,


I am implementing some logic in FPGA(Transmit/Reveive).


On the receive data first i look for a 8- bit pattern to detect the
START pattern.Now my question is in the data also i may get the same
START pattern how to distinguish between the START /STOP pattern and
data.


Any comments are appreciated.


Regards,
Prav

If the receiver delivers bytes to the upper level, I recommend you to
use escape sequences.

For instance:

Received Meaning
-------- -------
00 00
... ..
FC FC
FD 0D FD
FD 0E FE
FD 0F FF
FE Beg of packet
FF End of packet

Every time you receive 0xFE, you know you are at the beginning of
packet. You cannot find 0xFE inside the message (assuming no errors).
Similarly for 0xFF. Also, every time you receive 0xFD, you know you
have hit a 2-byte escape sequence, and you need to read the next byte.

 

[Kryten]

"Mochuelo" <cucafera@RE_MO_VE_THIStelefonica.net> wrote in message
news:2adhf19cdeifhmjatlfu1qb48srfp8dror@4ax.com...

If the receiver delivers bytes to the upper level, I recommend you to
use escape sequences.

For instance:

Received Meaning
-------- -------
00 00
.. ..
FC FC
FD 0D FD
FD 0E FE
FD 0F FF
FE Beg of packet
FF End of packet

Every time you receive 0xFE, you know you are at the beginning of
packet. You cannot find 0xFE inside the message (assuming no errors).
Similarly for 0xFF. Also, every time you receive 0xFD, you know you
have hit a 2-byte escape sequence, and you need to read the next byte.

Okay, so now as well as avoiding one byte code in the data, you now have to
avoid more than one.

This has not improved the situation.

8-bit data links have been invented.

Don't re-invent them.

 

[Mochuelo]

On Tue, 09 Aug 2005 22:11:31 GMT, "Kryten"
<kryten_droid_obfusticator@ntlworld.com> wrote:

"Mochuelo" <cucafera@RE_MO_VE_THIStelefonica.net> wrote in message
news:2adhf19cdeifhmjatlfu1qb48srfp8dror@4ax.com...

If the receiver delivers bytes to the upper level, I recommend you to
use escape sequences.

For instance:

Received Meaning
-------- -------
00 00
.. ..
FC FC
FD 0D FD
FD 0E FE
FD 0F FF
FE Beg of packet
FF End of packet

Every time you receive 0xFE, you know you are at the beginning of
packet. You cannot find 0xFE inside the message (assuming no errors).
Similarly for 0xFF. Also, every time you receive 0xFD, you know you
have hit a 2-byte escape sequence, and you need to read the next byte.

Okay, so now as well as avoiding one byte code in the data, you now have to
avoid more than one.
This has not improved the situation.

It makes synchronization -look at the thread title- more simple and
robust, using a very simple mapping with a ridiculous overhead
involved (1.2 % for long messages).

I could make it to avoid only one byte code, but I chose it to avoid
two to distinguish between beginning and end of packet. The benefit is
clear and the overhead is just 0.4 %, so go for it.

8-bit data links have been invented.

Like which one?

Show me one with better ratio benefit/overhead, and with a similar
implementation complexity.

Don't re-invent them.

 

[PeteS]

Another very simple way to do this (in line with Mochuelo's technique)
is to use a standard encoding (such as 8bit - 10bit encoding as used in
various ethernet and other communications protocols) and then assign a
comma code [sometimes known as a code violation] (precisely as is done
in such links) for start / stop.

This adds overhead, of course, but unless you want to get into
statistical analysis (such as framing bits require), it's simple, uses
a published standard and cheap in hardware to implement.

Cheers

PeteS

 

[Kryten]

"Mochuelo" <cucafera@RE_MO_VE_THIStelefonica.net> wrote in message
news:ljgjf1p91oita9pnvkts95onhpas8np99s@4ax.com...

On Tue, 09 Aug 2005 22:11:31 GMT, "Kryten"
kryten_droid_obfusticator@ntlworld.com> wrote:

8-bit data links have been invented.

Like which one?

HDLC

 

[Mochuelo]

On Wed, 10 Aug 2005 11:35:40 GMT, "Kryten"
<kryten_droid_obfusticator@ntlworld.com> wrote:

"Mochuelo" <cucafera@RE_MO_VE_THIStelefonica.net> wrote in message
news:ljgjf1p91oita9pnvkts95onhpas8np99s@4ax.com...
On Tue, 09 Aug 2005 22:11:31 GMT, "Kryten"
kryten_droid_obfusticator@ntlworld.com> wrote:

8-bit data links have been invented.

Like which one?

HDLC

HDLC is not 8-bit oriented. It is 1-bit oriented. Implementing bit
stuffing when you work one byte at a time is possible, but also a pain
in the ass (I did it once). Nothing to do with the simplicity of the
mapping I mentioned. I should remind that the first sentence of my
first post was "If the receiver delivers bytes to the upper level."