Documentation/networking/baycom.rst

   1 .. SPDX-License-Identifier: GPL-2.0
   2
   3 ===============================
   4 Linux Drivers for Baycom Modems
   5 ===============================
   6
   7 Thomas M. Sailer, HB9JNX/AE4WA, <sailer@ife.ee.ethz.ch>
   8
   9 The drivers for the baycom modems have been split into
  10 separate drivers as they did not share any code, and the driver
  11 and device names have changed.
  12
  13 This document describes the Linux Kernel Drivers for simple Baycom style
  14 amateur radio modems.
  15
  16 The following drivers are available:
  17 ====================================
  18
  19 baycom_ser_fdx:
  20   This driver supports the SER12 modems either full or half duplex.
  21   Its baud rate may be changed via the ``baud`` module parameter,
  22   therefore it supports just about every bit bang modem on a
  23   serial port. Its devices are called bcsf0 through bcsf3.
  24   This is the recommended driver for SER12 type modems,
  25   however if you have a broken UART clone that does not have working
  26   delta status bits, you may try baycom_ser_hdx.
  27
  28 baycom_ser_hdx:
  29   This is an alternative driver for SER12 type modems.
  30   It only supports half duplex, and only 1200 baud. Its devices
  31   are called bcsh0 through bcsh3. Use this driver only if baycom_ser_fdx
  32   does not work with your UART.
  33
  34 baycom_par:
  35   This driver supports the par96 and picpar modems.
  36   Its devices are called bcp0 through bcp3.
  37
  38 baycom_epp:
  39   This driver supports the EPP modem.
  40   Its devices are called bce0 through bce3.
  41   This driver is work-in-progress.
  42
  43 The following modems are supported:
  44
  45 ======= ========================================================================
  46 ser12   This is a very simple 1200 baud AFSK modem. The modem consists only
  47         of a modulator/demodulator chip, usually a TI TCM3105. The computer
  48         is responsible for regenerating the receiver bit clock, as well as
  49         for handling the HDLC protocol. The modem connects to a serial port,
  50         hence the name. Since the serial port is not used as an async serial
  51         port, the kernel driver for serial ports cannot be used, and this
  52         driver only supports standard serial hardware (8250, 16450, 16550)
  53
  54 par96   This is a modem for 9600 baud FSK compatible to the G3RUH standard.
  55         The modem does all the filtering and regenerates the receiver clock.
  56         Data is transferred from and to the PC via a shift register.
  57         The shift register is filled with 16 bits and an interrupt is signalled.
  58         The PC then empties the shift register in a burst. This modem connects
  59         to the parallel port, hence the name. The modem leaves the
  60         implementation of the HDLC protocol and the scrambler polynomial to
  61         the PC.
  62
  63 picpar  This is a redesign of the par96 modem by Henning Rech, DF9IC. The modem
  64         is protocol compatible to par96, but uses only three low power ICs
  65         and can therefore be fed from the parallel port and does not require
  66         an additional power supply. Furthermore, it incorporates a carrier
  67         detect circuitry.
  68
  69 EPP     This is a high-speed modem adaptor that connects to an enhanced parallel
  70         port.
  71
  72         Its target audience is users working over a high speed hub (76.8kbit/s).
  73
  74 eppfpga This is a redesign of the EPP adaptor.
  75 ======= ========================================================================
  76
  77 All of the above modems only support half duplex communications. However,
  78 the driver supports the KISS (see below) fullduplex command. It then simply
  79 starts to send as soon as there's a packet to transmit and does not care
  80 about DCD, i.e. it starts to send even if there's someone else on the channel.
  81 This command is required by some implementations of the DAMA channel
  82 access protocol.
  83
  84
  85 The Interface of the drivers
  86 ============================
  87
  88 Unlike previous drivers, these drivers are no longer character devices,
  89 but they are now true kernel network interfaces. Installation is therefore
  90 simple. Once installed, four interfaces named bc{sf,sh,p,e}[0-3] are available.
  91 sethdlc from the ax25 utilities may be used to set driver states etc.
  92 Users of userland AX.25 stacks may use the net2kiss utility (also available
  93 in the ax25 utilities package) to convert packets of a network interface
  94 to a KISS stream on a pseudo tty. There's also a patch available from
  95 me for WAMPES which allows attaching a kernel network interface directly.
  96
  97
  98 Configuring the driver
  99 ======================
 100
 101 Every time a driver is inserted into the kernel, it has to know which
 102 modems it should access at which ports. This can be done with the setbaycom
 103 utility. If you are only using one modem, you can also configure the
 104 driver from the insmod command line (or by means of an option line in
 105 ``/etc/modprobe.d/*.conf``).
 106
 107 Examples::
 108
 109   modprobe baycom_ser_fdx mode="ser12*" iobase=0x3f8 irq=4
 110   sethdlc -i bcsf0 -p mode "ser12*" io 0x3f8 irq 4
 111
 112 Both lines configure the first port to drive a ser12 modem at the first
 113 serial port (COM1 under DOS). The * in the mode parameter instructs the driver
 114 to use the software DCD algorithm (see below)::
 115
 116   insmod baycom_par mode="picpar" iobase=0x378
 117   sethdlc -i bcp0 -p mode "picpar" io 0x378
 118
 119 Both lines configure the first port to drive a picpar modem at the
 120 first parallel port (LPT1 under DOS). (Note: picpar implies
 121 hardware DCD, par96 implies software DCD).
 122
 123 The channel access parameters can be set with sethdlc -a or kissparms.
 124 Note that both utilities interpret the values slightly differently.
 125
 126
 127 Hardware DCD versus Software DCD
 128 ================================
 129
 130 To avoid collisions on the air, the driver must know when the channel is
 131 busy. This is the task of the DCD circuitry/software. The driver may either
 132 utilise a software DCD algorithm (options=1) or use a DCD signal from
 133 the hardware (options=0).
 134
 135 ======= =================================================================
 136 ser12   if software DCD is utilised, the radio's squelch should always be
 137         open. It is highly recommended to use the software DCD algorithm,
 138         as it is much faster than most hardware squelch circuitry. The
 139         disadvantage is a slightly higher load on the system.
 140
 141 par96   the software DCD algorithm for this type of modem is rather poor.
 142         The modem simply does not provide enough information to implement
 143         a reasonable DCD algorithm in software. Therefore, if your radio
 144         feeds the DCD input of the PAR96 modem, the use of the hardware
 145         DCD circuitry is recommended.
 146
 147 picpar  the picpar modem features a builtin DCD hardware, which is highly
 148         recommended.
 149 ======= =================================================================
 150
 151
 152
 153 Compatibility with the rest of the Linux kernel
 154 ===============================================
 155
 156 The serial driver and the baycom serial drivers compete
 157 for the same hardware resources. Of course only one driver can access a given
 158 interface at a time. The serial driver grabs all interfaces it can find at
 159 startup time. Therefore the baycom drivers subsequently won't be able to
 160 access a serial port. You might therefore find it necessary to release
 161 a port owned by the serial driver with 'setserial /dev/ttyS# uart none', where
 162 # is the number of the interface. The baycom drivers do not reserve any
 163 ports at startup, unless one is specified on the 'insmod' command line. Another
 164 method to solve the problem is to compile all drivers as modules and
 165 leave it to kmod to load the correct driver depending on the application.
 166
 167 The parallel port drivers (baycom_par, baycom_epp) now use the parport subsystem
 168 to arbitrate the ports between different client drivers.
 169
 170 vy 73s de
 171
 172 Tom Sailer, sailer@ife.ee.ethz.ch
 173
 174 hb9jnx @ hb9w.ampr.org