                           TheNet X-1J release 4.
        
                            Overview of Operation
        
1. INTRODUCTION
        
     This  paper  introduces  the main features  of  TheNet  X-1J 
     release  4.  This  is an update to  the  previous  paper  on 
     version   X-1J2,  and  incorporates  a  number  of   changes 
     including the following : 

     * The buffer loss problem has been fixed
     * The ARP table is automatically updated from ARP requests & 
       replies
     * The node maintains a second heard list of L3 Netrom  nodes 
     * that gateway through the node
     * The RxDeviation & Smeter ADC channels may also be used  as 
     * arbitrary inputs instead
     * A  bug in the copying of digipeated frames in KISS mode  2 
       has been corrected
     * A defensive port flush function has been added
     * Link  list integrity checking has been  extended to  check 
       reverse links
     * A bug in handling of BBSALIAS, HOSTALIAS and DXCALIAS  has 
       been fixed
     * The  USER  list shows circuit choke status  for  patchcord 
       connections.
     * The ADC* text messages may be up to 12 characters long
     * BBS, HOST and DXCLUSTER are cleared properly on cold start
     * The  ACL for incoming L4 circuits checks the user callsign
       as well as node callsign
     * A default route entry may be made for the IP router
     * Lines that start with '#' are ignored by the switch

     The  software is a derivative of TheNet 1.01 by  NORD><LINK. 
     Additional commands and bug fixes have been included in  the 
     release.  In addition, the Patcher has been upgraded  and  a 
     bug  fix  to  MOTOROLA.C attributable  to  KH6ILT  has  been 
     included.  A utility to create remote reconfiguration  files 
     by N8PTT is included. My thanks to K4ABT, KA2DEW and  WB4DDP 
     to  name but a few for assisting with  ideas,  encouragement 
     etc.  Credit  is also due to John Bednar,  WB3ESS,  for  the 
     SETHELP  utility and Al, WB0YRQ, for the  MFJ1278C  details. 
     The  file describing how to set up a node stack so that  all 
     or   a  subset  of  the  nodes  share  one  IP  address   is 
     attributable to Fiona, G7ANH.
        
     If  your  reaction is 'What I really want is  ......',  then 
     please read on anyway, especially section 6.
        
        
2. STRUCTURE
        
     One  of the problems to extending TheNet is the 32  K  EPROM 
     limitation  imposed by the architecture of TNC2 clones.  The 
     solution  to  this is to implement bank switching.  For  the 
     BSX2  TNC and similar TNC2 clones, this can be  achieved  by 
     the addition of a single wire as detailed in the bank switch 
     modification  file. This is at the expense of the  HIGH  and 
     LOW   commands.  The  other  version  that  was   previously 
     available with HIGH and LOW in it is no longer supported  as 
     it is incompatible with the deviation meter.

     The PK96 version supports the specific hardware features  of 
     the PK96. Baud rates for the ports may be set by use of  the 
     BRATE command and the software automatically selects  either 
     the 1200 or the 9600 baud modem. This file covers mainly the 
     TNC2  version.  At  the end will be found  a  PK96  specific 
     section that describes the differences.
        
3. NEW COMMANDS
        
     The following commands have been added to the release.
        
           BYE
           BBS
           HOST
           STATS
           MHEARD
           MODE
           MANAGER
           AUDIT
           TALK
           CALIBRATE
           LINKS
           ACL
           CLOSEDOWN 
           BTEXT
           DXCLUSTER
           HELP
           CTEXT
           ALIAS
           BBSALIAS
           HOSTALIAS
           DXCALIAS
           QUIT
           IPROUTE
           ARP
           IPSTATS
           IPADDRESS
           IPBROADCAST
           UI
           MTU
           METER
           ADC
           ADC1
           ADC2
           ADC3
           ADC4
           ARPTIMER
           L3MHEARD
           BRATE ( PK96 only )
        
     The following commands have been changed
           
           CQ
           NODES
           RESET
           the <escape> commands
           SYSOP
           
     The following features have been added to the code
           
           An Internet Router
           Ability to respond to three additional aliases
           A CWID keyer
           The command processor has been extended
           KISS mode operation on the RS232 port
           HOST mode support on the RS232 port
           Remote configuration of all parameters
           Additional textual help messages
           Support  for  a 4 channel ADC used  for  measuring  RX 
           deviation, voltage and signal strength
           Other changes as detailed herein.
        
     In addition, a number of small changes have been implemented 
     to  satisfy the needs of specialist situations such  as  the 
     ability to digi beacon packets.
     
     Network  management  in  this context  does  not  just  mean 
     'setting parameters remotely'. It means the ability to  set, 
     read  and interpret various monitors and  diagnostic  tools. 
     Version  X-1C  included  the  first  part  of  the   network 
     management,  the  MANAGER privilege and the  AUDIT  process. 
     Version   X-1D   extends   the   auditing   and   statistics 
     significantly including internal CPU monitors. Version  X-1E 
     includes most of the additions that are planned, and version 
     2  will  complete  the functions. No  other  release  before 
     version  2  was planned, but the need to produce  a  version 
     with  an IP router prompted X1J. Before moving to the  joint 
     development,  I had agreed to finish off some long  standing 
     commitments  hence release 2 of X-1J.  Release  2  supported 
     TexNet, an S meter, ADC commands for the other ADC channels, 
     bug fixes, speedups and an enhanced command enable / disable 
     syntax.
        
3.1 BYE or QUIT
        
     There  are  no parameters to these commands.  When  entered, 
     they terminate the session. Both commands do the same thing.
        
3.2 BBS
        
     The syntax of the command is :
        
                       BBS [ * | ? | callsign ]

     With  no  parameter,  the  command  connects  to  a  station 
     previously   specified  by  the  sysop.  Setting   the   BBS 
     destination  is  done by the use of the BBS command  with  a 
     callsign  as  a second parameter. Setting the BBS  to  allow 
     this  may only be done by a sysop. The '*' option  may  also 
     only  be  executed  by  the sysop,  this  command  clears  a 
     previously specified BBS.
     
     The '?' option ( or any text if not sysop ), prints out  the 
     current BBS station setting.
     
     If no BBS is set, the command issues an error message if  it 
     is invoked with no other parameters.
     
     The  idea  of  this command is that,  like  with  the  'BBS' 
     command  of  the 'BPQ software, a user may  connect  to  the 
     local BBS from the node.
     
     The  BBS,  HOST and DXCLUSTER commands work by  copying  the 
     callsign into a buffer. The copy operation does not compress 
     the  SSID into a single byte however, so a callsign such  as 
     KA2DEW-15  would occupy 9 bytes. I had the buffers set to  8 
     bytes  length  max in versions previous to X-1J  release  2. 
     Sorry.
        
        
3.3 HOST
        
     The syntax of the command is :
        
                       HOST [ * | ? | callsign ]

     This command is very similar to the 'BBS' command. It allows 
     connection  to  a  local  host, BBS  or  other  server.  The 
     difference  however,  is that as long as the TNC is  not  in 
     'crosslink' mode ( i.e. pin 23 on the RS232 port is high  ), 
     and if a callsign is not set, the 'host' command connects to 
     the local port.
     
     The  idea  of  this command is that,  like  with  the  'BBS' 
     command  of  the 'BPQ software, a user may  connect  to  the 
     local  BBS,  another  node or server  from  this  node.  For 
     example,  if  a print server were connected to the  node  in 
     'host'  mode,  this command would allow connection to  it  ( 
     like  the  'connect' command with no other parameter  ).  In 
     KISS   mode,  setting  a  callsign  or  node  alias   allows 
     connection to another system.
        
3.4 STATS
     
     The  STATS command has no parameters. It prints a number  of 
     internal TNC statistics. In this version, this is limited to 
     the  level  1 stats of the radio channel  and  the  internal 
     clocks,  the level 2 ( AX.25 ), 3 and 4 statistics, and  the 
     CPU health checks.
     
     For level 1, six pairs of numbers are printed, corresponding 
     to the percentage of time the transmitter was on followed by 
     the percentage of time the receiver DCD was on, for each  of 
     the  last six 10 minute periods. The data is presented  most 
     recent period first. Two pairs of numbers are then displayed 
     showing the transmitter underrun and receiver overrun. These 
     are formatted as per the level 2 stats with port 0  followed 
     by  port 1 for the current hour followed by the  totals  for 
     the previous hour. In the case of the RS232 port,  underruns 
     are  not  possible, and an additional error ( framing  )  is 
     included.  The  RX  overrun includes  overruns  and  framing 
     errors.
     
     For level 2, the following are displayed :
           
           Frame checksum errors
           Total packets heard
           Total packets received by the node ( ie sent to it )
           Total packets sent by the node
           Total receiver not ready packets sent
           Total reject packets sent
           Total receiver not ready packets received
           Total reject packets received
           Total number of link timeouts
     
     For each of the level 2 statistics, four numbers are  shown. 
     The  first two are cumulative totals over the period of  one 
     hour, incrementing in real time. The last two are the totals 
     for the previous hour. Each pair of numbers is the total for 
     the  radio  port  followed  by the total  for  the  RS232  ( 
     crosslink ) port. 
     
     For  checksum  errors, port 0 shows CRC errors  and  port  1 
     shows  ( when in 'crosslink' protocol mode only ),  checksum 
     errors. As HDLC errors can be triggered by noise, acceptance 
     of  CRC errors is conditioned by the state of the DCD  line. 
     If DCD is on and an error is signalled, it will be added  to 
     the  count.  This  reduces the false counts,  but  does  not 
     eliminate them. Distant stations that keep the squelch  open 
     ( just ) without being properly heard will result in lots of 
     apparent errors.
     
     For level 3, the number of level 4 frames gatewayed  between 
     nodes is displayed.
     
     For  level  4,  the  number of  transport  frames  sent  and 
     received by the node are shown.
     
     For  level  3 and 4 statistics, two numbers are  shown.  The 
     first  is the number of frames accumulating for  this  hour, 
     and the second number is the total number of frames for  the 
     previous hour.
     
     For  CPU health checking, two statistics are shown, the  CPU 
     loading  and the buffer usage. Each looks like the  level  1 
     stats with 6 numbers corresponding to the last six 10 minute 
     periods. 
     
     The  CPU loading shows the number of times, divided by  100, 
     that  the CPU makes it around its basic internal  scheduler. 
     For a node just switched on, receiving nothing, this will be 
     about  470  ish for a 4.9 MHz clock. With lots of  nodes,  a 
     heard  list of 20 stations and 70-80% activity on the  radio 
     channel for it to listen to, this can drop to about  350ish. 
     If  it  drops  to  double figures,  worry,  as  the  CPU  is 
     beginning  to  thrash.  At low double figures,  the  CPU  is 
     pretty much working flat-out. Time to up its clock rate !.
     
     The  BUFFERS  statistic  shows the minimum  number  of  free 
     buffers  that  the software had available to it  during  the 
     last six 10 minute period. This indicates whether the TNC is 
     failing   to   deliver  data  passed  to  it   for   onwards 
     transmission, as well as how much data is backed up waiting. 
     Additional stats needed to analyse this properly are not yet 
     being collected.
     
     The  display  also  shows the elapsed time  since  the  last 
     warmstart  followed  by  the running  time  since  the  last 
     coldstart. Each number is the number of hours of operation.
     
     The final set of statistics shown are the port flush values. 
     These  are  reset on coldstart. The first parameter  is  for 
     port 0 ( radio ) the second for port 1 ( RS232 ). Each shows 
     the  number  of  port  flushes  that  have  happened   since 
     coldstart.  A port flush occurs when data is queued  pending 
     transmission  and cannot be sent. It is designed to  protect 
     node integrity when a channel is blocked ( for example by  a 
     fault  ). More specifically, for each port, the node sets  a 
     flag  whenever data is queued. It sets a flag when  data  is 
     sent.  Every  10 minutes it has a look at the flags  and  if 
     data  was queued but not sent, it sets an  internal  warning 
     flag.  If  the  warning flag was also set  in  the  previous 
     period  then  evidently data is building up and  nothing  is 
     being  sent.  It then purges the queue of pending  data  for 
     that port and increments the counter. This is not a  perfect 
     defence, but should usually suffice.
     
3.5 MODE
     
     This  command is similar to the PARMS command, and  includes 
     the new syntax described in section 3.32.
     
     It  allows a number of other features of the software to  be 
     configured  remotely.  It removes the need for most  of  the 
     host mode <escape> commands.
     
     The following parameters may be configured :
           
           The host mode
           The CWID send period
           The CWID keyer speed
           The port nodes broadcast control
           The crosslink / kiss control
           The Tx delay
           The full duplex flag
           The RS232 port node broadcast interval
           The node broadcast algorithm
           The beacon period
           The 'connect' redirector
           The  'help message enable' flags, case  sensitivity  & 
           TALK 8 bit flag
           The 'hash' node broadcast port control
           Whether the node will listen for the extra aliases
           Whether  remote disconnect causes reconnection to  the 
           switch
           Control over 'slime trails'
           Control over digipeating up/down links
        
     In operation, it behaves just like the PARMS command.
     
     The parameters are as follows :
        
3.5.1 Host mode control
        
     This parameter controls the 'host' mode. This is the mode of 
     operation of the RS232 port when pin 23 is 'high'
     
     The valid values are 0 or 1.
     
     In  mode  0,  the port operates as  per  the  standard  node 
     specification.  Mode  1 is designed to allow  connection  to 
     hosts  or  modems or similar equipment that expects  a  'CD' 
     type  of  signal  to signify that  an  incoming  /  outgoing 
     connection is called for.
     
     In  mode  1,  the <escape> C and  <escape>  D  commands  are 
     disabled and the other <escape> commands do not operate when 
     connected. Instead, hardware handshakes are used to  control 
     connections to and from the TNC.
     
     The TNC monitors pin 20 to determine the state of the  host, 
     and  signals state changes to the host with pin 5.  When  an 
     incoming  connect request is received ( by the  'c'  command 
     with  no  parameters  or by the 'host' command  ),  the  TNC 
     raises pin 5 to signal the connection and expects pin 20  to 
     change state in response.
     
     When  the host wishes to connect to the TNC, it  signals  on 
     pin  20 and the TNC responds with by changing the  state  of 
     pin 5.
     
     It handles disconnects in a similar manner. Either the  node 
     or the host may initiate disconnects.
     
     This  mode  is  experimental, changes may  be  made  to  its 
     operation. It is designed for modems, print servers or hosts 
     such as UNIX system TTY login drivers.
     
3.5.2 CWID control
     
     The next two parameters control the CWID keyer. 
     
     The  first parameter is the CWID repeat period  in  seconds. 
     Valid values are 0 to 3600. 0 disables it but do not set  it 
     below 120 apart from to disable it.
     
     The second parameter controls the keyer speed. Specifically, 
     it sets the number of 10 millisecond periods per dot and per 
     inter symbol delay.
     
     The  speed of sending is 120/n, so setting n to 6  gives  20 
     wpm. Valid values are 4 to 10, corresponding to speeds of 30 
     and 12 wpm respectively.
        
3.5.3 Node broadcast control
        
     This  parameter  allows control to be exercised  over  which 
     ports nodes broadcasts are sent. Valid settings are 0 - 3.
     
     Value  0 disables node broadcasts. Value 3 ( the  default  ) 
     works as normal. A value of 1 enables broadcasts on the HDLC 
     port  only  whilst a value of 2 enables  broadcasts  on  the 
     crosslink port only.
        
3.5.4 Crosslink / kiss
     
     This  parameter is used to set the  communications  protocol 
     used on the crosslink port when pin 23 is tied low.
     
     The valid values are 0, 1, 2 or 3 
     
     Mode 0 - standard crosslink protocol enabled
     Mode 1,2,3 - use KISS instead of crosslink.
     
     In  mode 1, KISS simply replaces the crosslink  protocol  In 
     mode  2, packets received from the radio part that  are  not 
     intended  for the node are copied to the RS232 port in  KISS 
     mode. Similarly packets received on the RS232 port that  are 
     not intended for the node are sent to the radio port.
     In  mode 3, all packets received on one port are  copied  to 
     the other port as well as being analysed by the node.
     
     These modes are not simply KISS implementations that replace 
     the node, they run with the node.
     
     Mode 2 is designed to allow a KISS application and a node to 
     share  a  radio without interference with  each  other.  The 
     point  is  that  the PC TCP/IP system can  be  switched  off 
     whilst leaving the node running to allow others to use it.
     
     Mode 3 is a debugging mode. One problem when faultfinding on 
     a  node  is that it is impossible to see what  the  node  is 
     seeing on the channel without replacing the ROM. By  setting 
     this  mode, it is possible to connect a KISS application  to 
     the RS232 port and observe what the node is seeing.
     
     Mode 3 is also designed to allow a PC running AXSTATS to  be 
     connected to the RS232 port to allow logging and analysis of 
     channel performance from the node itself. Note that  packets 
     initiated  by the node for one port will not get  copied  to 
     the other.
        
3.5.5 Tx keyup delay
     
     This   parameter  sets  the  TX  keyup  delay  in  10's   of 
     milliseconds.  This  was  previously done  using  an  escape 
     command.
     
3.5.6 Full Duplex
     
     This parameter sets or clears the full duplex control  flag. 
     This was previously done using an escape command.
        
3.5.7 RS232 nodes broadcast interval
     
     When a crosslinked TNC is reset, it takes some time to learn 
     about  the nodes that the other TNCs can hear.  Also,  nodes 
     heard  by  one TNC can take an hour to be  notified  to  the 
     others.
     
     In  order  to improve this, this parameter may  be  used  to 
     change the frequency of nodes broadcasts on the RS232  port. 
     When  set to 0, the node operates as normal. When set  to  a 
     non  zero  value, it will broadcast the nodes on  the  RS232 
     port  at that interval. Hence setting it to 600 would  cause 
     nodes broadcasts at 10 minute periods. The nodes  broadcasts 
     on  the radio port will continue to occur at the basic  rate 
     set  by  the PARMS setting. The obsolescence count  will  be 
     decremented at the basic rate, not at the faster RS232 rate.
     
3.5.8 Node broadcast algorithm
     
     This  value  controls the algorithm used.  Bits  within  the 
     value set have significance as shown below.
     There  is a problem with the nodes broadcast algorithm  when 
     many TNCs are crosslinked on RS232. In order to address this 
     a  variation  to  the algorithm  has  been  implemented  for 
     experimental purposes. Feedback on its use is requested. Bit 
     zero affects the HDLC port and bit 1 affects the RS232 port. 
     When  a  bit is set to 1, the node  broadcast  algorithm  is 
     modified so that it will not rebroadcast on the same port  a 
     node  heard on that port when the best quality neighbour  is 
     on  that port. It makes little sense to use it on  the  HDLC 
     port but what the heck, it is implemented for  completeness. 
     The  only  settings therefore that make sense are 0  and  2. 
     These  correspond  to 'normal' and 'modified  on  the  RS232 
     port' respectively. Setting it to 1 or 3 will result in some 
     pretty weird effects.
     
3.5.9 Beacon period
     
     This  parameter  sets  the beacon interval  in  seconds.  In 
     TheNet  1.01, this was fixed at 10 minutes ( 600 seconds  ). 
     In  this  version, this parameter may be used to  change  it 
     according the prevailing license conditions.
     
3.5.10 'Connect' redirector
     
     In TheNet 1.01, when 'connect' is given with no  destination 
     callsign,  the node attempted to connect to the  local  host 
     port.  In a crosslinked system, this vanished down  a  black 
     hole. In previous versions of this code, the node  attempted 
     to  connect  to the station set by the  HOST  command,  only 
     trying  the  local host port if no destination  was  set  by 
     HOST.  With  this  version, the node may  be  configured  to 
     connect to the station set by the BBS, DXCLUSTER or the HOST 
     command  depending  on this parameter.  When  zero,  connect 
     attempts  will go to the HOST station, when set to  '1',  it 
     will  attempt to connect to the BBS callsign. When set to  2 
     it will attempt to connect to the DXCLUSTER callsign.
     
3.5.11 'help message enable' flags
     
     This  word controls the sending of help messages, with  each 
     bit of the word controlling a separate function.  Currently, 
     only 8 bits are effective, these being as follows :
        
     BIT       FUNCTION
     =========================
     0    Whether the 'please wait, trying xxxx' operates
     1    Whether all commands appear in help for sysop
     2    Whether the 'goodbye' message is given
     3    Whether a welcome message is enabled ( CTEXT )
     4    Whether nodes are shown as 'alias:callsign'
     5    If set, TALK data is passed as 8 bit data  rather  than 
          clearing the most significant bit
     6    If set, node aliases are deemed to be case sensitive
     7    If set, enables the TexNet "*** LINKED to" interface
        
        
     When  bit 0 is set, and the BBS, HOST or DXcluster  commands 
     are given, then a message is sent from the node telling  the 
     user  that  a connect attempt is being made. This  does  not 
     affect  the 'connect' command itself, unless the command  is 
     given  with no parameter as this is then equivalent  of  the 
     BBS or HOST command.
     
     When  bit  1  is  set, and if a  sysop  gives  an  incorrect 
     command,  the  help  screen  shows  all  commands  possible, 
     including  those currently disabled ( as by definition  they 
     are not disabled for the sysop ! ).
     
     When  bit 2 is set, then the use of the 'bye'  command  will 
     solicit a 'goodbye' message from the node.
     
     Bit 3 switches on and off the 'CTEXT' message. When enabled, 
     and  when  a  CTEXT message is set,  then  whenever  someone 
     uplinks  to  the  node  alias, the  ctext  message  is  sent 
     immediately on connect.
     
     Bit  4  switches the way in which nodes are shown  when  the 
     ROUTES command is used. When set to '1', nodes are shown  as 
     'alias:callsign'.  When  set to 0, they are  shown  only  as 
     'callsign'.
     
     Bit  5  controls  only the passing of  data  in  TALK  mode. 
     Normally, all data sent to the node has its most significant 
     bit  cleared, to eliminate parity or similar problems.  This 
     is  not  ideal  for those countries that  use  the  extended 
     character set. When this bit is set, and only when in  TALK, 
     data is passed as 8 bit data. Note that this does not  apply 
     to  an  initial message sent on the same line  as  the  TALK 
     command.
     
     Bit  6  makes node handing case  sensitive.  Normally,  node 
     aliases are forced to upper case for searching in the  table 
     and  for user 'connect requests'. If this bit is set,  these 
     operations  will become case sensitive. This could  be  very 
     confusing  for users unless they are aware of it and  expect 
     it. It allows node aliases to be entered as lower case,  for 
     example  in  setting the node alias and in  forcing  routes. 
     Don't set this bit unless it is actually needed !.
     
     Bit 7 controls the TexNet interface. If set, the TexNet "*** 
     LINKED  to"  command string handling is enabled  so  that  a 
     TexNet  to  Net/Rom  interface  may  be  effected.  This  is 
     described  further  in section 4.4. If the bit is  not  set, 
     then  a TexNet "*** LINKED to" string will solicit an  error 
     message.
     
3.5.12 'hash' node port control
     
     In  certain  networks ( notably the American ), there  is  a 
     need  to  restrict the propagation of local nodes.  This  is 
     done by using node aliases that start with a hash  character 
     ( # ) and instructing specific nodes not to broadcast routes 
     to nodes that start with this character. This parameter does 
     this  by  enabling each port to be individually  enabled  or 
     disabled  in  respect  to  'hash'  node  broadcasts.  Bit  0 
     controls  the radio port and bit 1 controls the RS232  port. 
     When  one  of these bits is set, hash nodes  will  never  be 
     broadcast on that port.
        
3.5.13 Extra aliases
     
     If  this is set to '1', then the node will listen for (  and 
     accept  uplinks to ) the aliases set in HOSTALIAS,  DXCALIAS 
     and  BBSALIAS if they are set. If this parameter is  set  to 
     '0',  or if the respective aliases are not set, it  will  do 
     nothing. If you do not use the aliases, set it to 0 to avoid 
     wasting processor time.
        
3.5.14 Reconnect to Switch
     
     If  this  parameter  is  set to  0,  the  node  operates  as 
     normally. If set to a non zero value ( i.e. set to '1' ), it 
     operates in 'reconnect' mode. When a station connects to the 
     switch,  then  uses  the BBS,  HOST,  DXCluster  or  Connect 
     commands to connect to another station, and then causes that 
     remote   station   to  disconnect  them,   then   they   are 
     automatically reconnected to the node with a 'welcome  back' 
     message.
        
3.5.15 NoSlime
     
     This  parameter controls 'slime trails'. A 'slime trail'  is 
     caused  when a remote node, whose identity is not  known  to 
     the  node,  sends a transport connect request to  the  node. 
     Subject to the settings of the port qualities, the node  may 
     make  an entry in the node table in order to reply to  them. 
     Such entries are typified by having no alias associated with 
     them.
     
     Each  bit  in  the NoSlime parameter  controls  a  different 
     function. Bit 0, if set, causes any stations without aliases 
     to be 'hidden' when a nodes command is given. Bit 1. if set, 
     causes the node to refuse to make slime trail entries in the 
     node table. Before you use this feature, be careful to  make 
     sure  that you understand the implications of doing  so,  as 
     without fixed entries the node will refuse to accept level 4 
     connections  from  a station until it has heard  their  node 
     broadcast.
     
3.5.16 NoDigi
     
     This  parameter  controls the node's willingness  to  accept 
     digipeated  level  2  connections  or  to  allow  digipeated 
     downlinks from the node. Each bit of the parameter  controls 
     a different function, as shown below :
        
     BIT  FUNCTION
     =======================================
     0    If set, do not allow digipeated connections to the node
     1    If set, do not allow digipeated downlinks from the node 
          switch
        
        
3.6 MHEARD
        
     The  TNC can be instructed to keep a list of the  last  'nn' 
     stations heard, where 'nn' is an integer between 1 and  100. 
     It can also be disabled. The syntax of the command is :
        
                       MHEARD [ nn ]

     The  parameter is optional and only operates for the  sysop. 
     It  sets  the maximum length of the list.  Setting  to  zero 
     disables the function.
     
     The  heard list uses free buffers for the list, so  a  large 
     setting means less RAM for the node software.
     
     The  list  is  maintained  as linked  list,  with  the  most 
     recently  heard station first. The display shows the  number 
     of packets heard from that station and the time since it was 
     last  heard, in hours minutes and seconds.  In addition,  it 
     shows the port on which the station was heard together  with 
     an indication as to whether the station is a node and / or a 
     TCP/IP  or a TexNet station. It does this by  examining  the 
     PID byte. 
     Every  hour the list is checked for stations that  have  not 
     been  heard for 12 hours, and any such stations are  removed 
     from the list.
     
     To  disable the internal updating of the list ( and  thereby 
     stop  the  CPU expending effort on the function ),  set  the 
     size  to  zero  rather than just disabling  the  command  as 
     described  in 3.8. Note though that the node will not  clear 
     the list as updates have been disabled, so it will be up  to 
     12  hours before the buffers used are freed.  To  accelerate 
     this  process, set the size to 1, wait until it has heard  a 
     station  ( any one will do ) then set it to zero. This  will 
     free up all but one buffer immediately.
     
     The  heard  list  is  the  user  interface  to  the  receive 
     deviation meter. Its operation is explained in section 3.31. 
     If  enabled ( ie if the METER parameter is not set to  0  ), 
     then  an  additional column will be displayed in  the  heard 
     list that will show the received deviation in kilohertz ( as 
     nn.n  ).  It  must be remembered that  this  is  derived  by 
     measuring  the received signal audio level, and will not  be 
     correct in the case of a badly distorted signal.
     
     The  heard list may also show received signal  strengths  if 
     enabled by the Sysop. In this case, the signal strength will 
     be  shown for each station in the list after  the  deviation 
     level ( if enabled ). The display will be either dBm or  the 
     common 'S1 to S9' format according to its configuration. How 
     accurate  it is depends on the accuracy of its  calibration. 
     At  best  it may typically be +- 1dB relative  accuracy,  at 
     worst  totally misleading. In the same way that you can  use 
     the deviation meter to set up your station, pay heed of  the 
     signal  level  too. If you are 40 dB over the noise  into  a 
     local  node,  consider  dropping your signal  20  dB  (  for 
     example from 10 W to 100 mW ). Those around you also running 
     high  power may however make this difficult. The idea is  to 
     get in reliably with the snallest signal not to see how  big 
     a signal you can put into the node.
     
3.7 CQ
     
     When CQ is disabled, the command now reports  apologetically 
     rather than simply ignoring the request.
        
3.8 ALL COMMANDS
     
     There  is  often  a requirement to be able  to  disable  the 
     connect  command whilst allowing level 3 relaying.  This  is 
     achieved  by the use of a command qualifier, the  syntax  of 
     which is :
     
                       CONNECT [ + | - ]

     If  '-'  is entered by the sysop, then the  connect  command 
     will  politely refuse to work. This can be reversed  by  the 
     '+' command.
     
     This  has no effect of layer 3 relaying. Also, the  BBS  and 
     HOST  commands  will still allow connections to be  made  if 
     they are enabled and set.
     
     Further,  the syntax is valid for ALL commands, for  example 
     the  CQ  command can also be disabled in the  same  way.  Be 
     careful though. The command is only accepted from the sysop, 
     so  if you disable the sysop and manager commands  you  will 
     lock out remote management !.
        
3.9 NODES
     
     When  information on a node that is not known is  requested, 
     the  program prints out an error message rather than  giving 
     the names of all known nodes.
     
     When a node entry is made by the sysop, callsign checking is 
     forced  ON  rather  than being determined  by  the  callsign 
     checking parameter.
     
     Don't forget that node alias handling may be case  sensitive 
     - see section 3.5.11.
     
     The entire contents of the node table routes may be obtained 
     by the sysop or manager by the command
     
                       NODES * *

     This  will dump info on all nodes, one node per  line,  with 
     the following format:
        
                  Alias:call   route1   route2   route3

     where  route1,  route2  and  route3  comprise  the  quality, 
     obsolescence  count  and  port  followed  by  the  neighbour 
     callsign  for each of the 3 route entries for that node.  If 
     any  of  the routes are in use, a chevron will be  shown  by 
     that route.
     
     The  extended  command  is only for sysop use  as  it,  like 
     auditing and conferencing, causes the node to be a source of 
     a  significant  amount of data ( dumping a large  number  of 
     node  details can consume hundreds of buffers !!! ).  It  is 
     quite possible that used indiscriminately, it could cause  a 
     warmstart of the node. Be careful.
        
3.10 RESET
     
     The syntax of the command is now 
     
                       RESET [ anything-else ]

     Entering the reset command alone will do a warmstart. If any 
     other parameter is entered, a coldstart is performed.
        
3.11 MANAGER
     
     The MANAGER command gives the user extra privileges. In this 
     version,  this  amounts  to the  ability  to  receive  audit 
     messages from the node. The level of auditing is set by  the 
     AUDIT command.
     
     The  privilege remains in force until cleared by  a  command 
     that  affects  the  user  state.  Specifically,  these  are, 
     entering  the  TALK  state,  executing  the  SYSOP  command, 
     entering the MANAGER command and getting the password wrong, 
     or  disconnecting from the node. Failing to get  the  second 
     password  right when using the closedown command  will  also 
     remove the manager privilege.
     
     If the MANAGER command is executed by a user who   connected 
     to  the node by a level 4 circuit rather than by a  level  2 
     circuit,  and  if the level 2 timeout is less  than  the  no 
     activity  timeout, the connection will never timeout as  the 
     clearing  and reconnecting of the level 2 circuit will  keep 
     the process alive provided level 2 auditing is enabled. This 
     allows  the operation of the node to be logged remotely  and 
     continuously.  Alternatively,  if  the level  4  timeout  is 
     greater  than 10 minutes, level 1 or CPU auditing will  keep 
     it  alive if level 2 is switched off. NOTE : I have a  nasty 
     feeling  that there is something not quite right here -  the 
     link sometimes dies !.
     
     A user with MANAGER privilege also has SYSOP privilege.
     
3.12 AUDIT
     
     The syntax of the audit command is : 
        
                       AUDIT [ new-value ]

     where  new value is an integer value. If no value is  given, 
     or  the  user does not have SYSOP status, the  current  mask 
     value  is displayed. Otherwise, the mask is updated and  the 
     new value displayed.
     
     The  mask  controls the auditing of various  events  in  the 
     node. Not all values are used yet, but those that are, are :
     
          BIT            USE
     ============================================
     0        Level 1 statistics on 10 minute updates
     1        Level 2 connects & disconnects
     2        reserved for future use
     3        Level 4 connects & disconnects
     4        Level 7 limited events ( use of sysop )
     5        Full level 7 auditing
     6        CPU auditing messages ( 10 minute updates )
     
     It  is suggested that the usual settings can simply be 0  or 
     255.
     
     For level 1, messages are sent every 10 minutes showing  the 
     percentage  of time that the receiver detected  carrier  and 
     the percentage of time that the transmitter was on.
     
     At  level  2  &  4, the messages are  of  all  connects  and 
     disconnects, shown in 4 different ways :
           
           C    Connect message received by node
           CA   Connect message sent / Acknowledge received
           D    Disconnect message received by node
           DA   Disconnect message sent / Acknowledge received
        
     In  each case, 2 callsigns are shown. At level 2  these  are 
     the source and destination of the AX.25 link. At level 4, it 
     is the remote node callsign and user callsign. Each  message 
     is  preceded by an indication of the source of the  message, 
     such as "L2" or "L4".
     
     At  level 7, with bit 4 set and bit 5 clear, the only  event 
     currently  audited is the use of the Sysop  command,  either 
     directly  or via the manager command. If bit 5 is set,  then 
     all  commands given to the switch are audited,  preceded  by 
     the callsign of the user who entered the command.
     
     Bit  6  controls  CPU health check auditing.  If  set,  then 
     whenever  the internal CPU statistics are updated,  messages 
     are  sent  showing the CPU processor loading total  and  the 
     minimum buffers level ( see STATS for more information ). 
     
     The  audit mask value should be set to 0 when  not  actually 
     being  used.  Do not leave it set to another value  as  this 
     wastes  processor  time. Note also that full auditing  on  a 
     busy  node  makes  things worse. Treat  it  as  a  debugging 
     feature !.
     
3.13 TALK
        
     Talk  is  a  conferencing command. It  allows  a  number  of 
     stations to hold a simultaneous conference ( a bit like  the 
     CONFERENCE  command  of a DX cluster ). There  is  only  one 
     conference, and stations may connect to it by connecting  to 
     the  node and issuing the TALK command. It may be exited  by 
     disconnecting or issuing the command '/EXIT' at the start of 
     a  line.  ( /EXIT may be abbreviated to /EX, and it  is  not 
     case sensitive ).
     
     Each line sent by a user is copied to all other users in the 
     conference,  preceded by the callsign of the user. The  data 
     will  be  sent as 7 bit data ( ie the most  significant  bit 
     will  be cleared ) unless the appropriate bit is set in  the 
     help flags ( see section 3.5.11 ).
     
     Whenever  a new station enters the conference, or a  station 
     leaves  the conference using the '/EXIT' command, the  other 
     conference users get a message informing them of the  event. 
     These status messages are sent with the callsign of the node 
     rather than the user.
     
     Finally,  when entering the TALK command, a message  may  be 
     sent  to all those users who are connected to the  node  but 
     not  otherwise doing anything. For example if  GxABC  enters 
     the line
     
           TALK Hello fred, can I have a chat, type 'TALK'

     Then  all other stations connected to the node,  present  in 
     the USER list but idle, get the message
        
           GxABC>> Hello fred, can I have a chat, type 'TALK'

     displayed on their terminal.
     
     Note that merely connecting to the node does not  constitute 
     being  connected  to the switch. Stations connected  to  the 
     switch appear in the USER list.
     
3.14 SYSOP
     
     The SYSOP command has been enhanced to increase the level of 
     security offered. One problem of the old system is that  the 
     password is easily visible unless the user repeats the SYSOP 
     command  a number of times. Even then,  correlation  between 
     passwords is easy, so the password needs frequent  changing. 
     To reduce the change period, and make it harder to discover, 
     the node will accept a string of characters and scan it  for 
     the password. Hence a response of, say, 30 or 40  characters 
     can  be  sent,  with a random number  of  random  characters 
     preceding the actual data and a random number following  it. 
     This does not eliminate such attacks, but if used carefully, 
     it makes it quite a bit harder to attack.
     
3.15 LINKS
     
     This  command shows the current level 2 links to  the  node. 
     Displayed one per line, the two callsigns are shown followed 
     by the link state, port number and current retry count.
     
3.16 CALIBRATE
     
     This  command  allows  remote  calibration  checks  of   the 
     transmitter deviation. Its syntax is
        
                  CALIBRATE period [ toggle ]

     The  period ( 1 to 60 seconds ), is the time for  which  the 
     transmitter  will  key  up for with  constant  tone.  It  is 
     undefined  as  to  which tone will be sent.  If  the  second 
     parameter  is given, the node will toggle between the  tones 
     every  [toggle]  seconds. The toggle must be between  1  and 
     [period] seconds. If a period is not given, the user is  not 
     sysop  or manager, or if it is out of range, the command  is 
     ignored.  If the tone generator is busy because it is  about 
     to send a CWID sequence, a 'busy' message is returned.  Note 
     -  quite  often it can appear that the node  has  locked  up 
     having  failed  to transmit the full  calibrate  period.  In 
     fact, this is usually the hardware PTT watchdog in the  TNC. 
     The  node thinks it is still sending but the hardware  timer 
     has removed the PTT signal.
        
3.17 DXCLUSTER
        
     The DXCLUSTER command operates just like the BBS command  in 
     that  it may be used to effect a connection to  a  DXcluster 
     (assuming there is one nearby). It should be disabled if  it 
     is not intended to be used to access a cluster.
     
     The syntax of the command is :
        
                       DXCLUSTER [ * | ? | callsign ]

     With  no  parameter,  the  command  connects  to  a  station 
     previously  specified  by the use of the  DXCLUSTER  command 
     with a callsign as a second parameter. Setting the DXCLUSTER 
     to  allow this may only be done by a sysop. The  '*'  option 
     may also only be executed by the sysop, this command  clears 
     a previously specified DXCLUSTER.
     
     The '?' option ( or any text if not sysop ), prints out  the 
     current DXCLUSTER station setting.
     
     If no DXCLUSTER is set, the command issues an error  message 
     if it is invoked with no other parameters.
     
     The  idea  of  this command is that,  like  with  the  'bbs' 
     command  of  the 'BPQ software, a user may  connect  to  the 
     local DXCLUSTER from the node.
     
3.18 HELP
     
     The  HELP command gives a message from the ROM. In  general, 
     it  is expected that the message will be designed to  assist 
     new users in understanding the operation or configuration of 
     the  node.  The  message may span many  lines,  and  may  be 
     changed  when  the  ROM  is  programmed.  As  delivered,  it 
     contains  a  brief help screen detailing the main (  user  ) 
     changes to the code.
     
3.19 CTEXT
     
     The CTEXT command sets or displays a message sent to a  user 
     who connects to the node by uplinking to the node's alias.
     
     The syntax of the command is :
        
                  CTEXT [ * | message ]

     With no parameter, the current message is displayed. If  the 
     user is also a sysop, and if text follows the command,  that 
     text  is added to the current connect text. If  the  message 
     starts  with  a '*', the connect text  message  is  deleted. 
     Hence,  to  clear the message, type the command  'ctext  *'. 
     This is a change in version X-1J from previous versions. For 
     further information, see section 3.33
     
     A  message is only sent if there is a ctext message set  and 
     if the relevant bit is set in the mode command parameter  as 
     described in section 3.5.11.
        
3.20 BTEXT
     
     The  BTEXT  command sets or displays the  additional  beacon 
     text sent along with the beacon packets.
     
     The syntax of the command is :
        
                  BTEXT [ * | message ]

     With no parameter, the current message is displayed. If  the 
     user is also a sysop, and if text follows the command,  that 
     text  is  added to the current beacon text. If  the  message 
     starts  with  a  '*', the beacon text  message  is  deleted. 
     Hence,  to  clear the message, type the command  'btext  *'. 
     This is a change in version X-1J from previous versions. For 
     further information, see section 3.33
     
     Normally, beacon packets are UI frames that contain the node 
     callsign and alias. If a beacon message is set, the text  of 
     the  message  follows the alias in the same  packet.  It  is 
     strongly suggested that beacon packets be kept brief !!!.
        
3.21 ACL
     
     This is probably the most complex additional command in  the 
     program.  It  should be used with care, and  only  when  you 
     really understand its operation - mistakes can result in the 
     need  to go out to a remote site ( probably when it is  cold 
     and wet ) to reconfigure the node.
     
     The command allows selective control, based on callsign,  of 
     a  list of different events. The ACL contains two  types  of 
     entry,  a default value and zero or more callsigns, each  of 
     which  are  associated  with  a  value.  When  one  of   the 
     controlled  events  occurs  ( such as an  incoming  level  2 
     connection or a nodes broadcast ), the ACL is scanned for an 
     entry that matches the callsign of the sender. If a match is 
     found  (  but see below ), the value  associated  with  that 
     callsign is used to determine the action the node will take. 
     If no match is found, the default value is used.
     
     An ACL function mask is provided. This enables specific  ACL 
     functions  to be disabled to speed up the node. Each bit  of 
     the  mask  enables ( if set ) or disables ( if clear  )  the 
     corresponding  function. For example, if the mask is set  to 
     2,  the  node will only check its ACL for outgoing  level  2 
     connections.
     
     Each bit of the value or mask controls a different function, 
     as shown below :
     
     BIT      OPERATION
     ===================================================== =
     0    bar incoming level 2 connection
     1    bar outgoing level 2 connection ( downlink )
     2    ignore nodes broadcasts from this station
     3    bar gatewaying at level 3 to/from this station
     4    bar incoming level 4 connections
     5    bar outgoing level 4 connections
     6    ignore SSID in matching an entry
     
     So  if for example an entry exists for a callsign G99XXX  of 
     6, then the node will not allow outgoing level 2 connections 
     to  the node ( downlinks ), and will ignore node  broadcasts 
     from that station. Note that these commands only operate  on 
     the  events  themselves  -  if  G99XXX  creates  a  level  2 
     connection, the node will quite happily use it itself.
     
     The  'ignore ssid' bit is used to match a  callsign  without 
     regard to its SSID. This makes life interesting when finding 
     a  match,  so the list is scanned twice, once for  an  exact 
     match, and then for a match ignoring SSID if an exact  match 
     is  not found. There can only be one exact match,  but  when 
     searching  for a match without using SSID, the  first  entry 
     found will be used.
     
     The syntax of the command is as follows ( 4 versions )
     
                  ACL * value
                  ACL & value
                  ACL callsign + value
                  ACL callsign -

     If  you  are not sysop, or if ACL is given on its  own,  the 
     current contents of the ACL are shown. The first form of the 
     command changes the default value, the second form sets  the 
     mask enable value, the third makes an entry in the list, and 
     the  last form removes an entry from the list. It  complains 
     about syntax errors.
     
     A  few  moments  thought  will show  that  the  sequence  of 
     commands
        
                  connect to node
                  execute sysop or manager command
                  type the command ACL * 127
                  type the command ACL & 127
                  disconnect
        
     is  quite catastrophic. You will not be able to get back  in 
     again apart from via the host port and noone will be able to 
     connect  to  or from the node. If you intend  to  experiment 
     with  the  command, you should start by  entering  your  own 
     callsign  with  a value of zero to ensure that you  can  get 
     back in again !!!.
     
     The  list  can be used as an 'accept' or  'reject'  list  by 
     judicious use of the default. To create a list that excludes 
     specific  calls,  put them into the list with  the  required 
     bits set in the value. The default should be zero. To create 
     an 'accept' list, put entries in with the required bits zero 
     and  set the corresponding bits in the  default.  Individual 
     bits  may be used to create accept or reject lists for  each 
     function.
     
     The command steals buffers at a rate of one buffer per  four 
     entries in the ACL. Also, a long ACL will slow the node down 
     nicely - so think before you enter a long list.
     
     This command is for experimental purposes - if you find  any 
     bugs,  let  me  know please ( I have not  fully  tested  the 
     gateway  bit  for example ). Also, it is  not  intended  for 
     malicious use but to allow fine control to be exercised over 
     backbone networks. If I get lots of negative responses back, 
     the command will go !
     
     The  mask value should be set so that only  those  functions 
     actually  being used are enabled. For example, if  the  node 
     has an ACL set to control level 2 uplinks and downlinks,  it 
     will also check its ACL for all other controlled  operations 
     such  as level 3 gatewaying. This will result in  much  time 
     being  wasted searching the list for a result that is  going 
     to always succeed. In the example cited therefore, the  mask 
     would be set to 3. On reset, the mask value is set to  zero, 
     SO  ALL ACL FUNCTIONS ARE DISABLED AND MASK MUST BE  SET  TO 
     ENABLE THEM !.
     
     The  level 4 function has been extended so that it  examines 
     not  only  the originating node callsign but also  the  user 
     callsign  from  that node in deciding whether  to  refuse  a 
     connection.  Previous to X-1J release 4, it only  looked  at 
     the node callsign.
        
3.22 CLOSEDOWN
     
     The  closedown  command  is  used  to  shut  down  the  node 
     remotely.   If   successfully  executed,   the   node   will 
     effectively  stop  operating until it is reset ( e.g.  by  a 
     power up ). The node's configuration ( routes, messages etc. 
     )  are  not  destroyed  -  the  node  simply  hits  a   HALT 
     instruction. You must be sysop to execute the command.
     
     The syntax of the command is:
        
                       CLOSEDOWN A

     The  node will respond with 5 numbers just as for  when  the 
     sysop or manager command was executed. Yes, you guessed, the 
     node  expects  another password. Give it correctly  and  the 
     node closes down completely. Get it wrong and you lose  your 
     sysop status. This obtuse and awkward syntax is designed  to 
     make sure it is not accidentally executed.
        
