[Packet] MFJ 1270B help

[Dr. Gerald N. Johnson]

On Sat, 2006-02-18 at 02:38 -0700, W0OXJ wrote:
> Just got on VHF packet with the MFJ TNC and having trouble coming up with a
> config for my needs.The docs I have read are very poor as to applications.If
> anyone has found a config they like for covering the packet radio while at
> the keyboard,away from the keyboard,BBS ops,mailbox apps,etc it would help
> me utilize my station much better than present.
> 
> I have searched the web without much help.My TNC is as follows:
> 
> MFJ ENTERPRISES INC TNC-2-Extended BBS
> AX.25 Level 2 Version 2.0 + BLP 1.0
> Release 1.2.9x 12/23/92 - 32K RAM
> Checksum $B1
> 
> I am located in a shaded area with a very low ham population and exclusively
> use a mountain-top node running MYSYS I think.Any help with the node ops
> would help also.
> 
> Any config help or info on where to get help would be appreciated.
> 
> 73,
> Bob
> W0OXJ
> 
Generally the default settings are good EXCEPT for FRAC, RETRIES,
MAXFRAME, and PACLEN.

You have to set RS-232 handshaking to match your terminal program.

FRAC defaults to 3 seconds, the world with nodes works far better with
FRAC = 12. FRAC is counted from key down, not the end of transmission.

RETRIES are too few, too impatient. 15 is the maximum and far more
satisfactory.

Unless you are on a private frequency, I find that MAXFRAME of 1
improves throughput because nearly always the collisions are in the
first frame an AX.25 has no provisions for resending missed packets and
accepting those after a missed packet. So if MAXFRAME is 7, and 7 frames
are sent and there's a collision in the first frame, all 7 have to be
sent again, and again. With MAXFRAME = 1 I have seen throughput on a
busy frequency double.

FRAC has to be longer than twice MAXFRAME * PACLEN * data rate. That's
because the node sends a packet on before it acknowledges it to you.
PACLEN of 80 contributes to making FRAC work.

I use a set of scripts and a commercial DOS terminal program called YAM.
It allows scripting to recognize BBS and node responses and to
completely automate my BBS connections. In my scripts they store the
received information to a plain text file. Then I read and edit with
WordStar 4 which easily writes blocks to new files and there I put my
BBS read requests and my scripts send them to the BBS on the next
connection. YAM is not very portable or universal. The other handy thing
about WordStar is that it easily makes plain text files that are easily
sent.

A trick to the BBS scripts is the sequence of commands:

L
RM
KM
KM

L lists the new messages.

RM reads mine. And if I haven't any, the BBS returns a not found line
that my script uses to trigger a Bye command. Always leave the BBS with
Bye so your list range is updated. Else you will get more new messages
twice and more each new time you connect.

The double KM almost absolutely guarantees the not found response.
Because if I did have incoming mail, the first one won't get that not
found response as the RM didn't. The second KM gets the not found
response except for the case of a new message for me arriving since the
BBS executed the RM command. Here in Iowa that has happened maybe twice
in the last ten years.

Someday, I may get around to writing a stand alone packet automation
program, but there are some that don't do badly and what I have works
for me. I check into two BBS, one only 40 miles the other 100 miles off
through a fiber optic and RF path at least once a day and I'm a remote
sysop for the near one.

-- 
73, Jerry, K0CQ @ W0AK.#CIA.IA.USA.NOAM
All content copyright Dr. Gerald N. Johnson, electrical engineer