Date: Fri, 12 Feb 93 04:30:14 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #40
To: tcp-group-digest
TCP-Group Digest Fri, 12 Feb 93 Volume 93 : Issue 40
Today's Topics:
ANSI stat()
Book on NOS!
Death of AX.25 (3 msgs)
G3RUH modem vs Direct FSK modems
New ax25? (8 msgs)
new firmware?
NOS & MSC under Windows NT?
nos bug query
NOSintro - TCP/IP over Packet Radio
NOS Xmodem Code release
Wampes latest version
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Wed, 10 Feb 93 09:42:45 EST
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: ANSI stat()
To: TCP-Group@UCSD.Edu, ssampson@sabea-oc.af.mil
The problem is not the availability of stat() but the fact that it
screws up royally on some DOS platforms and (Borland) compilers.
This is a fact - I was just trying to find out if anyone could say
exactly what the problem was and whose fault it was. If I remember
right it was left at Borlands door??
Yes I am confused also as I saw the same reference in the manual -
about it being ansi.
Doug
------------------------------
Date: Wed, 10 Feb 93 8:11:23 EST
From: John Ackermann AG9V <John.Ackermann@DaytonOH.NCR.COM>
Subject: Book on NOS!
To: Russell Nelson <nelson@crynwr.com>
You (Russell Nelson) write:
>
> Yeah! Finally! Ian Wade, g3nrw, wrote a book on NOS. I don't know
> enough about amateur radio to say if it adequately describes the
> AX.25, PBBS, and NET/ROM stuff. I can say for sure that it explains
> things I never understood before.
I got a complimentary copy from Ian on Monday. I haven't had a chance
to do more than dip into it yet, but it appears to be <very> well
done... a serious cut above the usual Tab Books crap that most ham books
seem to be these days.
I think I'll probably be recommending it to people who want something
more substantial than the currently available docs (mine included...).
Though he may not cover a lot of territory that the existing docs don't,
with the luxury of 300 pages to work with he can do a lot better job of
explaining things.
John AG9V
------------------------------
Date: Wed, 10 Feb 93 06:33:18 MST
From: rnielsen@tapr.ampr.org (Bob Nielsen)
Subject: Death of AX.25
To: MSgt S. Sampson <ssampson@sabea-oc.af.mil>
MSgt S. Sampson <noao!ssampson@sabea-oc.af.mil> writes:
> The problem is that you cannot have third party traffic on unspecified codes
> in the US. There is a precedent that we can use to do this anyway though.
> Pactor is an unspecified code, but the FCC doesn't care. So my feeling is
> that we go ahead and use whatever we want (Ethernet, JTIDS, TDMA, CSMA, etc).
> When we decide how we want the rules to read we just let the FCC know and
> they'll publish it. Until then I don't think they really give a damn nor
> should we. I'm not totally radical on this sort of anarchy, but in this case
> changing an useless protocol to something better (as in the Pactor case)
> improves communication and is therfore more important than waiting for the
> ARRL to get off their RTTY ass.
The Digital Committee suggested a change in the wording to the following:
97.109(e) No station may be automatically controlled while transmitting
third-party communications, except a station retransmitting digital radio
communications using an accepted protocol....
Hopefully the ARRL Board of Directors did not emasculate the wording
here. I have only seen part of what they approved and am a bit
disappointed, but hopefully the actual filing will be posted as soon as
it comes out, so there will be plenty of opportunity to comment.
Anyway, "accepted protocol" is a lot less restrictive than "AX.25"
(accepted by whom, the user?)
Bob Nielsen W6SWE
ax.25: w6swe@wb7tpy.az.usa.na Internet: rnielsen@tapr.ampr.org
amateur IP: 44.124.12.16 CIS: 71540,2364
------------------------------
Date: Wed, 10 Feb 1993 16:47:39 -0600 (CST)
From: MSgt S. Sampson <ssampson@sabea-oc.af.mil>
Subject: Death of AX.25
To: TCP-Group@UCSD.Edu
Concerning the death of AX.25 and the new protocol freedom petition:
Report and Recommendation
to the ARRL Board of Directors, from the
ARRL Committee on Amateur Radio Digital Communications
September 26, 1992
Here's a good idea:
-------------------
97.109 (e) No station may be automatically controlled while transmitting
third-party communications, except a station retransmitting digital radio
communications using an accepted protocol on the 6m and shorter
wavelength bands, or on 10m and longer wavelength bands in sub-bands
where automatic control is specifically authorized. The retransmitted
messages must originate at a station that is being locally or remotely
controlled.
Here's a bad idea:
------------------
97.216 Unattended Digital Station
(a) Any amateur station licensed to a holder of a General, Advanced or
Amateur Extra Class license may be an unattended digital station.
Yes, those unwashed heathens called Technicians, certainly shouldn't be
allowed to continue using packet radio. Seriously, I don't see why the
Technician Class has to give up priveleges to get unlimited protocol in
the ARS.
Steve, N5OWK (Tech+)
------------------------------
Date: Wed, 10 Feb 1993 16:47:39 -0600 (CST)
From: MSgt S. Sampson <ssampson@sabea-oc.af.mil>
Subject: Death of AX.25
To: TCP-Group@UCSD.Edu
Concerning the death of AX.25 and the new protocol freedom petition:
Report and Recommendation
to the ARRL Board of Directors, from the
ARRL Committee on Amateur Radio Digital Communications
September 26, 1992
Here's a good idea:
-------------------
97.109 (e) No station may be automatically controlled while transmitting
third-party communications, except a station retransmitting digital radio
communications using an accepted protocol on the 6m and shorter
wavelength bands, or on 10m and longer wavelength bands in sub-bands
where automatic control is specifically authorized. The retransmitted
messages must originate at a station that is being locally or remotely
controlled.
Here's a bad idea:
------------------
97.216 Unattended Digital Station
(a) Any amateur station licensed to a holder of a General, Advanced or
Amateur Extra Class license may be an unattended digital station.
Yes, those unwashed heathens called Technicians, certainly shouldn't be
allowed to continue using packet radio. Seriously, I don't see why the
Technician Class has to give up priveleges to get unlimited protocol in
the ARS.
Steve, N5OWK (Tech+)
------------------------------
Date: Wed, 10 Feb 93 06:50:16 MST
From: rnielsen@tapr.ampr.org (Bob Nielsen)
Subject: G3RUH modem vs Direct FSK modems
To: Steve_Wright@kcbbs.gen.nz (Steve Wright)
noao!Steve_Wright@kcbbs.gen.nz (Steve Wright) writes:
> Since there isn't a group specifically for packet RF bits (yet), may I ask
> this question in this excellant forum ...
>
> ahem ..
>
> what are the pro's and con's of direct FSK modems (G3RUH compatible)
> compared to the original RUH design which uses an EPROM lookup table.
>
> regards,
>
> Steve - ZL1BHD <- 'Big Hard Disk'
At the risk of continuing a discussion that probably doesn't belong here
(but where else, rec.radio.packet?)...
1. The G3RUH modem IS for direct FSK. The lookup table is used to generate
the shaping required for the desired spectrum.
2. The original design was by K9NG, so the term should be "K9NG
compatible".
Bob Nielsen W6SWE
ax.25: w6swe@wb7tpy.az.usa.na Internet: rnielsen@tapr.ampr.org
amateur IP: 44.124.12.16 CIS: 71540,2364
------------------------------
Date: Wed, 10 Feb 1993 09:15:18 -0500
From: goldstein@carafe.tay2.dec.com (k1io, FN42jk)
Subject: New ax25?
To: tcp-group@ucsd.edu
The absolutely last thing we should be doing about the routing problem
is worrying about the contention mechanism!
We have debated token passing before; it fails if there is a long
T/R time or many inactive stations who need to beep once every cycle.
But anyway the issue concerns routing, not contention. (What we nos
use on most simplex packet is a variant of Aloha, not CSMA. The
ARRL lies a lot, though they could chalk a lot of it up to gross
ignorance.)
I did once, as a sort of joke, post a proposal called "A802", as a
take-off on AX.25. Actually it's probably implementable. The joke
is that A802 has as much to do with IEEE 802.x as AX.25 has to dow
with CCITT X.25, which is to say, it takes some characters from the
name and does violence to the rest.
fred
------------------------------
Date: Wed, 10 Feb 93 10:42:12 CST
From: andyw@aspen.cray.com (Andy Warner)
Subject: New ax25?
To: tcp-group@ucsd.edu (TCP Group)
> We _DONT_ have to use callsigns for physical routing. We have to
> carry callsign information, it would be quite valid to send it
> as a tcp option field. Carrying that kind of information properly
> as opposed to netrom which fails to regularly identify the true
> source/destination user (only source/dest node) of a link.
> Not only that but all the BBS traffic can easily get hold of
> the callsign tcp option , or more likely extra tacked onto ip
> field.
Now, there's a novel idea. Is it feasable to eliminate the
physical address, due to the inherently broadcast nature of
the channel ? This would remove the need for ARP. Most
networks resort to physical addressing to reduce the workload
on hosts which are not the intended recipient. Currently
most radio interfaces run in the equivalent of promiscuous
mode, so the point is moot..
--
andyw. N0REN/G1XRL
andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835
------------------------------
Date: Wed, 10 Feb 1993 11:23:46 -0800
From: Lyndon Nerenberg <Lyndon.Nerenberg@ns.unbc.edu>
Subject: New ax25?
To: CCDRW@cc.newcastle.edu.au, iiitac@pyr.swan.ac.uk, tcp-group@ucsd.edu
There are a couple of things to keep in mind about link layer callsign
fields. First, the current six character field doesn't cut it any more.
I have seen numerous callsigns (most of them special allocations) that
exceed six characters. We must go to a variable length field.
Second, we need to scrap the association of SSID/callsign with both
identification and routing. I would prefer that the only callsign
in the frame be that of the *transmitting* station, however some
countries have tighter restrictions on identification. (Which brings
up a side argument - how badly do we want the new design restricted
by backwards regulations?) Actually the whole concept of the SSID
should be scrapped - it doesn't belong this far down the stack.
--lyndon
------------------------------
Date: Thu, 11 Feb 93 11:03:24 +1100
From: wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Subject: New ax25?
To: Alan Cox <iiitac@pyr.swan.ac.uk>, CCDRW@cc.newcastle.edu.au,
In atricle by Alan Cox:
>
> We _DONT_ have to use callsigns for physical routing. We have to
> carry callsign information, it would be quite valid to send it
> as a tcp option field.
I would like to see callsigns kept as unique identifiers a la Ethernet
addresses at the data link layer. But I agree, routing via callsigns
is an abomination.
Warren vk1xwt
------------------------------
Date: Wed, 10 Feb 93 15:08:08 -0800
From: John_Hays@NeXT.COM (John Hays)
Subject: New ax25?
To: tcp-group@ucsd.edu
Begin forwarded message:
>From: Alan Cox <iiitac@pyr.swan.ac.uk>
>Subject: Re: New ax25?
>We _DONT_ have to use callsigns for physical routing. We have to
>carry callsign information, it would be quite valid to send it
>as a tcp option field. Carrying that kind of information properly
>as opposed to netrom which fails to regularly identify the true
>source/destination user (only source/dest node) of a link.
Begin new message:
Actually, as I recall the regulations, the station needs to only ID
at 10 minute intervals and something about doing it in a manner that
the FCC can "grok" ... A plain ASCII frame with the transmitter's
callsign should do that. Simple Psuedocode follows...
main-loop ---
if (time-since-last-id >= 9-minutes-55-seconds &&
time-since-last-transmission <= 10-minutes) then send-id-packet;
John
------------------------------
Date: Thu, 11 Feb 93 16:34:10 +1100
From: wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Subject: New ax25?
To: Phil Karn <karn@qualcomm.com> (Phil Karn), CCDRW@cc.newcastle.edu.au,
In atricle by Phil Karn (Phil Karn):
>
> >> Yes, I think most of us agree AX25 needs replacing, lets experiment! with
> >> something new.
> >> I guess we have to define our problem a bit more and then we can start
> >>working
> >> on it.
>
> Well, I wasn't talking about replacing AX25, I was talking about creating
> a new network layer to sit between it and IP. But since you bring it up,
> yes, we could certainly use a new link layer protocol.
>
> >Ok, well start by replacing the CSMA Medium Access Control. How about
> >some form of Token Ring?
>
> There are, in my opinion, much better access protocols for radio channels
> than token ring. Token ring is complex, introduce long delays when the
> channel is nearly idle, and don't work well when loss rates are high
> (token recovery is the most complex and time consuming part of these
> protocols.)
>
> There are many things you can do to CSMA to make it work much better, you
> don't have to throw it out entirely.
I agree, it does need attention.
As for the something between AX.25 and IP, I'd rather see AX.25 replaced,
but I know the US is restricted in that area. What would this special
`middle-layer' have in it?
I'd prefer a replacement for AX.25 with a better MAC, and little else
apart from source/destination link addresses, a Protocol field, Data
and Sync fields, and a CRC. Connectionless and unreliable. What say?
Warren vk1xwt
------------------------------
Date: Thu, 11 Feb 93 23:07:46 -0800
From: Phil Karn <karn@qualcomm.com> (Phil Karn)
Subject: New ax25?
To: CCDRW@cc.newcastle.edu.au, tcp-group@ucsd.edu,
At 9:11 2/10/93 +0000, Alan Cox wrote:
>We _DONT_ have to use callsigns for physical routing. We have to
>carry callsign information, it would be quite valid to send it
>as a tcp option field. Carrying that kind of information properly
>as opposed to netrom which fails to regularly identify the true
>source/destination user (only source/dest node) of a link.
>Not only that but all the BBS traffic can easily get hold of
>the callsign tcp option , or more likely extra tacked onto ip
>field.
>
>Alan
The TCP option field would be the wrong place for ID information.
An IP header option would be better, but if you're going to carry
that overhead on every packet, why not make it do something useful?
Like using it as a link level address? There's really nothing wrong with
this.
NET/ROM's problems with indentification are a result of the layering
violation involved in making it talk to AX.25-only end stations. If you
build a properly engineered network with all stations speaking the
right protocol, this need not be a problem. Indeed, it's not a problem
with NET/ROM when the end-users also speak it (as they can with NOS).
Phil
------------------------------
Date: Thu, 11 Feb 93 23:07:46 -0800
From: Phil Karn <karn@qualcomm.com> (Phil Karn)
Subject: New ax25?
To: tcp-group@ucsd.edu
At 9:11 2/10/93 +0000, Alan Cox wrote:
|We _DONT_ have to use callsigns for physical routing. We have to
|carry callsign information, it would be quite valid to send it
|as a tcp option field. Carrying that kind of information properly
|as opposed to netrom which fails to regularly identify the true
|source/destination user (only source/dest node) of a link.
|Not only that but all the BBS traffic can easily get hold of
|the callsign tcp option , or more likely extra tacked onto ip
|field.
|
|Alan
The TCP option field would be the wrong place for ID information.
An IP header option would be better, but if you're going to carry
that overhead on every packet, why not make it do something useful?
Like using it as a link level address? There's really nothing wrong with
this.
NET/ROM's problems with indentification are a result of the layering
violation involved in making it talk to AX.25-only end stations. If you
build a properly engineered network with all stations speaking the
right protocol, this need not be a problem. Indeed, it's not a problem
with NET/ROM when the end-users also speak it (as they can with NOS).
Phil
------------------------------
Date: Wed, 10 Feb 93 21:11:11 -0800
From: Phil Karn <karn@qualcomm.com> (Phil Karn)
Subject: new firmware?
To: tcp-digest@ucsd.edu, "Jeffrey D. Angus" <jangus@skyld.tele.com>
At 10:37 2/9/93 -0800, Jeffrey D. Angus wrote:
>KISS Mode? The only things that would have to stay constant while re-using
>existing TNCs are the BELL-202 modem and the 8530 HDLC.
Actually, if you really want to redo amateur packet radio right from
the ground up, even these have to go. I'm becoming convinced that some
form of forward error correction (FEC) is essential, at least as an
option when links get bad, and this pretty much precludes HDLC framing.
I've been working on a sequential (Fano) decoder to a convolutional code
that runs fast enough on a 486 to handle a 56kb/s modem without any
trouble given channel bit error rates as high as several percent. This
would deal nicely with the 70cm radar problem we have in southern
California, among other things.
The reason FEC precludes HDLC framing is because you need a much more
robust synchronizing sequence to start off each frame. An HDLC flag is
much too short. You need something more like 32 or 64 bits long that
can be recognized reliably by a correlator even when a substantial
fraction (say 10%) of the bits are in error.
The Bell-202 modem I won't even talk about.
Phil
------------------------------
Date: Thu, 11 Feb 93 20:59:50 CST
From: jimh%kd4ldo.tcman.ampr.org@skeggi.vware.mn.org
Subject: NOS & MSC under Windows NT?
To: tcp-group@ucsd.edu
Has anybody out there attempted to compile NOS under Windows NT? I understand
that there are some problems with setjmp()/longjmp() under MSC 7.0 and wonder
if those problems can be solved using a 32-bit architecture.
What sorts of changes would I need to make to the makefile? Like most, I'm
more used to Borland products, so I'm not familiar with MS's compiler.
What I would like to do is compile NOS as an NT Console program, allowing it
to be multi-threaded. The DOS version works, but not without difficulty. The
lock files cannot be deleted (I believe this may be due to the way the file
is opened, and a small problem under NT's DOS server which does not exactly
emulate the DOS call.) And it seems to take *forever* for autoexc.nos to load.
This is most likely because NT is multitasking a multitasking environment, and
I think it would be solved by multithreading NOS.
Suggestions and replies can go either to tcp-group, me (at the address listed
below; not at the "Sender" address.), or both.
Jim
----
Jim Henderson, KD4LDO/W0 jimh@kd4ldo.ampr.org [44.94.249.38] on 144.99 MHz
Crystal, MN Internet: jimh%kd4ldo@skeggi.vware.mn.org
CIS: 71321,1461 Alt. Internet: hendersj@alpha.db.erau.edu
"Don't ask me how it works or I'll start to whimper!" - Arthur Dent
------------------------------
Date: Thu, 11 Feb 93 10:58:37 PST
From: "Erik Olson" <erik@marge.phys.washington.edu>
Subject: nos bug query
To: karn@qualcomm.com, tcp-group@ucsd.edu
>What you didn't say was what your FILES= parameter was in config.sys.
>If it was 5 (a common value) I could easily see you get into trouble.
>
>Phil
No, it's 20. Buffers=20 as well. I have now seen the effect triggered by
* SMTP server
* ftp server
* pop3 server
and in all cases it certainly doesn't seem to be a problem with having too
many files open (only shows 4 or 5).
I guess I'll come back to this one once someone else has seen it. :)
---
Erik Olson (at work) erik@marge.phys.washington.edu
University of Washington olson@phys.washington.edu
Cosmic Ray Lab, Phys. 405
------------------------------
Date: Wed, 10 Feb 93 14:31:48 -0800
From: brian (Brian Kantor)
Subject: NOSintro - TCP/IP over Packet Radio
To: brian@ucsd.edu
My complimentary copy of "NOSintro - TCP/IP over Packet Radio, an
introduction to the KA9Q Network Operating System" by Ian Wade G3NRW
just arrived.
It's 350+ pages, and appears to be quite thorough. The few chapters
I've had time to browse are rather readable, with good illustrations
and plenty of examples.
This might be the book that finally gets packet people off their
net/rom duffs and into real ham radio networking!
Well done, Ian!
ISBN 1-897649-00-2. Dowermain Ltd, publishers. Dunno the price.
- Brian
------------------------------
Date: Wed, 10 Feb 93 15:20:38 EST
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: NOS Xmodem Code release
To: nos-bbs@hydra.carleton.CA
I have place the nos TIPMAIL xmodem code at wg7j.ece.orst.edu
in incoming/nosxmdm.zip - it is about 80K.
This is based on wg7j107B code. Copy these files over that version.
More info is in the readme files. This includes the latest update to
the tipmail code.
With the addition of this code the tip mailbox with binary file
transfer (xmodem) has been working well on my system for over a
week. This allows standard xmodem binary file xfer using the NOS
BBS.
I will probably be doing some tweaking to the xmodem code - possibly
adding 1K blocks and batch support. As it stands it adds very little
to the size of NOS - about 2K.
I highly recommend utilizing this phone transfer to allow local beginners
to get the code. Everyone has a computer and modem.
I would hope the Johan would make this code a permanant part of his
future releases. It is fully ifdef'ed so it should not add any overhead
if you do not want it.
I also ifdef'ed the stopwatch code - why carry this baggage when you
don't need it. Besides it almost offsets the addition of the xmodem code.
Have fun and let me know if you have any problems.
Doug
------------------------------
Date: Thu, 11 Feb 93 13:46:12 MET
From: erb@insu7.etec.uni-karlsruhe.de (Olaf Erb)
Subject: Wampes latest version
To: tcp-group@ucsd.edu
B.T. writes:
> Date: Tue, 09 Feb 93 16:41:05 CET
> From: BARRY TITMARSH <BTITMARS%ESOC.BITNET@vm.gmd.de>
> Subject: Wampes latest version
> To: TCP-GROUP <TCP-GROUP@ucsd.edu>, pernici@mammolo.cnuce.cnr.it
>
> As far as i can see local to me the laters version being used on a number
> of official bbs's and local user to these bbs's is WAMPES-300193
Right, it's no official release, and maybe you know that db0sao, db0id and
other BBS's in Germany are auto-updated with Dieters versions.
> But in contacting the Authors and proters of the code I have not had a
> reply.
This is not true. I sent you two e-mails.
> In direct mail to the Author and a German Ham who ports the code to Linux
> I have only had short meaningless comments, which have given no indication
> of If and or Ever the wampes 930130 version will or will not be released.
Meaningless comments? I thought it's the truth:
> I had assumed that it had been infact released due to the Large number of
> 'Trusted users' in Germany actually seen on line with W-930130. The short
> responce i recived was 'Its not for me to decide when to release the code,
> Ask Deter the Author'
This was me, yes. It's not my decision if Dieter want to release a new
version of WAMPES! And you read what he said here yesterday.
I got a newer version than those at ucsd.edu from him, to test it with
Linux - and it does not compile clearly.. do you want such a version?
I bet one day later there would be many flames especially from YOU on this
list, Barry.
> Personaly if you like to wast email bandwidth then Do that.
> I have never had Any replies regarding Wampes.
This is not true. Maybe you should fix your mailer? Or generate resolvable
return-addresses?
> For me as a Linux user I stopped useing it months ago as the UNIX offers far
> more in the way of mail nntp smtp telnet and ftp and much much more.
It's your decision, all other users of WAMPES in Germany does not have
your problems, I think they're all satisfied. And maybe others in the world
can agree with this; I tried to help as much as I was able to via Email.
I hate writing something like this, but I cannot just delete such junk from
my mailer, sorry.
Flames to /dev/null, Barry. I thought you learned something.
Olaf
--
----------------------------------------------------------
! erb@insu1.etec.uni-karlsruhe.de dc1ik@db0sao.ampr.org !
----------------------------------------------------------
------------------------------
Date: Wed, 10 Feb 93 13:21:49 EST
From: DECARLIS@MTUS5.cts.mtu.edu
To: tcp-group@ucsd.edu
RMNC/FlexNet Software
Version 3.0
Sysop Documentation
we route everything
This documentation was put together under considerable time
pressure. The next RMNC/FlexNet version will contain completely
revised documentation. We ask for your understanding.
G. Jost, DK7WJ
J. Sonnabend, DG3FBL
Translated by
Don Moe, DJ0HC/KE6MN
Rev. 4 - 1 August 1990
Translated 20 October 1990
RMNC/FlexNet Software Version 3.0 Sysop Documentation
Contents__________________________________________________________
Page
1. Introduction................................................ 1 (Part 1)
2. Hardware.................................................... 2
2.1 Reset Card.............................................. 2
2.2 New Reset Card.......................................... 3
2.3 Battery Socket.......................................... 4
2.4 Function................................................ 4
3. Installation................................................ 5
3.1 Card Addresses.......................................... 5
4. Operation................................................... 5
4.1 The Phases of a Connection via the Digipeater........... 5
4.1.1 Link Setup....................................... 5
4.1.2 Information Transfer............................. 5
4.1.3 Link Failure..................................... 6 (Part 2)
4.1.4 Disconnect....................................... 6
4.2 Routing Methods......................................... 6
4.2.1 Routing via Destination Table.................... 6
4.2.2 Routing via Link Table........................... 7
4.2.3 Routing by SSID.................................. 7
4.3 User Commands........................................... 9
11 (Part 3)
4.4 Sysop Commands.......................................... 14
16 (Part 4)
4.5 Operational Aspects..................................... 21 (Part 5)
4.5.1 Protocol version AX.25V2......................... 21
4.5.2 Unproto Frames................................... 22
4.5.3 RNR Recovery..................................... 22
4.5.4 Reconnects....................................... 22
4.5.5 I-Polling Method................................. 22
5. Creating a Master EPROM..................................... 22
5.1 Parameter Compiler...................................... 23
5.2 EPROM Patch Slave....................................... 24
6. Future Developments......................................... 24
7. Usage Restrictions.......................................... 25
7.1 Exclusion of Liability.................................. 25
8. Command List................................................ 25
8.1 USER Commands........................................... 25
8.2 SYSOP Commands.......................................... 25
9. Appendix.................................................... 26 (Part 6)
9.1 p-Persistence Method.................................... 26
9.2 Layer-2 States.......................................... 26
9.3 External Clock.......................................... 28
9.4 Links to Net/ROM & TheNet Partners...................... 30
31 (Part 7)
36 (Part 8)
- i -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
Version History
2.0:4 13 Feb 89 Test DB0AAI
2.0:5 15 Feb 89 Test DB0AAI/DB0KT
- improved REJ recovery for WA8DED, etc.
- eliminated bug in command interpreter
2.0:6 20 Feb 89 Test DB0AAI/DB0KT/DB0DA
- optimized /ex (end of file)
- transmit time limitation
2.1 23 June 89 Test DB0EQ/DB0AAI
Distribution at HamRadio '89
- AX.25V2L2 version 1 support
- improved Layer 1 (ext. clock, RX)
- IO command implemented
- /SEND command in Converse mode
- general optimization
2.2 1 Oct 89 Test DB0AAI
- replaced FRACK with measurement of propagation delay of
<I> frames
- moved SETSEARCH to a text file to make usage more
flexible
- eliminated SLOTTIME parameter, set equal to TxDelay
- additional optimization of speed and program size
- altered handling of SSID range assigned to digipeater
allows operation of several nodes with the same callsign
3.0 1 July 90 TestDB0ODW, DB0KT, DB0DA,
DB0AAI,
DB0ZDF, DB0GV, DB0NWS,
DB0WST
- adaptive Sink Tree autorouter
- destination table
- automatic recognition of FlexNet neighbors
- measurement of propagation delay on link paths
- removed short wave restriction on C class licenses
--------------------------------------------------------------------------
For more information contact the FlexNet Group in Germany:
DK7WJ @DB0AIS.DEU.EU DG3FBL @DB0AIS.DEU.EU
Gunter Jost Jochen Sonnabend
Lichtenbergstr. 77 Annastr. 4
D-6100 Darmstadt D-6082 Moerfelden-Walldorf
Phone (49) 6151 715279 Phone (49) 6105 25590
or by sending a Fax to DG3FBL QRL: Fax (49) 6151 895718
--------------------------------------------------------------------------
- ii -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
1. Introduction;
Version 2 of the RMNC/FlexNet software differed significantly from
its predecessors, primarily regarding the usage of the hardware
and the interface presented to the user and operator.
RMNC/FlexNet-V3 has several new distinguishing features, the
autorouter doubtless being the most important.
The most significant innovations in the RMNC/FlexNet software are:
Hop-to-Hop Acknowledge
The most obvious improvement since RMNC/FlexNet-V2 is that
received frames from QSO's passing through the digipeater are
confirmed immediately. Previously, the frame may have been
transferred to another frequency and then forwarded; since V2 it
is acknowledged by the digipeater immediately and then forwarded.
This has improved the link reliability significantly. Whereas in
the past the probabilities of an unreliable transmission were
multiplied, today the entire route is as good as the worst link in
the path. In general this feature is called Hop-to-Hop
acknowledgement.
"Connectability"
Ever since the release of RMNC/FlexNet-V2, the users have been
able to connect to an RMNC digipeater and conduct QSO's with it.
The digipeater provides several service functions, such as
information about the current activity and the available links as
well as a conversation mode, etc.
Remote Control Capability
The RMNC/FlexNet software allows the operator to completely
control the digipeater remotely. This includes all layer 1 and 2
parameters, information texts, routing data, etc.
The installation of the new software is extremely simple: only the
EPROM's need to be configured and installed. In order to simplify
installing the parameters, a configuration program is provided for
IBM-PC's and compatibles. Details can be found under 3.
Installation and 6. Creating a Master-EPROM.
The software is free and may be freely copied in binary form
(EPROM) as long as the licensing rights are respected (see Section
7).
Limitations
Performance tests with the RMNC/FlexNet software have indicated
that the top speed for links and user access is around 9600 bps
per channel. At higher baud rates, error free processing of the
data can no longer be guaranteed, although this depends upon the
volume of traffic.
The software design allocates 100 bytes per QSO, thus limiting the
number of possible simultaneous QSO's. Tests have indicated that
this number of QSO's significantly exceeds the "natural" limit
imposed by the channel capacity. Although absolute numbers cannot
- 1 -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
be provided since these depend to a large extent upon the actual
configuration, they are in the vicinity of 100 per channel
computer.
Creation of the RMNC/FlexNet Software
The software described herein was developed by Gunter Jost, DK7WJ,
and Ekkehard Plicht, DF4OR, in Darmstadt, West Germany.
The first ideas for the software came to us in 1987, and the
development was done primarily in 1988. The initial tests were
conducted at our homes and later with the digipeater DB0ODW in
Odenwald. This digipeater is equipped with a complete 6809
development system which allows new versions to be tested after
uploading.
The software is written to 95% in C by DK7WJ and some parts such
as low level I/O in 6809 assembler. The code size, which was only
28 KByte in V2, has grown to 32 KByte, and thus there is no more
room available for further enhancements.
At this juncture we wish to thank all OM's who have helped us with
assistance or observations to get the software as error free as
possible. We especially thank all sysops who have contributed to
stabilizing the new version by patiently testing the software.
2. Hardware;
For the sake of completeness, we will first briefly recapitulate
the RMNC hardware requirements, even though the most important
aspects are certainly already known to the operators of previous
versions. For more detailed descriptions, please refer to the RMNC
documentation from the RMPRG, Frankfurt am Main, West Germany, c/o
DL2FCQ, Klaus-Dieter Friedrich.
A network node constructed with RMNC cards consists of 1 to 16
identical RMNC cards, each card containing the following:
mc6809 processor, 4 MHz clock
Z8530 SCC, serial port
6522 VIA, timer and parallel I/O
TCM3105 modem
Each card can be connected to a radio or an external modem. One or
more of the installed cards would be used for user access and the
remaining for the interlinks.
SCC
The serial data protocol, also know as HDLC, is generated by the
Z8530 SCC. The software allows a series of options for selecting
parameters such as the baud rate, full or half-duplex, external
clock, etc.
- 2 -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
Modem
The data from the SCC are sent either via the internal or an
external modem to the radio equipment. The internal modem, based
on the chip TCM3105, is designed for 1200 bps half-duplex. For
full-duplex operation, a hardware change is required, as was also
the case in the previous version of the RMNC software. The modem
is easily aligned with a single trimmer potentiometer. The layout
of the external modem connector (see figure 2) has not been
changed.
VIA
The VIA generates the necessary timing signals for system control
and serves to communicate with the other cards in the system. This
communication occurs over an 8-bit parallel bus and is thus quite
fast. The layout, the designations and the usage of the bus
signals has been changed since RMNC version 1.6! This is
irrelevant for normal operation, but is important for sysops who
wish to use their own hardware. (see figure 1).
Additionally the card address is determined by the VIA from a
three pole DIP switch. For further information see the section on
addressing the cards.
Processor
The mc6809 processor is clocked at 4 MHz, resulting in a bus cycle
time of 1 fsec. It is important that the clock rate of the
processor not be changed since the timing of the entire software
is based on 4 MHz! Tests at higher processor clock rates will take
place in the future.
2.1 Reset Card;
The old reset card from the RMNC can generally be used without
change. However, there is the possibility that the time constants
for the RESET as well as the PTT watchdog may be too short and it
may be necessary to lengthen them. A new Reset-I/O card has
recently become available and is strongly recommended for stable
operation.
2.2 New Reset Card;
The development of the new RMNC reset card was inspired primarily
by problems with the old card which occasionally did not provide a
clean Power-On reset. However, this signal is absolutely required
for reliable operation of the FlexNet software and also for the
battery backup. With the new card these problems should be solved.
In the case of software crashes, caused by such things as nearby
lightning strikes, there still is the possibility of loss of the
data stored in the RAM, and in such a case the EPROM default
values will be used. The card was developed by DK7WJ, and DC5YF
from the N rnberg PR group performed the layout.
The most important changes:
1. Clean Power-On reset even with fluctuating supply voltage. The
battery powered RAM is reliably protected from being
- 3 -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
overwritten. During a low-voltage condition, below
approximately 4.8 volts, a reset will occur.
2. The watchdog timing is performed using a digital counter chain
instead of monostable flip-flops so that the times remain
exact. A blockage of the watchdog as in a monoflop circuit is
now impossible.
3. The remaining free space was used to provide 16 switched
outputs and 16 inputs, which may be used for general control
and supervisory tasks.
4. The double-sided plated-through circuit board with solder mask
costs a little more but provides for quick and reliable
construction.
The following items should be heeded during construction:
1. One pin is incorrectly connected to the VG plug strip. This is
corrected by a solder bridge from 24a to 25a.
2. The 37 pole I/O jack must be mounted with plastic screws since
several circuit traces pass too closely to the mounting holes.
Alternatively, plastic insulating washers may be used.
3. Reliable operation of the card is only possible with 74HCxxx
IC's. xxHCTxxx or xxLSxxx are not suitable. (Exceptions: IC 7
and 8, see next).
4. IC 7 and 8 must be HEF40244. Although these are shown as
74HC244 in the parts list, these can be destroyed under certain
input conditions, since they have no Schmitt trigger inputs.
5. If the I/O lines are not required, IC's 6-12 can be left off.
6. Several clock signals are available on the bus to support
external modems:
4.1952 MHz : c2 (PCLK for the SCC's on the channel computers)
2.4576 MHz : a4
1.2288 MHz : a3
614.4 kHz : a2
Further clock frequencies can be taken from IC13 and put onto
unused bus lines as needed. If no clocks other than PCLK are
required, IC13 can be left off. The clock lines may be loaded with
a maximum of 2 LS-TTL loads.
For reasons of economy, a protection circuit on the bus was not
provided. After being unplugged from its connector, the card must
be handled according to customary CMOS practice. It may be plugged
in or removed only when the computer is powered off.
The power consumption of the card is less than 10 mA, assuming
open switch inputs. Each switched input draws an additional 0.5
mA.
- 4 -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
Input Circuitry
The inputs may be connected to voltages, switch contacts or opto-
coupler outputs. Switch contacts and opto-couplers are simply
connected from the input to ground. When closed, 0.5 mA of current
will flow.
Opto-coupler outputs can be connected directly without pull-up
resistors. Collector to the input, emitter to ground.
The inputs allow a maximum of 24 volts, and the switching
threshhold lies between 2 and 3 volts.
Output Circuitry
The outputs can drive relays or even opto-couplers directly. The
outputs can withstand a maximum of 50 volts in open condition and
can pass a maximum of 500 mA. Relays are switched to ground; thus
the other side of the relay coil must be attached to the voltage
required by the relay. A diode, such as 1N4148 with cathode on
plus, must absolutely be wired across the relay coil!
Alternatively, the "D" pin (18) of the connector can be attached
to the supply voltage of the relay, in which case the ULN internal
protective diodes take over. If LED's or opto-couplers are to be
driven, their anodes can be connected to +5V. A 220 Ohm resistor
limits the current flow to approximately 10 mA.
Warning: The outputs are not protected against short-circuits. In
the case of a current flow of more than 500 mA, the ULN's will be
destroyed. Thus IC sockets are recommended, as they don't cost
much more than fuses.
During reset the switch outputs are disabled reliably.
The state after reset can be programmed into the EPROM like all
other parameters. The I/O command has been included in the PC
compiler since RMNC/FlexNet version 2.1. In the case of battery
backup, the output states will be stored. When attaching external
equipment however, be aware that these are only switched on after
some delay following a reset.
If an older reset card is being replaced by the newer model, it
can be still be used with LED's for monitoring the bus if the 4060
and 4528 IC's are removed.
2.3 Battery Socket;
The RMNC/FlexNet software stores all QSO parameters in RAM. A loss
of power thus will cause the digipeater to forget all QSO's with
and over it. The majority of QSO's via the digipeater will
continue without hop-to-hop acknowledgement if the digipeater no
longer stores any unacknowledged frames. Furthermore, all
parameters changed by the sysop will be reset to the default
values. To retain the parameters during a power outage, a battery
socket may be installed on the master card. Only RAM must be
buffered, which is also on the slave cards. The second RAM on the
master card does not need a battery socket since it is
automatically initialized upon reset. This socket only makes sense
- 5 -
Msg# 316055 To: RMNC @WW From: DG3FBL Date: 24Oct92/0651
Subject: Part 2 / english FlexNet documentation
Bulletin ID: FLX9210_2_8
Path: DB0LX!DB0AAA!DB0MWE!DB0KCP!DB0CZ!OE9XPI!HB9EAS!DB0GE!DB0LJ!DB0GV
de DG3FBL @ DB0GV
RMNC/FlexNet Software Version 3.0 Sysop Documentation
with the new reset card since the old card did not always provide
a clean reset signal.
2.4 Function;
The function of the hardware does not differ significantly from
earlier versions. Merely the bus communication has been
restructured. Previously all cards in the system had equal
priority and sequentially got the chance to exchange data. Now the
cards are arranged in a so-called master-slave system. Here the
card with user access is the master and all others are the slaves.
The entire bus communication takes place under control of the
master; it interrogates the other cards sequentially whether they
have data and then forwards it if necessary.
Thus the only difference between the cards is that the master has
a different EPROM than the slaves. This provides the advantage
that only the master card needs to be programmed with parameters,
as all slave cards receive their parameter information from the
master.
Following a reset, the master determines how many cards are in the
system and at which addresses. These are then initialized
according to the parameters in the EPROM. If a card should fail
during operation, this will be automatically recognized by the
master after the resulting watchdog reset. This card will no
longer be interrogated, assuming that defective hardware does not
block the bus.
After a reset, all cards are ready to support a QSO. A connection
via the digipeater also counts as a QSO. The software on the link
cards autonomously carries out a layer 2 connection and directs
all received data to the bus so that it can be redirected by the
master to other links as necessary.
3. Installation;
3.1 Card Addresses;
When installing the RMNC/FlexNet software, addresses must be
assigned to the cards. Here it is important to note that the card
with the master EPROM has no address! It is easily identified
since it is the only one with a Master EPROM. The DIP switch on
this card must be set with all three switches open!
The remaining cards are addressed as before with the peculiarity
that each DIP switch is set to 1 higher than the card address.
This results in possible card addresses of 1 to 8. The cards may
be addressed in any desired order and vacant addresses are
irrelevant. For card addresses from 9 to 16, DIP switch settings
from 1 to 8 are used, but a value other than FF hex must also be
entered at address FF00 hex into the slave EPROM.
Example:
Master Slave-1 Slave-2 Slave-3 Slave-4
- 6 -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
111 (must) 000 001 100 010
Addr.0 Addr.1 Addr.2 Addr.5 Addr.3
In the display of the parameter table (P command), the master will
always appear at the address 0!
The EPROM's can then be installed. Only one master EPROM is used
here and all other cards receive identical slave EPROMs. To be
precise, it is irrelevant whether the master EPROM is used on a
link or user access, however it is recommended that it be on the
user access.
It may be necessary to make a small hardware change: replace the
capacitors for the PTT and watchdog time constants. In order to
determine whether the time constants are long enough, we recommend
the following procedure:
Enter the CAL command numerous times on all channels. This command
causes the corresponding card to transmit for a minute,
interrupted every 15 seconds to reset the PTT watchdog. If the
command executes correctly without causing a PTT alarm, the time
constant is OK, otherwise the capacitor on the card must be
enlarged.
The RMNC should now be ready for operation. After switching on
power, all LED's on the reset card turn on. Shortly thereafter a
characteristic counting of the 8 data lines will be seen
indicating that the system is determining which cards are
installed and their addresses. Immediately following the reset, a
beacon packet will be transmitted by the master card.
4. Operation;
Operation with an RMNC/FlexNet V3 node appears to the user
initially just like V2, not much has been changed. However, it is
no longer necessary to provide the complete digipeater path,
rather only the entry and exit digipeaters. The hop-to-hop
acknowledgement, available since V2, is probably already well
known by the users. The newly implemented autorouter represents
the actual improvement, making it significantly easier for the
user to initiate a connection.
4.1 The Phases of a Connection via the Digipeater;
4.1.1 Link Setup;
During the setup of a connection, the <SABM> frames received by
the digipeater are forwarded normally, a <UA> is not sent
immediately. Thus a connection will only be established if the
called station is actually there.
If the called station answers with a <UA>, this is forwarded to
the caller. At this point two QSO's are entered into the QSO
table, one from the calling to the called station and one in the
other direction.
- 7 -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
4.1.2 Information Transfer;
During the information exchange, hop-to-hop acknowledge is in
effect. Each <I> frame from one station or the other is
immediately acknowledged by the digipeater. It then attempts to
pass the <I> frame over the corresponding link.
Example:
Station A 1:<I> --> Digi
2:<Ack> <-- Digi
Digi --> 3:<I> --> Station B
Digi 4:<Ack> <--
Time sequence: 1, 2, 3, 4
Repeats due to interference or collisions will thus only occur on
one interlink path and not over the entire connection route. This
is particularly interesting when several digipeaters using this
principle are employed.
4.1.3 Link Failure;
If during an information exchange one side of the connection
collapses, the connection will be broken by the digipeater with a
message such as "*** DB0xxx --> link failure". This informs the
partner station that something did not work. Such a link failure
would generally occur if the digipeater requires more than the
preset number of repeats in order to forward an <I> frame.
4.1.4 Disconnect;
If station "A" executes a disconnect, this will be acknowledged
immediately by the digipeater. The digipeater will then attempt to
terminate the connection to station "B". If no further data from
this QSO is still in memory for station "B", the disconnect will
occur immediately. If there are unacknowledged data from this QSO,
they will be forwarded first and the connection will then be
terminated. If "B" sends further data to station "A" during this
period, the data are discarded.
4.2 Routing Methods;
As previously briefly mentioned, it is no longer necessary during
establishment of a connection to supply all digipeater callsigns,
rather only the entry and destination or exit digipeater. The
routing sequence: routing via destination table, routing according
to link table, routing by SSID.
4.2.1 Routing via Destination Table;
The first method is based on routing according to callsign
information. In this case the digipeater finds the next callsign
in the digipeater field of the received frame and compares it with
a table of calls maintained by the autorouter in a destination
table. If a callsign match is found, the frame will be sent on the
corresponding channel to the neighboring digipeater leading in the
direction of the goal.
- 8 -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
Example:
DB0ODW has the following links:
1:DB0KT
2:DB0EAD
3:DB0IE
and knows the following destinations:
DB0ONA, DB0AAI, etc.
The frame:
<fm DF4OR to DK7WJ via DB0ODW,DB0AAI>
will be extended to:
<fm DF4OR to DK7WJ via DB0ODW,DB0KT,DB0AAI>
^^^^^
next callsign
DB0KT is the next callsign in the digipeater field and is
known to DB0ODW as link partner, via channel 1. Thus the
frame is sent out via channel 1, even though no direct link
to DB0AAI exists.
4.2.2 Routing via Link Table;
If the autorouter finds no entry in the destination table, the
next step is to search through the link table entered by the sysop
for matches. If a route is found here, the frame is sent via this
port.
Example:
DB0ODW has the following links:
1:DB0KT
2:DB0EAD
3:DB0IE
4:DB0XXA #
The frame:
<fm DF4OR to DK7WJ via DB0ODW,DB0XXA>
will be sent via port 4 even though no entry exists in
the destination table.
4.2.3 Routing by SSID;
A further method of routing the frames is based on the SSID, which
was assigned to the digipeater. In the RMNC/FlexNet V3 software,
individual channels (card addresses) can be assigned SSID's, also
called port numbers here. This takes place with the PARMS command.
In order to use routing by SSID, the user supplies the SSID for
the port over which his frame is to be sent.
- 9 -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
Example:
DB0ODW has the following link information:
=>L
links: channel port
1:DB0KT 1 4
2:DB0EAD 2 3
3:DB0IE 3 5
The digipeaters DB0KT, DB0EAD and DB0IE are so-called permanent
links, i.e. entered with their callsigns. Furthermore an
assignment of SSID's to the channel numbers is performed: channel
0 has SSID 0, channel 1 SSID 4, channel 2 SSID 3, etc. If a
connection request arrives from an link and specifies an SSID for
DB0ODW, the frame will sent on the channel having this SSID:
<fm DF4OR to DK7WJ via DB0ODW-3>
This frame will be send via channel 2, which has the SSID 3.
However, the following appears on channel 2:
<fm DF4OR to DK7WJ via DB0ODW-0*>
Thus someone copying on channel 2 will know where the frame came
from. The SSID is thus turned around. Somewhat complicated?
Possibly, or inadequately explained. The best is to make some
tests in order to see the effects better.
Here are a couple other examples which should clarify the
principle of routing by SSID:
Digipeater DB0ODW
Card 0 +-< Card 0 <-- A to B v
SSID 0 | SSID 0 DB0ODW-7
|
Card 1 | Card 1
SSID 3 | SSID 3
|
A to B v DB0ODW-2* Card 2 <--+ Card 2
<-- SSID 7 SSID 7
Card 3 Card 3
SSID 4 SSID 4
Station A sends a frame to station B via DB0ODW-7, i.e. the frame
is output via SSID 7. The output appears "via DB0ODW-2", thus with
the SSID of the port on which the frame was received. The SSID was
swapped. And the answer from B to A goes as follows:
- 10 -
Msg# 316063 To: RMNC @WW From: DG3FBL Date: 24Oct92/0846
Subject: Part 3 / english FlexNet documentation
Bulletin ID: FLX9210_3_8
Path: DB0LX!DB0AAA!DB0MWE!DB0KCP!DB0CZ!OE9XPI!HB9EAS!DB0GE!DB0LJ!DB0GV
de DG3FBL @ DB0GV
RMNC/FlexNet Software Version 3.0 Sysop Documentation
Digipeater DB0ODW
Card 0 +-> Card 0 --> B to A v
SSID 0 | SSID 0 DB0ODW-7*
|
Card 1 | Card 1
SSID 3 | SSID 3
|
B to A v DB0ODW-2 -- Card 2 >--+ Card 2
> SSID 7 SSID 7
Card 3 Card 3
SSID 4 SSID 4
Another example:
Digipeater DB0ODW
C to D v DB0ODW-4 -- Card 0 >--+ Card 0
> SSID 0 | SSID 0
|
Card 1 | Card 1
SSID 3 | SSID 3
|
Card 2 | Card 2
SSID 7 | SSID 7
|
Card 3 <--+ Card 3
C to D v DB0ODW-0* SSID 4 SSID 4
<--
Station C wishes to send a frame via the port with the SSID 4. On
port 4, other stations see that the frame came from the port with
SSID 0.
As long as a digipeater only has fixed RMNC link partners, it is
more sensible to employ call routing alone. If a digipeater has
one or more Net/ROM neighbors however, it is important to use
both: designate on which channel a callsign can be reached and use
an SSID during connection setup. Thus the RMNC call will always
find the return route to a Net/ROM digipeater. Additional examples
can be found under the commands LINKS and PARMS (for sysops).
4.3 User Commands;
All commands that can be entered by a user are called USER
commands. The sysop has an additional set of commands or can use
the USER commands with supplemental parameters.
In the following explanations, <CR> represents entry of a carriage
return, 0D hex. The "=>" is the system prompt from RMNC/FlexNet
V3, indicating that it is waiting for input. All entries can be
entered in upper or lower case letters. If a command other than
- 11 -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
those listed below is entered, the digipeater responds with
"invalid command".
Command: A (Actual Info)
Syntax: A <CR>
The A command outputs the text "AKTUELLES". This text should be
reserved for current messages, such as planned changes in the near
future, reports about new links, etc. The text for "AKTUELLES" can
only be entered by a sysop.
This text is empty after a cold restart.
Command: B (Beacon text)
Syntax: B <CR>
The B command displays the current beacon file. This file contains
each beacon for each port along with its repetition rate.
Following a cold restart, a default beacon will be transmitted on
channel 0.
Command: C (Conversation mode)
Syntax: C <CR>
If the C command is entered without parameters, the Conversation
mode is entered. This mode allows a large number of stations to
participate in round-table discussions. A maximum of 255 different
groups are possible. After entering this command, the digipeater
displays a list of the stations currently logged into the
conversation mode and waits for a number corresponding to the
desired group to be joined.
Example:
=>C<CR>
*** conversation mode ***
users:
0: DL1AA 0: DL1ZZ --: DL2XY 73: DG3FBL 73: DK7WJ
channel (0..255) => <n><CR>
*** starting converse; exit: /q
In this example, DL1AA and DL1ZZ are in group number 0, DG3FBM and
DK7WJ in group 73. DL2XY is connected to the digipeater but is not
in conversation mode. After entering the desired number <n>, the
conversation mode begins. If other stations are already logged
into the selected channel, they all receive the message:
<DL9ABC>: *** Logon
During the conversation mode, the following commands are
available:
/w - displays all users of the conversation mode
and all stations connected to the digipeater
- 12 -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
/w n - shows all conversation participants on
channel n
/c - shows the current channel number
/c n - switches to channel number n
/s call msg - sends a private <message> only to <call>
/q - terminates the conversation mode
If a station disconnects from the digipeater or terminates the
conversation mode, all other participants on that channel receive
the message:
<DL9ABC>: *** Logoff
If a user switches to another channel, all participants on the
original channel receive the message:
<DL9ABC>: *** switched to channel n
If no channel number is entered upon starting the conversation
mode, the mode is immediately terminated and the user can enter a
new command.
Command: C (Connect mode)
Syntax: C Call [Digi1 Digi2 ... Digi8] <CR>
Entering the C command with parameters initiates a connection to
another station. The digipeater sends a SABM to the designated
callsign via the optionally specified digipeaters. As confirmation
the user receives the message "link setup...". When the connection
is established, the digipeater reports this with the message "***
connect to Call". If the connection to the desired callsign does
not come about, the digipeater reports "*** failure with Call". If
the other station responds with a busy, you will receive the
message "*** busy from Call".
The connection mode can be cancelled by sending a <CR> or a new
command. It is not possible to establish a QSO where the source
and destination callsigns are identical and have the same
digipeater in the path. If such an attempt is made, the user
receives the message "*** Call: can't connect twice" and the
connect command is cancelled.
This command can also be used on digipeaters with several user
ports to switch between ports. Entering "C MYCALL-7" will switch
to the port with SSID 7 and results in the confirmation "*** Call:
ssid ok".
If the QSO is terminated by the partner station after being
initiated using the connect command, the QSO will be resumed at
the previously connected digipeater, and the user receives the
message "*** reconnected to MYCALL".
Example: (the user is already connected to DB0HP)
=> C DB0ODW <CR>
link setup...
*** connected to DB0ODW
FlexNet V. 3.0 - DB0ODW - JN49IQ - Help with H
- 13 -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
=> Q <CR>
73!
*** reconnected to DB0HP
=>
or
=> C DB0ODW <CR>
link setup...
*** failure with DB0ODW
=>
Command: D (Destination Table)
Syntax: C [Call] <CR>
The D command lists the destination table automatically generated
by the digipeater. This table contains all stations to which the
autorouter knows paths. The range of valid SSID's are shown for
each callsign that can be reached. Additionally the average travel
time to the destination callsign is displayed in 100 ms
increments. If this number is quite large, it is possible that
several <SABM>'s can be sent by the user's TNC before the <UA>
arrives from the destination. The callsign of the destination may
be optionally entered. The digipeater determines the path to the
destination and then displays it after several seconds along with
the travel time. Digipeaters shown in capital letters along the
path support the FlexNet protocol, whereas those in lower-case
letters are used by the autorouter to reach a destination without
FlexNet neighbors. This list is essentially the same for all
digipeaters. Only if the travel time exceeds 15 minutes will the
destination be removed from the list. It is questionable whether
such a QSO would even be possible without a link failure.
Command: F (Find)
Syntax: F <CR>
This is the FIND command. This command can be used to search for a
specific station on the same or another frequency.
If the FIND command is entered along with a callsign, an <UI>
frame will be transmitted via one or several neighboring
digipeaters with the desired callsign as the target call. Source
callsign is the digipeater's MYCALL. If the sought station hears
this frame, it answers with a <DM> frame. The digipeater analyzes
all returning frames and using the other callsigns in the frame
can determine if it was a reply to a FIND command. If this is the
case, the user who requested the search will be notified where the
sought station was located. If that station is already connected
to the digipeater, no search frame will be transmitted, rather the
message will be immediately sent that the station is currently
active via the digipeater.
Example:
=> F DK7WJ <CR>
*** DK7WJ found via DB0ODW
=>
- 14 -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
Fundamentally only the digipeater will be mentioned where the
sought station was located. It will generally be known by
autorouter.
If the sought station is not found, no message is generated,
merely the system prompt "=>" reappears. Since the <UI> and <DM>
frames can be "lost" in route, it may be necessary to repeat the
FIND command several times.
Command: H (Help Info)
Syntax: H <CR>
The H command calls up the help information file. This text should
provide the user with some assistance in using the digipeater. The
help text can only be entered by the sysop. Following a cold
restart, the text memory is empty.
Command: I (Info Text)
Syntax: I <CR>
The I command displays the contents of the INFO text memory. This
text should be used to distribute general information about the
digipeater, such as location, equipment, antennas, etc. The INFO
text can only be entered by the sysop. Following a cold restart,
the text memory is empty.
Command: L (Link Info)
Syntax: L <CR>
The L command lists the link table entered by the sysop. The
channel number as well as the callsigns reachable on the channel
are listed.
Example:
=> L <CR>
DB0KT 0-7 60/68 P 1
DB0EAD 0-15 53 P 2
DB0IE 0-15 83 P 3
DB0EQ 0-8 (355/399) via DB0IE
DK7WJ 8-11 44/67 P 0 -
DB0ABA P 4
DB0BBS 0-15 --- P 5
=>
In the first column are all stations that can be reached by this
digipeater. In the second column is the range of SSID's valid for
the station. If there is no entry, then the range is 0-15.
The third column lists the current travel times to the neighbor in
100 ms increments. If the value is missing, no measurement is
performed to the neighbor. Three dashes indicate that the link
currently is not operational.
If only one number is in the travel time column, the partner
station does not support the FlexNet protocol or no QSO is
possible. If the value is in parenthesis, the value is too bad to
- 15 -
Msg# 316072 To: RMNC @WW From: DG3FBL Date: 24Oct92/1007
Subject: Part 4 / english FlexNet documentation
Bulletin ID: FLX9210_4_8
Path: DB0LX!DB0AAA!DB0MWE!DB0KCP!DB0CZ!OE9XPI!HB9EAS!DB0GE!DB0LJ!DB0GV
de DG3FBL @ DB0GV
RMNC/FlexNet Software Version 3.0 Sysop Documentation
be passed along to other FlexNet nodes. If there are two numbers
separated by a slant bar, the neighbor is a FlexNet partner. In
this case, the travel times for both directions are listed. If
these values are in parenthesis, the autorouter knows a better
path to the goal, meaning that the direct route is not used.
A permanent connection exists to the stations assigned a port
number. Stations that are reached via another are shown in the
list with "via". A dash after the port number means that this link
is not reported to the network. This is intended for auxiliary
links in case the existing links fail or for other reasons this
station should not be reported to the network, e.g. software
tests, etc.
Command: M (MyCall)
Syntax: M <CR>
The M command displays the call of the digipeater (MYCALL) as well
as the range of SSID's used with the digipeater.
Example:
=> L <CR>
mycall: DB0ODW, SSIDs: 0-7
=>
Command: P (Parameters)
Syntax: P <CR>
The P command lists the currently active parameters. The
parameters are classed into those that are valid for all ports
(Layer 2) and those that can be set for each port individually
(Layer 1).
Example:
=> P <CR>
no infobox timeout
L2: check 480s; retries 5; maxframe 3; paclen 256; NR-
check 90s
L1: channel ssid txd persistence mode
0 1 40 100 1200
2 3 20 --- 4800
5 -- 20 128 9600tr
7 7 30 64 300
The first item is the timeout value for the infobox. Here is
either the number of minutes or, as in the example, no timeout.
L2 Parameters:
The layer 2 parameters can only be set for all links
together, as follows:
check: T3 timer for AX.25V2L2 protocol
retries: number of attempts
maxframe: maximum number of unacknowledged frames
- 16 -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
paclen: maximum allowed frame length
NR-check: timer for testing for remote busy condition
L1 Parameters:
The layer 1 parameters can be set individually for each link,
as follows:
channel: card address (0=master)
ssid: SSID setting for this card
or "--" means that this card does not have a
special SSID.
txd: TxDelay time in 10 msec steps
persistence: persistence in x/255
mode: Baud rate setting for this port. A
supplemental "t" or "r" after the Baud rate
means external clock for TX or RX. If a link
operates in full-duplex, this is indicated by
"---" under persistence.
An explanation of the parameter and persistence can be found in
the appendix: p-Persistence method.
The P command also serves to provide information about the
parameter settings. Furthermore it is also very interesting for
the sysop since it shows which cards were found by the master
following a reset.
Command: Q (Quit)
Syntax: Q <CR>
The Q command, QUIT, terminates the connection with the
digipeater. A "73!" will be sent out first. After this frame has
been acknowledged, a disconnect follows. If the QSO was initiated
from a FlexNet digipeater using the connect command, a reconnect
to the last digipeater results automatically.
Command: S (Set Search)
Syntax: S <CR>
The S command (SETSEARCH) lists the digipeaters over which the
FIND command is executed.
Example:
=> S <CR>
search digis:
DB0ODW
DB0KT via DB0ODW
DB0AAI via DB0ODW
DB0DA via DB0ODW
DB0IE via DB0ODW
=>
According to this example, the FIND command would thus be sent
over the digipeaters DB0ODW, DB0KT, DB0DA, DB0AAI and DB0IE. The
search frame is sent out from the autorouter.
- 17 -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
Command: U (Users)
Syntax: U <CR>
The U command (USERS) list the users who are currently in QSO with
or over the digipeater. Various other information is also
displayed.
Example:
=> U <CR>
1: S 5: P 0: DB0ODW>DF4OR
6: S 7: U 1; P 0: DB0ODW>DK7WJ
35: S 5: P 0: DL1AA>DB0GV v DB0ODW,DB0KT
2014: S 5: L 1: DB0GV>DL1AA v DB0KT,DB0ODW
=>
The columns have the following meanings:
1. QSO number. The digipeater uses an internal number to
manage each QSO.
2. S x (x:0..15) QSO state. The number x corresponds to the
state number in the AX.25 protocol. S 5 means information
transfer, hopefully the most common state.
3. U n; is only shown as needed and indicates the number of
unacknowledged frames in this QSO.
4. P x; Port (channel number).
5. Calls and digipeater route
The first QSO's listed are those with the digipeater, followed by
those passing through the digipeater. Here the QSO's can be seen
that pass exclusively over the links.
When entering the U command, an optional parameter can be
specified, namely the channel number or an "i". If an "i" is
entered, only the QSO's with the digipeater's infobox are listed.
If a channel number is specified, all QSO's via that channel are
displayed.
Command: IO (I/O Status)
Syntax: IO <CR>
The IO command is used to show the input and output ports of the
new reset card. This card supports 16 inputs and 16 outputs, which
can only be activated by the sysop. These lines allow the
digipeater to be remotely controlled and data to be interrogated.
Here the imagination of the sysop knows no limits. The data are
output in binary.
Example:
=> IO <CR>
I:0000 0000 0000 0000 O:0000 0000 0000 0000
=>
The inputs are shown first, followed by the outputs. A 0 signifies
a "low" on the input, a 1 a "high", likewise on the outputs.
The meaning of the individual bits must be documented by the
sysop.
- 18 -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
4.4 Sysop Commands;
The sysop has commands in addition to those available to the user.
Some are extra commands, others are user commands with extended
parameters.
Commands with supplementary parameters:
L - LINKS, entry of link partners
M - MYCALL, setting the digipeater's callsign
P - PARAMETER, setting various parameters
IO - Input/Output, set or read
Extra commands:
CAL - CALIBRATE, transmit a calibration signal
K - KILL, terminate a QSO
MO - MODE, set HDLC operating parameters, reset all SCC's
SY - SYSOP, authentication of sysop
WRITE - Write text files, also beacons and search files
RESET - Reset the entire digipeater to default values
Command: CAL (Calibrate)
Syntax: CAL <ch> [Min] <CR>
The CALIBRATE command causes the transmitter on the card selected
by parameter <ch> to transmit continuously for one minute. During
this time, the carrier is modulated with a continuous sequence of
0's and 1's so that a keying ratio of 50/50 results.
This command serves two purposes:
- A partner station gets the opportunity to aim an antenna
using a steady signal.
- Modulation symmetry can be checked and adapted to the modem,
similarly at the partner's receiver.
Any waiting frames will be sent before executing the CAL command.
In order to reset the PTT watchdog, the CAL signal is briefly
interrupted every 15 seconds.
Starting with RMNC/FlexNet V3, the calibrate time can be
specified. Default is one minute. Entering "CAL <ch> 0" will
cancel a possibly longer CAL command on this channel.
Command: IO (I/O Command)
Syntax: IO <bit_nr> 0|1 <CR>
The IO command can set or clear the output ports on the new reset
card. The bit number to be changed must be specified after the IO
command, followed by a 0 or 1 depending on whether the bit should
be cleared or set.
- 19 -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
Command: K (Kill QSO)
Syntax: K <QSO_nr> <CR>
The KILL command serves to delete a current QSO from the user
table. This requires that the QSO number be specified, which can
be found in column 1 of the list from the U command.
What's the purpose of this command? The KILL command is not
intended to encourage capricious behavior. Under certain
operational conditions, it may be necessary to delete some QSO's
or QSO corpses from the table.
For example: Station A and B are connected to each other and a
lengthy text should be transmitted from B to A. After a period of
time, the recipient, station A, becomes busy and his TNC enters
the RNR condition. If this state is not manually alleviated by A,
this QSO will permanently remain active, or until the next power
outage.
Command: L (Link)
Syntax: L <ch|CALL|-> <CALL> [#|$|-] <CR>
Link information is entered with the L command, whereby two or
optionally three parameters are necessary. The callsigns can be
entered in either lower or upper case.
1. Parameter: ch (channel number, card number)
or
CALL (callsign of existing link)
or
- (minus sign)
If a channel number is specified, new link information for
this channel will be stored. If a callsign is entered, the
callsign is interlinked by this digipeater, i.e. the next
station can be reached via this station. If a "-" is entered,
the link information deleted for this channel or this
callsign.
2. Parameter: CALL
The callsign of the station is entered which can be reached
via this port or this station. Wildcards are permitted.
3. Parameter: # (hidden)
or
$ (no verification)
or
- (no reporting)
The third parameter is optional and has the following
meanings:
"#" : this link is NOT displayed in the link list. Thus
hidden links are possible.
"$" : this link is not tested for availability. This is
for links that should not continuously be tested.
"-" : this link will not be reported to the network. Thus
auxiliary or test links are possible. Internode
communication does take place between partners. All
- 20 -
Msg# 316073 To: RMNC @WW From: DG3FBL Date: 24Oct92/1103
Subject: Part 5 / english FlexNet documentation
Bulletin ID: FLX9210_5_8
Path: DB0LX!DB0AAA!DB0MWE!DB0KCP!DB0CZ!OE9XPI!HB9EAS!DB0GE!DB0LJ!DB0GV
de DG3FBL @ DB0GV
RMNC/FlexNet Software Version 3.0 Sysop Documentation
destinations other than this one are reported to the
network.
Example:
L 3 DB0KT
All frames destined for DB0KT are sent via card 3.
L 1 DB0KT
L 1 DB0FUL
Two link partners can be reached via card 1, thus both
callsigns are entered for number 1.
In principle, when no SSID is supplied with a link callsign, all
SSID's will be routed to this card. If a specific SSID is entered,
only it will be routed.
Example:
L 1 DB0KT
All frames destined for DB0KT, including DB0KT-1, -2,
etc. are sent via card 1.
L 1 DB0KT-7
Only frames for DB0KT-7 are redirected to card 1, all
others will be sent out on the user input channel, as
long as no other link information exists for the other
SSID's of DB0KT.
An automatic adaptation of the SSID ranges takes place between
FlexNet partners.
It is not possible to route one callsign to two different cards.
However several callsigns may be assigned to one card. It is also
not possible to use the same SSID on two different cards. If the
same link information is entered for two different cards, the
oldest is deleted.
Example:
L 3 DB0IE
Frames for DB0IE are sent via card 3.
L 5 DB0IE
As of now data for DB0IE are sent via card 5, the
previous entry is automatically deleted.
In order to delete link information specifically, a "-" (minus
sign) is entered as the first parameter in place of the channel
number.
Example:
DB0ODW has the links:
1: DB0KT
2: DB0EAD
3: DB0IE
L - DB0KT deletes the routing entry for DB0KT. Frames
will no longer be routed there but will be output on the
user access channel.
It is possible to enter link information with a callsign
containing wildcards. A "?" is used as the wildcard character.
- 21 -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
Example:
L 4 Y2????-2
This entry specifies that only those calls are routed by
the RMNC to card 4 that correspond to this pattern, e.g.
Y21AB-2, Y27XYZ-2, etc.
Links to Net/ROM partners should be configured as described in the
appendix.
Command: MO (Mode)
Syntax: MO <ch> <mode> <CR>
The operational parameters for the HDLC side of the card are set
using the MODE command. These parameters include the following:
- baud rate for internal clock
- full or half-duplex
- external or internal RX or TX clocks
The coding of the <mode> is in the form of a hexadecimal byte with
the following bit assignments:
Bit 7 6 5 4 3 2 1 0
f r t - - b b b
Bits 0-2: Baud rate
The baud rate is specified in bits 0-2. There are thus 8 different
baud rates supported, coded as follows:
Bit 210 Baud Rate
000 9600 bps
001 4800 bps
010 2400 bps
011 1200 bps (EPROM default value)
100 600 bps
101 300 bps
110 150 bps
111 75 bps
Other than 300 bps for use on short-wave, the slower baud rates
are certainly not very useful.
Bits 3-4: Unused, reserved for future use
Bits 5: Optional external/internal TX clock
Bit 5 = 0: internal TX clock used
= 1: external TX clock used
This option can be used in the case where an externally connected
modem supplies the transmit clock signal. In this case bit 5 must
be set to 1. Naturally it is also necessary to actually feed the
TXCLOCK signal to the appropriate pin of the modem connector.
(Refer to appendix 9.3, external modems)
Bits 6: Optional external/internal RX clock
Bit 6 = 0: internal RX clock used
= 1: external RX clock used
This option can be selected in the case where an externally
connected modem supplies the receive clock signal. Then bit 6 must
- 22 -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
be set to 1. Naturally it is also necessary to actually feed the
RXCLOCK signal to the appropriate pin of the modem connector.
(Refer to appendix 9.3, external modems)
Bits 7: Optional Full or Half-Duplex
Bit 7 = 0: half-duplex
= 1: full-duplex
If bit 7 is set to 1, the corresponding RMNC card operates in
full-duplex mode. This mode has been tested to 9600 bps and
functions perfectly as long as the partner station also supports
it. Some TNC's or the software used in the TNC's have problems at
this speed.
Examples:
MO 1 03
Card number 1 is set to 1200 bps, half-duplex and uses
internal TX/RX clocks.
MO 3 80
Card number 3 is set to 9600 bps, full-duplex with
internal clocks.
MO 2 5
Card number 2 is set to 300 bps, half-duplex with
internal clocks.
MO 6 C1
Card number 6 is set to 4800 bps, full-duplex with
external RX clock.
Note that the <mode> parameter must always be entered as a
hexadecimal number.
When a MODE command is entered, the master initializes all
attached cards in Layer 1. This should not cause any problems and
could at most cut short one frame being sent at that moment. The
QSO's in progress are not affected. A mode command could possibly
reinitialize stuck SSC's. Therefore before using the RESET command
after a link failure, first try the mode command to reinitialize
all cards.
Refer to appendix 9.3 for connections to external modems and usage
of the options for external clocks.
Command: M (MyCall)
Syntax: M <call> [<ssid1> <ssid2>] <CR>
The M (MYCALL) command is used to set the callsign of the
digipeater. The optionally supplied SSID's can specify a range
which the digipeater supports for connects. The SSID range must
contain all SSID's needed for the links. No port SSID can be
outside this range.
- 23 -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
Examples:
M DB0ODW 0 7
The callsign is set to DB0ODW and the digipeater can be
connected with the callsigns DB0ODW-0 to DB0ODW-7.
M DB0AAI
The callsign is set to DB0AAI and the digipeater can
only be connected with SSID 0.
If the MYCALL is changed, this takes effect only for the new
connections with or via the digipeater. Currently active QSO's,
including the one with the sysop, will continue under the old
callsign.
Command: P (Parameters)
Syntax: P I <value>
or
P <L2P> <value>
or
P <L1P> <value> <ch>
The P command sets the Layer-1 and Layer-2 parameters as well as
the infobox timeout. For the Layer-2 parameters only three input
values are needed since these values apply to all cards. In the
case of the Layer-1 parameters, the channel number is also needed
since each channel can be set individually.
The infobox timeout is specified in minutes, where a value of 0
means no timeout.
Possible Layer-2 parameters are:
c - check
r - retries
m - maxframe
l - paclen
n - NR check
Check
Syntax: P C <value>
Range: 10-2550 in steps of 10 (seconds)
Default: 480
The check timer corresponds to the T3 timer in the AX.25
protocol.
Retries
Syntax: P R <value>
Range: 1..255
Default: 10
The maximum number of attempts to be made to transmit a
frame.
Maxframe
Syntax: P M <value>
Range: 1..7
Default: 3
Number of simultaneously sent frames for a single QSO.
- 24 -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
Paclen
Syntax: P L <value>
Range: 1..256
Default: 256
Length of a frame (I field)
NR-Check
Syntax: P N <value>
Range: 10..2550 in steps of 10 (seconds)
Default: 120
This is the timer which specifies how often the partner
station should be polled if it is in the RNR state.
Possible Layer 1 parameters are:
txd
persistence
TXDelay
Syntax: P T <value> <ch>
Range: 1..255 (10 millisec.)
Default: 40
This determines the TXDELAY for card <ch>.
p-Persistence
Syntax: P P <value> <ch>
Range: 1..255
Default: 128
This sets the probability for card <ch> to key the
transmitter. Refer to the appendix for a exact description of
the p-Persistence procedure.
Note: A persistence of 0 prevents the card from ever keying
the transmitter, even for full-duplex! This can be used if a
link should be taken out of service for a while. It is also
possible however to be locked out if all links are set to p-
Persistence 0.
Command: SY (Sysop)
Syntax: SY <CR>
The SYSOP command is used to inform the digipeater that the user
is a sysop. This is intended to be a simple block for "players"
who like to reconfigure other digipeaters.
The digipeater sends a random number as response to this command.
Based on this random number and a "secret code" stored in the
EPROM, the digipeater computes the necessary number for a
successful login. This means that the user must perform the same
computation and send the result to the digipeater.
The algorithm employed is simple enough that the result can even
be computed in the head, hence the security is somewhat limited.
If necessary the algorithm may be changed in the future.
How does it work? Here is an example:
=> SY <CR> <- Sysop command
12345> <- random number from digipeater
- 25 -
Msg# 316077 To: RMNC @WW From: DG3FBL Date: 24Oct92/1208
Subject: Part 6 / english FlexNet documentation
Bulletin ID: FLX9210_6_8
Path: DB0LX!DB0AAA!DB0MWE!DB0KCP!DB0CZ!OE9XPI!HB9EAS!DB0GE!DB0LJ!DB0GV
de DG3FBL @ DB0GV
RMNC/FlexNet Software Version 3.0 Sysop Documentation
Assuming that the secret code programmed into the EPROM was 54321,
the computation is as follows:
Multiply the digits in a column:
12345 <- random number
54321 <- secret code
1 * 5 = 5
2 * 4 = 8
3 * 3 = 9
4 * 2 = 8
5 * 1 = 5
The separate products are then totalled:
5+8+9+8+5 = 35
Finished! This is the number to send back to the digipeater.
Assuming the computation was performed correctly, the user
immediately has sysop status.
In order to hide the process somewhat, the sysop command could be
repeated several times. At least once the correct answer must be
supplied. If the other answers are incorrect, a potential intruder
would find it somewhat more difficult to recognize the correct
number.
No particular message is sent following a successful login as
sysop, and only after trying a harmless command, such as TIMEOUT,
can be determined if the process succeeded.
If the user has logged in once as sysop, the preset timeout no
longer applies, which means that he can remain connected to the
digipeater indefinitely without making any further entries.
The sysop authorization is cancelled by a disconnect, a reconnect
(link reset) or a connect command.
Several sysops can log in simultaneously.
Command: WRITE
Syntax: WRITE <A|B|C|H|I|S> <CR>
The WRITE command is used to enter the texts for ACTUAL, BEACON,
C-TEXT, HELP, INFO and SETSEARCH. Except for BEACON and SETSEARCH,
all texts may have any format. All texts taken together can be no
longer than 5000 bytes.
When there have not yet been entries for the texts A, I and H, the
digipeater will just send another prompt when the corresponding
text is requested.
The contents of C-TEXT are is sent following the standard system
message at the beginning of a connect. The standard message is:
"RMNC/FlexNet V. 3.0". If C-TEXT is empty, only the standard
prompt is sent.
- 26 -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
After completing the WRITE command, the remaining free storage
space is reported in bytes, regardless of the text.
We recommend the following use for these texts:
ACTUAL: For current information such as:
"Out of service tomorrow due to maintenance"
or
"New link to DB0xxx is now available. Give it a try."
INFO: General information about the digipeater, such as location,
equipment, antennas, I/O port usage, etc.
HELP: A brief list of the most important user commands.
Due to limited storage, the texts cannot be stored in the EPROM.
The text input is terminated with "/EX" or a Ctrl-Z. The line is
then stored up to the character just before /EX.
Since many packet radio stations use "split-screen" programs, all
texts other than the C-TEXT should start with a <CR>. This will
look better on the user's screen.
In the case of the BEACON texts, a special format must be
observed. Any number of beacons can be programmed for all links.
The structure of such a text is as follows:
m c <tocall> [ via [ via ...]]: Beacon
text.....................#
where
"#" separates the different beacon texts.
"m" is the number of minutes between beacon transmissions (1
to 255 minutes allowed).
"c" is the card address where the beacon is to be sent.
<tocall>: is the destination callsign of the beacon, such as
"BEACON", "RMNC", "FLXNET", "TEST", etc.
via: Up to 8 digipeaters may be specified over which the
beacon should be sent.
Example:
10 0 RMNC:Digi Odenwald * JN49IQ * Krehberg/Odw. *#
30 1 RMNC DB0KT DB0ODW:DB0KT QRV#
5 0
FLXNET:Test beacon....DB0xxx
In this example, the text consists of three beacons separated by
"#" (beacon1...#...beacon2...#...beacon3). Between the individual
entries, carriage returns may be inserted in order to make the
text more readable.
Capitalization of the callsigns is unimportant.
The sender callsign is always the preset MYCALL of the digipeater.
If no beacon has yet been entered, the digipeater sends the
following default beacon every 3 minutes on the card containing
the Master EPROM: "3 0 FLXNET:RMNC V. 3.0"
- 27 -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
All beacons are sent as <UI> frames (Unproto-Information) with the
command bit set.
The SETSEARCH text also requires a special format. An unlimited
number of search commands may be sent. The number of digipeaters
is limited to 7. The text has the following structure:
<call1>
<call1> [<call2> [<call3> [<call4> [<call5>]]]]
The search routes for the FIND command are entered into the
SETSEARCH text. First the digipeater is entered where the search
frame is to exit, then the digipeaters used to get there. These
paths should be identical with the routes used by the users. Thus
digipeaters on the route to the destination should be left out.
Examples:
Search routes for FIND command
DB0ODW
DB0DA via DB0ODW
DB0KT via DB0ODW
DB0AAI via DB0ODW
The first example indicates that the search command should be
transmitted by this digipeater. The second example shows how a
search route to DB0DA is to be specified. DB0DA is reached from
DB0ODW via the autorouter.
4.5 Operational Aspects;
4.5.1 Protocol version AX.25V2;
The RMNC/FlexNet-V3 processes QSO's over the digipeater in
protocol versions 1 and 2. A QSO with the digipeater is only
supported in version 2! We prefer not to get into a general
discussion to the advantages and disadvantages of both versions at
this point, but are of the opinion that AX.25V2 generally provides
all participants a higher data rate. Furthermore, virtually all
users should now be able to use the newer protocol version.
Connects to the digipeater using protocol version 1 are answered
with a <DM> (Disconnect Mode).
If station A initiates a connect in version 2 with station B,
which then answers in version 1, a connection is established quite
normally and a QSO is thus possible. However, the connection does
not enjoy the so-called hop-to-hop acknowledgement, but rather the
frames are merely digipeated in the traditional manner. QSO's
using version 1 do not appear in the user list.
4.5.2 Unproto Frames;
Fundamentally, the RMNC/FlexNet-V3 software transmits and routes
all <UI> (unproto frames), even <UI> frames in protocol version 1.
This allows an unproblematic operation with TCP/IP, since most of
the TCP/IP programs send <UI> frames in version 1. The length of
the <I> field in the <UI> frame may not exceed 256.
- 28 -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
4.5.3 RNR Recovery;
Since each QSO with and via the digipeater only has a limited
memory space available, it may occur that a user is set to Remote
Busy <RNR> by the digipeater. This is most likely to happen during
a file transfer. It may also occur in converse mode if one of the
participants in the group has a bad link.
As soon as the <RNR> condition has been alleviated, the TNC
waiting in the <RNR> state receives an <RR> frame with the
command/response bit set. In some software TNC versions this
results in an immediate resumption of the transmission, others
first poll the digipeater in order to receive an <RR> with
poll/final bit set.
4.5.4 Reconnects;
A particular problem for a digipeater supporting hop-to-hop
acknowledge is the handling of reconnects. A reconnect is the
reestablishment of a connection between two stations while a
connection already exists, either over the same or another route.
Since the digipeater is not informed in the case of a reconnect
via another route, this can lead to certain problems. The
digipeater maintains the current QSO in its tables. As long as no
unacknowledged frames from this QSO are left over, nothing will
happen and the QSO quietly "dies" after 13 minutes. If there are
still frames waiting to be sent, however, the digipeater will
attempt to poll the other station. Since the QSO over the new
route has no doubt continued in the meanwhile, the sequence
numbers will most certainly no longer agree with those of the
digipeater, resulting in a <FRMR> (frame reject).
The best solution to avoiding this problem is first to terminate
the QSO properly and then to initiate a new connection.
4.5.5 I-Polling Method;
During a connection it is very likely that an <I> frame may not be
acknowledged. In this case, the protocol version 2 prescribes that
a poll frame <RR> be sent to ask if the last <I> frame was
received. If not, it will be repeated, otherwise the next frame
will be sent.
It can be proven that this method leads to a superfluous frequency
loading if the <I> frame in question is very short. Therefore, in
the case of a short frame, protocol version 3 will not send a poll
frame <RR> but rather the short <I> frame is immediately repeated,
however with the poll bit set. This method represents a mixture of
the old version 1 and the newer version 2.
The question what constitutes a short frame is difficult to
answer. We have set the length to 15 bytes. This means that each
<I> frame containing up to 15 bytes is immediately repeated, if it
is not acknowledged within the FRACK time (T1). This value cannot
be changed.
- 29 -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
5. Creating a Master EPROM;
The RMNC/FlexNet-V3 software is only provided in an unconfigured
form. In order to perform the configuration, an eprommer capable
of programming 27C256 EPROM's and a PC are required.
5.1 Parameter Compiler;
A part of the RMNC/FlexNet-V3 software consists of the "parameter
compiler". With the help of this compiler and a parameter file, a
binary file is generated that is completely parameterized and
ready for burning into an EPROM. The slave EPROM's do not need to
be configured since they are identical for all RMNC's.
In order to have the compiler generate a new master file, an
individual parameter file must first be written. The parameter
file is a completely normal text file that can be created by any
editor. All necessary parameters are entered into this file. The
syntax used in the file is essentially the same as the sysop
commands. The resulting binary file can then be burned into the
27C256.
When using a 27C256 EPROM, the slave file must be programmed into
the upper half, starting at $4000.
The following files are on the diskette:
MRMNC.EXE - the compiler
DB0AAI - a sample parameter file
RM_SLAVE.BIN - binary file for all slaves
SYSOP30.PRN - sysop documentation, 72 lines/pate, IBM
READ.ME - last minute infos
Compiler usage:
MRMNC <parmfile> <binfile> <CR>
The first command line parameter is the filename of the parameter
file with extension. If no binary file is specified as output
file, only the syntax of the parameter file will be checked. If a
binary file is specified, it will be generated. If a file with the
same name already exists, the user will be asked before
overwriting the file. The compiler automatically creates a list
file documenting the default values generated.
Parameter file structure:
In general, everything following a "*" is considered commentary.
Blank lines are ignored. Otherwise the command syntax is the same
as for the digipeater. Capitalization is irrelevant.
Example:
***** Configuration for DB0AAI Version 10/01/89
Mycall DB0AAI 0 7
sysop 12345 * secret code for sysop access
P S 0 0 * user access via channel 0: SSID 0
- 30 -
Msg# 316085 To: RMNC @WW From: DG3FBL Date: 24Oct92/1708
Subject: Part 7 / english FlexNet documentation
Bulletin ID: FLX9210_7_8
Path: DB0LX!DB0AAA!DB0MWE!DB0KCP!DB0CZ!OE9XPI!HB9EAS!DB0GE!DB0LJ!DB0GV
de DG3FBL @ DB0GV
RMNC/FlexNet Software Version 3.0 Sysop Documentation
* Permanent link partners. Routing always to specified
* channel if call without SSID, if SSID don't care; max
* 32 calls! If # follows call, link will not be shown to
* users!
L 1 DB0KT
L 2 DB0ONA
P S 1 2 * ONA is Net/ROM, thus assigned SSID 1
L 3 DB0AAC
L 4 DB0ID
L 5 DF5IY-7 #
IO 7 1 * set I/O bit 7, turn on PA *
* Layer 1 modes, input in hex, default is 03 (1200 baud
* half-duplex)
mode 0 03 * only as example
P I 240 * connect timeout in minutes for
infobox
p c 480 * check
p r 10 * retries
p m 3 * maxframe
p l 256 * paclen
p n 120 * NR check
* Parms user access
parm txdelay 40 0
parm persist 100 0
END * final command!
Deviations from the normal syntax happen in the case of the sysop
command, for example, since the compiler is informed of the secret
code. The WRITE command does not work here! Do not forget the END
statement.
5.2 EPROM Patch Slave;
For link cards 1 to 8, the file RM_SLAVE.BIN can be burned
directly into an EPROM. For link cards 9 to 16, the byte $3F00
($7F00 for 27C256) must be changed to a value other than $FF. Thus
this card adds 8 to the address setting of the DIP switch.
6. Future Developments;
Further developments, both in hardware and in software, are being
planned for the RMNC node computer design from the Frankfurt
RMPRG.
- 31 -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
Hardware
The first item is to test and publicize a CMOS version for the
RMNC cards. This version will have a significantly lower power
consumption and will run twice as fast. The card will then be
clocked at 8 MHz instead of 4 MHz.
We are considering developing a new CPU card to replace the
current master. The other cards in the system remain the same and
serve as intelligent I/O units. Preliminary specifications:
CPU - 16 bit
RAM - min. 256KB, max. 1024 KB
ROM - 256 KB
I/O - parallel, serial (high-speed, RS232, HDLC)
DMA - bus communication to slaves (1 Mbit/sec)
Details will appear in the mailboxes under the heading "RMNC".
Software
The FlexNet software for the RMNC will also be developed further.
The next step is the creation of a special master version which
operates a normal RMNC card without HF support and is equipped
with additional features.
Under consideration is likewise a Net/ROM interface in order to
simplify the transition from FlexNet to Net/ROM systems for the
user.
Details will appear in the mailboxes under the heading "FLEXNET".
7. Usage Restrictions;
The RMNC/FlexNet software is a product of Gunter Jost, DK7WJ. All
copyrights to the software remain with the author.
The user receives merely the right to use the software under the
following conditions:
- The software is used exclusively in amateur radio for non-
commercial purposes;
- The legal regulations governing amateur radio are obeyed;
- No alterations are to be made to the software unless they
have been authorized by the author. Installation of the
operational parameters is specifically excluded from this
limitation.
- The copyright notice RMNC/FlexNet may not be removed.
Under these conditions, unlimited numbers of copies may be made
from the original diskette and distributed, whereby the
originator, the FlexNet Group, Darmstadt, West Germany, G. Jost,
DK7WJ, must always be noted. The source code for the program is
not available.
- 32 -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
7.1 Exclusion of Liability;
The authors and the distributors of the software cannot be held
liable for possible damages resulting from the installation and
use of the RMNC/FlexNet-V3.xx software.
By installing and using the software, the user acknowledges and
accepts these usage restrictions and the exclusion of liability.
8. Command List;
Data in [] are optional.
8.1 USER Commands;
A - display AKTUELLES text
B - display BEACON text
C - begin converse mode
/w - show all users
/w n - show all users on channel <n> in converse mode
/c - show current channel number in converse mode
/c n - change to channel number <n> in converse mode
/s Call Text - send a message to a specific user
/q - leave converse mode
C call [digi] - initiate connect to <call>
D [call] - show destination table; path to destination
<call>
F <call> - FIND command, search for <call>
H - display HELP text
I - display INFO text
IO - show state of I/O port
L - show all link information
M - show MYCALL and connect SSID's
P - show Layer 1/2 parameters
Q - QUIT, terminate connection
S - SETSEARCH, show search paths
U [ch;"i"] - USER, show user table, also selectively
8.2 SYSOP Commands;
CAL <ch> [min] - card <ch> transmits calibration signal
IO <ch> 0|1 - clear/set an output bit
K <QSO-#> - delete a QSO from the table
L <ch> <call> [#$-] - LINK, route <call> via card <ch>
L - <call> - LINK, delete link info to <call>
M <call> [s s] - MYCALL, enter <call> as MYCALL
MO <ch> <mode> - MODE, set card <ch> to <mode>
P I <value> - PARAMETER, set infobox timeout
P <L2P> <value> - PARAMETER, set Layer-2 parameter
P C <value> - set CHECK parameter
P R <value> - set RETRY parameter
P M <value> - set MAXFRAME parameter
P L <value> - set PACLEN parameter
P N <value> - set "Not Ready Check" parameter
P <L1P> <val> <ch> - PARAMETER, set Layer-1 parameter
P T <value> <ch> - set TXDELAY parameter for card <ch>
P P <value> <ch> - set PERSISTENCE parameter for card <ch>
SY - SYSOP
- 33 -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
WRITE <A|B|C|H|I|S> - WRITE, enter text messages (end with /EX)
WRITE A - WRITE, enter AKTUELLES text
WRITE B - WRITE, enter BEACON text
WRITE C - WRITE, enter C-TEXT text
WRITE H - WRITE, enter HELP text
WRITE I - WRITE, enter INFO text
WRITE S - WRITE, enter SETSEARCH text
9. Appendix;
9.1 p-Persistence Method;
The p-Persistence method is a technique to control the access by
several stations relative to one another on a single frequency.
The assumption is also made that the stations do not necessarily
hear each other. Earlier access methods were based on the so-
called DWAIT parameter. The p-Persistence method is intended to
replace that method. It is already implemented in the WA8DED
software as well as in TCP/IP using a KISS-TNC.
Two parameters are employed in the p-Persistence method:
Persistence and Slot-time. The first parameter determines the
probability that the transmitter will be keyed when the channel is
clear, and the second is the time to wait. The process may best be
explained through an example:
The TNC has data to send and wishes to key the transmitter. At
this point a random number between 1 and 255 is computed. If this
random number lies below the persistence parameter, the
transmitter can be switched on, assuming the frequency is not
occupied. If this random number lies above the persistence,
however, a period of time must pass, namely the slot-time. The
slot-time is the same as TX-Delay since RMNC version 2.2. After it
passes, another random number is calculated and the process
repeats from the start.
The p-Persistence parameter specifies the probability that the
transmitter will be keyed immediately without delay. If the
persistence equals 255, the probability is thus 255/256, nearly 1.
For a persistence of 128, the probability is 128/256, or 0.5, for
64 it is 64/256, or 0.25, etc.
The best arrangement would be if the persistence value could be
set in conjunction with the channel occupancy so that other
stations also get the chance to use the frequency. This means that
during periods of high activity the persistence is small (e.g. 32
to 64), for low activity somewhat higher (e.g. 128 to 192).
The length of the slot-time should also be set in conjunction with
the channel occupancy, for low activity shorter and for high
activity longer.
9.2 Layer-2 States;
In the display of the currently active connections with and via
the digipeater, the Layer-2 states are listed in the second
column. These are shown in the following table. For an exact
- 34 -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
explanation of the individual states, please refer to the AX.25
Version 2 Protocol Specification.
State Meaning
1 Disconnected
2 Link Setup
3 Frame Reject
4 Disconnect Request
5 Information Transfer
6 REJ Frame sent
7 Waiting Acknowledge
8 Device Busy
9 Remote Device Busy
10 Both Devices Busy
11 Waiting Acknowledge and Device Busy
12 Waiting Acknowledge and Remote Device Busy
13 Waiting Acknowledge and Both Devices Busy
14 REJ Frame sent and Device Busy
15 REJ Frame sent and Remote Device Busy
16 REJ Frame sent and Both Devices Busy
Disconnected
This condition is the starting state of each connection. It is
left when a connection is established. In FlexNet-V3, QSO's with
State 1 are not displayed.
Link Setup
A connection is being established, i.e. <SABM> frames are being
sent, the confirmation <UA> has not yet been received.
Frame Reject
Due to a synchronization error, a <FRMR> frame was sent. The
connection is being restarted.
Disconnect Request
The connection is being terminated, i.e. <DISC> frames are being
sent, the confirmation <UA> has not yet been received.
Information Transfer
Hopefully the most common state. The connection has been
established, both stations are exchanging <I> frames.
REJ Frame sent
A <REJ> frame was sent because a received frame did not arrive in
the proper sequence. Thus a repetition is being requested.
Waiting Acknowledge
After an <I> frame was sent and before the waiting period (FRACK)
has expired, an acknowledge is being expected.
- 35 -
Msg# 316095 To: RMNC @WW From: DG3FBL Date: 25Oct92/0039
Subject: Part 8 / english FlexNet documentation
Bulletin ID: FLX9210_8_8
Path: DB0LX!DB0AAA!DB0MWE!DB0KCP!DB0CZ!OE9XPI!HB9EAS!DB0GE!DB0LJ!DB0GV
de DG3FBL @ DB0GV
RMNC/FlexNet Software Version 3.0 Sysop Documentation
Device Busy
The TNC is busy, most likely due to full memory. If another <I>
frame is received, the TNC responds with an <RNR> frame (Receiver
Not Ready).
Remote Device Busy
The TNC at the other end of the connection is busy.
Both Devices Busy
Both TNC's, the local as well as at the other end of the
connection, are busy.
Waiting Acknowledge and Device Busy
Waiting Acknowledge and Remote Device Busy
Waiting Acknowledge and Both Devices Busy
These conditions (11, 12, 13) represent a combination of the
previously listed states 7 and 8 through 10.
Reject Sent and Device Busy
Reject Sent and Remote Device Busy
Reject Sent and Both Devices Busy
These conditions (14, 15, 16) represent a combination of the
previously listed states 6 and 8 through 10.
9.3 External Clock;
Operational modes of the SCC
In general the SCC 8530 from Zilog contains two separate serial
channels and each channel has its own baud rate generator. Since a
channel needs two different clock signals for HDLC operation (1x
and 32x clock), the baud rate generator of the second channel (B-
channel) is used for supplying the 32x receive clock in order to
simplify the design. Thus the B-channel can no longer be used for
data transmission. If both channels of the SCC are needed for data
transmission (HDLC), the receive clock would need to be derived
elsewhere, additional external components would be required.
In the normal operation of an RMNC with its own modem, the clock
is derived from the clock signal PCLK supplied by the reset card.
The A-channel of the SCC is used for data transmission. The baud
rate generator for A (BRGEN A) generates the transmit clock (1x),
the baud rate generator of the B side generates the clock for the
DPLL on the A side (32x).
Transmitter:
ASCC PCLK --->BRGEN(A) --->TX(A)-Register
ASCC TRXcA-Pin
Receiver:
ASCC RTX(A) --> DPLL(A) --> RX
(A)-Register
BSCC PCLK ---> BRGEN(B) --->TRXcB
- 36 -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
Transmitter
The RMNC clock (PCLK) on the reset card feeds the baud rate
generator A. This divides down corresponding to the designated
baud rate and drives the transmit shift register. Simultaneously
the transmit clock is available at the output TRXcA. This signal
from the SCC is also applied to the connector strip for the
external modem (pin 16). Pin 16 is jumpered with pin 8 (RTXcB),
however this jumper is irrelevant for all operating modes of the
RMNC.
Receiver
The receiver works with an internal DPLL which must have a 32x
clock signal coming from the baud rate generator B. It is fed by
PCLK, BRGEN B outputs its signal on TRXcB. This signal from the
SCC is routed to pin 6 of the external modem connection and
jumpered to pin 18 on the connector. The signal is taken from this
pin to RTXcA on the SCC. This is the clock input for the SCC
receiver section. The DPLL follows this signal internally, and the
output is determined by the receive baud rate.
External Clock
When using an external modem, either the transmit or the receive
clock signal may be supplied externally. The selection is done
with the MODE command. Since the external modem must supply the 1x
receive clock, the SCC's internal DPLL is not used and is
disabled. The clock signal(s) are provided via the connector on
the edge of the card. TRXcA is the input for the transmit clock
(pin 16 of the modem connector), RTXcA is the input for the
receive clock (pin 18). The following should be observed in regard
to these connections:
In normal operation with the internal modem, TRXcA on pin 16 is an
output, but with an external modem it becomes an input. Thus two
outputs would connected together if the mode is switched to normal
operation when an external modem is still connected.
Although pin 16 (TRXcA) on the modem connector is jumpered with
pin 8 (RTXcB), this is unimportant and neither is it needed nor
does it disturb anything.
Pin 18 (RTXcA) is jumpered to pin 6 (TRXcB). In normal operation
this jumper supplies the A-DPLL with the 32x clock signal. In
operation with an external modem, this jumper must be opened up,
since the output TRXcB would otherwise conflict with the clock
output of the external modem.
Transmitter:
TRXcA pin -------------> TX(A) register
Receiver:
RTXcA pin -------------> RX(A) register
Transmitter: The 1x transmit clock is routed externally via TRXcA
(pin 16 of the external modem connector). This pin is now selected
as input!
- 37 -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
Receiver: The 1x receive clock is routed to pin RTXcA and supplies
the RX shift register directly without DPLL.
In the simplest case the connection of an external modem appears
as follows:
Modem Modem Connection SCC
RX-data --------> Pin 17 RXDA
TX-data <-------- Pin 15 TXDA
RX-clock --------> Pin 18 RTXcA
TX-clock <-------- Pin 16 TRXcA
0V --------> Pin 11 DCDA
+--> Pin 12 CTSA -> PTT logic
+--> Pin 13 RTSA
In this case both clock signals are provided by the modem. The
clock signals must be 1x.
In addition, remove TCM3105 and 74HC00 and jumper pins 12 and 13
on the modem connector for PTT. Remove the jumper between pins 6
and 18 on this connector. Connect pin 11 (DCDA) to Low (only for
full duplex).
What about DCD? On the RMNC card the DCD output from the 3105
modem IC is gated via a NAND gate with the PTT signal from the SCC
(RTSA) and thus generates the actual PTT signal. This means that
an already started transmission could be interrupted by an
activated DCD. The purpose for this is left open. This condition
cannot occur in half duplex operation. For full duplex there are
two possibilities:
1. The DCD can be supplied by the external modem if it is
stable. In this case it is fed to pin 11 of the modem
connector. IC 74HC00 must be removed and the PTT rewired
so that the output RTSA (pin 13) is connected to the input
CTSA (pin 12) on the modem connector.
2. DCD is held in one state, namely active. Thus pin 2 of the
74HC00 is high.
A further possibility: internal modem and full duplex. It is also
possible for the internal TCM3105 modem to operate in full duplex,
however only at 1200 baud. In this case the gating between the PTT
and DCD signals must be disabled. This can most easily performed
by cutting the trace between pins 3 and 4 of the 74HC00 and
jumpering pins 4 and 5 together.
9.4 Links to Net/ROM & TheNet Partners;
RMNC/FlexNet version 3 supports links to Net/ROM and TheNet
neighbors and forwards these links through the network, as long as
they function.
In the following explanation we assume that our FlexNet node
DB0FLX has a link to a Net/ROM node DB0NR.
A Net/ROM node consists of several TNC's with different SSID's.
Usually the user access has the SSID 0. For example, DB0FLX has a
link to DB0NR-4. It would thus be appropriate to enter DB0NR-4
- 38 -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
into the link table, as was the case in RMNC/FlexNet version 2.
This brings certain disadvantages however:
- The Net/ROM node may have other FlexNet neighbors. If these
also forward their DB0NR-x information, DB0NR-x will appear
multiply in the FlexNet destination tables. This makes
these tables rather involved.
- If a user wishes to connect DB0NR, without asking his
FlexNet entry node, he will not know which path is most
favorable for reaching DB0NR at that moment. Thus he may
take a detour in establishing a connection, since FlexNet
routes the different DB0NR's differently.
The problem can be easily solved by performing some tricks when
entering the links. The basic idea is that the network only needs
to know that DB0NR exists. The way to reach the individual TNC's
at the Net/ROM's only needs to be known by the neighboring node
which has the best link to DB0NR.
The entry at DB0FLX must appear as follows, where the link to
DB0NR is on channel 5:
L 5 DB0NR-3 - The minus sign means that although the
link is checked, the call DB0NR-2 is not
reported further.
L DB0NR-3 DB0NR This is the trick: here the link to the
user access DB0NR is checked.
Simultaneously however the SSID range 0-
15 is reported to the network via NR-3.
At this point FlexNet knows one route to DB0NR, but only DB0FLX
knows that the path to DB0NR-3 is direct and the path to the other
DB0NR TNC's is indirect via DB0NR-3. Only DB0NR (0-15) shows up in
the destination lists. The user access DB0NR-0 can be reached
directly. If, for example, the converse TNC DB0NR-8 exists, it can
also be connected directly.
The situation gets even trickier if DB0NR has a second FlexNet
neighbor. Let's call it DB0ZZZ, which has a link to DB0NR-2. Now
the link list needs to be extended with the following entries:
L DB0NR-3 DB0NR-2 $ Indirect link that is not tested or
reported further, but is shown in the
link list.
L DB0NR-2 DB0ZZZ Link to FlexNet is tested via DB0NR and
possibly used by the network.
There is naturally a certain hitch in the matter:
- The D command now also reports a route to DB0NR-14, even
though it may not even exist. The link command can only
link one (-0, -1, -2) or all SSID's (0-15).
- The Net/ROM link nodes, not the user accesses, must allow
L2 digipeating. This should not cause any problems for
- 39 -
RMNC/FlexNet Software Version 3.0 Sysop Documentation
accesses to DB0NR-0, since the diode matrix in the Net/ROM
TNC's operate without collisions.
The links made possible by this trick for two FlexNet digipeaters
via a Net/ROM node suffer naturally from the missing hop-to-hop
acknowledge. This compromise can be accepted in view of the
advantages for the network: if the links operate 100%, there will
be no disadvantages, since the hop-to-hop acknowledge only comes
into effect for retries. If they work poorly, FlexNet will use
another route if available.
In case the Net/ROM operator is uncooperative and disables L2
digipeating on the link TNC's, the link should still be configured
as described. The call of the Net/ROM will just not be forwarded
and the users are forced to find their own way there. When
digipeating is again enabled, the route starts running
immediately.
- End -
bbs>
------------------------------
End of TCP-Group Digest V93 #40
******************************
******************************