3.23 ALIAS
     
     The ALIAS command allows the node's alias to be changed. The 
     syntax is :
        
                  ALIAS [ * | new-alias ]

     If  no  parameter is given, or if the user is not  SYSOP  or 
     MANAGER,  the  current alias is displayed. If the  alias  is 
     deemed  to be a valid alias, the node's alias is changed  to 
     the new one entered. Note that the algorithm that checks for 
     the  alias  structure  is a bit queer. It  is  however,  the 
     original  algorithm of TheNet and I am loathe to  change  it 
     for  fear  of  side effects. Note  too  that  the  companion 
     CALLSIGN command is NOT included - chaos is not something  I 
     crave.  If the sysop gives the parameter of '*', the  node's 
     alias is cleared.
        
3.24 BBSALIAS HOSTALIAS DXCALIAS
     
     These commands are used to enable the node to respond to  up 
     to three additional aliases. The syntax of each is the same, 
     and by way of example the BBSALIAS syntax is :
        
                  BBSALIAS [ * | new-alias ]

     If  not sysop, if no new alias is specified, or if  it  does 
     not  pass the weird alias syntax checker ( see 3.23  )  then 
     the  current  alias  is  displayed. If  not,  the  alias  is 
     changed. If '*' is given, the alias is cleared.
     
     The  aliases  so entered are nothing to do with  the  node's 
     identity. If a BBS alias is set, for example to MXMBBS, then 
     the node will listen for level 2 connects to that alias.  It 
     will  respond to them and will automatically invoke the  BBS 
     command. The use will also get the optional welcome  (ctext) 
     message and 'trying to connect to ....' messages if  enabled 
     by the appropriate 'mode' parameter.
     
     The  idea is that where a node sits on a channel  that  does 
     not  have  access  to the local host, BBS  or  cluster,  the 
     normal aliases of those stations may be enabled in the  node 
     to allow consistent access to the local services. Note  that 
     the  three  stations  do  not have to be  a  BBS,  Host  and 
     cluster, it could be three BBSes or any other combination.
        
3.25 IPSTATS
     
     The  IPstats command has the same basic syntax as the  PARMS 
     and  MODE  commands.  When invoked  without  parameters,  it 
     displays  the  current  stats. Each statistic  may  also  be 
     altered by sysop, as defined in section 3.32.
     
     In  addition to the standard IP MIB, there is an  additional 
     parameter  used  to set the level 2 default modes,  and  the 
     first  entry  in the MIB is used to enable  or  disable  the 
     router.
     
     The   complete  set  of  IP  MIB  stats  are  included   for 
     compatibility  with  other IP systems, but several  are  not 
     used.  Also,  the  stats  are 16 bit  counters  not  32  bit 
     counters as in NOS. Like NOS however, the stats do not reset 
     every  hour,  they must be cleared by the sysop.  They  will 
     however wrap around at zero.
     
     The entries are:
        
             1    Port default modes
             2    Enable / Disable the IP router functions
             3    Default IP Time To Live
             4    IP Received frames
             5    IP Header Errors
             6    IP Input Address Errors
             7    IP Forwarded Datagrams
             8    IP Unknown Protocols
             9    IP input frames Discarded
             10   IP Input frames Delivered
             11   IP Output Requests
             12   IP Output Discards 
             13   IP Output No Routes errors
             14   IP Reassembly Timeout errors
             15   IP Reassembly Required errors
             16   IP Reassembly OKs
             17   IP Reassembly Fails
             18   IP Fragmentations completed OK
             19   IP Fragmentation Failures
             20   IP Fragmentation Creates
        
     The  default mode word may be set to 0, 1, 2 or 3. Each  bit 
     controls a port, with bit 0 controlling port 0 ( radio port) 
     and bit 1 controlling port 1 ( RS232 port ). When set to  1, 
     the  default  mode for that port when sending on a  level  2 
     connection  will  be Datagram. When set to 0 it will  be  by 
     Virtual  Circuit.  The default mode is used  when  no  other 
     information is given, either by the ARP table or by the  TOS 
     bits in the IP header.
     
     The enable / disable word may be set to 0 or 1. When set  to 
     0, the operation of the router is stopped, when set to 1 the 
     router functions.
     
     The  IP Time To Live ( TTL ) word is used to set the  number 
     of  routers through which an IP frame may pass before it  is 
     discarded.  It is similar to the node layer 3 TTL  word.  It 
     may  be set to any value up to 255, but values below 2  make 
     no sense and are therefore not permitted.
     
     The IP fragmentation reassembly timeout counter is not  used 
     as  the node is just a router. It is left set to 30  seconds 
     just to show which one it is !
     
     The  rest  are just statistics. The patient  user  can  have 
     hours  of fun working out which ones are not used ( or  just 
     think about it for a second or two ).
        
