Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

baycom(9) [debian man page]

BAYCOM(9)						      Kernel Reference Guide							 BAYCOM(9)

NAME
baycom - amateur (AX.25) packet radio network driver for baycom modems SYNOPSIS
#include <linux/baycom.h> #include <linux/hdlcdrv.h> DESCRIPTION
The driver currently supports three different modems: ser12, par96 and par97. ser12 This is a very simple 1200 baud AFSK modem. The modem consists only of a modulator/demodulator chip, usually a TI TCM3105. The computer is responsible for regenerating the receiver bit clock. The modem connects to a serial port, hence the name. Since the serial port is not used as an async serial port, the kernel driver for serial ports cannot be used, and this driver only supports standard serial hardware (8250, 16450, 16550). par96 This is a modem for 9600 baud FSK compatible to the G3RUH standard. The modem does all the filtering and regenerates the receiver clock. Data is transferred from and to the PC via a shift register. The shift register is filled with 16 bits and an interrupt is signalled. The PC then empties the shift register in a burst. This modem connects to the parallel port, hence the name. par97 This is a redesign of the par96 modem by Henning Rech, DF9IC. The modem is protocol compatible to par96, but uses only three low power ICs and can therefore be fed from the parallel port and does not require an additional power supply. IOCTL CALLS
The ioctl calls follow the implementation in the hdlcdrv. BAYCOMCTL_GETMODEMTYPE returns the modem type (i.e. ser12 or par96) and the options in effect (currently only the source of the DCD signal) BAYCOMCTL_SETMODEMTYPE sets the modem type and the options. Only superuser can do this. BAYCOMCTL_GETDEBUG return some debugging values. Not always available. SEE ALSO
baycom (9), soundmodem (9), linux/drivers/net/hdlcdrv.c, AUTHOR
baycom was written by Thomas Sailer, HB9JNX/AE4WA, (t.sailer@alumni.ethz.ch). Linux 2.1.x 2 October 1996 BAYCOM(9)

Check Out this Related Man Page

HDLCDRV(9)						      Kernel Reference Guide							HDLCDRV(9)

