OpenBCM V1.13 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
CO2JA  > BPQ      11.01.97 14:05l 285 Lines 10379 Bytes #-10888 (0) @ WW
BID : 28921_CO2JA
Read: DG2VY DJ5QY DD6ZJ DG0LGF DG0OAW VK3EUB SP6ASD DL8HK GUEST
Subj: AX25.COM Docs Part 2/2
Path: DB0AAB<DB0KCP<DB0KFB<DB0CZ<DB0LJ<DB0ACH<ON4RAT<ON5VL<LX0PAC<ON7RC<
      ON1BWP<ON6AR<ON4AWP<ON1CED<ON4KTK<ON4TOR<ON1KPU<ON4MOU<F5TMZ<F6FOE<
      KC6UFM<XE3DX<XE1LM<CO2BQQ<CO2JA
Sent: 970103/0414Z @:CO2JA.#HAV.CUB.NA #:28921 [La Habana] FBB5.15c $:28921_CO2
From: CO2JA@CO2JA.#HAV.CUB.NA
To  : BPQ@WW


                AX25 driver for BAYCOM-like modem.

Frequently asked questions with answers.

Q: How to start quickly ?
A:
1. Start the ax25.com - most important parameters are COM base and irq.
   an example for COM1: ax25 -B3f8 -I4
   Now the driver takes control over the RS232 port and stays resident
   waiting for NOS orders...
2. Start KA9Q NOS (you need the one supporting packet drivers)
   and then type in:
     ax25 mycall <your callsign>
     attach packet 0x60 ax25 5 512
     trace ax25 111
   you should see packets being received now in trace window
   In most NOS versions you press F9 to get there.
3. Try to connect to another station by typing:
   connect ax25 <callsign>
or split ax25 <callsign> (split window session in JNOS)

This setup in far from complete - it's just to see whether the driver
cooperates with your hardware and it only allows you to work native AX.25
Refer to NOS manuals/docs/guides for setting up a complete TCP/IP station.


Q: I use -cd option (software DCD) and my station transmits over others
   - it looks like DCD status is always "free channel".
A:
Try to lower DCD threshold using -T option. Default value is 50.


Q: Are there any programs the driver dislikes ?
A:
Yes, SP9AUV discovered a small and nice program saying "Good Morning"
(in polish) disabled the driver completely on his PC. The reason is a mistery
as the program is not even resident.
If the driver does not work, try to start the DOS from a diskette with
simplest possible config.sys and autoexec.bat and give the driver
another try.


Q: How to change ax25 driver parameters ?
A:
If you realized that you have started ax25.com with not the parameters
you liked use termin.com to terminate the driver (e.g. termin 0x60)
and start ax25.com again with another option set.
At the moment there is no way to change the driver's parameters
after the driver is loaded.


Q: Can the ax25 driver be loaded into high RAM ?
A:
Yes, the driver can be loaded into UMB to save base memory.
However on my 386 when I tried to get UMB using EMM386.EXE
the driver performance become worse even when loaded into low RAM.
After trying UMBDR521 I got more UMB space (!?) and the driver
could run both in low and high RAM without any side effects.


Q: Can the driver work on an XT ?
   or better: Why the driver does not work on my XT ?!
A:
I can't see any reason why not (appart from CPU speed)
but haven't got a single report about the driver working on an XT.
In contrary I'm getting lot of claims that "BAYCOM works
but the ax25 driver does not". I don't understand why...

Suggested solution are:
1. Try to specify "p" option after -I - this may help.
2. Take KA9Q NOS version from UCSD.EDU - it locks interrupts for
   shorter amount of time when executing timer interrupt.

Q: How to check whether my PC is fast enough ?
A:
Do simple loopback by connecting DTR (data out) to CTS (data in).
Then start the driver at 300 bps and -cf option (full duplex).
Start the NOS, attach the packet driver (see "How to start quickly")
and let NOS transmit few packets (for example by enabling beacon
every 10 sek). Every packet sent should reapear as received in trace window.
If so try higher speeds, if not either your PC is too slow or something else
is wrong.


Q: How big packets can ax25 driver handle ?
A:
The receiver can handle 2048 byte frames.
This include address, control and data field but not CRC.
The transmitter buffer can hold up to about 4KB.
That is the amount of data which can be transmitted
per each PTT push.


Q: How to modify ax25.com buffer's sizes ?
A:
You may want to enlarge ax25.com buffers or make them smaller
to save memory. Go into assembler source ax25.asm which should be included
in this package - there is a comment about buffers around line 30.


Q: How to compile ax25.asm to get ax25.com ?
A:
You type in two DOS commands:
  tasm ax25
  tlink /t ax25


Q: How to connect my new modem to my RS232 port ?
A:
To cooperate with ax25 driver the modem should meet some
minimal requirements. Basic roules are:
1. The modem must provide decoded received data on CTS pin.
2. The driver outputs data to be transmitted on DTR pin.
   Modem should modulate and pass this signal to the radio.
3. Pin RTS controls the PTT of the radio. When it becomes positive
   the radio (together with the modem) should go into transmition mode.
4. Optionally the modem may provide carrier detect signal
   on DCD pin.
5. Don't forget about GND line which is the reference for all above signals

BAYCOM and many other modems build around TCM3105 or AM7910/11
for use with BAYCOM or TFPCX software conform to this scheme.