3.26 IPADDRESS & IPBROADCAST
     
     These  commands are used to set or display the IP  addresses 
     used by the node. The syntax of each is (by way of example):
        
                  IPADDRESS [ ipaddress ]

     where ipaddress is in the form 
        
                  nnn.nnn.nnn.nnn 

     where nnn is an integer in the range 0..255
        
     So  to set the node IP broadcast address to that  used  over 
     here, the command would be :
        
                  IPBROADCAST 44.131.0.0

     The IPADDRESS is the address that the node will respond  to. 
     It  is used only as detailed in section 7. The IP  broadcast 
     address  is  the one used to denote broadcast  packets  that 
     will  be largely ignored. Note that port addressing  is  NOT 
     currently supported. Anyone who finds this limiting, drop me 
     a line and I'll see if I can change it.
     
3.27 IPROUTE
     
     This is one of the two main databases used by the node.  The 
     IP  Route table is used to tell the router where to  send  a 
     frame  for  a  specific destination. It  maps  addresses  or 
     address  ranges to a gateway IP address and  to  sub-network 
     ports.  The  ARP database then tells the node  what  station 
     corresponds to that address and protocol. The node  supports 
     two subnet protocols, AX25 and Net/Rom.
     
     The  database  is stored in an ordered list,  in  decreasing 
     order  of  the number of relevant bits. This  is  to  permit 
     searching  of  the database when trying to find  a  specific 
     destination.  Given  an  address, it  scans  addresses  with 
     decreasing  numbers  of  bits until it finds  a  match.  The 
     syntax of the command is as follows :
        
         IPROUTE [address [ / bits ][ + port [gateway [metric]]]]

     or
        
         IPROUTE [address [ / bits ][ - ]]

     In  the first form, it makes an entry in the table,  in  the 
     second it deletes one. Only sysop or manager may effect such 
     a change. The parameters are as follows :
     
     address The amprnet address in the form nnn.nnn.nnn.nnn
     bits    The number of significant bits (eg  44.131.0.0  /16)
     port    The port, either 0 or 1 for AX25 or n for Net/Rom
     gateway The optional gateway for this dest. nnn.nnn.nnn.nnn
     metric  Currently not used, a numeric value
     
     When  an entry is made with a specific number of  bits,  the 
     address  is  'masked  off' to that many bits,  so  enter  an 
     address  of  44.131.16.31 / 24 and it will  get  entered  as 
     44.131.16.0.  The valid range for the number of bits is 0  - 
     32.
     
     Entering a route with bits set to 0 will cause an entry to be
     made in the IProute table of 0.0.0.0 which will function as a
     default route entry.
        
3.28 ARP
     
     The  ARP  table  maps a pair  of  address+port  to  hardware 
     address+subnetwork mode. The address is either a destination 
     or  a gateway in the form nnn.nnn.nnn.nnn. The  protocol  is 
     either  Net/Rom or AX25. The hardware_address is a  callsign 
     and the subnetwork mode is DG or VC ( only has  significance 
     for level 2 links ).
     
     The syntax of the command is :
        
             ARP [ destination [ + [ P ] protocol callsign [ mode 
             ] ] ]

     or
        
             ARP [ destination [ - protocol ] ]

     In  the  first form an entry is made in the  table,  in  the 
     second an entry is deleted. This is only permitted for sysop 
     or manager.
     
     The parameters are :
     
     destination    An address of the form nnn.nnn.nnn.nnn
     P              If present, marks the entry as 'published'
     protocol       AX25 or Net/Rom
     callsign       A valid amateur callsign, e.g. G8KBB-5
     mode           DG or VC
     
     If  'P' is entered, then the node will publish the  address. 
     Specifically,  if an ARP request is seen by the node  for  a 
     station  with  the address given, it will  send  a  response 
     advising the caller of the callsign to be used.
     
     More details on the operation of the router are contained in 
     section 7.
     
     The ARP table also shows a further parameter of TIMER.  This 
     is  only  shown when it has a value other than 0.  When  non 
     zero, it is a timer showing the number of minutes before the 
     ARP entry is automatically deleted. Entries made by means of 
     the  ARP  command have timer values of  zero  and  therefore 
     persist.  Entries  made  from the network  by  ARP  protocol 
     frames  have the timer entries set to the  ARPtimer  initial 
     default.
     
3.29 UI
     
     The  UI command allows a string to be sent as a Level  2  UI 
     frame. The syntax is
        
                  UI dest string_of_text_ending_in_return

     Dest  is  a callsign like destination such as  'MAIL'.  What 
     will  happen is that a single UI frame will be sent  with  a 
     source  callsign  of  the user who entered  the  command,  a 
     destination callsign of dest, and the rest of the string  as 
     text.
     
     It  is designed to be used in situations where a  local  BBS 
     does not have access to a common channel and wishes to  send 
     mail notification packets. Not surprisingly, the ability  to 
     do this is BBS specific.
        
3.30 MTU command
     
     The  MTU  command is used to configure  the  node's  Maximum 
     Transmission Unit figures ( primarily for TCP/IP support  ). 
     In  general, they should be left at the default  values.  Do 
     not  experiment  unless  you are  sure  you  understand  the 
     significance of what you are doing !!!!
     
     The syntax of the command is identical to the syntax of  the 
     PARMS and MODE commands, as defined in section 3.32.
     
     There are 5 values configured by the command. These are :
     
     Number         Default   Function
     ========================================================== 
     1        256    Sets the MTU for the IP router, AX.25  Level 
                     2, Radio port ( port 0 )
     2        256    Sets the MTU for the IP router, AX.25  Level 
                     2, RS232 port ( port 1 )
     3        236    Sets  the MTU for  the  IP  router  Net/Rom 
                     interface
     4        257    Sets the maximum number of data bytes  permitted 
                     in  an AX.25 level 2 frame before  an  error 
                     response  is returned to the sender (  frame 
                     too long )
     5      328      Sets  the maximum number of bytes  permitted 
                     in a level 2 packet. Above this, frames  are 
                     discarded. If a packet may contain 256  data 
                     bytes,  and  a  maximum  length  address  of 
                     sender,  recipient and 8 digis comprises  70 
                     bytes,  and  2 bytes are  used  for  control 
                     bits, the total ( 256+70+2 ) is the  setting 
                     of this parameter.
     
     This command replaces the ROM patching needed for TheNet  X-
     1H.
     
     The minimum that an MTU may be set to is 64, the maximum  is 
     1024, but large packets increase the probability of crashing 
     the node. Beware !!!!!!.
     
     The  MTU for the Net/Rom port should not in general  be  set 
     higher than 236 or it will not be compatible with Net/Rom.
     
     The limits on the other two correspond to those necessary to 
     support frames in the range 256 - 1024 data bytes long.
        
3.31 METER command
     
     This  command's syntax is similar to the PARMS command,  and 
     includes the new syntax as described in the overview  guide, 
     section 3.32.
     
     It  allows the following parameters to be  controlled.  Note 
     that the parameter list differs from TheNet X-1J, where  the 
     first ( and only ) parameter was the deviation meter scaling 
     factor.
     
             1 The meter mode flags
             2 The deviation meter scaling factor
             3 The signal strength meter noise floor value
             4 The S meter display format multiplier
             5 The dBm meter display format multiplier
             6 The dBm noise floor value
             7 The voltmeter channel 1 multiplier 
             8 The voltmeter channel 2 multiplier
             9 The voltmeter channel 1 offset value
             10     The voltmeter channel 2 offset value
             11     The voltmeter channel 3 multiplier 
             12     The voltmeter channel 4 multiplier
             13     The voltmeter channel 3 offset value
             14     The voltmeter channel 4 offset value
        
3.31.1  The meter mode flags
     
     Each  bit of this parameter controls a different  aspect  of 
     the meters as shown below
     
     BIT       If set, then ....
     ======================================================
      0        The deviation meter is enabled
      1        The signal strength meter is enabled
      2        The signal strength is shown as S  points  rather 
               than dBm
      3        ADC channel 3 is enabled ( voltmeter channel 1 )
      4        ADC channel 4 is enabled ( voltmeter channel 2 )
      5        Voltmeter channel 1 divisor is 1000  rather  than 
               100
      6        Voltmeter channel 2 divisor is 1000  rather  than 
               100
      7        Voltmeter  channel  1  displays  fine  resolution 
               rather than integers
      8        Voltmeter  channel  2  displays  fine  resolution 
               rather than integers
      9        ADC channel 1 is enabled ( voltmeter channel 3 )
      10       ADC channel 2 is enabled ( voltmeter channel 4 )
      11       Voltmeter channel 3 divisor is 1000 rather than 100
      12       Voltmeter channel 4 divisor is 1000 rather than 100
      13       Voltmeter channel 3 displays fine resolution rather 
               than integers
      14       Voltmeter channel 4 displays fine resolution rather 
               than integers
     
3.31.2  The deviation meter scaling factor
     
     This  is the parameter previously described in section  3.31 
     of  the  overview  guide.  It  scales  the  deviation  meter 
     display.  One change however from X-1J. Setting it  to  zero 
     does  not disable the deviation meter - bit 0 of  the  meter 
     mode word as described above controls whether it is enabled.
     
     When  set  to  a value in the range 1 - 255,  the  meter  is 
     enabled  and the value is used as a scaling factor. The  ADC 
     is an 8 bit device, so it will give a response in the  range 
     0 - 255, corresponding to an ADC input voltage in the  range 
     0 - 3 volts DC. If optimally configured, this corresponds to 
     the  maximum  audio level possible for  the  given  receiver 
     discriminator.
     
     The  ADC  reading  ( 0 - 255 ) is multiplied  by  the  meter 
     parameter value ( 1 - 255 ) to give an answer in the range 0 
     to  65 KHz ( approx. ). This is the value displayed  in  the 
     mheard list.
     
     Hence, if, for example, a DC voltage of 2 volts at the input 
     to the ADC corresponds to 3.4 KHz deviation, the ADC reading 
     will  be 171 ( +- a few ) and the Meter parameter will  need 
     setting to 20 ( ie to 3400 / 171 ).
     
     If  the  ADC  reading is 254 or higher,  then  in  order  to 
     indicate  an  overrange,  the symbol '>'  will  precede  the 
     corresponding deviation entry in the heard list.
     
     
3.31.3  The signal strength meter noise floor value
     
     This parameter sets the 'no signal' offset applied to  input 
     readings  from the signal strength meter. It  is  subtracted 
     from the count read from the ADC to give a reading based  on 
     a  no  signal  value of zero. If the no  signal  (  noise  ) 
     reading is, for example 0.65V, corresponding to an ADC count 
     of 256 * 0.65 / 3 or 54, then 54 is subtracted from each ADC 
     signal strength reading to give an integer from 0 to 201 for 
     an input reading between 54 and 255.
     
3.31.4  The S meter display format multiplier
     
     This  parameter  operates  in a similar manner  to  the  dBm 
     multiplier  (  section  3.31.5  )  but  having  divided  the 
     intermediate  result by 256, that value is displayed  as  an 
     integer  in the range 0 to 9 preceded by the letter 'S'.  If 
     the  value exceeds 9, it is displayed as 'S9+'. If  the  dBm 
     multiplier  has  been  set  up  correctly,  then  set   this 
     parameter to the dBm multiplier divided by the number of  dB 
     per S point.
     
3.31.5  The dBm meter display format multiplier
     
     This  parameter  is used to convert an ADC reading  for  the 
     signal  strength meter into a dB count. The ADC  reading  is 
     converted  into  a  count  from 0 to  n,  according  to  the 
     description   contained  in  section  3.31.3.  It  is   then 
     multiplied by this parameter and divided by 256. When  added 
     to the dBm noise floor value ( section 3.31.6 ), this  gives 
     the displayed dBm value in the heard list.
     
