HAM Radio 1

home *** CD-ROM | disk | FTP | other *** search

/ HAM Radio 1 / HamRadio.cdr / misc / tn208 / tn206.doc < prev next >

Wrap

Text File | 1991-01-10 | 98.7 KB | 2,239 lines

\******************************************************************************/ ;* */ ;* */ ;* */ ;* ***** ***** */ ;* ***** ***** */ ;* ***** ***** */ ;* ***** ***** */ ;* *************** *************** */ ;* ***************** ***************** */ ;* *************** *************** */ ;* ***** ***** TheNet and TheNet Plus */ ;* ***** ***** Portable. Compatible. */ ;* ***** ***** Public Domain */ ;* ***** ***** NORD><LINK */ ;* */ ;* This software is public domain ONLY for non-commercial use */ ;* */ ;*****************************************************************************/ ;*****************************************************************************/ ;* */ ;* */ ;* */ ;* THENET PLUS NODEOP MANUAL */ ;* For version 2.06 */ ;* */ ;* January 1991 */ ;* */ ;* ************************************************** */ ;* */ ;* */ ;* */ ;* */ ;* */ ;* */ ;* */ ;* */ ;* */ ;* *************************************** */ ;* ********************************* */ ;* */ ;* */ ;* Programming: William A. Beech, NJ7P */ :* Documentation: Jack Taylor, N7OO */ ;* Editing: Neil Petersen, WD9DQH */ ;* */ ;* ************* */ ;* ********* */ ;* */ ;* */ ;* */ ;* */ ;* */ ;*****************************************************************************/ TABLE OF CONTENTS ***************** =============================================================================== 1. FORWARD.................................................................. 1 2. BACKGROUND............................................................... 2 3. THENET PLUS HIGHLIGHTS................................................... 3 4. PRELIMINARIES............................................................ 4 4.1 TNC SELECTION....................................................... 4 4.2 ALIAS SELECTION..................................................... 4 4.3 TNC MODIFICATIONS................................................... 5 4.4 NODE RADIO CONSIDERATIONS........................................... 6 4.5 RADIO ALIGNMENT..................................................... 6 4.6 NODE CHECKOUT....................................................... 6 5. USER COMMAND LIST........................................................ 9 6. SYSOP COMMAND LIST...................................................... 12 7. HOST INTERFACE.......................................................... 16 8. NODE PARAMETERS......................................................... 17 9. NETWORK MANAGEMENT (PARAMETERS 2 & 25).................................. 22 10. ROUTING LOOPS........................................................... 23 11. DUAL-PORT OPERATION..................................................... 24 12. MULTI-PORT OPERATION.................................................... 26 APPENDIX A.."To Lock or not to Lock" by Mark Marston, KA1NNN................ 28 ============================================================================== i 1. FORWARD For a long time there has been a need for a practical NodeOp manual. While the material presented herein is primarily for those desiring to set up and operate a TheNet Plus node, the methodology and procedures should apply to the operation of any of the netnodes. As this is the first cut at producing a NodeOp manual, there are bound to be areas lightly covered, or overlooked. No doubt others will have differing opinions on some topics. Our goal here is to provide detailed and factual information on the art of NodeOping. To that end, feedback is welcomed. I can be reached via packet: N7OO@NJ7P.AZ.USA.NA. A prerequisite for proper node software development is to reach a sensible balance between network loading and providing useful features for the users. It is very tempting for software developers to design nodes with numerous "bells and whistles". However, our RF networks are for the most part overloaded with BBS and TCP/IP traffic. Until our networks are upgraded to handle increased capacity, it is important that trends in new node design be oriented toward reducing the contribution of the node to network congestion. We are pleased to report TheNet Plus meets this criteria. While we do add slightly to network congestion with the "HEARD" feature, congestion is reduced considerably with the "Not Found" response. By shifting to the unique concept of listing aliases, instead of callsigns in the ROUTES table, a minimum of an additional 3 bytes per entry is saved. Appropriate use of the new "BYE" command will also save on network loading. TheNet Plus versions - Version 2.00 was the prototype test node. The maximum number of calls listed in the Heard list was 10 over a 10 minute period. Version 2.01 was the first "general release" of TheNet Plus. The Heard list was changed to a maximum of 20 calls listed over a 15 minute period. A parameter was added which allowed the NodeOp to set the maximum number in the Heard list to a value less than 20, if desired. Version 2.02 was a non-released experimental node. Version 2.03 was identical to version 2.01 with the exception of a bug fix associated with Parameter 24. In version 2.01, if Parameter 24 (callsign verification) was turned off, it also disabled the N * function. Version 2.03 corrects this situation. Version 2.04 corrected a problem caused by the fix in version 2.03 and changed Parameters 28, 29, and 30 to agree with the SETPLUS utility and this doc. Version 2.05 added several new NodeOp convenience features. One was to have the STA LED light when someone connected to the node. It was felt this would assist the NodeOp in servicing his equipment while at the site. Another new feature was to add three SYSOP KEY commands, MARK, SPACE and DIDDLE which keys the transmitter and turns on appropriate alignment tones. Also added was an ON - OFF remote control capability. One of the node command responses was 1 changed to "Host busy", instead of "Host table full" when a user attempted to connect to the Host (a disallowed function when the Host port is active). The "Not Found" response to an unknown node now indicates "Not Found: <node alias>" which purpose is to provide the user an "assurance prompt". Version 2.06 corrects a long-standing routing display anomaly, which takes care of the last known problem. Comments, suggestions and bug reports regarding the software should be addressed to: NJ7P@NJ7P.AZ.USA.NA. 2. BACKGROUND First, a little background on the node chip that makes the magic work. It is a 27C256 EPROM which has a nominal 32K of internal programming space. The netrom people did an ingenious job of assembling all the necessary programming code to fit within this space. There were four netrom versions, 1.0, 1.1, 1.2, and 1.3. Each version from 1.0 either cleaned up bugs or added additional features. With version 1.3 it was announced there was no more room left in the chip for new features and thus further development work would not be done. Basically, all of the necessary node instructions are "burned" into the chip. The existing TNC 32K RAM memory chip is then used for temporary data storage of certain functions such as the NODES and ROUTES tables. The Nord><Link people in Germany came along and essentially cloned netrom. They developed a procedure which squeezed the programming code to the point where sufficient room remained for additional features. Namely, INFO and the HIGH - LOW remote control capability. They also streamlined some of the code functions. Their first release was called TheNet version 1.0. Equipped with the user friendly INFO feature, it has become very popular with NodeOps around the world. With their distributions, Nord><Link provided source code in the public domain so other programmers could do node development work. Nord><Link subsequently produced the popular TheNet Converse node. The Converse node allowed users connecting to it to engage in ragchews. Two somewhat specialized node versions, TheNet 1.1-I and 1.1-E were then released by Nord><Link. The 1.1-I (INTERLINK) was intended for protected backbone applications and has a "positive" list of up to 4 stations that are allowed to connect FROM that node. A non-listed station may connect to it, but is not allowed to connect FROM it, short of disconnecting. TheNet 1.1-E was designed to be an ENTRY level user node. In response to a USERS command, it would show the digi path (if any) of an uplinking user. As of this writing, Nord><Link has released a TheNet version 1.16, but since most of the included documentation is in German and French, it is unclear as to its features at this time. TheNet Plus (here after called TNPlus) came about after observing the retention rate of packet newcomers was very low. One of the factors discouraging the newcomers was that they didn't know who to talk to out on the network. As in other ham radio modes, they were expecting to find an opportunity for ragchewing through the system, other than just locally. It was reasoned if our network nodes had a simple "heard" capability it would make 2 packet operation more of a fun experience and thus help slow down the user dropout rate. After considerable effort, NJ7P was able to modify the original TheNet code so the node would list users in a heard list. Further development led to some additional user features and thus, TNPlus was born! This manual is intended to provide a practical guide for the new, as well as the seasoned NodeOp in setting up and operating his TNPlus node. 3. THENET PLUS HIGHLIGHTS With this release, you will find the following new features and commands over those found in TheNet version 1.0: 1. INFO is now entirely SYSOP programmable. 2. A (B)ye command has been added. 3. "Not Found <aliascall>" response to unknown nodes. 4. A (H)eard command has been added. 5. Node radio TXD is remotely SYSOP adjustable. 6. Parameter listing expanded as described in the Parameter section. 7. Aliases instead of callsigns appear in the ROUTES list. 8. A simplified ON - OFF remote control function for SYSOP use. 9. Remote or local generation of alignment tones for setting deviation and frequency. 10. STA LED on the TNC lights when node is in use. As indicated, aliases, instead of callsigns, are now used in the nodes ROUTES list. This feature is intended to make life easier for the average node user. Previous versions with the callsign listed, required the out-of-area user to employ the "N <callsign>" command to determine the alias name associated with that callsign. Most users primarily use the alias, rather than the callsign during their network travels, so this feature should help in reducing some of the unnecessary packet clutter on the system. If a user has a need to know the callsign associated with a particular alias, it is only necessary to use the "N <alias>" command to get that information. Should a node not have an alias, or during the 30 to 60 minute period following the TNPlus initial startup period, node callsigns will be shown in the ROUTES list if they are heard. Following the neighbor's NODES broadcasts, the callsigns will then be replaced by the node alias. 3 4. PRELIMINARIES The following steps should be taken in the process of getting your new TNPlus node operational: 4.1. TNC Selection "Net" type chip nodes work only with TNC-2's or clones. There MAY be a problem with noding an AEA PK-88. The Kantronics series of TNCs will NOT work for this application. Multi-mode type TNCs will NOT work for this application. Use only a TNC-2 or clone (Pac-Comm, MFJ) that has the full compliment of 32K memory installed. Using the older 16K equipped TNCs will result in failure of your node to work. Your TNPlus node chip is a programmed type 27C256 EPROM and replaces the TNC firmware chip located at U-23 in most TNCs. This TNC chip can be identified by the label on top indicating something to the effect of "TNC 2 1.2.6" or, "TNC 2 1.2.7". CAUTION! CMOS handling precautions are necessary when removing/installing these chips. Never replace components with power applied. The safest procedure is to ground yourself, your work area and your TNC during the chip replacement process. Keep your TNPlus chip in its protective container until time to insert it into the TNC. 4.2. ALIAS SELECTION Selecting the alias that is "just right" for your node has always been a problem. From early on it was recognized there would be a high probability of alias duplication if individual NodeOps were to make independent choices. One method which is used widely, is to use airport designators, as these are centrally assigned in order to prevent duplications from occurring. But this method has not been universally adopted. Quite often the airport designator only had meaning for local residents and was not descriptive of the node location to those connecting from a distance. We currently do have node alias duplications in our network. This was not too serious of a problem if the nodes affected are separated by some distance. However in California we find two SFO nodes and two FAT nodes which ARE confusing to node travelers. As the use of HF node/gateways increase, distance no longer prevents duplicate alias confusion. For instance, there is FST in California and FST in Texas. We have SAN in California and SAN in Maine, etc. Some state packet groups have adopted the policy of prefacing their alias with the state abbreviation. This certainly cuts down on the chances of alias duplication. Another method might be to solicit the central data bank K4NGC maintains. This data bank contains a listing of node aliases world wide. Possibly this source would be willing to act as an information service to determine if your choice for a node alias already exists or not. In any event, it would be helpful for maintaining his data base if NodeOps would advise by message of additions, deletions or changes to node status by giving: type of node (G8BPQ, TheNet, etc.), node alias, callsign, SSID, location and frequency of the affected node. This information should be sent to K4NGC @ K4NGC.VA.USA.NA or, via LL BBS at (703) 680-5970. 4 Aliases for backbone nodes by convention, have the pound sign (#) prefacing them. These are the so-called hidden nodes which typically are used to tie a LAN frequency to a network trunk. "Pound nodes" are intended to be invisible to the network traveler and will not appear in response to a standard user initiated NODES command. 4.3. TNC MODIFICATIONS Prior to modifying your TNC for TNPlus operation, make sure it is functioning normally. Then perform the TNC modifications. These consist of: a. Connecting a small wire from RS-232 pin 23 to the "common" side of JMP 9, the three pins facing the front panel on the board. b. Perform VHF or HF DCD modifications, as appropriate. These modifications were developed and documented by Eric Gustafson, N7CL. They yield improved TNC performance and will improve node operation. For the TAPR TNC-2 or clone, the VHF modification is extremely simple and consists of adding a capacitor and two resistors to the circuit board: Replace R-73 with a 180K ohm resistor. Place a 180K ohm resistor paralleled with a .01 Mfd capacitor on the underside of U-20, between pins 3 and 6. Note: To perform the above modification, it will be necessary to deinstall the TNC circuit board. An alternative method of doing these mods would be to purchase a TNC DCD modification kit from the Tucson Amateur Packet Radio Association (TAPR), telephone (602) 749-9479. Specify the TNC model number when you order. c. On earlier version TNC-2s it will be necessary to increase the CPU clock speed to 4.95 MHz. Check your TNC documentation on how to do this. 1990 vintage TNC's probably are already set at this clock speed. Early version TNC-2s used at U-3, an LM 324 opamp which is not fast enough for 9600 baud RS-232 operation. If your TNC does NOT have this chip it probably will operate satisfactorily. If it does have the chip. a TL074 or TL084 is a suitable replacement. Modification of the watchdog timer to increase its time out value does not seem warranted as the 12-second timer value is sufficient. The Pac-Comm Tiny 2 TNC comes TheNet ready. It may require a more complex DCD modification kit, also available from TAPR. 5 4.4. NODE RADIO CONSIDERATIONS Radios selected for node use should be capable of heavy duty use. The T/R switch circuitry should be able to handle virtually millions of operations without failure. This means PIN diode T/R switching as a first choice followed by high quality reed relay switching. Receiver front-end filtering should be quite sharp if your node is to coexist with other radio services. In that case consider using one or two tuned cavities to cut down on front end overload and desensitization. If your radio is operating on a simplex frequency, the cavities will also aid in reducing the effects of "white noise" being generated by the transmitter. At congested sites a circulator may be required. Some amateur class VHF radios employing PLL frequency synthesizer technology should be avoided. Two reasons: PLL settling time between transmit - receive is too slow for optimum packet thruput. Assuming a TXD of 500 milliseconds, the effective thruput rate would be cut in half. I.e., 1200 baud = 600 baud, 4800 baud = 2400 baud, and 9600 baud = 4800 baud. Also, the transmitter may be keyed before stabilizing on frequency. This latter situation could cause interference to other receivers on different frequencies. If your candidate radio uses PLLs, ask the manufacturer about on suitability for packet node use. In general, retired commercial service FM radios, such as the Motorola MICOR and GE MASTR II, or later, make excellent node radio choices. The commercial radios are designed to operate in moderate to high intensity RF environments, are physically rugged, and fairly reasonably priced on the used market. These radios typically come in a variety of power levels up to 110 watts and are normally configured in different frequency bands adjacent to the amateur frequencies. Thus be prepared to do some modification to get one of these radios on frequency. This extra effort is usually worth it since the odds are you will end up with a very stable and reliable node radio. 4.5. RADIO ALIGNMENT Assuming your node radio is tuned and on frequency, setup for FM radios consist mainly of adjusting the transmitter deviation for NO MORE than 3 KHz. TNPlus versions 2.05 and later have a built in tone alignment capability to aid in setting deviation. A range of 2 KHz to 3 KHz deviation for alternate tone frequencies is typical. Even if you have purchased high quality channel crystals, be prepared to make frequency corrections over the next 30 to 90 days, due to normal crystal aging effects. 4.6. NODE CHECKOUT Before placing your node in service, it is a good idea to verify modem tone frequency accuracy. This can be done by using a frequency counter on the TNC audio output in conjunction with the KEY MARK and KEY SPACE commands. Or by following the modem calibration procedure using the firmware chip as described in the TNC manual. Carefully save the original TNC firmware chip for possible future use. 6 NOTE: Sometimes the contents previously stored in RAM memory will interfere with node initialization when the TNC is first powered ON. This situation has been observed after replacing the TNC firmware chip with the new nodechip. The solution is to turn off the TNC and pull the battery jumper (JMP 5 on MFJ's) for about one minute. This power down process deletes the contents previously held in RAM memory. Reinstall the battery jumper and the TNC should initialize properly. Using a standard RS-232 cable, such as the one between your TNC and terminal, connect your terminal to the noded TNC. Make sure the TNC to terminal data rate is set to agree with each other! Power on the TNC. The STA and CON LED's should go on and then off. A TNPlus sign-on message will appear on your terminal's screen. Connect to the new node by pushing the ESC C <enter> keys. The screen should now read: "CONN to <callsign>". At this time verify the node is working by checking out its commands. Type: "I" <return>, "H" <return>, "N" <return>, "P" <return>, "R" <return>, "S" <return>, "U" <return>, an invalid command such as "W" <return>, and "B" <return>. You should get an appropriate response back from each of these node commands. Operation of the node in this manner is called "Host Interface" and is similar to using a regular TNC in the NON-MONITOR mode. You will not be able to monitor unconnected packets. Reconnect to the node and if a nearby station or node is operational, you can connect to it by issuing the standard "C <callsign>" command. You will be able to perform normal packet activities while connected as the Host. After your node has been on the air for 30 - 60 minutes, it will have given a NODES broadcast and then will be recognized by nearby line of sight nodes. When you are satisfied your node is performing satisfactorily, you can disconnect by either the B command, or the ESC D command. A unique password string has been hard burned into your "TNPlus" node chip. You will need to remember this password string since from time to time you may want to enter new material into the INFO section. To view the default password string, on versions 2.01, 2.03 and 2.04, connect to your node as host and type "ESC P" <return> which will then write out your password on the terminal monitor screen. Only from the host interface can you view or change the password. To change the password, type "ESC P <new password string> <return>". The new password string will stay active until: 1. You change it from the host interface position. 2. The node has been powered down for a long period or the internal TNC battery has failed. 3. The SYSOP RESET command has been performed. If any of these conditions occur, the programmed password string is lost and then the default password string is again active. For these reasons, you will want to save the default password in a safe place. An important note: The password string is CASE sensitive, which means it will not accept a lower case letter when a capital letter is required. 7 NOTE: From version 2.05, the ESC P command has been deleted from the HOST interface. In order to make programming room available for the "KEY" alignment features it was necessary to make a trade-off between that and existing functions. As a result, it was decided to remove the ESC P command from HOST mode. The password string is still normally programmed in at time of node chip preparation and should be recorded for NodeOp use. (See SETPLUS.DOC). To remotely SYSOP your node, you need to have a radio/TNC combination on your node radio's frequency. Connect to the node by issuing a "C <nodealias>" command and then type "S". S will return you a random series of 5 numbers. Enter the password string that corresponds to these numbers. (Review the SYSOP COMMAND LIST below for more details) The node will ignore you. To test the success of your SYSOP command, type "P <return>". This will give you a string of numbers, representing the default values for the various node parameters. Note the value of the first number (typically 100). Now type "P", space, "400". If successful, the first number should come back reading the new value 400. Again type "P" space and insert the original number back in the parameter listing. Now that you have been accepted as a SYSOP, you can input new information into the INFO section. You will probably want to place information about your QTH and operating frequency. Following that, you might want to mention the next radio club meeting, callsign of the local BBS, or any other information that might be of interest to local and distant users. For example, as SYSOP, enter: "I CARA elections coming up on the Sept 3rd meeting, 7PM" <enter> and you should get back the same response from the node. For specific information on how to write into the INFO section, review the material presented in the SYSOP COMMAND LIST. As SYSOP, you can also change the parameters. In fact, you changed one of them in the example above. The default node parameters have been carefully set for your node. (IT IS NOT RECOMMENDED THEY BE CHANGED UNLESS YOU HAVE A STRONG REASON FOR DOING SO!) In general, the node parameters modify the nearby node network performance in subtle, and sometimes not so subtle, ways. An improperly set node parameter can harm the overall network thruput. Before making any changes, read over this manual carefully and consult with your neighbor NodeOps to get a feel for what the change may do. One change that you may want to make is in setting parameter 3 to a value as presented by Mark Marston, KA1NNN, "To Lock or not to Lock", as discussed in appendix A. The concept outlined in appendix A was first publicized by N5DUB in Oklahoma and is a highly recommended procedure to use on any node subject to propagation conditions. To summarize the locked routes concept, Parameter 3 is set to a value of 100. Then the routes of known RELIABLE neighbor nodes are "locked" to the normal value of 192 by the SYSOP command: "R 0 <callsign> + 192". This procedure will direct the network flow through the "good" nodes and ignore the "bad" nodes that show up briefly during periods of propagation. 8 5. USER COMMAND LIST TNPlus version 2.06 has the following commands available to the user: (Commands may be abbreviated as indicated.) BYE (B) - Use this command when you want the disconnect to be initiated from the far end of the circuit. CONNECT (C) - This is the general command to connect to and from the node. Examples are: "C PDT" to connect to a node, "C KB5CDX" to connect from the node to a local station. Connecting through a digipeating path is allowed: "C VE3LJW v VE3KYZ", for instance. CQ - When the node receives a CQ command, it transmits once: CQ plus any user text up to a maximum length of 77 characters, including spaces. The node is also conditioned by this action to display the CQing station in its USERS response for a period of time set by Parameter 15 (usually 15 minutes), unless the CQing station issues some other command before the time runs out. Should another station perform a USERS command during this time, he would be able to see something like this: DMN:WD5EZC-2> TheNet Version 1.0 (695) Circuit (CLOUD:WD5EZC-1 W2RRY) <~~> CQ (W2RRY-15) Anyone observing the CQ can connect to the node and then connect to W2RRY-15 to initiate a QSO. If the CQing station doesn't get a reply after a few minutes, he can reinitiate the CQ command from time to time in hopes of attracting someone in the local area of the calling node. Remember, each time the CQ command plus text is given it will be broadcast by the node for just that one time. HEARD (H) - The "H" command will display level 2 (normal) users heard by the node during the past 15 minute period. Netnodes and level 3 users will not normally be seen once your node has "initialized" itself (a 30 - 60 minute period after startup). The maximum number of users allocated for the Heard table is 20 and is a SYSOP settable parameter. Stations listed in the heard table are not ranked in order of time. I.e., the first station listed may not be either the most recent or the oldest station heard. If a station has not been heard during the past 15 minutes, a "No One" response is given. The Heard function compares the new call with the node alias table. If a match is not made, the new call will appear on the Heard list. There will be times when either a new node or a propagated node callsign will appear on the Heard list. Digipeated and local node downlink callsigns will also be listed. If a user notes an SSID of -14 or -15 associated with the callsign, the odds are these calls will be unconnectable since the originating station is separated by one or more digi's or nodes. 9 INFO (I) - TNPlus now contains one SYSOP programmable INFO section which has a capacity of up to 160 characters including control characters and spaces. The dual "hard" and "soft" INFO found in previous versions has been replaced by this more versatile feature. It is doubtful the user will be able to tell any difference, unless the NodeOp forgets to reprogram it after a RESET. The advantage to the NodeOp of having a completely programmable INFO section is he will not have to completely reprogram the TNPlus EPROM should circumstances require a change of the text formerly found in the hard coded portion (normally QTH and node frequency). While 160 characters are now available, good network management practice dictate only enough text be used to get the pertinent message across. Although it may seem "distinctive" to fill the remainder of this space with spaces, line feeds, or Control G's, please don't do it. Users find such practices annoying plus it dumps unnecessary packets onto our congested networks. Examples of INFO text and format are: WTEX:W5CDM-3> Located at Notrees, Tx. Ant 600 ft. courtesy of WD5THB & W5CDM... RDG:WA6YNG-1> From 18 Miles West of Redding On Shasta Bally at 6200 Ft. - 145.05 Mhz. With a Motorola Micor 60 watt radio on battery and float supply. YKA:VE7RKA> Greenstone Mountain Packet System Kamloops, B.C. SysOps- VE7EHL - VE7EJE Mark your calendars, Nov 22, Packet meeting at the Lotus, C U There... CLAMS:WA1ZDA-3> HATCHET MT. HOPE, ME 223.42 MHZ LINKED TO: WA1ZDA-7:LOBSTR WA1ZDA-1:PENBAY The procedure for writing to INFO is explained further in the SYSOP COMMAND LIST. NODES (N) - This command calls down a listing of the nodes contained in the NODES table. It gives a user a listing of possible destination nodes for him to connect to. It's a very good practice to use this command sparingly. Owing to the condition of our congested networks, a NODES dump may cause all users on the channel to be disconnected due to the large barrage of packets this command normally yields! Since our VHF networks are relatively stable, the chances are, the contents of our local node table is not apt to change radically from hour to hour. Thus local users should be encouraged to NOT command a NODES dump every 5 minutes! 10 Variations on the N command are: "N *" and "N <alias or callsign>". The "N *" command ADDITIONALLY yields a NODES dump of the # (hidden) nodes. The hidden nodes are those normally associated with backbone trunking. As such it is not normally intended for users to connect to them. A very excellent command is that of "N <alias or callsign>". This allows a user to determine the path quality and identification of the nearest node leading to the destination node used in the command. An example: We are at the NDGAF node and wish to know the route to NDPMB. We issue a "N NDPMB" command and receive back this response: NDGAF:WA0RLE-1> Routes to: NDPMB:WC0M-8 192 5 0 NDPMB 146 5 0 NDPET This tells us there is a DIRECT radio path (the 192 and 0) and that the path is fairly current (as indicated by the 5). We can then assume we have a high probability of success should we want to connect to NDPMB. We also note there is a secondary path to NDPMB via NDPET. The numbers given in the N <alias or call> command will be explained later. Here we just want to show how the N <alias or call> command is a powerful tool to help one navigate throughout the network. PARMS (P) - (Parameters) Issuing this command will yield a status listing of the nodes parameters. There are 30 (up from 26 in TheNet version 1.0) of them and the node response may look like this: SKY:W7YB-3} 100 61 192 255 6 5 1800 31 45 4 3 180 4 7 900 225 10 4 3 7 85 18000 1 0 1 1 0 20 30 0 Each parameter affects the node operation in one way or another. The values chosen for your node will impact the operation of the other nodes in the network. The convention is to number the parameters from left to right in the example above, starting 1, 2, 3, etc. ROUTES - This command yields a listing of all radio line of sight or wire connected nodes "known" to the node. The listing will also show nodes and digi routes set by the SYSOP locking commands. Due to the different protocols involved, Thenet does not recognize KA-Nodes, ROSE nodes, or TEXNET nodes in it's ROUTES list. It will recognize G8BPQ, MSYS and TCP/IP nodes. A typical ROUTES display may look like this: WTEX:W5CDM-3> Routes: 0 ODSA 192 30 > 0 DKC 192 23 > 0 MAF 192 10 0 FST 192 16 0 RKN 192 11 0 BGS 192 5 Here we see in column 1, all of the connections are via direct radio port (0) paths. The right arrow indicator tells us two of the paths are either in use or have had activity within the past 15 minutes. All radio paths show a standard path quality value of 192. The last column indicates the most active 11 node in the list is ODSA with 30 destination routes showing. The least active is BGS with 5 destination routes showing. 6. SYSOP COMMAND LIST In addition to the USER command listing given above, there are a special set of commands for SYSOP use. To be able to use these, you will have to be recognized by the node as a SYSOP. The method for doing this is to answer correctly the random set of numbers given in response to a (S)YSOP command as described previously. INFO (I) - Allows the SYSOP to enter text into the soft coded INFO section on the node. This new INFO section has available a maximum of 160 characters. Up to 80 characters on one line is allowed. To use, type: "I (space) text <enter>" for the first line. If you prefer to NOT have text appear on the first line, then type "I (space) (Control G) <return>". This gives a "beep" along with a blank first line. For text to be entered on the 2nd and subsequent lines, type: "I (space) + <text> <return>" until the total 160 character limit is reached. As this technique is different than previously used, a little in-house practice is advised until you become familiar with it. Review the INFO format examples previously given for ideas on how you want to set the INFO text format. An example for setting INFO: SYSOP action: I (control G) <return> Node response: SVATST:NJ7P-4} SYSOP action: I +Sierra Vista, AZ Node response: SVATST:NJ7P-4} Sierra Vista, AZ SYSOP action: I +145.01 MHz Node response: SVATST:NJ7P-4} Sierra Vista, AZ 145.01 MHz SYSOP action: I +CARA elections coming up soon, be prepared to help! Node response: SVATST:NJ7P-4} Sierra Vista, AZ 145.01 MHz CARA elections coming up soon, be prepared to help! SYSOP action: I +BISBEE node will soon QSY to 145.11 MHz. 12 Node response: SVATST:NJ7P-4} Sierra Vista, AZ 145.01 MHz CARA elections coming up soon, be prepared to help! BISBEE node will soon QSY to 145.11 MHz. This process can be repeated until the maximum of 160 characters, including non-typing and punctuation, has been reached. To erase the entire INFO section, just type: "I <Control G>". If the INFO section is to frequently be changed, an INFO file could be prepared in advance with the appropriate commands and text included. After SYSOPing the node, the file can be uploaded. Another advantage of preparing the file in advance is it doesn't require as much on the air time. KEY MARK (K M) - Operates the PTT line of the TNC and turns on the Mark (high) tone for approximately 22 seconds. KEY SPACE (K S) - Operates the PTT line of the TNC and turns on the Space (low) tone for approximately 22 seconds. KEY DIDDLE (K D) - Operates the PTT line of the TNC and alternates rapidly between Mark and Space for approximately 22 seconds. The purpose of the "KEY" commands are to make the NodeOp's job of setting deviation and RF frequency much easier. Previously it was necessary to reinstall the original TNC firmware chip and perform the CALIBRA procedure in order to set FM deviation. Now if the NodeOp has the appropriate equipment and is within radio range of the node, he can routinely check frequency and deviation remotely! At the site, this same procedure can be done via the HOST mode interconnect. Once entered, there is no way the KEY command can be terminated until the internal timer runs it's course. If the TNC-2 watchdog timer is set for less than a 22 second duration, the watchdog will unkey the PTT. However, the node will continue the KEY command until the remaining time has expired. During this period, the node will not execute any other commands. ON - OFF - A simplified remote control capability as compared with the HIGH LOW commands found in TheNet version 1.0. "ON" turns on the CON LED and "OFF" turns the LED off. In the MFJ 1270B, the voltage sense from the CON LED appears on pin 8 of the DB-25 connector. The voltage sense also appears on the base of Q16, a 2N3904, the output of which goes to pin 2 of the TTL connector. The main caution here is that the controlled device not require more than a couple of milliamps either source or sink. The MFJ 1270 places the DTRA line from the SIO/0 directly on pin 2 of the TTL connector. A transistor buffer should be used between this line and any controlled device. PARMS (P) - Allows the NodeOp to make changes, as necessary. To use, type "P space * * * * * * * * * * * * * * 650 <enter>" to change parameter 15 from 900 to 650, for instance. The asterisks preceding the value to be changed protects the preceding parameters from being changed. To change Parameter 4, type "P * * * 245", as another example. 13 LOCKING NODES - Occasionally a need may arise to modify node entries in the NODES table. The SYSOP command for this is: N NODECALLSIGN + ALIAS QUALITY OBS PORT NEIGHBOR (digicall, digicall) For example: N K7WAA-1 + CAHTO 0 0 0 K7WAA-1 Assuming the path to neighbor node CAHTO is unreliable, good network management practices would dictate CAHTO be locked out. In the above example, setting the QUALITY to 0 will prevent CAHTO from appearing as a direct path. Setting the Obsolescence count to 0 makes CAHTO be listed as a permanent locked entry. If the Obs count was set to a value between 6 - 1, this locked entry would then be deleted at a time as established between Parameters 5 (Obsolescence counter) and 7 (Broadcast interval). To manually unlock CAHTO, the command is reversed: N K7WAA-1 - CAHTO 0 0 0 K7WAA-1 Here you will note, we used a minus sign for this purpose. It is necessary that the unlock command be exactly the same as the lock command, with the exception of the minus sign. Up to two digi stations can be specified in the nodes lock command. These calls are added following the neighbor callsign. Setting the Obsolescence to zero permanently locks the destination node into your NODES table. Even if the locked node fails, it will still be listed in the NODES table. A failed node entered as a locked ROUTE on the other hand, will not be listed in the NODES table if a corresponding LOCKED NODES command has not been used. The LOCKED NODES command to use if a node should NOT have an alias is: N NODECALLSIGN + * QUALITY OBS PORT NEIGHBOR (digicall, digicall) Usage example: N AK7Z-1 + * 143 0 0 AK7Z-1 LOCKING ROUTES -- There may be times a NodeOp will want to modify the path quality value of a route to a given node. Additionally, locking routes is useful at times in indicating a digi path to a node not normally seen by the network. If for network management reasons one wants to isolate one network from another as far as preventing the flow of NODES broadcasts from intermingling, the locked routes technique is preferable over the locked nodes procedure. If one wants the existence of the isolated node to be known, then a combination of the two techniques should be used. The locked routes command is: 14 R PORT NODECALLSIGN (digicall digicall) + PATHQUALITY To unlock the routes use: R PORT NODECALLSIGN (digicall digicall) - PATHQUALITY An optional use of up to two digi's can be specified. An example: R 0 W5CDM-3 + 143 KP2S W5ODA N5AA The result of this operation might look like: MAL:W2RRY-1 Routes} 0 DKC 192 9 0 CLOUD 192 43 0 WTEX via KP2S, W5ODA, N5AA 143 1! Here we see the exclamation mark which indicates a SYSOP locked entry. The process of locking routes or nodes as explained above is called "perming". Perming is normally done when it is necessary to IMPROVE network thruput. The most common example of perming is when you lock UP reliable neighbors with their PATH QUALITY values being set higher than that of Parameter 3. Normally only the ROUTES locking command is used for this situation. If the NODES locking command were to be used, then the neighbor would remain in the NODES tables and hence be broadcast into the network even if that neighbor should fail. Here is an example of a LOCKED ROUTE for a neighbor that has failed: SVA5:N7OO-2} Routes: 1 AZ 245 7 1 AZSE 245 18 1 CONF 245 1 1 SVA 245 19 1 SVALAN 245 8 1 #SVA6M 245 4 0 N7DZH-5 192 0 ! In this example, HELIO has suffered a power failure. After a period of time as determined by the combination of SVA5's NODES broadcast interval, Parameter 7, and Obsolescence counter, Parameter 5, knowledge of HELIO will ordinarily go away. However in this case, HELIO:N7DZH-5 has been permed into SVA5's ROUTES as a reliable neighbor. This can be readily seen by observing the path quality value has been fixed at 192 as evidenced by the exclamation point symbol. By noting the "0" in the "number of destination routes" column, we know this is a useless route. If and when HELIO comes back, the "destination routes column" will indicate a value of greater than 0. Meanwhile, HELIO has not been permed into the NODES table of SVA5 and thus will not be propagated during NODES broadcasts until it becomes active again. With TNPlus the alias HELIO will be listed in the ROUTES until HELIO is decremented out of the NODES table. At this time it automatically reverts to the node call-sign, N7DZH-5 in the example above. 15 When perming digi paths, both NODES and ROUTES locking can be used if the respective NodeOps want the destination nodes to appear in the local NODES broadcasts. Also, the ROUTES locking can modify the path quality value which is normally fixed by Parameter 3. When setting a digi path between two nodes, the path quality value should be something less than 192. A value of 144 or lower should be chosen. Although a permed route can be set by only one NodeOp, as a matter of courtesy, it should not be established unless both agree. A digi path between two nodes tends to act as a NODES broadcast filter. When the locked routes are permed in, only the destination node callsign will appear in each of the NODES tables. When locked nodes are permed, the callsign as well as the alias will appear. In either case non-permed node callsign/aliases will not appear as the digi prevents the transmission of NODES broadcast information. RESET - This is the big panic button. When one of the shiny new PC based nodes goes berserk and dumps out garbage nodes which pollutes your NODES table, you can clean your node by typing RESET. This not only wipes NODES and ROUTES tables, it also wipes your softcoded INFO section. Stations connected or networking through your node at the time of the RESET will be disconnected. To use, type "RESET". 7. HOST INTERFACE When your terminal is attached to the RS-232 port of the node, you are accessing the Host Interface. It's function is to allow you, as NodeOp, to perform housekeeping operations. The node is configured to automatically accept you as the authorized SYSOP whenever it senses your terminal connection. In addition to the regular USERS commands, the Host Interface has specific host commands available. These are: ESC C - to connect to the node. ESC D - to disconnect from the node While accessing the Host Interface, you can (without qualification) perform all the other SYSOP functions that are available to you remotely. The Host interface is set up as a single user application. You as SYSOP can access it by giving an ESC C command via a terminal connected to the RS-232 port. A user can access only if there is no one actively connected to the node via the RS-232 port AND if parameter 27 is set to (1). Under these circumstances a user would connect to the node as normally done. Once the "connected to" response is received, the user would enter another "C" command. The node will then respond again with "connected to" <nodecall>. At this time communications can take place between the terminals of the user and the Host. 16 8. NODE PARAMETERS (listed in sequence from 1 to 30) 1. Sets the maximum number of nodes, both hidden and non-hidden, in the NODES table. If this number is set too low, say to 1, you will limit the number of neighbor routes that show up in your ROUTES table. In other words, your node will not recognize more than one network node. If this value is set to say, 400, it will safely recognize all of the nodes the "path quality filter" as set by Parameter 2, will pass. It won't hurt anything to set parameter 1 to 400, but it is better to set it to a lower value to act as a "safety valve". A default value of 50 to 100 is recommended here. (Range: 1-400) 2. Minimum path quality for automatic updates. This parameter sets, in terms of path length, a limit to the number of distant nodes which will appear in your NODES table. Thus it also sets a limit, again, in terms of path length, to distant nodes being rebroadcast from your node to its neighbor nodes. Assume we have a network all in a line totaling 5 nodes. "Path quality" is a term that defines the probability of a connect from the first node to the second, from the first to the third, from the first to the fourth, and from the first to the fifth. The concept this is based on recognizes the probability of a connect from the first to the second node is higher than a connect from the first to the third, etc. The lowest probability of a connect being from the first to the fifth. Let's assume at a point in time your node (node number 1) has not recognized any other nodes and it issues a NODES broadcast. It says in effect "I don't know of anyone else, but here I am!" Node number 2 hears this broadcast and says "Eh? There's someone out there!" His internal programming determines he just heard a NEIGHBOR NODE which he then assigns a PATH QUALITY value equal to his parameter 3 setting and then tucks the new stranger into his NODES table (he also sticks it into his ROUTES list). After a time determined by parameter 7, node number 2 issues his NODES broadcast. This broadcast tells node number 3 that node number 2 has heard node number 1 and that node number 2 has assigned a PATH QUALITY value of say, 192 to node number 1. Node number three obeys his internal programming, does some calculation on number 1's PATH QUALITY number and assigns it a value of, say, 144. Each node down the line duplicates this process, assigning a decreasing PATH QUALITY value to node 1 of 108, 81, and finally at node number 5 of 61. Thus parameter 2 acts as a filter on the number of distant nodes it will accept into its NODES tables, and subsequently rebroadcast. For further elaboration on setting this parameter, read the section on Network Management - parameters 2 & 25. Recommended default value for a busy network is 60 or 80. (Range: 0-255) 3. Path quality assigned to radio channel 0. Since much of the automatic network management techniques of TheNet are centered around the path quality concept, we will briefly discuss the basic conventions. Certain types of packet networks (wire links, HF/VHF/UHF radio with varying user access) work more efficiently than others. The most ideal packet link is a wire line running from one TNC to another (two dedicated ports). Least ideal is a multi-user accessed HF link subject to interference and varying propagation 17 conditions between the two TNCs. Through observations and studies the following conventions have been established: TYPE OF PATH BETWEEN TNCs PATH QUALITY %PERFECT RS-232 wire line (2 port) 255 99 Satellite link 252 98 RS-232 wire line (3 port) link 248 97 UHF radio non-user radio link 240 94 VHF radio non-user radio link 224 88 VHF/UHF user accessed radio link 192 75 10 Meter user accessed radio link 180 70 HF user accessed radio link 128 50 It should be remembered these path quality values are for ideal situations. Path congestion and propagation conditions will lower the values accordingly. But by convention, you will see these values used in parameter 3 throughout the system. The above chart explains why it is undesirable to allow user access to your backbone trunks. By doing so, the path quality is degraded. Recommended default for a VHF/UHF user accessed radio link is 100 with the "reliable neighbors" permed to 192. (Range: 0-255) 4. Path quality assigned to RS-232 channel 1. As noted above, this parameter is assigned higher path quality numbers. Values typically run from 255 for one TNC down to 245 for several TNCs matrixed together on a node stack. Here is a good place to point out the significance of the numbers seen in a ROUTES display. For example: CLAMS:WA1ZDA-3} Routes: 0 ME220 150 16 1 PENBAY 255 15 1 LOBSTR 255 15 The 0 and 1's seen in the left column correspond to the port identifiers listed in parameters 3 and 4. The 0 means it is a radio port and the 1 is a RS-232 TNC port. The next column is the default settings (in this example) for parameters 3 and 4. Here we note the NodeOp has determined the radio path to ME220 is not a good "standard" 192 quality path and therefore has assigned it a value of 150. If he had other neighbor nodes that WERE a good 192 quality path, he would set his parameter 3 to 192 and then use the ROUTES locking technique (discussed above) to set the ME220 node to the 150 value. Though not pertinent to this discussion, the final column indicates the number of destination routes through that path. (Range: 0-255) 5. This is the initialization value for the obsolescence counter. The counter displays how current a path is to a destination node. Your node keeps track timewise of all nodes heard during neighbor broadcasts. By convention, this counter value is normally defaulted to "6". If for some reason (QRM or node failure) a known node is not heard upon receipt of the next neighbor broadcast, the obsolescence value for that node is decremented to "5". If not heard at the next broadcast, it goes to "4", etc. Once the value goes to "0", knowledge of that node is removed from the NODES table. But if the node IS heard before the value falls to "0", it automatically is reassigned a "6". By 18 comparing the broadcast timer value in parameter 7 against the obsolescence count, one can calculate how "fresh" a path is. This technique is used to analyze results from a "N <alias or callsign>" command: HEBO:W7XI-8> Routes to #HEBO:W7XI-7 255 6 1 #HEBO 254 6 1 #HEBO4 Here, the first column is path quality, the second is the obsolescence count and the third is the port, either 0 or 1. As would be expected for a direct RS-232 wire type connection between (in this case) 3 TNCs, the obsolescence count is "6" thus indicating a high probability of success in making a connect to #HEBO. Another example: CLAMS:WA1ZDA-3> Routes to LEW:KQ1L-1 > 190 6 1 LOBSTR 189 6 1 PENBAY 149 5 0 ME220 We note several things here. First the activity arrow indicates someone has either attempted or has satisfactorily used this path within the past 15 minutes. LEW is not a neighbor node. Otherwise LEW would show in the routes listing. We see the path to LEW is through LOBSTR. From this we know LEW is not on CLAMS frequency since we observe LOBSTR is RS-232 connected to CLAMS, as indicated by the "1" in the ports column. The obsolescence count (6) is good and the path quality in column 1 is high, so all indications are positive for a good connect to LEW. Before leaving parameter 5, we should make note that some NodeOps set this parameter to an abnormally high value of 12. Since the whole purpose of the obsolescence counter is to decrement out stale or useless nodes in a reasonable time, a higher value than 6 would seem to be counter to good network management practice. If the broadcast timer set by parameter 7 goes off every hour, then a failed node could be retained in the NODES list for 12 hours should parameter 5 be set for 12. On the other hand, some NodeOps set this parameter at 3 or 4. They do this to expedite the removal of unwanted nodes temporarily brought in by propagation conditions. (Range: 0-255) 6. Sets a limit on the minimum obsolescence value associated with other nodes to be included in the NODES broadcast. For instance if your node has not heard from the CARBON:VE6RCB node for 3 or 4 broadcast periods, the likelihood is high CARBON has failed. Thus it is good network practice to avoid sending out useless node data. This is the function of parameter 6. The default is "5", but some NodeOps recommend "4". (Range: 1-255) 19 7. Broadcast timer interval in seconds. Older nodes defaulted the broadcast time to 1 hour (3600 seconds). This is satisfactory under stable propagation conditions. Where paths may be subject to change, a value of 30 minutes (1800) is preferable. Whatever value is set, it should be the same as that of the neighbor nodes. Otherwise it is apt to adversely impact the operation of some of the previously discussed parameters. In other words, indicate poorer paths then what really exists if set for a shorter time interval than the neighbors. The opposite is true if this timer is set for longer periods. It may indicate good paths that in reality have gone away. (Range: 0-65535) 8. Time to live initilizer. Sets the number of hops through the system a frame from your node will remain active. The default of 32 works fine. (Range: 0-255) 9. Transport layer timeout timer. The recommended default of 180 seconds works good here. It gives an adequate margin for congested networks. (Range: 5-600) 10. Maximum transport layer tries. If a known path fails, the node will retry for a number of times equal to the product of Parameters 10 and 20. Recommended default is 3. (Range: 2-127) 11. Transport layer acknowledge time. Default is 3 seconds, some feel up to 10 seconds for a 1200 baud channel might be useful. (Range: 1-60) 12. Transport layer busy delay. The default of 180 seconds here has proved satisfactory. (Range: 1-1000) 13. Transport layer window size (MAXFRAME). A value of 4 is satisfactory. (Range: 1-127) 14. Congestion control threshold. Default of 4 works fine. (Range: 1-127) 15. No-activity timer. Default of 900 seconds (15 minutes) is good. This timer sets the life of the activity arrow. On version 2.05 and later also sets the life of the node STA light following the last user disconnect. (Range: 0-65535) 16. P-persistence setting of 64 is recommended. (Range: 0-255) 17. Slot time. Defines the "slot time" length in 10 ms increments. A value of 10 (100 ms) is recommended when Parameter 16 is set to 64. (Range: 0-127) Parameters 16 and 17 work together to set up a random delay determining when the node will key up following a DCD decision that the channel is clear. This is an anti-collision technique. When the node is ready to transmit, a number between 0 and 255 is internally generated. If this number is equal or less than the value set by Parameter 16, the node keys immediately upon sensing a clear channel. If the internally generated number is greater than the value of Parameter 16, the node waits for a period of time equal to the slot time and then internally generates a new number, etc. A value of 64 is 25% of 255 and 20 thus sets the percentage of time the node will immediately keyup. Protected trunking nodes (those with only one transmitter on their receive frequency) would have faster thruput if there were no node keyup delay. Setting parameter 16 to a value of 255 will accomplish this. 18. Link timeout (FRACK) default of 6 seconds is satisfactory. (Range: 1-15) 19. Link layer MAXFRAME default: VHF = 7, HF = 1. (Range: 1-7) 20. Link maximum tries of 7 has proven satisfactory. (Range: 0-127) 21. Link timeout timer default value of 100 ms is good. (Range: 0-6000) 22. Link T3 timeout timer (CHECK). The older default of 18000 (10 ms increments), or 3 minutes, caused a poll packet to be sent after that duration of no activity. Can be set to 0 to avoid some link overhead due to polling. Default is 0. (Range: 0 - 65535) 23. Digipeating. If this function is ENABLED (1), it allows users to subvert the normal network flow by assigning priority to the digipeating station. The default of DISABLED (0) is recommended. (Range: 0-1) 24. Validates callsigns is recommended to be ENABLED (1). If DISABLED (0), the chance exists that someone could float obscene words as callsigns through your node. Also, a distant user upon mistyping a C <alias> command, will have to wait for a period of time dictated by Parameter 20 plus network propagation delay before being informed of a failure. If ENABLED, he would only have to wait for the period of network propagation delay before getting an "Invalid callsign" response. In some cases, this could save the distant user 10 to 15 minutes. If the NodeOp is desiring to allow users to downlink to KA-node aliases, possibly these aliases could be named so they will satisfy the callsign verification criteria, i. e., no more than 6 characters with one number included. For example: CDXB0X (note the zero in "B0X"). Callsign validation ENABLED also prevents those who forget to install their callsign into the TNC from uplinking to the node. The node response to a NOCALL is "Node busy". Default is "1". (Range: 0-1) 25. Station ID beacons can be either ENABLED (2), CONDITIONAL (1), or DISABLED (0). Since the node IDs with each user packet, many NodeOps DISABLE this feature (0) to help reduce LAN congestion. When enabled (2), the node IDs every 10 minutes. CONDITIONAL (1) IDs 10 minutes after last packet. Default is "0". (Range: 0-2) 26. CQ broadcasts ENABLED (1), DISABLED (0). Disabling this feature means the CQ user text will not be broadcast by the node. The CQing user will still be able to be seen by someone doing a USERS command during the time the CQ is active. Default is "1". (Range: 0-1) 21 27. Host Mode connects ON (1), OFF (0). When a NodeOp has a terminal connected via the RS-232 Host Interface, ON (1) will allow users to connect to him IF he is not actively connected to the node at the time. Off (0) prevents users from connecting. (Range: 0-1) 28. Heard list length. Sets the maximum limit on the number of stations that can be listed in the Heard table. Default is 20. (Range: 1-20) 29. Node radio TXD is adjustable in 10 ms increments. Allows NodeOp to better match his node radio's T/R response time for more efficient thruput. Default is 30. It should be noted 300 ms is equal to .3 seconds. .3 X 1200 baud = an off the top node thruput reduction of 30% thus cutting the effective rate to 840 baud. From this real world example, we see why selection of a node radio with a fast T/R switch (and oscillator settling times) is important. The default of 30 is specified as most radios will switch within .3 seconds. However many radios will switch faster and the NodeOp should experimentally determine and set TXD for the shortest time. (Range: 0-255) 30. Full Duplex ON (1) or OFF (0). Default is 0. (Range: 0-1) 9. NETWORK MANAGEMENT (PARAMETERS 2 & 25) Back in the days when our packet network was just getting started with the new netnode technology, nodes were sparsely located and network traffic loading was very light. The original netnode chips had default values which encouraged a large number of nodes to accumulate into the NODES broadcasts. In early times, it was not unusual to make direct connects to a DX node appearing in your local NODES table. Indeed, Parameter 8, the "Time to Live" parameter was defaulted for an optimistic value of 64. (Parameter 8 being set to slightly higher than the maximum number of hops to which you could make a direct connect). A packet network shares its channels with all types of users, plus it has to share the channel with node-to-node housekeeping packets. The TheNet technology is an automatic adaptive concept. This allows the nodes to automatically "remember" who their neighbors are and adapt to changing network conditions. The price for this is a certain amount of overhead, which competes with user packets. NodeOps are of course proud of their node efforts and it gives them pleasure to see a large number of nodes listed on their local NODES table. However, if we analyzed the PROBABILITY of a user connecting to a listed DX node, we would probably find the odds to be very remote for making a direct connect to it! Again, the reason for this is due to the huge increase of USER traffic as well as a big increase of additional nodes, with an attendant increase in the number and size of housekeeping broadcasts. We NodeOps no longer have the luxury to set our node parameters so as to gather as large a node table as possible! Some people estimate the TheNet node overhead is on the order of 35 percent of the total network loading! Every time a USER requests a NODES dump, it takes away a certain amount of the resource from other USERS. Large node broadcasts are sent every 30 minutes or so, back and forth to other nodes within the network. This, too, takes away a 22 certain amount of the resource. Node ID packets every 10 minutes takes away a small portion of the resource. On an individual node basis, this overhead may seem like a small thing. but when it is spread all up and down our "party line" simplex node network in conjunction with all of the other nodes doing the same thing, it IS significant! NodeOps can (and should) help this situation by limiting the maximum size of the NODES table to a value slightly larger than the number of hops a user can REALISTICALLY direct connect to. This can be determined experimentally by attempting direct connects to the DX nodes listed in the table. For instance, if we discover we can only make 4 hops consistently, we can calculate the Parameter 2 value necessary to allow this. Parameter two is a "filter" which in effect, establishes a limit to the number of distant nodes OUR node will recognize in its NODES table. We can calculate the value with which to set Parameter 2 for a 4 node direct path over a 1200 baud user circuit as follows: .75 x 192 = 144 x .75 = 108 x .75 = 81. (Refer to the chart listed under the section on NODE PARAMETERS, Parameter 3.) This tells us the path quality to a node separated 4 nodes away is 81. We can then set Parameter 2 to a value of 80 and know that nodes further than this path value away, will not be picked up in our NODES table. If NodeOps were to universally cooperate in realistically analyzing our local networking conditions and set Parameter 2 accordingly, it would make a significant reduction on network overhead! Another simple thing that can be done to relieve unnecessary overhead is to TURN OFF the 10 minute node IDer, Parameter 25. There is no legal requirement for a 10 minute node ID since the node IDs itself every time it's activated by a USER. When we NodeOps install our nodes we become, in effect, part of the network management team. It is incumbent upon us to facilitate thruput as much as possible by careful attention to our node parameters. Experience has shown most of the existing parameter default values work quite well. Circumstances, however, may require some careful tuning and its hoped this provides some insight on setting up Parameter 2. 10. ROUTING LOOPS When TheNet receives a command instruction to connect to a destination node, it will attempt to set up a circuit via the path it has determined has the highest path quality listing. If this results in a timed out connection, it then will attempt a connect via the next best route. If this attempt also fails, the node will attempt a third path if one is listed. Sometimes a primary route may experience temporary failure. A node receiver down the line may be subject to interference or desensitization, etc. for a period of time. If this occurs while a connect request is in progress, it is possible your local node will time that circuit out and attempt a connect on the next best route listed. If after a time you note an unusual delay in having your connect request processed, disconnect. Then, reconnect to your 23 local node and do a "N <destination nodecall>" command (where destination nodecall is the alias of the destination node you just attempted a connect to). Notice the position of the activity arrow on the resultant response. Chances are, the activity arrow will indicate an attempt is being made via a "routing loop" path. A path that has a "0" path quality, or perhaps to a path that leads elsewhere. As long as the activity arrow is pointing to an unconnectable path, there is little one can do but wait until the internal timer "resets" (usually 15 minutes following the last connect request for that particular node). Then if the circuit is clear, one should be able to make a connect via the primary path. 11. DUAL-PORT OPERATION This is the method TheNet nodes use to network (gateway) from one frequency to another. Two TNCs are interconnected via their RS-232 ports. A radio connected to one TNC is on frequency "X" and a radio connected to the other TNC is on frequency "Y". Packet traffic intended for nodes on one frequency or the other will automatically be routed to their destination. To prepare for gateway operation you need to make sure both TNCs have the proper modifications, as discussed below. You also need to make sure both TNCs are functional and are working as nodes. Prepare the special RS-232 cable wired as indicated in the diagram. Attach the radio cable to your TNC (you will have to provide the custom connection to your own radio). Set the audio level to properly modulate your radio (On VHF, MAXIMUM deviation should be no more than 3 KHz, with between 2 and 3 KHz being optimum). To set the audio transmit levels, you can exchange the node chip with the TAPR firmware chip (make sure you take static electricity precautions) and place the TNC into the COMMAND MODE (Control C) and type CALIBRA <ENTER>. If you then type a K, the TNC will put out a continuous tone for about 12 seconds. To change to the other tone pair frequency, hit the space bar. Within the 12 second keyup period, hitting the K key again will unkey the TNC. To get out of the CALIBRA mode, type Q. The audio gain control is R-76 and is the fourth miniature blue control on the right (looking from the front of the TNC) of the group of 4 potentiometers. Once the transmit audio level is correctly set, CAREFULLY replace the node chip. It may be that the TNC transmit audio level already matches that required by the radio. If that is the case, the above procedure would be unnecessary. In any event, this procedure would not be required on a HF SSB radio, as you simply adjust the mic gain for desired power output. Make a connect to a distant station or two to verify the node and radio are working properly. At the rear of the TNC is a dip switch that sets the baud rate for both the terminal and the radio. For interconnected TheNet nodes the baud rate is 9600. The VHF/UHF radios of course are set for 1200 baud. This means that switches 5 and 7 will be ON, all others OFF. Connect the special RS-232 cable between the two TNCs. Connect the radio port cables to the appropriate radios. Turn on the TNC power and you should see the red lights flash on, then off, except for the power light which stays on. 24 It will take anywhere from 30 minutes to an hour or two for your nodes to "initialize" to each other and for the gateway to be operational. This is because each node is waiting for a broadcast from the other before each is recognized. The nodes will broadcast 30-60 minutes after being powered on. If for some reason there is activity on the node at the time of broadcast, it is possible this activity might interfere with reception of the broadcast and therefore it might take one or more 30 minute periods before the two nodes fully recognize each other. Meanwhile, your nodes may recognize other neighbor nodes in the area sooner than they do each other as it is all dependant upon the timing of their broadcasts. But until both of your nodes recognize each other, the gateway will not work. You should perform the VHF DCD modification to your node TNC. This allows for quicker transmit - receive response and also helps to avoid collisions. You can leave your VHF radio unsquelched for even quicker response, if you want. The TNC should only key up on valid packets, rather than noise. If you plan on HF node/gateway operation, then the HF DCD modification should be done to the HF TNC. This gives the same benefits as the VHF mods, but is more elaborate. It has a THRESHOLD control which needs to be adjusted to harmonize with your IF filter in the HF radio. Rather than cut up your TNC, you can insulate the threshold control by wrapping it with tape and leaving it inside the TNC, once adjusted. Proper adjustment to HF is to tune your receiver to a quiet channel just receiving noise. Adjust the THRESHOLD control until the DCD just occasionally flickers. You can either leave it there, or back off slightly from that point. This will be the optimum THRESHOLD range and, once set, should hold true. The setting of this adjustment is dependent on the broadness of the IF filter in your radio. If you change radios with different IF filter characteristics, or switch to different HF bands, the control may need adjusting. But for fixed frequency node work once set, it should not need further adjustment. If later on you decide to use the TNC on VHF, it will work fine. You may need to crank the THRESHOLD all the way to the clockwise position to optimize its setting. Even there, the DCD light may not flicker on noise, but this is not unusual since the setting is a function of the VHF radio's wider IF filter response. One additional caution: be sure to ohm out the TNC to radio port connections in the cable that comes with the TNC as quite often the connections and the color coding specified in the TNC manual is incorrect! RS-232 dual node cable diagram Frame ground - 1 <--------------------> 1 - Frame ground Transmit data - 2 <-------. ,---------> 2 - Transmit data \' Receive data - 3 <--------' `---------> 3 - Receive data Signal ground - 7 <--------------------> 7 - Signal ground Neg test voltage -10 <---, ,---> 10 - Neg test voltage | | Data rate select -23 <---' `---> 23 - Data rate select 25 The above information should be sufficient to get the dual gated nodes up and running. 12. MULTI-PORT OPERATION Multiple TNCs and radios can be interconnected to form a "node stack". A diode matrix is used to route the signals in proper sequence between the TNCs. Interconnecting more than two TNCs does decrease the thruput since the circuit is no longer operating full duplex. Diode matrix node stacks of up to 14 TNCs are in operation. Shown is a four TNC matrix circuit. For more than four TNCs, the circuit is appropriately expanded. RS-232 Four Matrix Note: On the DB-25 connectors, all pin 1's are connected together as are all pin 7's. On EACH DB-25, pins 10 and 23 are jumpered together as are pins 4 and 20. |-->|-- C2-2 |-->|-- C2-5 Connector 1-3----|-->|-- C3-2 Connector 1-20----|-->|-- C3-5 |-->|-- C4-2 |-->|-- C4-5 |-->|-- C1-2 |-->|-- C1-5 Connector 2-3----|-->|-- C3-2 Connector 2-20----|-->|-- C3-5 |-->|-- C4-2 |-->|-- C4-5 |-->|-- C1-2 |-->|-- C1-5 Connector 3-3----|-->|-- C2-2 Connector 3-20----|-->|-- C2-5 |-->|-- C4-2 |-->|-- C4-5 |-->|-- C1-2 |-->|-- C1-5 Connector 4-3----|-->|-- C2-2 Connector 4-20----|-->|-- C2-5 |-->|-- C3-2 |-->|-- C3-5 This circuit requires 24 small signal diodes, such as 1N914's, four DB-25 male connectors, a supply of small various color coded wire and a small piece of perf board on which to mount the diodes and interconnecting wires. The circuits are wired in sequence. For Connector 4, for instance, pin 3 is wired to the anode side of three diodes in parallel. The cathodes go to Connector 1, pin 2, Connector 2, pin 2 and connector 3, pin 2. Connector 4 pin 20 is connected to the anode of three diodes in parallel. The cathodes go to Connector 1, pin 5, Connector 2, pin 5 and connector 3, pin 5. The wire bundle going from each of the DB-25's to the perf board can be any length you prefer, but possibly 16 inches would be adequate. After the circuit is wired, use an ohm meter to check continuity on each circuit. As in the dual port configuration, make sure all TNC's are set for 9600 baud on their RS-232 ports. Following power up it will take from 30 - 60 minutes for the adjacent node broadcasts to "wake" them up. For information on a commercially available 8-port diode matrix board, send a SASE to: NorthEast Digital Assn, PO Box 563, Manchester, NH 03105-0563. 26 Provided on the distribution diskette is either a hex or a binary image of TheNet Plus. We are also providing a simple utility which can allow you to custom tailor your node's callsign, SSID, parameters and password to any value that suits you. If you are thinking of purchasing an EPROM programmer, we have found JDR Electronics has a suitable model at low cost. But from whatever source, specify one that will handle CMOS chips. You will also need an inexpensive EPROM eraser and these are available from a number of dealers. In keeping with the high standards set by the Nord><Link people, the production of TheNet Plus is placed in the public domain with the understanding it is NOT to be used commercially. We only ask that you share this material with like-minded individuals. 73 and enjoy! Bill Beech, NJ7P Jack Taylor, N7OO 27 APPENDIX A. ============================================================================== TO LOCK OR NOT TO LOCK By Mark Marston, KA1NNN "But the book says to avoid locked routes at all costs" This statement is heard over and over again. Yes, the book does say that, but what that means and what most people THINK it means are two different things. The manual used similar sounding phrases to define two VERY different areas. To explain this clearly, we must start at the basic structure of Node operation. PART 1: BASIC NODE STRUCTURE NETROM/TheNet maintains two tables of information. One is called the Route Table and the other is called the Node Table. Let's look at the function of the Route Table first. The Route Table is used for calculations of INCOMING BROADCASTS ONLY!! I can not stress this enough! The route table has ABSOLUTELY NOTHING to do with out-going routing, or broadcasts. The route table's sole purpose is to define which Nodes can be HEARD DIRECTLY and what "quality" to assign to them and for "quality" calculations of their broadcasts. That is ALL! Incoming information ONLY! More on the route table in a moment, but let's define the Node Table. The Node Table contains a list of all the Nodes that routing information is available for. This information is received by "Routing Broadcasts" made by the nodes which are heard directly. (i.e., From nodes listed in the Route Table). Now here is where it gets confusing. Each Node Table Entry contains 1 to 3 "choices" to try to reach the ultimate destination. These "choices" are nodes that are heard directly (i.e. Again the definition of the Route Table). NOTICE that the entire path to each node is NOT stored, rather packets are "pointed" step by step to an adjacent node until the final destination is reached. A mathematical formula is used to determine the order of the available choices and the best (highest "quality") route is placed at the top of the list. The term "quality" is somewhat misleading as it has nothing to do with a routes ability to pass data. Quality values are used to sort the order of routing choices to maintain a logical routing flow from node to node. To summarize: Each Node Table Entry contains the Name and Callsign of the Node, and a list of 1 to 3 routing choices. These "routing choices" MUST be adjacent nodes... Nodes which can be heard directly...Which leads us to one of the Rules for NETROM/TheNet. "There is ALWAYS a corresponding Route Table Entry for any Routing Choice in a Node Table Entry." 28 NOTICE THE TERMINOLOGY! A "ROUTE TABLE ENTRY" is NOT the same as a "Routing Choice" in a "NODE TABLE ENTRY". This is where most people got confused in the manual. They refer to two separate entries in two separate tables. Now that we have defined both the tables used in the Nodes, lets look at how each table is used. "Broadcasts and the Route Table" When a Node makes a Routing Broadcast, it broadcasts the following info: The Name and Callsign of the node making the broadcast. And for each Node it has in its Node Table: Its Name, Callsign, Top Routing choice, and quality of that Routing choice. When that broadcast is received by another node, the receiving Node checks its ROUTE TABLE for the callsign of the node making the broadcast. If it is found, the Node will calculate all of the broadcast information received using the ROUTE TABLE quality value assigned to the broadcasting Node. If it is not found, a ROUTE TABLE Entry is CREATED AUTOMATICALLY and given the DEFAULT quality value. The Node then proceeds to calculate all the broadcast information using this default quality value. Thus the ROUTE TABLE may be used to "scale" the qualities of routing information received from a particular Node. This often needed when there are 2 or more paths that are mathematically equal, but in reality, there is a preferred path. By decreasing the quality of the less desired paths or increasing the quality of the preferred path in the ROUTE TABLE, you can modify the Routing Choice Order in the Node Table since they are always placed in numerical order highest to lowest. "Broadcasts and the Node Table" The Node Table is the sole source for broadcast information. Nodes make their broadcasts at periodic intervals. For each Node Table Entry the top Routing Choice is broadcast. The second and third choices are never broadcast. If a Routing Choice Quality is zero, it is not broadcast. When broadcast information is received from another node, a "counter" in each Routing Choice is refreshed to show how current the information is. If routing information for an existing Node is not received in the broadcast of a Routing Choice, the "counter" on that Routing Choice is decremented by 1. If the counter reaches 0, that Routing Choice is deleted from the NODE TABLE ENTRY. If other Routing Choices remain for that Entry, then the Entry is retained in the Node Table. If ALL the Routing choices for a Node Table Entry are eliminated, the Node Table Entry ITSELF is deleted from the NODE TABLE. In this way, Nodes dynamically reflect the operational status of other Nodes. If a Node goes down, it no longer makes broadcasts, the counters in the Routing Choices that point to the failed Node decrement - finally reaching 0 - eliminating that Node and any routes thru it from the Node Tables in the network. 29 One last point that concerns the ROUTE TABLE. When a Route Table Entry has NO corresponding Routing Choices ANYWHERE in the NODE TABLE (due to the Node Table's elimination of the Routing Choices as described above) the Node will determine the ROUTE TABLE Entry to be unnecessary and will delete it from the ROUTE TABLE. If that Route becomes active again, the Node will create a Route Table Entry as if it were a new, unknown Node and it will be given the default quality value. This concludes the basic structure of NETROM/TheNet Nodes. Now we have our terms straight (ROUTE TABLE Entries and Routing Choices in NODE TABLE Entries), let's get back to the original question. PART 2: Locked NODE Table Entries and Locked ROUTE Table Entries Ok, first back to the book that says "Avoid locked Routes at all cost": Let's rephrase that with our terminology, "Avoid locked Routing Choices in NODE TABLE ENTRIES at all cost". Further reading under that paragraph will reveal that they were referring to Node Table Entries, which has nothing to do with ROUTE TABLE entries! The book goes on to say that locked NODE TABLE routing choices will defeat the dynamic routing abilities of the Node. A locked NODE TABLE Routing choice will never be deleted by the Node and is broadcast on every broadcast cycle. The route could be completely dead but a locked routing choice will be broadcast regardless. It certainly sends potentially false information to the other nodes. There are exceptions of course, one the book mentions is a (yuk) digipeater path to another node. This must be manually placed by the node SYSOP as broadcasts can not be made thru digipeaters - therefore information about a node thru a digipeated link would never be received. There are some other exceptions that may come up but the BEST rule of thumb is: Try to solve routing problems by manipulating quality values in the ROUTE TABLE to scale the NODE TABLE Routing Choices in the right order for your needs and use a locked NODE TABLE Routing Choice as the last resort. Ok, now on to my pet peeve. Locked ROUTE TABLE entries. Remember this has NOTHING to do with the NODE TABLE and it functions. A LOCKED ROUTE TABLE ENTRY DOES NOTHING MORE THAT TO PREVENT THE ENTRY FROM BEING DELETED WHEN THERE ARE NO USES OF IT IN THE NODE TABLE!!! The manual suggests a use for the locked Route Table Entry. They say if you run into a situation where a Node can hear a Node but can't talk TO it, (i.e. a one-way path) they suggest placing a locked Route Table Entry with a quality of 0. This forces the Node to ignore all information received from that node - thus it never tries to communicate with it as there are never any entries established that point to it. Right idea guys, but they got it backwards. Here's why. 30 PART 3: R O U T E S E C U R I T Y Most of the locals are tired of hearing me repeat this point but I see many systems that don't employ route security and as a result, their systems suffer. I am referring to Node's worst enemy - LIFTS! Nodes are stupid. They have no judgement of realistic paths. If a lift condition allows a Node in Maine to hear a Node in New York, with the default parameter settings, the Node will assume if you can hear it, it must be a neighboring Node. It will make entries for the "Lift Node" and all of the Nodes it knows of. You can easily wake up some morning and find your network FULL of nodes that you never HEARD of!! What's worse is LIFT NODES DON'T WORK! Oh, they may connect, you might even get a packet or two passed. But Lifts are unstable and retry after retry will be spent trying to reconnect to that Lift Node. PLUS the system will thrash round and round ENDLESSLY if users see all these new nodes and try to connect to them. Your valuable airtime will be chewed up by packets going round and round the local nodes trying to find the path back to a node that got its signal heard on a Lift. "Well lock that node out! Right?" Wrong. Oh, that works for that Node on that day, but what about the Node in Rhode Island that comes in tomorrow? "Ok, lock him out too"..but the network has had to suffer the damage..it can take hours for "Lift Nodes" to completely dissolve from a network. So what are you going to do? Place a lockout entry for every Node on your frequency for a 750 mile radius? The Route Table would be hundreds of entries long and that would only cover the nodes you KNOW about! What about the ones you didn't hear about or the new one that goes in next month? There is no end to the mess that can happen to routing if your network does not have security to protect itself from this danger. There is simple solution. Like I said above, right idea but backwards. Pick Your Neighbors! Rather than to Lock OUT the Nodes you don't want, Lock IN the ones you do! These simple steps will give you total security and keep your network running smoothly. 1) Pick your real true neighboring Nodes from the ROUTE TABLE and lock them in at the recommended default quality (192 for 2m, 224 for backbones) 2) Reduce Parameter 3 (Default radio link quality given to new nodes) to a value EQUAL to Parameter 2 (Minimum quality to accept) Here is how it works. Your real neighbors have the full quality value assigned to them. Nothing changes there, but by reducing parameter 3 to the same level as parameter 2, NEW Nodes that are heard are given a quality on the threshold of acceptance. This means that the NEW NODE making the broadcast will have its name and callsign entered into the NODE TABLE, but all its other broadcast information will have qualities too low to be accepted. So only the node itself will be allowed into the NODE TABLE and NONE of the associated routing. Because the Node is on the threshold of quality acceptance, it won't spread to other Nodes because its quality will be degraded to a point that will fall below other Nodes minimum quality accepted value. This allows you to examine the NODE TABLE to see if a Node has heard something new without having 31 it crash in on your network before you can decide whether it should be a real path, or just a temporary "Lift Node". The reason for "Locking" the qualities of your real proven neighbors, is to preserve their quality rating as true neighbors. If one of your true neighbors goes down, IT WILL BE REMOVED FROM THE NODE TABLE!!! when the counters reach 0 but we don't want the automatic ROUTE TABLE deletion to occur when all the NODE TABLE Routing Choices have been deleted. If that happened, when the Node came back, the NETROM/TheNet code would think that it was a "NEW" Node and give it a low quality. Thus the rest of the network wouldn't know it was back in service, since the quality level wouldn't allow it to be spread as it should be for a true neighbor. Locking the ROUTE TABLE Entry will allow the Node to disappear from the NODE TABLE without having the ROUTE TABLE entry disappear as well. Then when the Node returns, its quality as a true neighbor is preserved and will return to the NODE TABLE at full quality. Remember, we are talking about locking the ROUTE TABLE ENTRY not the Routing choices of the NODE TABLE ENTRY. They are two different things! IT IS IMPERATIVE that you force your Nodes to use the correct paths...your true neighbors. Picture this: If a Node on one side of the state suddenly hears a Lift signal from a Node on the other side of the state, without route security, your entire network routing structure will be destroyed as the Nodes in between will suddenly reverse their routings back to each side of the state, splitting down the middle and pointing in OPPOSITE DIRECTIONS from the normal flow, as they try to use this "shortcut". The network can thrash for hours until the flood of broadcasts finally reverts things back to normal. Route Security can save YOUR network from this disaster! It should be noted that if the default quality for radio links (parameter 3) is set to a value BELOW the minimum to accept (parameter 2), it will LOCK OUT ALL NEW NODES from entering the NODE TABLE. In this way you can prevent users from even attempting to connect to a "Lift Node". Even if "Lift Nodes" are contained to the receiving Node, and none of their routings are accepted, attempts by users to connect to the "Lift Node" can cause that Node to "thrash" as it attempts to communicate via the Lift conditions. Due to the time delay involved in purging Nodes, the Lift could have been dead for some time before the NODE TABLE Entry is deleted. Partial contact is worse that no contact as it keeps the Nodes retrying as an occasional packets gets through. Therefore, during periods when Lift conditions are present, it may be desirable to prevent ANY new Nodes from entering using this method. ROUTE SECURITY is the only way to insure healthy routing for your network! I hope this helps to explain the differences in the NODE TABLEs and in Node Management Options. If anyone has any comments, questions, or suggestions, please direct them to KA1NNN @KA1NNN.ME.USA.NA Happy Networking! 73 Mark Marston KA1NNN Network Manager N.E. 145.03 32