frames in communication protocols

Hello,

Communication protocols can be divided to several levels. My question here is about the "frame" level.

Most simple protocols consist of some start byte, then data of a fixed length, then a checksum and then an end byte. This is practical, because if some of the bytes get lost, the receiver looks for a start byte again and loses only one frame.

However, consider the freak scenario of the start byte appearing in the data all the time. If one byte of a frame gets lost, the receiver can then incorrectly re-sync on the data as the start of the next frame, and resync on it again and again, as the start byte keeps appearing in the data.

One way to solve this is to make sure start and end bytes never appear in the data. For example, we can define that if some such byte appears, it gets preceded by a special marker byte. This results in variable length messages but solves the problem.

What are other ways to combat these problems ? Any good sources on alternatives for communication on the frame level ?

Thanks in advance, Eli

Reply to
richard.melikson
Loading thread data ...

- you could use an alternative type of marker, such as an interval without characters (e.g. modbus) or a line "break" condition

- you could use a specially formatted character, e.g. 9 bit characters with the top bit indicating address/data.

- you could use a marker longer than 1 byte, perhaps a pseudo-random 4 or even 8 bytes. It would still be possible to "perversely" construct a frame that embeds this in the data. Perhaps you would never see this until you write a "flash update" routine where the code updates itself (that embeds the magic constant)! But if the marker is only a fallback in the event of corruption elsewhere, I think it could be OK.

--

John Devereux
Reply to
John Devereux

FYI, this is approximately the technique used for PPP HDLC-like framing described in RFC1662

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
 Click to see the full signature
Reply to
Michael N. Moran

snipped-for-privacy@gmail.com escribió:

Variable length messages that follows IEC 60875-5-2 use a header with:

- The start byte (0x68)

- The length byte (up to 0xFF)

- The length byte repeated

- The start byte repeated

This, togeteher with the checksum and the end byte, is good enough in my experience. IEC 60875 is widely used in remote terminal units and SCADAs.

Reply to
Ignacio G.T.

Original ethernet: use manchester coding. The end of the frame is indicated by invalid manchester code: the line goes back to DC. (note that the "length" field is not used for framing, and usually contains a packet type code instead).

Newer ethernet: use 8b/10b coding. Each 10 bit code has more than 256 values, so you can use one for a unique SFD byte.

Disk drives: "address marks" have a clock pulse missing (invalid FM or MFM sequence). RLL works more like 8b/10b ethernet, there's a unique code word.

HDLC bit stuffing. Interframe gaps are indicated with 0x7Es, so there can not be any runs of 6 1s a 0 is stuffed after any run of 5 1s.

HDLC byte stuffing. Interframe gaps are indicated with 0x7Es, so if there are any 7Es in the text, replace them with 7D 5E (also replace any 7Ds with

7D 5D).

SONET: A1 (0xF6) and A2 (0x28) bytes appear in the same place in every 125us frame. If A1A2 is missing for three frames in a row, declare out of frame and look for an A1 which persistently exists at a different time. The data is scrambled so that it is very unlikely for persistent A1 bytes to appear at any other time (scrambling also elimiantes DC from the signal).

T1: one bit out of every 193 is a framing bit (F). Look for a 1, 0, 1, 0, repeating pattern in the F bit (but it's a different pattern for superframe, extended superframe, etc.).

Video: send a pulse with an invalid voltage (blacker than black) to indicate end of line and end of field. A lot of power is in the sync pulses.

IS-95 CDMA (for cell phone): a lot of power is in a pilot channel containing a no-data pseudo-random sequence. If there is a strong autocorrelation with the phone's own PN generator, then a base station is found and the offset gives the frame boundary for other channels which contain data.

--
/*  jhallen@world.std.com AB1GO */                        /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
 Click to see the full signature
Reply to
Joseph H Allen

And thousands of hardware and software developers will hate you for decades.

--
Grant Edwards                   grante             Yow! Am I accompanied by a
                                  at               PARENT or GUARDIAN?
 Click to see the full signature
Reply to
Grant Edwards

That sort of scheme is very simple to implement and the way I usually do it, the message is only "variable length" on the wire: do the header/trailer escaping/unescaping in a FSM driving by the interrupt routine. The messages buffers are all still fixed length that way.

--
Grant Edwards                   grante             Yow! I've got a COUSIN
                                  at               who works in the GARMENT
 Click to see the full signature
Reply to
Grant Edwards

Well I didn't say it was a *good* way :)

--

John Devereux
Reply to
John Devereux

:-)

It confuses me why they did it in the ASCII format, which has framing characters anyway.

--
/*  jhallen@world.std.com AB1GO */                        /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
 Click to see the full signature
Reply to
Joseph H Allen

I wasn't aware that anybody used the "gap" delimter in ASCII mode. None of the implementations I ever worked with did gap detection in ASCII mode: all they used was ':' for start of frame and '\r' for end of frame.

--
Grant Edwards                   grante             Yow! My nose feels like a
                                  at               bad Ronald Reagan movie ...
 Click to see the full signature
Reply to
Grant Edwards

Here's the spec: but I can believe controllers not implementing the timeout:

1.3.1 ASCII Framing

In ASCII mode, messages start with a colon ( : ) character (ASCII 3A hex), and end with a carriage return-line feed (CRLF) pair (ASCII 0D and 0A hex).

The allowable characters transmitted for all other fields are hexadecimal 0 ... 9, A ... F. Networked devices monitor the network bus continuously for the colon character. When one is received, each device decodes the next field (the address field) to find out if it is the addressed device.

Intervals of up to one second can elapse between characters within the message. If a greater interval occurs, the receiving device assumes an error has occurred. A typical message frame is shown below.

--
/*  jhallen@world.std.com AB1GO */                        /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
 Click to see the full signature
Reply to
Joseph H Allen

[...]

I had forgotten about that part of the spec. Still it's not using the gap as a frame delimiter (which RTU mode does). A gap greater than 1s is simply an error and defines neither the end nor beginning of a frame. The start of the next frame is still a ':' character, right?

--
Grant Edwards                   grante             Yow! My Aunt MAUREEN was a
                                  at               military advisor to IKE &
 Click to see the full signature
Reply to
Grant Edwards

The state machine description in the spec doesn't actually show a timeout transition for the receiver, so I believe this is optional.

For a transmitter, meeting the 1s rule is simple, unless you're trying to type a raw packet on a terminal for testing purposes :)

Reply to
Arlet Ottens

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.