3.31.6  The dBm noise floor value
     
     This is the noise floor ( dBm ) reading that corresponds  to 
     the  zero  count  in  section 3.31.3. It  is  entered  as  a 
     positive  count  corresponding  to  a  negative  value.  For 
     example, if the zero point in the example of section  3.31.3 
     is -113 dBm, the noise floor value entered is 113.
     
3.31.7 The voltmeter channel 1 multiplier
     
     This  is the multiplier that controls voltmeter channel 1  ( 
     ADC  channel  3 ). It is set as described  in  section  3.34 
     below.
        
3.31.8  The voltmeter channel 2 multiplier
     
     This  is the multiplier that controls voltmeter channel 2  ( 
     ADC  channel  4 ). It is set as described  in  section  3.34 
     below.
     
3.31.9    The voltmeter channel 1 offset value
     
     This is the value subtracted from the ADC reading before  it 
     is  multiplied by the multiplier parameter. It is  described 
     more fully in section 3.34 below.
     
3.31.10   The voltmeter channel 2 offset value
     
     This is the value subtracted from the ADC reading before  it 
     is  multiplied by the multiplier parameter. It is  described 
     more fully in section 3.34 below.
     
3.31.11 The voltmeter channel 3 multiplier
     
     This  is the multiplier that controls voltmeter channel 3  ( 
     ADC  channel  1 ). It is set as described  in  section  3.34 
     below.
        
3.31.12  The voltmeter channel 4 multiplier
     
     This  is the multiplier that controls voltmeter channel 4  ( 
     ADC  channel  2 ). It is set as described  in  section  3.34 
     below.
        
3.31.13   The voltmeter channel 3 offset value
     
     This is the value subtracted from the ADC reading before  it 
     is  multiplied by the multiplier parameter. It is  described 
     more fully in section 3.34 below.
        
3.31.14   The voltmeter channel 4 offset value
     
     This is the value subtracted from the ADC reading before  it 
     is  multiplied by the multiplier parameter. It is  described 
     more fully in section 3.34 below.
        
3.32 PARM, MODE, MTU, METER & IPSTATS command syntax
     
     The syntax of these commands has changed.
     
     All  use the same syntax, which may be either of two  types, 
     the  original  TheNet  1.01 syntax (  as  used  in  versions 
     previous to X-1J ) or an 'offset & value' type.
     
     The original syntax was, by way of example, 
     
          PARM { [ * | new_value ] [ * | new_value ] .......... }
     
     so to set the 10th PARM ( the L4 retries ) to 1, the  syntax 
     would be :
     
          PARM * * * * * * * * * 1
     
     The equivalent new syntax command would be :
        
          PARM / 10 1
        
     The '/' command signifies that what follows is the parameter 
     number  followed  by the new value. As for the  old  command 
     syntax,  the  complete  list  of  parameters  is  displayed. 
     Setting  the  parameters may only be done by a  Sysop.  Note 
     that  BOTH  command  syntaxes are supported -  you  can  use 
     whichever you prefer.
     
3.33 BTEXT, INFO and CTEXT Command Syntax
     
     In  Version X-1J, the syntax of these commands  changed.  In 
     addition, the Info message was doubled in size to 160 bytes.
     
     If  someone who is not Sysop uses the command,  the  current 
     settings are displayed.
     If  a Sysop uses it without any additional  parameters,  the 
     current setting is displayed.
     If  a  Sysop  enters  one of  the  commands  followed  by  a 
     parameter of '*', the current message is deleted.
     If  a Sysop enters a string of text, that text is  added  to 
     the current message, followed by a newline.
     
     It is therefore possible to build up multiple line messages. 
     If  you wish to start a message with a blank line,  enter  a 
     message  with  a  non  display  (  or  innocuous  display  ) 
     character such as control-A. It will get entered followed by 
     a  newline. On most systems this will not display.  On  some 
     systems such as PCs running NOS, it will display as a smiley 
     face.
     
3.34 The ADC command
     
     This  command  is  used  to read the  voltages  on  the  ADC 
     channels 3 and 4 ( referred to as the 'voltmeter channels  1 
     and  2'  in  the documentation. It  also  displays  the  ADC 
     channels 1 and 2 ( referred to as the 'voltmeter channels  3 
     and 4' in the documentation ) if these optional channels are 
     enabled.
     
     ADC  channels  1 and 2 are normally used for  the  deviation 
     meter  and  S meter respectively. If one or other  of  these 
     functions is not wanted, then the corresponding ADC channels 
     may  be used as general purpose inputs just like channels  3 
     and 4. In this case, the METER Mode Flags are used to enable 
     the channels, the ADC3 and ADC4 commands are used to set the 
     textual descriptions and the ADC command is used to read the 
     channels. If the S meter or deviation meter are enabled  and 
     the  channels are also in use as ADC command  channels  then 
     the  ADC command readings will read true but  the  deviation 
     meter  or S meter may occationally read incorrectly  if  the 
     ADC  command  is issued by a user and actioned at  the  same 
     time as the software is reading on a received packet.
     
     A typical display is shown below :
        
                       IPNET:G8KBB-5}
                       13.2 V DC
                       -5 deg C
        
     Each  channel  is associated with a scaling  factor  in  the 
     METER  command, an offset value, two control flags and  each 
     meter may be enabled or disabled by setting or clearing  the 
     appropriate  bit  in  the meter control  flags  word  (  see 
     section 3.31 ). Finally, each has a textual string that  may 
     be appended to the reading, as shown in the above examples.
     
     The displayed voltage is shown as 
     
          ( meter_reading - offset_value ) * Scaling_factor / n
        
     where  n  is  100 or 1000 depending on the  setting  of  the 
     resolution  bit ( see section 3.31.1 ). The  calculation  is 
     done  with 16 bit signed registers, so it is important  that 
     the intermediate result of 
     
          (meter_reading - offset_value ) * Scaling_factor
     
     lies in the range -32768 to + 32767, hence the choice of n.
     
     It  is shown with a resolution of either 1 or 0.1  depending 
     on the resolution flag, as described in section 3.31.1. 
     
     By way of example, with a scaling factor of 71, a resolution 
     of 'fine', an offset of 0 and a divisor of 1000 will give  a 
     display  ranging from 0 to 18.1V in steps of 100 mV  for  an 
     input  in the range 0 to 3V DC input to the ADC. By  setting 
     the  scaling factor and divisor accordingly, it is  possible 
     to  create a meter with full scale readings up to 320V.  For 
     the 18 V fsd meter, a resistor from ground to the ADC  input 
     of 2.2K with a resistor from the ADC input to the voltage to 
     be  measured  of 11K will give the correct  display  with  a 
     scaling  factor  of 71 and an ADC reference of 3V (  with  a 
     slight  error  that  can be corrected by  tweaking  the  ADC 
     reference ).
     
     The  facility may be used to create a temperature  meter  by 
     connecting  a  suitable sensor to the ADC input.  This  will 
     usually give a value that ranges over a portion of the input 
     range for a range of temperatures. The reason for the offset 
     value  and  use of signed arithmetic is to allow  the  input 
     reading   to   be  converted  into  a  direct   display   of 
     temperature.   Full  details  are  contained  in  the   file 
     'temp.doc', but by way of example, if the input probe  gives 
     a  range of 0 to 2.6 V for a temperature display of  -40  to 
     +90 degrees Celcius, the settings would be
     
                       offset = 68
                       scaling factor = 59
                       divisor = 100 ( control bit cleared ) 
                       resolution = coarse ( control bit cleared )
        
     and  for a corresponding Farenheit display of -40  to  +194, 
     the settings would be
        
                       offset = 38
                       scaling factor = 106
                       divisor = 100 ( control bit cleared ) 
                       resolution = coarse ( control bit cleared )
        
     Note  that there is little point using the  fine  resolution 
     mode for these displays.
     
     The  ADC  channels  are read whenever  the  ADC  command  is 
     issued,  interrupts being disabled for 100 microseconds  for 
     each   reading  on  a  4.9  MHz  TNC2.  The  ADC  needs   40 
     microseconds  to convert the data, and the 100  microseconds 
     allows for a 10 MHz TNC2 to be used.
        
3.35 ADC1, ADC2, ADC3 and ADC4 commands
     
     These commands are used to set a textual string that follows 
     the ADC readings. The format and parsing is the same as  for 
     the INFO and similar commands ( see section 3.31 ), but  the 
     length is only 8 characters. The same routines were used  to 
     save space but this is not really an ideal way to do it.  To 
     set  a  string, the previous must be cleared  with  the  '*' 
     option, and a new string entered. If the string is less than 
     12 characters long it will be followed by a  newline.  These 
     strings  are  not preset in the EPROM and will  need  to  be 
     entered  after a coldstart. All other meter  parameters  may 
     have ROM defaults.
     
3.36 L3MHEARD
     
     The  L3  Heard list records the identity of nodes  that  use 
     this  node for gatewaying their Net/Rom frames.  Every  time 
     that the node receives a Net/Rom frame from another node  it 
     is  either destined for the node or it is for gatewaying  to 
     another  node. When a frame is received for gatewaying,  its 
     passage  is recorded in the L3 Heard list. It functions  and 
     is managed in a manner similar to the main heard list,  with 
     the  callsign  of the sending node, time since it  was  last 
     heard,  total  number of frames gatewayed and level  2  port 
     number  from  which  it  was  received  being  recorded.  In 
     addition,  each  entry  records the  callsign  of  the  last 
     destination node. Each Net/Rom frame contains an originating 
     node callsign and a destination node callsign.  The entry in 
     the  table is associated with the originating node  callsign 
     and the final entry on each line shows the destination  node 
     of the last frame gatewayed from each origination node.
     
     The  L3 heard list is managed in a manner identical  to  the 
     main  heard list. It has a length set by the sysop and  will 
     drop  old entries from the end of the list when the list  is 
     full  or when a node hasn't gatewayed through the  node  for 
     more than 12 hours.
     
     The  initial  size of the L3 heard list is the same  as  the 
     size of the main heard list with both set to the ROM default 
     size.
     
3.37 BRATE
     
     This command only works with the PK96.
     
     The  PK96 hardware does not have the TNC2 hardware  switched 
     baud rates. Instead, it has software selected baud rates and 
     a  9600 baud modem as well as the 1200 baud modem. The  node 
     software  supports this by the inclusion in the ROM  default 
     values  of  initial baud rates and by a  sysop  only  switch 
     command to allow those to be changed during operation.
     
     Each baud rate may be set in the range 300 to 19200 baud  to 
     one  of 7 standard rates. This does not imply the code  will 
     reliably  handle data at 19200 but it seemed fun to  include 
     it. 
     
     The rom defaults may be overridden by the BRATE command. The 
     syntax of this is similar to the PARMS, MODE etc.  commands, 
     and  has two parameters. The first is the radio  port  rate, 
     the  second the RS232 rate. Values are in the range 0  to  6 
     and have the following meanings :
     
        Setting    Baud Rate
          0           300
          1           600
          2          1200
          3          2400
          4          4800
          5          9600
          6         19200
        
     When the BRATE command is used to change a setting, it  DOES 
     NOT  take  immediate  effect. It will take  effect  after  a 
     warmstart.  Coldstart  will,  of  course,  restore  the  ROM 
     defaults. A warmstart may be effected by the RESET command ( 
     as sysop ) or by powering off and on again the PK96.
     
     The  radio  baud  rate  setting  also  controls  the   modem 
     selection. If the selected baud rate is 1200, then the  1200 
     baud  modem is selected. If any other rate is selected,  the 
     9600  baud  modem  is  selected,  but  with  the  baud  rate 
     requested. 
     
     When  a CWID is sent ( if enabled ), the code will  reselect 
     the 1200 baud modem regardless of which modem was in use  in 
     order  to send a valid ID in tone. It also keys the tone  on 
     and  off  rather than switching between tones  as  the  TNC2 
     version  does. If the 9600 baud modem was in use,  the  9600 
     baud modem will be reselected after the CWID.
        
3.38 ARPTIMER
     
     The  ARP  timer  is managed as  for  other  parameter  based 
     commands such as PARMS, MODE etc. and is used to control the 
     ARP protocol machine.
     
     The  ARP table has, until now, been managed  manually.  With 
     this  version,  the node will automatically update  its  ARP 
     table  by  issuing  ARP requests  and  by  interpreting  ARP 
     requests and ARP replies.
     
     The  ARPtimer command has two parameters. The first  enables 
     (1)  or disables (0) the ARP service routine. The second  is 
     the  ARP  timer in minutes. When the node  receives  an  ARP 
     request  or reply, it will if appropriate make an  entry  in 
     the  table and set the timer to the ARPtimer value. It  will 
     then  decrement  once a minute. When it reaches 0,  the  ARP 
     entry  is  deleted. The ARP timer may be set  to  any  value 
     between  15 and 1440 ( i.e. quarter of an hour ans 24  hours 
     ).
     
     ARP requests/replies DO NOT apply to Net/Rom  encapsulation. 
     Entries   will   only  be  made  automatically   for   AX.25 
     connections.  For  Net/Rom  encapsulation,  make  the  entry 
     manually.
     
     If the ARP function is disabled, the system does two things. 
     Firstly,  it  will  stop  processing  received  ARP  frames. 
     Secondly,  it  will stop decrementing the  ARP  table  entry 
     timers thereby freezing the ARP table entries. As a  warning 
     to any attentive sysop, it will still generate ARP  requests 
     if it lacks a table entry but will ignore any response.
     
     Note  that  any entries in the ARP table made by  the  SYSOP 
     using  the ARP command will not be overwritten  by  received 
     frames and will not age.
     
     One  final  difference between this code and NOS.  When  NOS 
     receives  a  frame for transmission for which  it  needs  to 
     request  an  ARP  entry, it will  queue  the  frame  pending 
     address resolution. It will also send an ICMP source  quench 
     if  further  frames  are  received  whilst  the  request  is 
     pending.  This code will not. The IP frame that  causes  the 
     ARP request to be sent will be lost. So, if you PING it  and 
     it sends an ARP request you will get a response to the  PING 
     the next time you ping it.
     
4. Other Changes
     
     This  section covers the other miscellaneous changes to  the 
     software.
        
4.1 Command Processor
     
     The command processor has been altered. In general, but  not 
     in  all cases, commands only appear on the 'help' menu  when 
     they are enabled, so for example the 'BBS' command will  not 
     be  shown  unless  it  has been enabled  with  the  'BBS  +' 
     command.  The  exception is the sysop commands,  like  MODE, 
     LINKS  and PARMS, which are never shown to users but are  of 
     interest  to them. If the appropriate bit is set however  in 
     the  MODE  command  ( see 3.5.11 ), then for  the  sysop  or 
     manager,  all commands appear in the help prompt -  EVEN  IF 
     DISABLED.
     
     The help screen now shows commands in a combination of upper 
     and lower case characters.
     
     Some  commands  however are never displayed in  the  command 
     lists,  even when enabled. An example of this is  the  PARMS 
     command.  This is controlled by a flag associated with  each 
     command  in the same way that the command enable  /  disable 
     bit is associated with each command.
     
     An  addition to the command syntax controls this. A  command 
     is  displayed  to  a user only when it is  enabled  and  its 
     display bit is set. The display bit is set by using the  '+' 
     command with the letter 'D' following the '+'. Conversely it 
     is cleared by using the '-' option followed by 'D'. Hence to 
     display  the  PARMS command in the user  command  list,  the 
     sysop enters
     
                       parms + d
        
     or to hide the STATS command whilst still leaving it open to 
     users to use, the sysop enters
        
                       stats - D
        
     The 'D' may be in upper or lower case. 
     The full syntax of the command modifier is therefore
        
                       command [ - | +  [ D ] ]
        
     If  no letter follows the '+' or '-', or if it is  not  'D', 
     then  the  command enable / disable flag  is  modified.  The 
     letter 'D' may be in upper or lower case.

     It is frequently the case that a configuration file is created
     that can be uploaded to the node following a reset. It is also
     useful to be able to put comments into such a file. In order to
     assist this, any lines that start with a '#' are ignored by the
     switch.        

4.2 Beacon digi
     
     It is possible to set a digi in the address used for  beacon 
     packets.  Details  of how to do this are  contained  in  the 
     configuration  guide. Note that this is provided  for  those 
     rare occasions when there is a genuine need. This is  rarely 
     the case and should not be done unless really necessary.
     
4.3 Nodes Broadcasts after power-up
     
     The node will now broadcast its node table 60 seconds  after 
     power-up.  This is to ensure that the network is back to  an 
     operational  state  as  soon as possible  following  a  node 
     reset.  The reason for the short delay is to cater  for  the 
     situation  where the Sysop switches on the node  before  the 
     radio.
     
4.4 TexNet interface handling
     
     The TexNet interface is controlled by bit 7 of the user help 
     messages  word  ( MODE parameter number 12 ). If  set  to  a 
     value between 128 and 255, the TexNet interface is  enabled. 
     With values between 0 and 127 it is disabled.
     
     When disabled, operation is as normal.
     
     When enabled, the node will react to the TexNet "***  LINKED 
     to.."  messages.  When a level 2 connection to the  node  is 
     made, the node will examine the first line of text  received 
     by  the  node.  It must be a line of text  terminated  by  a 
     return  character,  and it must be the first  line  of  text 
     received. If any other line is received first, the node will 
     issue an error message.
     
     The line is checked to see if it starts with the text
        
                       *** LINKED to
     
     It  must start in the first character of the line and  match 
     exactly the string shown. If it does, the text that  follows 
     the string is scanned for a valid callsign. If one is found, 
     the user call is remapped so that any subsequent actions  of 
     that user are attributed to that new callsign. Any text that 
     follows  the  callsign  ( including any  TexNet  SSID  )  is 
     ignored.
     
     So, for example, if the string
        
                       *** LINKED to WB4DDP  E something else
     
     is received by a node ANODE:G8KBB from a station G9BF,  then 
     the session, otherwise attributable to G9BF will be remapped 
     to WB4DDP. The 'E' that followed was an SSID of 14, which is 
     ignored.
     
     The heard list will show the following
        
                       ANODE:G8KBB} TheNet X-1J4 (644)
                       TexNet(G9BF WB4DDP)
        
     Any  actions by that user, such as conferencing  or  onwards 
     connection to other nodes will use the callsign WB4DDP. If a 
     remote  disconnect  causes  reconnection to  the  node,  the 
     remapped callsign will continue to be used.
     
     Note  that only one station at a time may use  a  connection 
     between  a TexNet node and a TheNet node as it references  a 
     remapped  level  2  connection. It is  however  possible  to 
     connect to the callsign or alias of the node and invoke  the 
     remapping function.
     
     When  the  TexNet remapping is done, then the  connect  text 
     message  will be sent to the user if the connect message  is 
     set  and  enabled. If the node sees a packet with  a  TexNet 
     PID, it will note that station as TexNet in the heard list.
        
