FILE QST.83.02.0l.0.KA6M
To: Paul Rinaldo
Fm: H Magnuski, KA6MSj: HDLC Sync-vectors and Pre-frame sync
Comments on Karl's article --
1. Four bytes of pre-frame sync is an entirely different thing from four bytes of sync vector. What Karl is advocating, in effect, is that the HDLC chip must receive four contiguous flags before it decides that a frame is truly arriving. I don't know of any way to make our HDLC chips go into start-of-frame mode on more than one flag.
2. If the data link is so bad that a lot of false syncing is expected, then I think we're going to have some serious problems getting any data through at all. If the receiver has started receiving a false packet at the very beginning of a transmission, only one properly received flag is required to scratch the false packet and start anew. There is no chance of missing a flag and its subsequent packet because you happen to be in the wrong byte-sync at the time the flag flies by.
3. Preframe sync of a zero pattern can technically cause false packets to be detected. The pattern FLAG-ZERO FILL-ZERO FILL- ... -FLAG will be interpreted as a frame with a bad FCS by most hardware. I know, as my repeater was tripping up on the packet stream being sent out by the VADCG TNC in the early days of trying to make the two talk to each other. Filler FLAGS do not cause this problem (which is small but annoying).
4. HDLC inherently provides for sending transparent data, and fixed block coding offers absolutely no advantage in that area.
5. 1 don't recall any agreement to adopt X.25 or AX.25. The use of those terms to describe what we have adopted is misleading.
73, Hank
FILE QST.83. 02. 06. 0.VE7APU
To : Paul Rinaldo, W4RI
Info : John Spraggs, VE7ADE
Hank Magnuski, KA6M
Den Connors, KD2S/Lyle Johnson, WA7GXDSubject: Pre-frame sync, etc.
Dear Paul,
To my knowledge, the 8273 is the only one of the three chips you are concerned with that automatically generates the pre-frame