1 |
1625 |
jcastillo |
LINUX DRIVER FOR BAYCOM MODEMS
|
2 |
|
|
|
3 |
|
|
Thomas M. Sailer, HB9JNX/AE4WA,
|
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 |
|
|
picpar: 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. Furthermore, it incorporates a carrier
|
29 |
|
|
detect circuitry.
|
30 |
|
|
|
31 |
|
|
All of the above modems only support half duplex communications. However,
|
32 |
|
|
the driver supports the KISS (see below) fullduplex command. It then simply
|
33 |
|
|
starts to send as soon as there's a packet to transmit and does not care
|
34 |
|
|
about DCD, i.e. it starts to send even if there's someone else on the channel.
|
35 |
|
|
This command is required by some implementations of the DAMA channel
|
36 |
|
|
access protocol.
|
37 |
|
|
|
38 |
|
|
|
39 |
|
|
The Interface of the driver
|
40 |
|
|
|
41 |
|
|
Unlike previous drivers, the driver is no longer a character device,
|
42 |
|
|
but it is now a true kernel network interface. Installation is therefore
|
43 |
|
|
simple. Once installed, four interfaces named bc[0-3] are available.
|
44 |
|
|
sethdlc from the ax25 utilities may be used to set driver states etc.
|
45 |
|
|
Users of userland AX.25 stacks may use the net2kiss utility (also available
|
46 |
|
|
in the ax25 utilities package) to converts packets of a network interface
|
47 |
|
|
to a KISS stream on a pseudo tty. There's also a patch available from
|
48 |
|
|
me for WAMPES which allows attaching a kernel network interface directly.
|
49 |
|
|
|
50 |
|
|
|
51 |
|
|
Configuring the driver
|
52 |
|
|
|
53 |
|
|
Every time the driver is inserted into the kernel, it has to know which
|
54 |
|
|
modems it should access at which ports. This can be done with the setbaycom
|
55 |
|
|
utility. If you are only using one modem, you can also configure the
|
56 |
|
|
driver from the insmod command line (or by means of an option line in
|
57 |
|
|
/etc/conf.modules).
|
58 |
|
|
|
59 |
|
|
Examples: (use either method, not both)
|
60 |
|
|
insmod baycom mode="ser12*" iobase=0x3f8 irq=4
|
61 |
|
|
sethdlc -i bc0 -p type "ser12*" io 0x3f8 irq 4
|
62 |
|
|
|
63 |
|
|
Both lines configure the first port to drive a ser12 modem at the first
|
64 |
|
|
serial port (COM1 under DOS). The star ('*') instructs the driver to use
|
65 |
|
|
the software DCD algorithm (see below).
|
66 |
|
|
|
67 |
|
|
insmod baycom mode="par96*" iobase=0x378 irq=7
|
68 |
|
|
sethdlc -i bc0 -p type "par96*" io 0x378 irq 7
|
69 |
|
|
|
70 |
|
|
Both lines configure the first port to drive a par96 or par97 modem at the
|
71 |
|
|
first parallel port (LPT1 under DOS). options=1 instructs the driver to use
|
72 |
|
|
the software DCD algorithm (see below).
|
73 |
|
|
|
74 |
|
|
insmod baycom mode="par96" iobase=0x278 irq=5
|
75 |
|
|
sethdlc -i bc0 -p type "par96" io 0x278 irq 5
|
76 |
|
|
|
77 |
|
|
Both lines configure the first port to drive a picpar modem at the
|
78 |
|
|
second parallel port (LPT2 under DOS). The driver uses the hardware DCD
|
79 |
|
|
signalled by the picpar modem (see below).
|
80 |
|
|
|
81 |
|
|
The channel access parameters can be set with sethdlc -a or kissparms.
|
82 |
|
|
Note that both utilities interpret the values slightly different.
|
83 |
|
|
|
84 |
|
|
|
85 |
|
|
|
86 |
|
|
Hardware DCD versus Software DCD
|
87 |
|
|
|
88 |
|
|
To avoid collisions on the air, the driver must know when the channel is
|
89 |
|
|
busy. This is the task of the DCD circuitry/software. The driver may either
|
90 |
|
|
utilise a software DCD algorithm (a star after the mode string) or use a DCD
|
91 |
|
|
signal from the hardware (no star).
|
92 |
|
|
|
93 |
|
|
ser12: if software DCD is utilised, the radio's squelch should always be
|
94 |
|
|
open. It is highly recommended to use the software DCD algorithm,
|
95 |
|
|
as it is much faster than most hardware squelch circuitry. The
|
96 |
|
|
disadvantage is a slightly higher load on the system.
|
97 |
|
|
|
98 |
|
|
par96: the software DCD algorithm for this type of modem is rather poor.
|
99 |
|
|
The modem simply does not provide enough information to implement
|
100 |
|
|
a reasonable DCD algorithm in software. Therefore, if your radio
|
101 |
|
|
feeds the DCD input of the par96 modem, the use of the hardware
|
102 |
|
|
DCD circuitry is recommended.
|
103 |
|
|
|
104 |
|
|
picpar: the picpar modem features a builtin DCD hardware, which is highly
|
105 |
|
|
recommended.
|
106 |
|
|
|
107 |
|
|
|
108 |
|
|
|
109 |
|
|
Compatibility with the rest of the Linux kernel
|
110 |
|
|
|
111 |
|
|
The serial driver, the line printer (lp) driver and the baycom driver compete
|
112 |
|
|
for the same hardware resources. Of course only one driver can access a given
|
113 |
|
|
interface at a time. The serial driver grabs all interfaces it can find at
|
114 |
|
|
startup time. Therefore the baycom driver subsequently won't be able to
|
115 |
|
|
access a serial port. You might therefore find it necessary to release
|
116 |
|
|
a port owned by the serial driver with 'setserial /dev/ttyS# uart none', where
|
117 |
|
|
# is the number of the interface. The baycom driver does not reserve any
|
118 |
|
|
port at startup, unless one is specified on the 'insmod' command line. Another
|
119 |
|
|
method to solve the problem is to compile all three drivers as modules and
|
120 |
|
|
leave it to kerneld to load the correct driver depending on the application.
|
121 |
|
|
|
122 |
|
|
|
123 |
|
|
Further reading
|
124 |
|
|
|
125 |
|
|
Please take a look at http://www.ife.ee.ethz.ch/~sailer/ham/linux/hdlc.html
|
126 |
|
|
for further informations on the driver.
|
127 |
|
|
|
128 |
|
|
|
129 |
|
|
vy 73s de
|
130 |
|
|
Tom Sailer, sailer@ife.ee.ethz.ch
|
131 |
|
|
Packet Radio: hb9jnx@hb9w.che.eu
|