Asynchronous HDLC serial protocol question

So today I searched the World Wide Web for common point to point serial protocols. I came across this thing called 'HDCL'. I do think I understand this technique pretty well, however one thing still bothers me.

So this protocol uses a start and end flag (0x7E in hex) to indicate a frame of data. Normally you would have something like this if I understand it correctly:

[0x7E] {DATA FRAME_1} [0x7E]     [0x7E] {DATA FRAME_2} [0x7E]      ETC...

When a receiving party receives this stream, it will first 'hunt' the flag 0x7E, then reads the frame until the closing flag.

Now I was wondering what will happen when a flag becomes corrupted. So you would have something like this:

[0x00] {DATA FRAME_1} [0x7E]     [0x7E] {DATA FRAME_2} [0x7E]      ETC...

When the receiving party now hunts the flag it will discard the corrupted flag and DATA FRAME_1. Eventually the closing flag of DATA FRAME_1 will be seen as the beginning of a new frame, which in fact is not the case... This single corrupted flag is now making the whole stream to be corrupted, as the closing flag will always be seen as the start of a new frame... Am I missing a crucial point here, or am I correct that the stream will be corrupted once a framing flag goes bad? Thanks in advance!!!

The robust way of reading the data would see the two 0xFE’s in a row, with no data in between, and assume that the first was a closing tag whose opening tag was corrupted.

When using a protocol like that, the packet includes size and checksum information, so packet integrity can be checked.

Hi Paul,

But what if there is some time between the packets? Then you won't be able to detect both the end and the start of the frame. Look I could design something that will detect if the receiver reads two consecutive flags, it then discards one of the flags and the packet will be lost. However this isn't part of the standard protocol. And I can't imagine this simple "problem" isn't already solved in the standard protocol.

But what if there is some time between the packets?

Why is time a factor? If the start of a packet is mangled, and the end of the packet is taken as the start of the packet, the next byte that comes in, whenever that happens, will either be a start/end marker, or it won't.

Two start/end markers in a row means one of two things - either an empty packet (very unlikely) or the start of the current packet was missed.

Whoops sorry, I was assuming that I had to read both flags until I could start reading the next frame stupid me :o.

Right now everything is sorted out and the protocol is working just fine, both if a flag becomes corrupted or not :P. Cheers Paul :wink: :smiley: