home *** CD-ROM | disk | FTP | other *** search
/ CD Actual 8 / CDACTUAL8.iso / docs / kernel-2.0 / char-dev / readme.bay < prev    next >
Encoding:
Text File  |  1996-07-11  |  7.0 KB  |  165 lines
  1.             LINUX DRIVER FOR BAYCOM MODEMS
  2.  
  3.          Thomas M. Sailer <hb9jnx@radio.amiv.ethz.ch>
  4.  
  5. This document describes the Linux Kernel Driver for simple Baycom style
  6. amateur radio modems. The driver supports the following modems:
  7.  
  8. ser12: This is a very simple 1200 baud AFSK modem. The modem consists only
  9.        of a modulator/demodulator chip, usually a TI TCM3105. The computer
  10.        is responsible for regenerating the receiver bit clock, as well as
  11.        for handling the HDLC protocol. The modem connects to a serial port,
  12.        hence the name. Since the serial port is not used as an async serial
  13.        port, the kernel driver for serial ports cannot be used, and this
  14.        driver only supports standard serial hardware (8250, 16450, 16550)
  15.  
  16. par96: This is a modem for 9600 baud FSK compatible to the G3RUH standard.
  17.        The modem does all the filtering and regenerates the receiver clock.
  18.        Data is transferred from and to the PC via a shift register.
  19.        The shift register is filled with 16 bits and an interrupt is signalled.
  20.        The PC then empties the shift register in a burst. This modem connects
  21.        to the parallel port, hence the name. The modem leaves the 
  22.        implementation of the HDLC protocol and the scrambler polynomial to
  23.        the PC.
  24.  
  25. par97: This is a redesign of the par96 modem by Henning Rech, DF9IC. The modem
  26.        is protocol compatible to par96, but uses only three low power ICs
  27.        and can therefore be fed from the parallel port and does not require
  28.        an additional power supply.
  29.  
  30. All of the above modems only support half duplex communications. However,
  31. the driver supports the KISS (see below) fullduplex command. It then simply
  32. starts to send as soon as there's a packet to transmit and does not care
  33. about DCD, i.e. it starts to send even if there's someone else on the channel.
  34. This command is required by some implementations of the DAMA channel 
  35. access protocol.
  36.  
  37.  
  38. The Interface of the driver
  39.  
  40. The driver interfaces to the AX25 stack via a KISS interface. The driver
  41. can be accessed as a character device with major 60. Major 60 is the first
  42. number of the local/experimental range. I did no steps to coordinate a
  43. major number for this driver, but I plan to do so in the near future.
  44. The driver supports multiple modems (currently four, as defined with
  45. NR_PORTS). It therefore responds to minor numbers 0 to 3. I recommend
  46. to access the driver via the special device files /dev/bc[0-3], which
  47. can be created with 'make bc'.
  48.  
  49.  
  50. Compiling and installing the driver
  51.  
  52. First unpack the source files into a directory. Then enter the following: (you
  53. must be root to do it)
  54.  
  55.   make dep
  56.   make
  57.  
  58. This will create the files baycom.o and setbaycom. baycom.o is as well copied
  59. to /lib/modules/`uname -n`/misc. If you plan to use kerneld, do the following:
  60.  
  61.   depmod -a
  62.  
  63. Do not forget to create the device special files if you install the driver the
  64. first time. This can be done with:
  65.  
  66.   make bc
  67.  
  68. You are now ready to use the driver. You can now activate the driver manually
  69. by entering
  70.  
  71.   insmod baycom
  72.  
  73. or leave this task to kerneld (if installed). Add the following line to
  74. /etc/conf.modules
  75.  
  76.   alias char-major-60 baycom
  77.  
  78.  
  79.  
  80. Configuring the driver
  81.  
  82. Every time the driver is inserted into the kernel, it has to know which
  83. modems it should access at which ports. This can be done with the setbaycom
  84. utility. If you are only using one modem, you can also configure the
  85. driver from the insmod command line (or by means of an option line in
  86. /etc/conf.modules).
  87.  
  88. Examples:
  89.   insmod baycom modem=1 iobase=0x3f8 irq=4 options=1
  90.   setbaycom -i /dev/bc0 -p ser12 0x3f8 4 1
  91.  
  92. Both lines configure the first port to drive a ser12 modem at the first
  93. serial port (COM1 under DOS). options=1 instructs the driver to use
  94. the software DCD algorithm (see below).
  95.  
  96.   insmod baycom modem=2 iobase=0x378 irq=7 options=1
  97.   setbaycom -i /dev/bc0 -p par96 0x378 7 1
  98.  
  99. Both lines configure the first port to drive a par96 or par97 modem at the
  100. first parallel port (LPT1 under DOS). options=1 instructs the driver to use
  101. the software DCD algorithm (see below).
  102.   
  103. The channel access parameters must be set through KISS parameter frames. The
  104. AX25 stack may be used to generate such frames. KA9Q NET derivatives such
  105. as WAMPES or TNOS offer the 'param' command for this purpose.
  106.  
  107.  
  108.  
  109. Hardware DCD versus Software DCD
  110.  
  111. To avoid collisions on the air, the driver must know when the channel is
  112. busy. This is the task of the DCD circuitry/software. The driver may either
  113. utilise a software DCD algorithm (options=1) or use a DCD signal from
  114. the hardware (options=0).
  115.  
  116. ser12: if software DCD is utilised, the radio's squelch should always be
  117.        open. It is highly recommended to use the software DCD algorithm,
  118.        as it is much faster than most hardware squelch circuitry. The
  119.        disadvantage is a slightly higher load on the system.
  120.  
  121. par96: the software DCD algorithm for this type of modem is rather poor.
  122.        The modem simply does not provide enough information to implement
  123.        a reasonable DCD algorithm in software. Therefore, if your radio
  124.        feeds the DCD input of the PAR96 modem, the use of the hardware
  125.        DCD circuitry is recommended.
  126.  
  127. par97: as far as I know it is in this respect equivalent to par96.
  128.  
  129.  
  130.  
  131. Compatibility with the rest of the Linux kernel
  132.  
  133. The tty interface gave me some headaches. I did not find a reasonable
  134. documentation of its interfaces, so I'm not particularly sure if I implemented
  135. it the way I should. Perhaps someone with a more profound knowledge about
  136. tty drivers could check the interface routines.
  137. The driver produces a rather high interrupt load. par96/par97 generates 600
  138. interrupts per second, ser12 1200 while transmitting and 2400 if hardware
  139. DCD is used, 3600 otherwise. If other device drivers disable interrupts
  140. too long, the performance of the driver drops (the packet loss rate increases),
  141. especially with the ser12 modem.
  142. There were also reports that under rather high load situations the driver
  143. drops frames. This might be either an interrupt problem, or an AX25 stack
  144. running in user mode might not get enough CPU time to process the packets
  145. before the drivers internal buffers overflow. There is no way to throttle
  146. the other radio stations from this layer, throttling must be done in the
  147. AX25 layer.
  148.  
  149. The serial driver, the line printer (lp) driver and the baycom driver compete
  150. for the same hardware resources. Of course only one driver can access a given
  151. interface at a time. The serial driver grabs all interfaces it can find at
  152. startup time. Therefore the baycom driver subsequently won't be able to
  153. access a serial port. You might therefore find it necessary to release
  154. a port owned by the serial driver with 'setserial /dev/ttyS# uart none', where
  155. # is the number of the interface. The baycom driver does not reserve any
  156. port at startup, unless one is specified on the 'insmod' command line. Another
  157. method to solve the problem is to compile all three drivers as modules and
  158. leave it to kerneld to load the correct driver depending on the application.
  159.  
  160.  
  161.  
  162. vy 73s de
  163. Tom Sailer, hb9jnx@radio.amiv.ethz.ch
  164. hb9jnx @ hb9w.ampr.org
  165.