4.5 The USER command and CHOKE status
     
     The USER command shows stations connected to the node.  When 
     a user connects on to another node or downlinks, an entry is 
     formed  showing the two links on either side of a "<-->"  or 
     "<..>"  symbol. In this version, the '-' characters will  be 
     replaced  by  another  character if one  or  other  link  is 
     choked. The first '-' character is associated with the  left 
     hand  connection ( circuit or uplink ). The second with  the 
     other circuit or downlink.
     
     For a level 2 uplink or downlink, the "-" is replaced by 'C' 
     if the connection is choked. For Level 4 connections, the "-
     "  is replaced by one of 3 characters, "R" if it  is  choked 
     from the other end, "L" if it is choked from this end or "C" 
     if it is choked from both ends !.
        
5. CWID keyer.
     
     The  CWID  keyer  sends  the  station  callsign  in  CW   by 
     alternating between the two modem tones ( TNC2 ) or keying a 
     single tone ( PK96 ). This is nominally sent at 20 wpm  once 
     every  30 minutes, but the speed and period can  be  changed 
     remotely. 
     
     After  a delay of 30 minutes, the callsign is sent  appended 
     to  the  end of the next data packet that is sent  over  the 
     air.  There  is  a 500 ms delay after the end  of  the  data 
     packet before the call is sent.
     
     The program prefers to send CWIDs appended to ordinary  data 
     packets. However, if one minute after the CWID has  supposed 
     to be sent it is still pending because no data packets  have 
     been  sent, it will key up the transmitter anyway.  Persist, 
     TxDelay  and other parameters are honoured, but the  process 
     involves  changing  the  SIO  mode and  this  will  have  an 
     annoying effect on any packets being received in full duplex 
     mode.
     
     
6. Version X-2.
     
     X-1 was the first release of this code. The objective is  to 
     get  some  practical feedback and test the code  before  the 
     full release, version X-2, which I hope will be very similar 
     to this release ( X-1J2 ). I have been saying this for  some 
     time now, but things keep getting added. 
     
     Version  X-1A added the escape-N command and the  change  to 
     the connect, nodes and reset commands. The timers were  also 
     added to the stats command.
     
     Version X-1B removed all the escape commands apart from C, D 
     and P. It also added the MODE command and extended the + and 
     - command qualifiers to all commands.
     
     Version  X-1C  added  TALK, MANAGER  and  AUDIT.  The  SYSOP 
     command  was  enhanced and the INFO command was  altered  to 
     limit  the  length  of a message ( a  bug  in  the  original 
     version of TheNet ). The help screen was changed to  display 
     commands in a combination of upper and lower case.
     
     Version  X-1D extended the auditing and statistics to  cover 
     auditing everything but level 3, and statistics of the  CPU, 
     Level 1, Level 2 and timers.
     
     Version  X-1E  added  beacon  timer  control,  the   connect 
     redirector, the nodes dump facility, level 3 & 4  statistics 
     and the LINKS and CALIBRATE commands.
     
     Version  X-1F  added the CLOSEDOWN, DXCLUSTER,  ACL,  CTEXT, 
     HELP and BTEXT commands. Another parameter was added to  the 
     MODE command to control textual messages. The mod  suggested 
     by DF2AU to correct the DCD latchup was included. Additional 
     statistics were added covering CRC errors, receiver overrun, 
     transmitter underrun and framing errors.
     
     Version X-1G added mainly the IP router, with the  following 
     commands  to control it - IPROUTE, ARP, IPSTATS,  IPADDRESS, 
     IPBROADCAST. In addition, the ALIAS, BBSALIAS, HOSTALIAS and 
     DXCALIAS commands crept in, as did QUIT as an alternative to 
     BYE.  The  help  messages extended to enable  nodes  in  the 
     routes  list to appear as alias:callsign, and an extra  byte 
     on the MODE command allowed '#' nodes to be selectively  NOT 
     broadcast.  The order of HELP and HOST commands  changed  so 
     that  'h'  on  its  own gave help not  host.  The  code  was 
     optimised  with  some time critical parts being  recoded  in 
     assembler and a peephole optimiser being used for additional 
     improvements.
     
     Version X-1H fixed 3 bugs in X-1G.
     
     Version  X-1J  added the deviation meter  support  with  the 
     Meter  command and Mheard changes. In  addition,  parameters 
     were  added  to the MODE command for  slime  trail  control, 
     control of digipeating and reconnection to node. The command 
     syntax  of  Info,  Btext and Ctext was  changed  to  support 
     multiple lines and the Info message space was doubled to 160 
     bytes. Nodes broadcasts now occur 60 seconds after power  up 
     and  the ARP Digi bug fix was included. The level 4  minimum 
     retries was dropped to 1 and the PARM, MODE, IPSTATS,  METER 
     and  MTU  command syntax was extended to support  'offset  & 
     value' type operation. An MTU command was added to allow  IP 
     MTU  limits to be changed under software control.  The  node 
     alias  case  sensitivity bit and TALK 8 bit data  bits  were 
     added.
     
     Version  X-1J Release 2 fixed a couple of bugs, added the  S 
     meter  function, voltage reading functions, TexNet  handling 
     and extended the command enable / disable switches with  the 
     'command - D'  syntax.
     
     Version  X-1J release 3 was an interim version for  testing. 
     If you have it trade up to release 4 !
     
     Version  X-1J  Release 4 fixed the buffer loss  problem  and 
     implemented  the  automatic update of the ARP table  by  ARP 
     REQUEST  and  ARP REPLY. The node also  maintains  a  second 
     heard list of L3 Netrom nodes the gateway through the  node, 
     and a bug in the copying of digipeated frames in KISS mode 2 
     has been corrected. A defensive port flush function has been 
     added and link list integrity checking has been extended  to 
     check  reverse  links.  A  bug  in  handling  of   BBSALIAS, 
     HOSTALIAS and DXCALIAS has been fixed as has the clearing of 
     BBS,  HOST and DXCLUSTER on cold start. The USER list  shows 
     circuit choke status for patchcord connections.
     
     If  you read this and say 'Pah. it doesn't do XXXXX' or  'It 
     still  doesn't  do YYYYY' or anything of a  similar  nature, 
     don't  keep  it to yourself. Tell me. I may well do  it.  An 
     example of this are the many changes introduced into X1-J as 
     a result of suggestions mainly by KA2DEW.
        
