Bulletins from the Pacific Packet Radio Society - page 180

a lack of ability in getting the DPLL sufficiently "looked" before address, control and data fields commence.

The 1933 is particularly unfriendly. The lack of direct user control over the state of the Tx Data pin forced us to redesign the Modem to allow on/off tone keying for CWID on the TAPR TNC. (I suppose the main claim to fame of this chip is that it is CHEAP -- $14.)

The though of having to modify 180 TNCs in the field is not pleasant. Several of us have discussed the pre-frame sync proposal, and have certain reservations.

1) What is the minimum useable keyup time before a user can safely send data? There are many parameters to consider here, including transmitter characteristics, receiver stabilization time, MODEM lockup time, repeater keyup (if used), etc.

It has been our limited experience so far that these are the big delays in getting a packet started. We currently fill this time with flag bytes, and have had no problems to date with lost data (causing retries) that have been traced to lack of HDLC DPLL sync.

2) How close to "dead center" in the bit time must the PLL sample the bit for data integrity? I expect this depends on the particular noise the system has in the communications link, but perhaps some Packeteer can model this and come to some conclusions. I am sure that more sophisticated Modems will appear in the future that use statical sampling, or majority sampling, techniques to help noise tolerance, but that will have to wait...

To adopt a "standard" based on the particular requirements and/or shortcomings of a particular chip (the 8273 in this case), seems a bit strong. Some feel it may also be premature.

I don't know of anyone who has voiced an objection to the premise that preframe transitions are a good thing, but most of my contacts feel that adopting a "standard" is not good. Perhaps a "recommendation" is more in line, at least until some hard evidence can be assembled to support it as a need.

Thank you for the opportunity to comment -- please keep us in the Loop! There will be continued discussion on this question in the future here.

73's Lyle

FILE QST.83.02.2l.0.kd2s

to all PACSAT team members
from Den, KD2S

Click for Original Graphic Image of this page.