NAME
hdlcdrv - HDLC amateur (AX.25) packet radio network driver SYNOPSIS
#include <linux/hdlcdrv.h> linux/drivers/net/hdlcdrv.c extern inline void hdlcdrv_putbits(struct hdlcdrv_state * s, unsigned int bits); extern inline unsigned int hdlcdrv_getbits(struct hdlcdrv_state * s); extern inline void hdlcdrv_channelbit(struct hdlcdrv_state * s, unsigned int bit); extern inline void hdlcdrv_setdcd(struct hdlcdrv_state * s , int dcd); extern inline int hdlcdrv_ptt(struct hdlcdrv_state * s); void hdlcdrv_receiver(struct device *, struct hdlcdrv_state *); void hdlcdrv_transmitter(struct device *, struct hdlcdrv_state *); void hdlcdrv_arbitrate(struct device *, struct hdlcdrv_state *); int hdlcdrv_register_hdlcdrv(struct device * dev, struct hdlcdrv_ops * ops, unsigned int privsize, char * ifname, unsigned int baseaddr , unsigned int irq, unsigned int dma); int hdlcdrv_unregister_hdlcdrv(struct device * dev); DESCRIPTION
This driver should ease the implementation of simple AX.25 packet radio modems where the software is responsible for the HDLC encoding and decoding. Examples of such modems include the baycom family and the soundcard modems. This driver provides a standard Linux network driver interface. It can even be compiled if Kernel AX.25 is not enabled in the Linux con- figuration. This allows this driver to be used even for userland AX.25 stacks such as Wampes or TNOS, with the help of the net2kiss util- ity. This driver does not access any hardware; it is the responsibility of an additional hardware driver such as baycom or soundmodem to access the hardware and derive the bitstream to feed into this driver. The hardware driver should store its state in a structure of the following form: struct hwdrv_state { struct hdlc_state hdrv; ... the drivers private state }; A pointer to this structure will be stored in dev->priv. hdlcdrv_register_hdlcdrv registers a hardware driver to the hdlc driver. dev points to storage for the device structure, which must be pro- vided by the hardware driver, but gets initialized by this function call. ops provides information about the hardware driver and its calls. privsize should be sizeof(struct hwdrv_state). ifname specifies the name the interface should get. baseaddr, irq and dma are simply stored in the device structure. After this function succeeds, the interface is registered with the kernel. It is not running, however, this must be done with ifconfig ifname up. hdlcdrv_unregister_hdlcdrv shuts the interface down and unregisters it with the kernel. hdlcdrv_putbits delivers 16 received bits for processing to the HDLC driver. This routine merely stores them in a buffer and does not process them. It is thus fast and can be called with interrupts off. The least significant bit should be the first one received. hdlcdrv_getbits requests 16 bits from the driver for transmission. The least significant bit should be transmitted first. This routine takes them from a buffer and is therefore fast. It can be called with interrupts off. hdlcdrv_channelbit puts a single bit into a buffer, which can be displayed with sethdlc -s. It is intended for driver debugging purposes. hdlcdrv_setdcd informs the HDLC driver about the channel state (i.e. if the hardware driver detected a data carrier). This information is used in the channel access algorithm, i.e. it prevents the driver from transmitting on a half duplex channel if there is already a trans- mitter on air. hdlcdrv_ptt should be called by the hardware driver to determine if it should start or stop transmitting. The hardware driver does not need to worry about keyup delays. This is done by the HDLC driver. hdlcdrv_receiver actually processes the received bits delivered by hdlcdrv_putbits. It should be called with interrupts on. It guards itself against reentrance problems. hdlcdrv_transmitter actually prepares the bits to be transmitted. It should be called with interrupts on. It guards itself against reen- trance problems. hdlcdrv_arbitrate does the channel access algorithm (p-persistent CSMA). It should be called once every 10ms. Note that the hardware driver must set the hdrv.par.bitrate field prior to starting operation so that hdlcdrv can calculate the transmitter keyup delay correctly. HARDWARE DRIVER ENTRY POINTS
The hardware driver should provide the following information to the HDLC driver: struct hdlcdrv_ops { const char *drvname; const char *drvinfo; int (*open)(struct device *); int (*close)(struct device *); int (*ioctl)(struct device *, struct ifreq *, int); }; drvname and drvinfo are just for informational purposes. The following routines receive a pointer to the device structure, where they may find the io address, irq and dma channels. open must be provided. It is called during ifconfig ifname up and should check for the hardware, grab it and initialize it. It usually installs an interrupt handler which then gets invoked by the hardware. close must be provided. It is called during ifconfig ifname down and should undo all actions done by open, i.e. release io regions and irqs. ioctl may be provided to implement device specific ioctl's. IOCTL CALLS
The driver only responds to SIOCDEVPRIVATE. Parameters are passed from and to the driver using the following struct: struct hdlcdrv_ioctl { int cmd; union { struct hdlcdrv_params mp; struct hdlcdrv_channel_params cp; struct hdlcdrv_channel_state cs; unsigned int calibrate; unsigned char bits; } data; }; Since the 16 private ioctl request numbers for network drivers were not enough, the driver implements its own sub request number with cmd. The following numbers are implemented: HDLCDRVCTL_GETMODEMPAR returns the IO parameters of the modem in data.mp. This includes the io address, irq, eventually dma, and ports to output a PTT sig- nal. HDLCDRVCTL_SETMODEMPAR sets the modem parameters. Only superuser can do this. Parameters can only be changed if the interface is not running (i.e. down). HDLCDRVCTL_GETCHANNELPAR returns the channel access parameters. HDLCDRVCTL_SETCHANNELPAR sets the channel access parameters. Only superuser can do this. They may also be changed using the kissparms command if using ker- nel AX.25 or the param command of *NOS. HDLCDRVCTL_GETSTAT statistics and status information, such as if a carrier is detected on the channel and if the interface is currently transmitting. HDLCDRVCTL_CALIBRATE instructs the driver to transmit a calibration pattern for the specified number of seconds. HDLCDRVCTL_GETSAMPLES returns the bits delivered by the hardware driver with hdlcdrv_channelbit. The bits are returned 8 at a time with the least signifi- cant bit the first one. This command may not be available, depending on debugging settings. HDLCDRVCTL_GETBITS returns the bits delivered by the hardware driver to the HDLC decoder. The bits are returned 8 at a time with the least significant bit the first one. This command may not be available, depending on debugging settings. SEE ALSO
baycom (9), soundmodem (9), sethdlc (8), linux/drivers/net/hdlcdrv.c, AUTHOR
hdlcdrv was written by Thomas Sailer, HB9JNX/AE4WA, (t.sailer@alumni.ethz.ch). Linux 2.1.x 2 October 1996 HDLCDRV(9)
Man Page