7. The IP router
     
     The IP router co-exists in the node with the other software. 
     It is connected to the L2 and L3(Net/Rom) protocol machines, 
     and is managed from the L7 switch. It will accept data  from 
     L2  Datagrams, L2 Virtual Circuits or NOS protocol  extended 
     Net/Rom  frames. It will output to these 3 depending on  the 
     setting of the IProute and ARP tables.
     
     The  router supports the IP options of NOS and also does  IP 
     fragmentation.  Level  2 segmentation is not  supported.  In 
     addition,  ICMP is implemented in so far as it is needed  to 
     respond  to  errors  or PINGs. No higher  layer  support  is 
     provided,  i.e.  TCP  is  not  implemented,  ip_send()   and 
     ip_receive()  are  only implemented in so far  as  they  are 
     needed for ICMP. You can therefore PING it but anything else 
     will solicit an ICMP error message.
     
     The  default  MTU is 256 for AX.25 and 236 for  Net/Rom.  It 
     will  accept  longer datagrams than this  and  fragment  the 
     output  but it is not recommended as it merely  wastes  RAM. 
     The MTU command may be used to change this.
     
     It is possible to be creative in the use of L2 datagram  and 
     virtual circuits by use of the port default settings and the 
     ARP table. The algorithm used is :
     
     When a frame is to be sent, the ARP table is scanned for the 
     appropriate entry. The entry tells it what callsign to  use. 
     For  Net/Rom  encapsulation,  it  is  sent  to  the  Net/Rom 
     protocol  handler.  For AX.25  encapsulation  the  following 
     applies. The ARP table may indicate DG or VC. In this  case, 
     that  mode is taken. If there is no DG or VC entry, the  TOS 
     bits are examined. If the delay bit is set, a datagram  mode 
     is  selected.  If  not, and the reliability  bit  is  set  a 
     virtual  circuit  is selected. If neither bit  is  set,  the 
     default  mode for that port is used to select a mode  (  see 
     IPstats command, first parameter ).
     
     Port addressing is not supported at the moment. When a  node 
     stack  is being used, it is possible to set all nodes  or  a 
     subset of them to the same IP address. For more information, 
     see the file 'IPXLINK.DOC'.
     
     The  IP router is manually controlled - no rspf or rip.  The 
     node  will manage its ARP table automatically now.  See  the 
     section on the ARPtimer for more details.
        
8. MISC
     
     Anyone  interested  in  a copy of the  program,  drop  me  a 
     message  on  GB7MXM.#36.GBR.EU  Also,  any  suggestions  for 
     change gratefully received.
        
9. The AEA PK96
     
     This  section  describes the implementation of  TheNet  X-1J 
     release 4 for the PK96.  The PK96 version will not work in a 
     TNC2 and vica versa.
     
     It  is  important to read this section as it  describes  the 
     differences  from the TNC2 version and how to install it  in 
     the  PK96.  The  main documentation set  reflects  the  TNC2 
     version !. 
     
     In summary :
     
       
     The  PK96  version  does  not  have  the  ADC  support   and 
     associated  commands such as METER, ADC, ADC1 and  ADC2.  It 
     does not include meter displays in the heard list.
       A  command has been added to set the radio and RS232  port 
     baud rates ( BRATE )
       The software supports the hardware of the PK96 ( sic )
       The RS232 DCDB ( pin 23 ) signal to control the  crosslink 
     protocol  selection  has been implemented using  a  hardware 
     change to the PCB unless the PCB of the PK96 is version C or 
     later. 
       The MAIL LED gives a health check signal by flashing  once 
     a second
       The STA LED flashes whenever the node routes ( as  opposed 
     to sources or sinks ) a Net/Rom L3 or IP frame
       The  rear  panel  push switch may be  used  to  perform  a 
     coldstart
        
        
        
9.1. Rear panel push switch
     
     Pressing  the  rear panel switch will perform  a  coldstart. 
     This  may  be done at any time other than straight  after  a 
     reset when interrupts are ignored. The easy way to perform a 
     warmstart  is  to  switch the power off  and  on  again.  Be 
     careful  not to accidentally push the reset switch when  the 
     power is on !
        
9.2. ROM differences
     
     All  traces of the ADC have been removed. This also  extends 
     to the ROM parameters, and the default baud rates are stored 
     in   address   offsets  0x151  and  0x152   in   THENET1.X1J 
     respectively.
     
     Please  be  sure  to use the new patcher   and  the  correct 
     version  of  SETHELP. Using the PK96 commands  on  the  TNC2 
     files or vica versa will corrupt the code.
     
     Also,  note that bank switching is different with the  PK96. 
     No need for wires, just plug the EPROM in. The EPROM is  the 
     same  27C512 as is needed for the TNC2 version and it  needs 
     both files THENET1.X1J and THENET2.X1J in just the same way. 
     Only  THENET1.X1J needs to be patched with the ROM  defaults 
     however, and THENET2.X1J is 4K shorter as a consequence. The 
     HELP  text in THENET2.X1J may not however be 4 K longer.  It 
     may only extend to 0x6fff.
     
     The patcher therefore only modifies THENET1.X1J.
        
9.3. CROSSLINK selection
     
     The PK96 prior to version C of the PCB does not support  the 
     pin  23  RS232 mode selection signal for crosslink  or  dumb 
     terminal mode. If you have version C or later, insert JP5 to 
     connect the signal to RS232 pin 23. 
     
     IMPORTANT  - the signal goes directly to a CMOS gate  input, 
     so it must either be left open circuit ( for terminal mode ) 
     or connected to GROUND ( for crosslink or KISS protocol mode 
     ). Do not connect it to any other voltage.
     
     The easy way to ground it is to connect JP4 in the TNC which 
     puts  ground  on  pin  10. Connect pin  10  to  pin  23  for 
     crosslink,  and  remove  the  connection,  JP4  or  JP5  for 
     terminal mode.
     
     If  you have version B of the PCB it can be modified with  a 
     bit  of care. To see if it is version B, take the cover  off 
     and  look  at  the type number next to the power  on  /  off 
     switch. It should read something like 
     
                                013-135 B
        
     The  'B'  signifies revision B. If you want  to  modify  it, 
     proceed as follows. 
        
     IMPORTANT  -  I suspect that your supplier will take  a  dim 
     view of this with respect to the warranty. Your decision.
        
     1.      Find  yourself an anti-static work area and use  it. 
             You will be soldering to CMOS inputs.
     2.      Switch  off.  Remove power cord  and  other  cables. 
             Remove  the  case by removing the four  case  screws 
             (two down each side ), the RS232 connector  mounting 
             pillars on the back of the unit and the fixing  ring 
             for  the  audio connector jack socket, also  on  the 
             rear.
     3.      Remove  the  battery link connector (  next  to  the 
             battery  ) and subsequently take care not  to  short 
             circuit the battery.
     4.      Remove the 4 PCB mounting screws ( two at the  front 
             on each side, one near the DIN connector behind  the 
             reset  switch, one at the site of the  5V  regulator 
             behind the fuse ).
     5.      Slide the PCB backwards to clear the LEDs and  power 
             switch from the front panel and lift it clear.
     6.      Locate  pin  52 of the CPU. The CPU is  the  64  pin 
             device ( 0.07 inch pin spacing ) located between the 
             40 pin 8530 chip, the ROM and the RAM. It is denoted 
             U1 on the PCB silk screen. This pin is connected  to 
             ground  by tracks on both the top and the bottom  of 
             the  board. Use desoldering braid or  a  desoldering 
             tool to completely desolder it and carefully bend it 
             up  and out of the hole so that it can have  a  wire 
             soldered  to it. If you cannot  completely  desolder 
             it,  get a very fine screwdriver behind the  pin  on 
             the  top of the board and gently bend it out  whilst 
             applying  minimum heat to the pin with  a  soldering 
             iron  from below. Do it carefully and the  pin  will 
             come out without damaging the PCB tracks. 
     7.      Locate pin 12 of U15.  This is a 74HCT04 or  similar 
             located  between  the CPU, the 8530  and  the  modem 
             disconnect header. Connect a short fine wire on  the 
             top of the board from pin 12 of U15 to pin 52 (  the 
             one you bent out ) of the CPU.
     8.      Turn the board over. There is a short piece of track 
             between  pins  13  and  14 of U15.  Cut  it  with  a 
             scalpel.
     9.      Connect a 10K resistor between pins 13 and 14.  Keep 
             it  close to the board as you will need  to  replace 
             the board in the case soon.
     10.     Locate  pin 23 of the RS232 connector on the  bottom 
             of  the  board.  ( remember  that  RS232  connectors 
             number their pins along each row, so pin 23 will  be 
             third  from the end nearest the power  connector  of 
             the shorter row of PCB pins ). Connect a short piece 
             of wire on the bottom of the board from RS232 pin 23 
             to pin 13 of U15.
     11.     Remove  the  EPROM and replace it  with  the  TheNet 
             EPROM.
     12.     Connect  a  short piece of wire from pin 10  of  the 
             RS232 connector to ground. A convenient point to use 
             is  one of the connector mounting points  where  the 
             metal  parts of the connector body are  soldered  to 
             ground.
     13.     Replace  the  PCB  in the case and  refit  the  four 
             mounting screws. Check that there are no shorts from 
             the wiring to the case.
     14.     Connect  a voltmeter to pin 52 of the CPU  with  the 
             negative  lead  to ground. Apply power the  TNC  and 
             switch  on. All LEDs apart from the XMT  LED  should 
             light  and extinguish again if the node is  working. 
             The  MAIL  LED will then start to flash once  per  2 
             seconds. The voltmeter should read low ( i.e.  about 
             0  Volts  ).  Link pin 10 to pin  23  of  the  RS232 
             connector. The voltmeter should read 5V ( approx. ). 
             If  this  does not work correctly,  switch  off  and 
             recheck it.
     15.     Switch off and remove the power lead.
     16.     Replace the battery link connector.
     17.     Check the PCB mounting screws are tight and  replace 
             the  case. Replace the RS232 mounting  posts,  audio 
             connector ring and all 4 case screws.
     18.     Reconnect  the cables, switch on, and check  it  all 
             works.
     19.     Go get a beer, wine, cup of tea, coffee or  whatever 
             else tickles your fancy.
     
        
9.4. Crosslink connections and other RS232 matters
        
     The  RS232  connections differ to those of a TNC2.  The  RTS 
     input  controls whether the node can send data on the  RS232 
     interface,  and as there is no input on pin 20, it  must  be 
     used   for  the  crosslink  handshake.  Unfortunately,   the 
     crosslink handshake signals work the 'wrong way up' for  the 
     input, so it will be necessary to invert the signal into pin 
     4.  This only applies if you have a diode matrix or  similar 
     active  coupler.  To  crosslink  2  nodes  just  ignore  the 
     handshake signals.
     
     Finally, pin 4 will stop the node sending data to the  RS232 
     port if it is grounded. It can be grounded by switching  off 
     a  computer that drives this input. The effect is that  data 
     would be backed up waiting to be sent indefinitely. The node 
     would  eventually  run out of buffers. To  prevent  this,  a 
     modification  has been done to the code. Every ten  minutes, 
     the  node  checks to see if there was data to  be  sent  and 
     whether  any was sent. If there was, and no data  was  sent, 
     and if this also happened in the previous 10 minute  period, 
     it will purge the send list of all data waiting to be  sent. 
     It will also increment the 'port flush' counter.
     
     Just in case DCD gets stuck on ( this is not likely for  the 
     PK96  but  can occur with some TNC2 clones and the  code  is 
     also implemented in the TNC2 version ) the same process will 
     apply to the radio port.
     
     The  'port flush' counters have been added to the STATS,  at 
     the end of the list. Two numbers are shown, the first  being 
     the  counter  for the radio port, the second for  the  RS232 
     port. Under normal operations, neither should increment.  If 
     a  port  gets  stuck, then the counter for  that  port  will 
     increment  every ten minutes for which the port has data  to 
     send and can't send it.
     
     Finally,  the  64180  CPU  in the PK96  does  not  have  the 
     capability  to interrupt the CPU when the CTS  line  changes 
     state.  The  code  normally  uses  this  to  implement   the 
     crosslink  CSMA  protocol where a number of  nodes  share  a 
     common  diode matrix connection. Instead the code polls  the 
     line  status every 10 milliseconds. This means that it  will 
     not be very agressive in seizing the channel and other nodes 
     will  tend  to get a bigger share of the channel.  How  well 
     this will perform is not known - so if it gives problems let 
     me know and I'll increase the polling speed - at the expense 
     of  processing power. A better alternative is to use one  of 
     the many active crosslinks that poll nodes in sequence.
     
     
Dave G8KBB
7, Rowanhayes Close
Ipswich
IP2 9SX
England
