Bulletins from the Pacific Packet Radio Society - page 164

synchronization transitions. This feature is very convenient. On the other hand, all three of the chips offer direct control of the bit stream being sent out in some form or another. This direct control of the bit stream is not very convenient to use mainly because it requires extra software to drive. I would expect that both the WD-1933 and the Zilog 8530 would be able to simulate the automatic operation of the Intel 8273 with appropriate software.

All the chips operate in flag stream mode as well so they all can be made to send any number of flags before the block. The easiest way to do that is by adjusting the clear to send delay on the modem. The 16 reversals is more efficient because it gives the modem more transitions to synchronize on. With bit oriented protocols, as we are using, the modem only has to do bit synchronization - not byte synchronization. The synchronization that Karl is referring to in his article is 'byte' synchronization which the chips we are doing performs automatically. Karl is confused. He thinks that the 'flag' being used in bit oriented protocols is a 'sync vector' that the modem needs to see in order to provide correct clocking to the digital circuitry and so he has become very concerned over the identification of this particular bit pattern. He also appears to think that this pattern might occur accidentally in the data stream and cause trouble. Neither of these is the case. With bit-oriented protocols, the only thing the modem need be concerned with is providing a clock tied to the data transitions. The fact that a 'flag' may occur with random garbage coming in on the data line is of no concern to us since the 8273 and others will only give us a packet if it is bounded by flags at either end and has a valid CRC-16. The 'flag' bit string can never occur in the data no matter what random data we send out because the chip uses a bit-stuffing technique.

I am afraid that Karl's article will spread more confusion in any area where there is already plenty. His sections on 'Sync-vector requirements' and 'Formats for Coded Transmission' contain information which don't apply to X-25 or our system but because of his mention of the "flag" byte and X-25 in the section 'Sync-vector requirements' make it appear that it does. Furthermore, the mention of the adoption of AX.25 in the Introduction is incorrect and I strongly disagree with some of the conclusions in the section titled, 'Conclusions'. He has a right to his opinion however.

In reference to Karl Meinzer's article, I agree 100% with Hank's 5 itemized comments and I have some additional comments.

1. I fought the battle of fixed length versus variable length packets back in 1979. Karl's conclusion that we should adopt a fixed block length for packets seems to fly in the face of all the progress we have made to date. While Karl's system for control of the satellite may have been very effective the fact is that in a general use data communications network we usually do not have 512 bytes (the number Karl used) to send at a time. Of

Click for Original Graphic Image of this page.