If you are going to build your own modem you may encounter
the problem of level conversion. RS232 ports of a PC
use +/- 12 V while most modem chips need TTl levels (0..+5V).
The most elegant solution is to use MAX232 or similar converter.
A simpler (but not that elegant) way of doing conversion is to use
CMOS inverters (I use 4049 with my TCM3105). Like on the picture below:


                _____    |\
RS232 DTR   ---|_____|---| \o_____ TTL modem TxD
             50 or 100 k | /
                         |/

                _____     /|
RS232 CTS   ---|_____|--o/ |_______ TTL modem RxD
                0.5 k    \ |
                          \|


                _____     /|     /|
RS232 DCD   ---|_____|--o/ |___o/ |____ TTL modem DCD
                0.5 k    \ |    \ |                      Modem Tx control
                          \|      \         ____+5V__      |
                                              |   _|_      |        Radio PTT
                                   Si diode  _|_  | | 3M   |          |
                                             /_\  |_|      |          |
                _____    |\     _____  | |+   |    |  |\   |  ___ B |/  C
RS232 RTS   ---|_____|---| \o--|_____|-| |----|----|--| \o---|___|--|
             50 or 100 k | /    2.2 k  | |            | /    10 k   |\
                         |/            10 uF          |/              | E
                                                                   -------
RS232 GND ---o
             |
            _|______ 0V

Inverters are supplied from 0 and +5 Volts - same levels
as modem TTL part. Note that there are no negative supplies anywhere.

The first scheme _does_ work because CMOS inputs accept voltages outside
power supply range thanks to input protective diodes.
The resistor limits the current flowing through these diodes.
You _must_not_ avoid it !

The second scheme does work as well because the threshold between
logical states in PC's RS232 is a bit above 0 Volts.
BAYCOM team recomends HC or HCT series circuits - they must have
a reason for it but I don't know what it is...

Please note that transmitted and received data polarity is not important
in packet radio. Only transitions matters. BUT polarity of DCD signal
DOES matter: positive means "channel is busy - another station transmiting"
while negative means "channel is free - now we are allowed to transmit".

The last scheme shows PPT circuit with simple watchdog timer. It limits
the transmition time and is recomended for unattended stations
to protect against software failures.

It is a good practice to ground unused RS232 inputs (RI, DSR, DCD).
Due to capacitive coupling to neighbour pins there may apear short spikes
on them - these will trigger extra interrupts thus loading the CPU.

Another warning: I've seen BAYCOM modem schematics with a transistor
driving CTS line. This solutions looks good because the
transistor's collector is supplied with negative voltage delivered
from TxD. But in practice I had nasty problems with such modems
when a longer (1 meter) cable was being used... the receiver would
not decode at all or it would receive only short frames.

The transistor drives CTS well but only when in saturation state.
In open state CTS becomes very sensitive to any pickup - and the main
source of pickup is TxD line - there is a square +/- 12V continues wave.
If your cable is long and there is no shield between the wires
this wave gets into CTS and makes decoding the true
modem signal hard... The problem goes away with inverter drivers
or short or shielded cable between modem and PC.

To find out if TxD really comes into CTS run BAYCOM,
connect the modem (but no radio) and switch to CARRIER 1 mode
(not needed for versions prior to 1.5). If you see RECV
instead of QRV you got the problem...

Have fun and _please_ send success/failure notes
and comments/hints/complaints to:

	email:  jalocha@chopin.ifj.edu.pl
	or      jalocha@vxcern.cern.ch
	or      jalocha@dxcern.cern.ch
	packet: SP9VRC@SP9ZDN.POL.EU (may not work from everywhere)

my home address:   Pawel Jalocha
		   Rynek Kleparski 14/7
		   PL-31150 KRAKOW (Poland)

Pawel, SR9VRC


 History file
===============

First versions on 25-27 of April 1992: first approach to transmitter
code caused inaccurate data transition timing. After fixing that bug
another one got in: after transmiting 7KB of data the driver refuses
to accept packets.


29 April 1992:

More-or-less stable version. Variables aligned to word boudary.


4 May 1992:

Defaults for tx head,tail and slot time are like most TNCs

6 May 1992:

Tx head, tail, slot time are printed out in bits and ms units.


August 1992:

An attempt to cure problems occuring on COM ports handling
IIR register not as I wished they did.
By the way minor code review.


November 1992:

There was a bug (just by mistyping) in version from August 1992
- when COM interrupt found UART in do-not-need-service state
it would not issue proper EOI. This could be responsible
for hangups not present in version of May.

-S option (sound effects) added. Every valid frame received
makes a 1/18 sec beep.

"p" sub-option after -I added (makes IRQ priority higher)

High-lighting added to some messages. Uses ANSI codes so may cause
a bit of disorder when ANSI.SYS is not loaded.


January 1993

Use byte I/O instead of word I/O when writing baud rate into 8250 UART.

-T option - threshold for software DCD (option -cd)

-cd option improved to be insensitive for asymetry
in modem's output (bad RXB for TCM3105).

Low pass filter DPLL for clock recovery replaced with random walk DPLL.
I don't really know which is better... random walk DPLL seems
to be a bit better... so I leave it in.




Read previous mail | Read next mail


 03.11.2026 17:09:53lGo back Go up