Overview: A lot of POOP has been discovered on packet frequencies across the nation and around the world! Indeed, in addition to its health and welfare implications, POOP is both unnecessary and often times offensive.
While other four-letter acronyms have been used to describe the haracteristics of POOP, it is hoped that POOP is suffitly recognizable by packeteers to eliminate the need to express the others!
What, exactly, is POOP? How does one eliminate it? How can one help others to cause it to not be propagated? The answers to these questions form the basis of this paper.
POOP- What is it?
POOP is simply an acronym for Poor Operating On Packet. While it may evoke other thoughts in one's mind, the relationship between those other thoughts and poor operating practices is probably pretty clear and will not be further elaborated upon.
POOP- How does one eliminate it?
In order to eliminate POOP, one must simply not generate it. If it is generated, it will be passed onto packet channels, needlessly clogging them.
While there are many varieties of POOP, and it would be impossible to describe all in this paper, several of the more obnoxious and prevalent forms of it are described.
Frog POOP
If you have ever been around a pond, you have undoubtedly heard the loud and constant noise put on by frogs. Its seems amazing that so small a creature can make such a disturbance!
If you have ever monitored a busy packet channel, you have probably seen plenty of beacon messages. Here again, a large disturbance may be caused.
Beacon features were included in TNC software in early days of packet when stations were few and far between. Like the frog in the pond, the noises were made to attract attention of like species -- in this case, other packet stations. Unlike the frog, who settles down after he gets what he was looking for, many packeteers continue to send beacons, often on crowded channels.
Some packeteers contrive clever beacons to sound bells, clear screens, or print multi-line declarations on the screens of all who can decode the beacon.
The proper rules governing beacons are simple:
1) Determine why you need a beacon.
Beacons declaring that you are unavailable, or on vacation, are perfectly useless and mark you as a real POOPer. If the information you are attempting to convey is important, perhaps leaving it as a message addressed to all on the nearest packet bulletin board station (PBBS) is a better alternative.
On the other hand, if your are living in tornado alley and see a funnel, and urgent beacon may be appropriate.
(In-search-of POOP)
If the purpose of your beacon is to let folks know you are around and want to connect, it may be better to just turn on the radio and let your TNC decode a few packets from other stations. This way you can see who is on and then simply send a connect request rather than a beacon.
Many new TNC software releases include an MHEARD function, allowing you to see the contents of a buffer containing the last several packet stations heard by your station.
If you are convinced that you must transmit without listening for a few minutes (or if the channel really does appear dead), dropping into the UNPROTO mode (CONVERSE mode from COMMAND mode without first connecting) and typing a short CQ message (which may be a simple as a carriage return if UNPROTO is set to CQ) is preferable to beaconing one.
2) Compose the briefest possible beacon text.
Cute beacons that fill a screen, sound bells, or clear screens will only mark your station as obnoxious. It is a classic way to lose friends and increase your count of enemies!
3) Use the BEACON AFTER mode rather than BEACON EVERY.
If the channel is busy, one-way broadcasts (which is, after all, what a beacon really is) are not welcome. It's bad enough to try to maintain a connection through a digipeater or two without without having a channel clogged by transmissions from unattended stations that come on the air every few minutes. Beacon AFTER with a value of thirty minutes will assure that you do not contribute to busy channel bedlam.
4) Don't send beacons more often than every thirty minutes, . preferably less frequently.
5) Digipeat beacons with care!
Digipeating merely cause a large number of local packeteers to be subjected to screens full of your beacon text.
Squid POOP
As amateurs, we admit to occasional spelling errors. We meant Scwid (Sending CWID)...
Sending a CWID is somewhat akin to using class B (spark) transmissions on the lower end of 20 meters when the band is open. It's annoying and serves no useful function.
The CWID feature was included in earlier TNCs to help the uninitiated masses of Amateurs identify a station that was making "packet racket." The decoder of the cw would (hopefully) contact the station sending the CWID and inform him of the strange noises eminating from his radio, upon which the proud packeteer would politely inform the bearer of the bad tidings that the noise was intentional. In the insuing conversation and demonstration, another convert would then be won over to the way of communicating.
Besides, the FCC once required a CWID every ten minutes or so!
Nowadays, the FCC has recognized our heretical behavior, packet is state-sponsored and CWID is no longer required of packet stations.
As a final note, most packet operation occurs on VHF, and everybody knows that most folks on VHF can't copy code anyway!
Bull POOP
Try entering a field containing a bull. While many bulls are mild mannered, some are very territorial and will chase you away.
The same is true of a packet BULLetin board station. Many are mild mannered aware of other packet stations on the channel and content to share the channel with them.
Others, however, are not. They will chase you away unless you came to feed them.
They do it quite simply, and often are ignorant to their ferocity.
A skilled matador, however, can soon tame a ferocious bull. So can the operator of a PBBS tame his BULL.
The keys are TNC setup files. Most PBBS software contains a file (or files) describing the characteristics of the TNC(s) attached to the computer serial port(s). The magic commands are PACLEN, MAXFRAME and DWAIT.
If a PBBS is operating on HF, PACLEN should be fairly short, perhaps 40 or so. Since this parameter describes the length of information field, not the header and control bytes, a setting in excess of 80 (the length of one line on most computer displays) is probably the longest needed.
MAXFRAME can be the cause of a lot of useful bandwidth reduction. If the PBBS is on a channel shared by other users, MAXFRAME 1 is reasonable. I have heard PBBS's sending packets of many frames to stations that were having a hard time decoding anything, and the channel was reduced to uselessness for other stations. Similarly, I have often heard PBBS's on HF sending long packets of multiple long frames, getting an ACK on the first one only (if any), and repeating the process over and over. Computers are infinitely patient, but humans wanting to use the channel may not be!
DWAIT is perhaps the strongest medicine to apply to an overly possessive BULL. PBBS stations should set DWAIT to 320 milliseconds. For a TAPR TNC 1 running 3.X software, this corresponds to DWAIT 8; for a TNC 2 it is DWAIT 32.
If you are not the owner of a BULL, but venture into territory where one lives, you can help tame the beast! The following suggestions are highly recommended:
1) DO NOT DX A PBBS! In this case, DX means multi-hop. digipeating to a PBBS on VHF.
2) Don't send BBS a command before it has responded to your. previous command!
Hitting a key twice (or hitting it harder!) WILL NOT improve your chances of getting through! The nature of a packet system is that the message gets through accurately, or not at all. Sometimes it may take a while, especially if a digipeater or HF link is involved, but it will get through. If not, you will get a ***DISCONNECTED message.
Untimely POOP
POOP can't easily be made timely, but TNCs can! And TNC's that aren't timely can sure contribute to the level of POOP on a packet channel!
In the January, 1986 issue of PSR Quarterly, Tom Clark, W3IWI, made a convincing argument for the setting of the DWAIT parameter for all packet operations. His recommendations are:
| Time mSec | TNC 1 DWAIT | TNC 2 DWAIT | |
|---|---|---|---|
| User type | |||
| Digipeaters | 0 | 0 | 0 |
| Keyboard users | 160 | 4 | 16 |
| PBBS Hosts | 320 | 8 | 32 |
| File Transfer | 480 | 12 | 48 |
Digipeaters wind up with the highest priority. Since these stations are the most susceptible to collisions, and generate the most congestion on a retry, they deserve first shot at an empty time slot.
Keyboard users, operating in a keyboard-to-keyboard QSO, generate little traffic. After all, one can only type so fast! They get the next priority.
PBBS and host stations generally produce a fair amount of data out for a little data in. Thus, the keyboarder has priority getting into the PBBS, but the PBBS waits for other keyboard users before dumping what will probably be a longer packet onto the channel.
File transfers, generating the most data and hence requiring the most bandwidth, are requested to be more polite and give other users a fair shot at the shared channel. Thus, they are held off the longest. Wide adoption of this scheme may not significantly reduce congestion on a channel, but it should help the channel operate on a fairer basis than otherwise.
Snake POOP
A snake has a fairly unique characteristic. A snake has no ears!
Too many packeteers seem to have the impression that, by connecting a TNC to the speaker jack on their radio, they don't have to have a speaker connected!
The results can often be observed. Excessive retries on a channel because the antenna isn't oriented properly, leading to multipath and poor reception. The other end of the link simply "goes away" for no apparent reason (unless you are listening!). The other station is over deviating, or another user on another mode, or ... And, on a shared-mode channel (or shared repeater), packet can get a bad name in a hurry!
Kangaroo POOP
A kangaroo jumps around. If you have long files to transfer, you should jump around, too!
A busy channel during the early evening hours is not the place for file transfers, or other bandwidth hungry procedures. What can you do? Jump off to another frequency, perhaps. If this is not feasible, set your alarm for 3 AM and jump to another time, eating up the channel then.
POOP the final scoop
The ultimate means to eliminate POOP is to SCOOP! By means of the SCOOP, no one will ever be able to detect packet POOP emanating from your station!
SCOOP means Setting COrrect Operating Parameters. If you heed the advice to avoid POOP given above, this final measure will permit you to have full clean-air rating!
Happy packeting!
NOTE: This document was handed out at the Dayton Hamvention at. the Packet Forum which was well attended.