Hamradio

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
===== English DK7WJ/DG0JAB/DL4VBP =====
R M N C / F l e x N e t  and   P C / F l e x N e t

Sysop Manual Software

June 1995

Gunter Jost, DK7WJ

translated by Mario Lorenz, DG0JAB

last edited July 1998, DL4VBP

The documentation describes RMNC/FlexNet up to version 3.3h and PC/FlexNet up to version 3.3g.

This manual was written with great care. However, it may contain errors. Therefore, there is no warranty of any kind nor any other legal responsibility of the author or the translator.

Copyright (C) 1987-1998 Gunter Jost,
DK7WJ, Lichtenbergstr. 77, D-64289 Darmstadt

All rights reserved. No part of this manual may be reproduced or duplicated without prior written consent of the author.

Versions 

__**1. News on Version 3.3**__

__**1.1. Channel Synchronization**__

It is now possible to synchronize several channels by software. The DCDs of these channels are checked mutually, and only one channel may send at one time. The timing parameters are optimized for multimode user access ports and cannot be changed at the moment. Activation is done by an additional "s" in the MODE-command. All ports with the "s"-flag set are barred against each other. A hardware DCD conjunction may, but does not need to be removed. It is not possible to define more than one group of synchronized channels.

__**1.2. DAMA-Master**__

The node now is capable of the DAMA protocol, currently only simplex. On synchronized channels, the DAMA mode is synchron, too. The transmission time per QSO is currently limited to about. 4 seconds; parameters cannot be specified currently. DAMA mode may be activated by an "m" in the MODE-Command. It is possible to have several independent DAMA masters at the same time, e.g. for user ports on different frequencies. On multimode ports, the combination "sm" has to be used (not on RMNC fullmaster).

__**1.3. DAMA-Slave**__

When a channel hears another DAMA master, e.g. when using the system as user frontend, this channel is set to DAMA slave mode automatically. For network nodes this feature can be turned off.

__**1.4. Local C-Text**__

An additional C-Text can be set up for users which connect locally, i.e. without a digipeater in their path. This text can be written by using the command "WRITE L". Any user can read it with the help of "LOCAL". It is useful to move special hints, for example about the local user ports, away from the C-Text to the L-Text, if they are not of any interest when accessing the node via interlinks.

__**1.5. New Link Options**__

Subnet links (">" - links) can be hidden now. The ">" must be replaced by ")" to achieve this.

__**1.6. New Trace Options**__

|#       |suppression of RR/RNR/REJ-Frames |
|$       |suppression of I- and UI-Texts, i.e. only the frameheaders are displayed |
|<call>  |trace only this callsign. Only check source and destination callsigns, digipeater callsigns are not checked. SSID is taken care of, if specified. |
|>       |only frames sent |
|<       |only frames received |

The port number still needs to be defined.

__**1.7. Talk Command**__

With this command a line of text can be sent to another user who is connected to the infobox. The output is similar to the "/s"-command in convers mode. This command is not implemented on RMNC fullmasters.

Syntax: "TALK <call> <text>"\\ 
Instead of typing the TALK-command for each line, a durable TALK mode can be activated by "TALK <CALL>"; it is ended by giving "/q". This is similar to convers mode.

__**1.8. TxDelay Measurement**__

On any port TxDelay measurement of the other stations can be activated. If the measured TxDelay exceeds the needed TxDelay more than 100ms, the connection is interrupted. For stations without a digi in their path, a warning message is issued.

__**1.9. New MODE-command Parameters**__

|-     |Turn off port
|y     |On this port, you will always be sysop as long as there are no digipeaters in your path. For security reasons, on RMNCs this may only be set in the MRMNC compiler. On these ports the loop detector is inactive.\\ ATTENTION: This attribute should only be set on local(wired) links. Even here, it must be impossible to connect back to the node, otherwise everything can be reprogrammed freely. |
|C     |Only relevant in KISS mode: Force CRC mode.\\ On some PC/Flexnet drivers: Activation of software DCD. |
|M     |DAMA master (see separate discussion) |
|S     |Channel synchronization (see separate discussion) |
|U     |This port is a user port. Activates following features (on RMNC fullmaster only partially implemented):\\ * Port never goes into DAMA-Slavemode\\ * TxDelay-Measurement (see separate discussion)\\ * If in DAMA mode: Disconnect of users who poll the digi several times (i.e. they are no proper DAMA slaves). If a connection is interrupted due to one of the conditions above, a warning message is issued, but only if the user is connected directly, i.e. without any digipeaters in the path. |

__**1.10. New U-Options**__

|=       |show only Infobox-QSOs (was: any character) |
|<call>  |show only QSOs from/to this callsign (solomaster only) |
|*       |as usual, display additional QSO data |

__**1.11. New L-Option**__

With "L *", extended statistics are shown. This includes the uptime of the software and the up- or downtime of each link. Link resets will reset this time only if they are caused locally or the connection is interrupted.

__**1.12 Heardlist / MH-Command**__

The Hearlist, up to now only used internally for routing, can be displayed now. All heard callsigns are inserted into the list. This also improves the port routing. The list contains max. 200 callsigns and is saved to HD
on PCs every ten minutes.

^Options:^
|<port>  |Portnumber 0-15, list only callsigns heard on this port |
|<count> |number of callsigns to be listed. Default is 30. <count> must be in the range 16 ... 200. |
|<call>  |Look for this callsign. SSID is ignored if not specified. |

__**1.13. Better command line interpreter**__

The command line interpreter of the infobox now works line oriented instead of frame oriented. This makes uploading of parameters faster and the convers mode has fewer problems formatting the text. Not implemented on RMNC fullmasters.

__**1.14. Other changes to Version 3.2**__

  * Baudrate no longer defaults to 1200 baud. It now needs to be explicitly set for each port. Therefore, the list file only shows the used ports now.
  * The P-command accepts a port number; "P 1" now only lists the line for port 1
  * On solomasters, text memory is 7.5KB now
  * The autorouter has been modified slightly; routing-changes in the network are broadcasted faster now.

__**2. INTRODUCTION**__

__**2.1. The history of FlexNet**__

First ideas for the software came back in 1987, and the first version was developed in 1988. First tests were run at home and later at the digipeater DB0ODW in Odenwald, Germany. This digi was equipped with a complete 6809-development system and made it possible to test new versions by uploading them. In 1989 the work on the RMNC version began. The RMNC (Rhein-Main-Network-Controller) was developed by the PR-Group of Frankfurt (RMPRG) and offered an optimal platform for FlexNet. Since 1991 a version for MS-DOS-Computers has existed, but it has been used only internally and never been distributed. However, after a growing demand for such a PC/FlexNet, in 1994 a new modular driver concept was developed in cooperation with DL8MBT, the author of the BAYCOM software. This makes PC/Flexnet usable for almost everybody. PC/FlexNet is freely configurable and may be used with any I/O-modules. It also offers an application interface for high level applications, such as terminal emulations. Development kits for this interface and the IO-drivers are available. PC/Flexnet is usable also for end-users which do not need a whole node.
User are offered by this an AX25-driver with the advantages of FlexNet, like the very easy parameter setting and the modular driver concept. It runs with almost every terminal program which supports the WA8DED Hostmode.(See File TFEMU.DOC for details) In this case, FLEXDIGI.EXE is not loaded, and therefore no work needs to be wasted in setting it up.

At this point we wish to thank everyone who helped us in developing the software. Our special thanks to all the sysops, who patiently tested the software again and again to get it stable. The goal of FlexNet was and is to develop a robust and easy-to-maintain node software, which should annoy sysops and users as little as possible.

__**2.2. Important features of FlexNet**__

RMNC/FlexNet V2 was a version which had many differences to previous versions for users and sysops, both operational & optical. The RMNC/FlexNet V3.0 had some new features, where the autorouter was the most important one. V3.2 was completely revised and became faster and more comfortable again. V3.3 brought the DAMA channel access method and is forerunner of a completely new access method which is also usable on echo duplex nodes. Maintenance of the RMNC was even more simplified, the change of the whole software of the node can now be done by changing one single EPROM. All L2- and L1-parameters except TxDelay are set adaptively to the current working conditions; this means that the sysop has almost no work in setting up parameters. We found it unnecessary to have parameters for every special cases.It was reached the point where the node runs without any maintenance, except for dropouts, of course. Some statistics are useful for the sysop in optimizing the interlinks and make the network transparent to the user. The permanent development and the very cheap hardware made RMNC/FlexNet to the most popular system within Germany, and the growth rates in foreign countries are impressive. From now on FlexNet for MS-DOS is available. The RMNC is not intended to
be replaced, it is still the preferred platform for unattended nodes. However, it is an alternative for existing PC-based nodes and makes it possible to experiment with FlexNet without prior high investments in hardware.

__**2.2.1. Hop-to-Hop-Acknowledgement**__

Since V2 an important feature has been the immediate acknowledgement of received frames of QSOs which run via the digi. This greatly improves the stability of the links. The possibility of a failure used to be increased exponentially to the number of digipeaters in the path. Now the whole link is as good as the worst interlink on the way.

__**2.2.2. Connectability**__

Since V2 the RMNC-digi has been connectable, i.e. QSOs are now possible with the digipeater itself (previously it was only a L2-digi). The digi offers several service functions, for instance convers mode, link information and some information pages.

__**2.2.3 Remote Control**__

The FlexNet-software makes it possible to enter sysop mode of the digipeater remotely. This allows changing of parameters, information pages, link information and so on after successful authorization as sysop.

__**2.2.4. Installation**__

Updating to a new RMNC/FlexNet-software version is easy, just one EPROM needs to be programmed and changed. To simplify the configuration of the node, an IBM-PC(and compatible) based program is available for doing this job. Please refer to the chapters "Installing RMNC/FlexNet and "Generating a MASTER EPROM".

The software is available at no costs for use in amateur radio and may be copied freely in binary form (Disk/EPROM) as long as you accept the legal terms. (see section 6)

__**3. Using FlexNet**__

Using a FlexNet node is very similar to using any other digipeater system. However, you have to specify the callsign of the entry and the destination node. The hop-to-hop-acknowledgement which has been used since V2 should now be known to the users. The FlexNet auto-router should not cause problems anymore also. Surprises can occur from the loop detector only. It displays the message "loop detected" if the user tries to connect a node which would be routed back to the same port the user comes from.

__**3.1. Adaptive Parameter Settings**__

Most parameters which had to be set manually on traditional node systems are set automatically by FlexNet according to the actual conditions. After many experiments, RETRIES were set to 10, but this caused QSOs on fast links to break on short interrupts. To fix this, the node polls at least 90 seconds before giving up. The number of polls, therefore, indirectly depends on the data rate and the use of the channel. FRACK (Frame-Acknowledge-Time, T1) is permanently adjusted to the time the other station needs to acknowledge the I-Frames. MAXFRAME is set according to the reliability of the connection. When all frames are acknowledged reliably, MAXFRAME is quickly set to 7. On 1200Bd, however, 7 frames are sent relatively rarely, since the maximum time of one transmission is restricted to 12 seconds. All QSOs are handled equally, i.e. they share the 12 seconds transmission time. If one station needs a retransmission of frames (e.g. by REJects), MAXFRAME is decreased instantly. In this case it is provable that the throughput is significantly higher when MAXFRAME is set between 1 and 3. Only the quality of the connection TO the other station is checked, not the connection FROM the other station. A poll which gets the acknowledgement of all frames or a lost acknowledgement does not affect MAXFRAME. PERSISTENCE is the most critical parameter when many users are using the same channel. A fixed parameter setting is always only a bad compromise between collision probability and transmission willingness. FlexNet, therefore, makes use of a new access method, which works fully
adaptively. All stations on the channel are permanently counted (column "usr" in the P-list). A waiting time is calculated from this value and from the data rate. The channel needs to be free for at least this time (about 4 secs on 1200Bd and 10 users) to cause FlexNet to think about transmitting. When this time is over, the channel is checked in variable intervals and - if necessary - the node goes "on air". The throughput is drastically increased by this algorithm, especially on duplex nodes. Now aggressive stations do not have the advantage of being serviced faster;
there is always enough free time for weak stations. If there are only one or two stations, the channel is almost fully accessed, thus making fast downloads possible on low traffic times. On simplex nodes, of course, many
collisions still happen. But even here, the new algorithm improves things significantly. It would be good if the user software could follow this trend to adapt the parameters to the actual conditions. A computer should be able to do this job better and faster than a human could do, especially since it seems to be common that most users are unable to set their parameters correctly.

__**3.2. The phases of a connection via the Digipeater**__

__**3.2.1. Link Setup**__

During the connection setup the received SABM-frames are routed normally, the UA is not sent immediately. This means that the connection is established only if the called station is reachable. When the called station answers with an UA, this will be routed to the calling station. At this moment, 2 QSOs are in the user list, one from the calling station to the called station, and one back. A special feature of FlexNet is, that the connection can be established in one single step without disadvantages, the common L2 digipeating is simulated. At home, you can directly "Connect <user> via <entrynode> ,<exit node>" or "Connect <destination node> via <entry node>". You do not need several "Connect" commands to make your way to the destination. As hop-to-hop-acknowledgement is still active, the quality of your QSO is not affected.

__**3.2.2. Information Transfer**__

During the information transfer, hop-to-hop-acknowledgement gets activated. Every I-Frame is immediately acknowledged by the digipeater. Now the digipeater tries to route the packet further on to its destination. REJects due to interference or collision only happen at one section, not in the whole route.

__**3.2.3. Link Failure**__

If the connection breaks at one side during information transfer, the digipeater interrupts the whole connection and displays the message: "<nowiki>***</nowiki> OK0NE: link failure". Thus, the partner gets informed that something does not work.

__**3.2.4 Disconnect**__

When station "A" disconnects, the digipeater responds immediately with an UA. The digi now tries to abort the connection to "B". When there is not any data for station "B" anymore, this happens at once. If there are some I-frames left, they are sent to "B" before the connection is terminated. When "B" tries to send frames to "A", which is already disconnected, these frames are discarded.

__**3.3. Methods of Routing**__

As mentioned above, not every digipeater in between needs to be named, only the entry- and the destination-digipeater must be known. There are 4 methods to route a frame to its destination. They are tried in the following order:
  - destination table routing
  - link table routing
  - Heardlist routing
  - SSID routing

__**3.3.1. Destination Table Routing**__

The first method is based upon the callsign information. The digi tries to look up the destination callsign in a table maintained by the autorouter. If the callsign is found in this list, the frame is sent to the correspondingneighbor.

Example: DB0ODW has the following interlinks:

1:DB0KT\\ 
2:DB0AAC\\ 
3:DB0IE\\ 

and knows the destinations: DB0EQ, DB0ZDF etc. The frame: <fm DG3FBL to DK7WJ via DB0ODW, DB0ZDF> gets expanded to <fm DG3FBL to DK7WJ via DB0ODW*,DB0AAC,DB0ZDF> DB0AAC is now the next call in the digipeater field, and is known as a
neighbor of DB0ODW on port 2. So the frame is sent on port 2 to DB0AAC which will then route it to DB0ZDF.

__**3.3.2. Link Table Routing**__

When the router does not find a matching entry in the destination table, the digi now tries to look up the call in the link table as set up by the sysop. If a route is found here, the frame is sent to the right port.

Example: DB0ODW has the following interlinks:

1:DB0KT\\ 
2:DB0AAC\\ 
3:DB0IE\\ 
4:DB0AIS #\\ 

The frame <fm DG3FBL to DK7WJ via DB0ODW,DB0AIS> is transmitted on port 4, although there is no entry in the destination table. In this case, only the link table is used for routing.

__**3.3.3. Heardlist routing**__

The node remembers the last 200 stations heard in an internal list. The SSID of the station is taken care of, if possible. So it is possible to be standby on different ports with different SSID's without any problems; you will always receive your frames on the right port. Incoming connection wishes and UNPROTOS are routed according to this list.

__**3.3.4. SSID routing**__

The last chance to get the frame delivered is the SSID specified for the digipeater. The sysop can assign SSID's to certain ports using the PARMS command. To make use of the SSID routing, the user just specifies the SSID of the port where he wishes his frame to be transmitted.

Example: DB0ODW has the following mappings of the SSID's to the port numbers:

port 1 has the SSID -0, port 5 the SSID -12, port 6 the SSID -3

When there is a connect request received which specifies a SSID for the node, the frame is sent on the port specified by the SSID:

<fm DG3FBL to DK7WJ via DB0ODW-12>

This frame is transmitted on port 5, which owns the SSID -12, provided there is no other way known to DK7WJ. On port 5 the following frame appears:

<fm DG3FBL to DK7WJ via DB0ODW-3*>

This ensures that someone on port 5 knows where the frame came from, i.e. the entry-SSID is put into the frame. This SSID change is needed to ensure that the receiver knows where to send his UA to, i.e. port 6 with the SSID -3. This is an important feature of FlexNet. All paths are reversible, i.e. transparent to the receiver, even if the connection came by connecting further on at a node. This routing method is used mainly on user ports.

When all these routing methods fail, the frame is discarded. If the frame was created by an "Connect" command at the node, the user gets the message: "<nowiki>***</nowiki> <call>: can't route"

__**4.Infobox-commands**__

__**4.1. User Commands**__

User commands are all the commands normal users can access. The sysop has a set of additional commands or may specify additional parameters to normal user commands. In this documentation, <CR> means entering of a Carriage Return, $0D. The "=>" is the system prompt of FlexNet;input is expected now. All input can be made either upper or lower case.Is another command entered than those listed below, the node answers with: "invalid command".

__**4.1.1. L<A>test News**__

Syntax: A <CR>

The A-Command shows the text for latest news as set by the sysop. After a cold reboot this text is empty.

__**4.1.2. <B>eacon**__

Syntax: B <CR>

The B-Command shows the current beacon file. In this file you can see which beacon is sent on which port in which interval. After a cold reboot the default beacon is sent on port 0 or 1.

__**4.1.3. <C>onvers mode**__

Syntax: C <CR>

If no callsign is given, the CONNECT command puts you in convers mode. By this mode, a great number of stations can have a round table conversation There are 255 different convers channels available. After entering the C-Command, you get a list of all stations connected to the node and, if they are in convers mode, too, the channel on which they are. Now the node prompts for a number, which selects the channel you want to join.

Example:

<code>
=>C <CR>
users:
0: DL1AA 0:DL1ZZ  ---: DL2XY    73: DG3FBL    73: DK7WJ

channel ? 73 <CR>
*** starting convers, exit: /q
</code>

In this example, DL1AA and DL1ZZ are on channel no. 0 and DG3FBL and DK7WJ on channel 73. DL2XY is connected to the node without being in convers mode. Having given the desired number 73, the conversation starts. All stations logged in onto the chosen channel get the message:

<code>
 " <DL9ABC>: *** Logon"
</code>

While being in convers mode you have the following commands at your disposal:

|"/w"              |shows all stations connected to the node (with convers channel number if available) |
|"/c"              |shows the actual channel number |
|"/c n"            |switches to channel n |
|"/s <call> <msg>" |sends private msg to <call> only |
|"/m <call> <msg>" |sends private msg to <call> only |
|"/q"              |quits convers mode |

If a station disconnects while being in convers mode or quits convers mode, all other users of the channel get the message:

<code>
"<DL9ABC>: *** Logoff".
</code>

If a user changes to another channel, the users of the left channel get the message:

<code>
"<DL9ABC>: *** switched to channel n"
</code>

If there is no channel number entered on convers start-up, convers mode is ended immediately. You are then prompted for a new command.

__**4.1.4. <C>onnect**__

Syntax: C Call [via] [digi1 digi2 ... digi8] <CR>

The CONNECT command is used to connect further onwards. The node will try to connect you to the station via the path you specified. To confirm your command, you get the message "link setup...".As soon as the connection is made, you will get "<nowiki>***</nowiki> connected to <call>" from the node. When the called station did not respond, you get "*** failure with <call>". If the called station sends a Busy (DM),  the message "<nowiki>***</nowiki> busy from <call>" is sent to you. The link setup can be interrupted by sending a single <CR> to the node. If you see the message "*** can`t connect twice", you have tried to establish a QSO which already exists with the same callsign fields.

With the C-Command it is also possible to change the user port, if the node has more than one. By typing  "C -7" you change to the port with the SSID 7. This is acknowledged by the message "<nowiki>***</nowiki> <call>: SSID OK".

If you connect to another station from the node onwards, and that station disconnects you, you will get reconnected to the node. To show you what happened, you get a "<nowiki>***</nowiki> reconnected to <call>" then.

A connect request will be denied, if it causes a loop in the network. If, for example, you are connected to DB0KT via DB0ODW, you cannot connect back to DB0ODW nor to other nodes behind DB0ODW.  You should quit the QSO with DB0KT then and retry after the reconnect.

Example: (user is connected to DB0HP)

<code>
=> C DB0ODW <CR>
link setup...
*** connected to DB0ODW
RMNC/FlexNet V3.3d - DB0ODW - JN49 IQ - Help mit H

=> C DB0HP <CR>
*** DB0ODW: loop detected
=> Q <CR>
73!
*** reconnected to DB0HP
=>
</code>

__**4.1.5. <D>estinations**__

Syntax: D [call] <CR>

The DESTINATIONS command prints out the destination table maintained by the node. In this table all nodes, where the autorouter knows a way to, are shown. For every callsign there are the SSID range of the callsign and the average round trip time in 100 ms steps are shown. As an optional parameter a destination callsign may be given. The node will now try to work out the way to this node and will show it (after some seconds, depending on the (round-trip time). Uppercase callsigns mean that the node knows the FlexNet protocol, lower case callsigns are inserted by the autorouter to reach the next FlexNet node. The characters "???" mean, that the previous digi does not know the way to the destination. This may happen, when the route to the destination is reorganized at the moment or when the destination is not reachable anymore. The "D-Table" is usually the same on all nodes. Only when round trip times get too high, a node is not shown anymore. Only nodes that you can reach without link loops are shown by default. This reduces link load and has the advantage that you will see only the nodes that are not in your direction. By using the
option "*", you will get the complete list. Another possibility is the selective display of a part of the list. By entering "D HB9" for example, you get all destinations containing "HB9" in the callsign, i.e. the whole  Swiss network. Both parameters may be used together. If you type "D * HB9" you will get all Swiss destinations, including these you cannot reach without loops.

__**4.1.6. <F>ind**__

Syntax: F call <CR>

With the FIND command it is possible to look for a station which is standby on this or another node. When the F-Command and the callsign are entered, the digi sends UI-frames with the POLL-bit set to this station via some neighbor nodes. Source callsign is the callsign of the OM who issued the FIND command. If the called station hears the frame, it will answer with a DM- Frame. The node analyses all frames coming back and is able to determine if this was an answer of the FIND command. If this is the case, you will get a message via which node the station was found. If the called station is already connected to the node, no special frame is sent and the user will get the message that the user is QRV on the digi.

Example:

<code>
=>F DK7WJ <CR>
*** DK7WJ found via DB0ODW
=>
</code>

Only the node via which the called station was found is put out. It will be known to the autorouter. If the station was not found, a system prompt "=>" appears again. Since the used UI and DM frames may get lost, it is advisable to use the FIND command more than only once to be sure the user is not QRV. Due to the protocol, the SSID of the called station must be known.

__**4.1.7. <H>elp**__

Syntax: H <CR>

The H-Command prints out the text-file HELP. The text can be entered by the sysop only and should give short help text about using the node. After a cold reboot the text is empty.

__**4.1.8. <I>nfo**__

Syntax: I <CR>

The I-Command prints out the text-file INFO. This text can be entered by the sysop only and should provide information about the node (QTH, equipment, antennas and so on). After a cold reboot the text is empty.

__**4.1.9. <IO> (In/Out)**__

Syntax: IO <CR>

The IO-Command shows the state of the I/O-ports of the RMNC reset card. There are 16 lines in and 16 lines out. The latter may be set only by the sysop. Using this ability it is possible to remote control the node by hardware. There are no limits to the fantasy of the sysop. The data is shown binary.

Example:
<code>
=>IO<CR>
I: 0000 0000 0000 0000     O: 0000 0000 0000 0000
=>
</code>

The input lines are shown first and then those of the output. 0 means "low", 1 means "high". The meaning of the single bits needs to be documented by the sysop.

__**4.1.10. <L>inks**__

Syntax: L <CR>

The LINKS-Command displays the link table set up by the sysop. Example:

<code>
=>L <CR>
DB0KT     0-7     60/68        P1
DB0AAC    0-15    (---)        P2
DB0IE     0-1      583         P3 @
DB0EQ     0-8   (355/399)      via DB0IE
DK7WJ     8-11    44/67        P0  -
DB0ABA                         P4
DB0BBS    0-15     ---         P5
</code>

In the first column the callsigns of the neighbor nodes are shown. Second column shows the SSID ranges of these stations (default: 0-15). In the third column you read the round trip time to the neighbor in 100 ms-steps. No number here means that the round trip time is not calculated. Three hyphens mean that the link is not available at the moment. Three hyphens within brackets mean that the link is not available but the autorouter is aware of another way to the station. If there is only one number in the column, the link partner does not know about the FlexNet protocol, or the internode QSO could not be established. When the sysop knows that the neighbor does not know the FlexNet protocol, he may set the attribute "@" to the link. Then only the link is tested, not if the partner knows the protocol. If the round trip time is surrounded by brackets, the link is so bad that it is not made known to the network. If there are two numbers, separated by a diagonal stroke, the neighbor is a FlexNet node. In this case the round trip times of both directions are shown. If these values are within brackets, the autorouter knows a better
way to the destination, i.e. the direct link is not used. The 4th column shows either the port number of the link to the neighbor (on direct links) or the stations via which the neighbor is reachable. A hyphen behind the port number means that the link is not made known to the network. This may be used for temporary links or software tests for example. "L *" shows the last 16 round trip times that have been calculated. This makes the diagnosis of problems more easy.

__**4.1.11. <LO>cal**__

Syntax: LO <CR>

The LO-Command shows the text-file LOCAL. This text is appended to the CTEXT for local users, but it can be displayed by the LO command separately. The text may only be entered by the sysop. After a cold reboot this text is empty.

__**4.1.12. <M>ail**__

Syntax: M <CR>

The MAIL-Command connects you to the nearest BBS as defined by the sysop. This command therefore works like a "Connect" command with predefined destination. The BBS callsign can be shown with "M ?" (notice the space!)

__**4.1.13. <MH>eard**__

Syntax: MH [options] <CR>

The MHeard-Command by default displays the last 30 direct heard callsigns. Optionally, a port number, a callsign (with or without SSID) or a number (16 ... 200) of entries to be listed, may be given. "MH x" shows all entries that contain the "x" in the callsign i.e. "MH WJ" shows the entries for DF4WJ and DK7WJ but also a WJ2O callsign.

__**4.1.14. <MY>call**__

Syntax: MY <CR>

The mycall command gives the callsign and the SSID range of the node. Example:

<code>
=> MY <CR>
mycall: DB0ODW, SSID's: 0-7
=>
</code>

__**4.1.15. <P>arameters**__

Syntax: P <CR>

The PARAMETERS command puts out a list of the current parameters and some channel statistics. Additionally, the links as shown with the <L> command are displayed.

Example:
<code>
=> P <CR>
po  id td  qso usr tifr rifr tkby  rkby  qty    mode     links
1   -- 10   30  1  365  287    50    33  100   9600d*+   DB0KT 0-10   6/6
2   -- 1    36  1  271  908    30   163   99  19200d*+   DB0GV 0-0    4
3   -- 1     1  1    0    0     0     0  100   9600d*+   DB0GV 6-6   10
4   -- 40    3  1   27    3     2     0   82   1200*+    DB0TCP 0-15 580/647
5   -- 1    50  1  835  377   102    55  100  19200dtr*+ DB0SHI 0-15  11/39
6   -- 1    39  1  582  546    78    42  100  38400d*+   DB0GV 10-12  1/1
7   -- 40    4  1   31    3     2     0   70   1200*+    DB0ASF 0-15 229/243
8    7 40    8  8  184   36    34     1   92   1200*+
</code>

The single columns mean:

|po:      |Port number |
|id:      |Port SSID, on interlink-only ports "--" |
|td:      |TxDelay in 10 ms units |
|qso:     |number of QSOs on this port, internode QSOs are also counted |
|usr:     |number of stations heard on this port (since 3 mins) |
|tifr:    |transmitted I-frames within the last 10 mins |
|rifr:    |received I-frames within the last 10 mins |
|tkby:    |transmitted kilobytes within the last 10 mins |
|rkby:    |received kilobytes within the last 10 mins |
|qty:     |quality of the channel; this is updated every 10 mins, but not if there was nothing to send. |
|mode:    |Baudrate on this port, additionally: |
|         |"c"  KISS: CRC-Mode, HDLC: Software-DCD (depends on hardware) |
|         |"d"  fullduplex |
|         |"t"  external TX-Clock |
|         |"r"  external RX-Clock |
|         |"z"  NRZ mode |
|         |"m"  DAMA master |
|         |"s"  port is synchronized |
|         |"u"  port is user port |
|         |"y"  autosysop |
|         |"+"  8 Mhz CPU-Clock (RMNC) |
|         |"!"  12 Mhz CPU-Clock (RMNC) |
|         |"#"  16 Mhz   CPU-Clock (RMNC) |
|links:   |see <L>-Command |

When counting the I-frames, re-iterated frames and frames which got lost due to DISC are not counted. The kilobyte statements are only the contents of the acknowledged I-frames, re-iterations are not counted, too. Thus, this is the genuine net data rate.

__**4.1.16. <Q>uit**__

Syntax:  Q <CR>

The QUIT-Command ends the QSO with the node. After a "73!" you get disconnected. If you are connected from another FlexNet node, you will be reconnected to that node.

__**4.1.17. <S>etsearch**__

Syntax:  S <CR>

The SETSEARCH-Command displays all digipeaters via which the FIND-Command searches for someone. Example:

<code>
=>S<CR>
search digi's:
DB0ODW
DB0KT via DB0ODW
DB0AAI via DB0ODW
DB0DA via DB0ODW
DB0IE via DB0ODW
=>
</code>

The frame generated by the FIND-Command would be sent via DB0ODW, DB0KT, DB0DA, DB0AAI and DB0IE.

__**4.1.18. <T>alk**__

Syntax: T <call> [<text>] <CR>

With this command you can talk to other users connected to the node. There are two modes: If there is a text given behind the callsign, then this line is sent and you get back to the prompt. Thus, you have to issue a new Talk-Command for each line. By "T <call> <CR>" you get into the permanent talk mode which can be left later by using "/q". This is similar to convers mode, with the difference that it does not happen on a convers channel. All Convers-Commands are active and the current status can be displayed with "/c".

__**4.1.19. <U>sers**__

Syntax:  U [n] <CR>

The USERS-command displays all users which have a QSO with or via the node. Additional information is provided:
Example:

<code>
=> U <CR>

   1: S5    P0: DB0ODW>DG3FBL
   6: S7 U1 P0: DB0ODW>DK7WJ

  35: S5    P0: DL1AA>DB0GV v DB0ODW DB0KT
2014: S5    P8: DB0GV>DL1AA v DB0KT DB0ODW
</code>

i.e.
|1. column:    |QSO number. The node uses this number for internal management of the QSO. |
|2. column:    |QSO state. This number shows the state of the QSO. (see appendix for explanation) |
|3. column:    |shows the number of unacknowledged frames of the QSO, if there are any. |
|4. column:    |port |
|5. column:    |calls and digipeater field |

The QSOs with the node are shown first, then the ones which run via the node. Additional parameters may be specified on the "U" command line. If you enter an "i", only QSOs with the node are shown. If you enter a port number, you get all QSOs via that port. Using "U *" you get additional information about the QSOs. The parameters may be combined. For example, "U * 4" shows all QSOs on port 4 with detailed information.

Example:
<code>
=> U * <CR>

   1: S5        F100  M3   P0  : DB0ODW > DG3FBL
   6: S7  U1    F87   M7   P0  : DB0ODW > DK7WJ

  35: S5      ! F50   M4   P0  : DL1AA > DB0GV v DB0ODW DB0KT
2014: S5      ! F66   M7   P8  : DB0GV > DL1AA v DB0KT DB0ODW
</code>

Additionally, the actual FRACK time "Fxxx" and the MAXFRAME "Mx" are shown for each QSO. On DAMA masters the DAMA priority is shown instead of FRACK. A "!" in front of the F-value says, that the QSO is using header-compression (see section 9.8).

__**4.2. Sysop-Commands**__

In addition to the commands a "normal" user may use, the sysop has some extra privileges. This includes additional commands, or additional parameters to the user commands. Commands which have additional parameters are the as followed:

|<L>inks             |setup of link partners |
|<M>ail              |setup of nearest BBS |
|<MY>call            |setup of node callsign and SSID range |
|<P>arms             |setup of sundry parameters |
|<IO>                |read inputs/set outputs |

Additional commands are:

|<CAL>ibrate         |transmit calibration signal |
|<K>ill              |kill a single QSO |
|<MO>de              |setup HDLC parameters/reset L1-devices (SCCs) |
|<SY>sop             |sysop authorization |
|<W>rite             |write text-files (beacon- and search-files, too) |
|<TR>ace             |monitor a port |
|<RESET>             |cold reboot of the node |
|<RESTART>           |warm reboot of the node |

__**4.2.1. <CAL>librate**__

Syntax: CAL <ch> <mins> <CR>

The CALIBRATE-Command turns on the TX of a specified port (parameter <ch>) for one minute. While this time the carrier is modulated by a continuous sequence of 0 and 1, producing a "diddle" tone with a 50:50 ratio. The command is useful in 2 cases:\\ 
  * It makes it possible for the link partner to set his antenna to the right direction.
  * The symmetry of the modulation may be checked and the modem maybe adjusted for best results.
If there are frames in the buffer, they are sent before the calibration starts. To trigger the PTT watchdog the CAL signal is interrupted every 15 seconds for a short time. Optionally, the calibration time in minutes may be given.Default is one minute. With the command "CAL <ch> 0" the CAL signal is cancelled.

__**4.2.2. <IO>**__

Syntax: IO <bit_no> 0|1 <CR>

With the IO-Command the output-lines of the reset-card may be set or cleared. <bit_nr> specifies the number of the bit to be changed, and 0 or 1 says whether the bit should be set to "high" or "low".

__**4.2.3. <K>ill**__

Syntax:  K <QSO-No> <CR>

The KILL-Command terminates an existing QSO. The QSO number must be specified (U-Command, 1. column). Why this command? It is not made to let the sysop feel like the "big boss", but sometimes it is necessary to kill a QSO.

Example:\\ 
Station A is connected to station B, and A transmits a longer text to B. After a certain time, the receiver of the text, station B, gets busy, i.e. his TNC sends RNR. When this state is not fixed by B itself, the QSO will last for ever, at least up to the next blackout.

__**4.2.4. <L>inks**__

Syntax: L <ch|CALL|-> <CALL> [#|$|-|@|>|)|!] <CR>

The LINK-Command is used to set up interlinks. Two parameters are needed, a 3rd one is optional. Callsigns may be written either as upper- or lowercase.

^1st parameter: ^
|port:     |set up direct interlink on this port |
|callsign: |set up interlink via that callsign, i.e. the destination is reachable via a neighbor already specified. |
|-       : |the minus sign deletes the link entry |
^2nd parameter: ^
|Here the callsign of the link partner is given. If no SSID's are specified, 0-15 are assumed. When only the SSID 0 is to be linked, -0 has to be added to the callsign. |
^3rd parameter: options ^
|"#" |link is not shown to the users, thus hidden links, for example for service reasons, are possible. |
|"$" |link is not checked for availability and not made known to the network. |
|"@" |no internode communication on this link , but may be used, if the partner is not aware of the FlexNet protocol (i.e. mailboxes) |
|"-" |partner is not made known to the network. This makes emergency- or testlinks possible. Internode communication takes place, thus destinations are routed, only the partner stays hidden. |
|">" |Subnet-Link. This is used to set up subnets, which will receive all information from the network, but are not made known to the network. The partner callsign and the destinations from it are saved for routing reasons, but not sent to the other network nodes. |
|")" |Works like ">", but the link is hidden (">" + "#") |
|"!" |no forwarding of Subnet destinations: Same like ">", but the difference is that the "gateway" node is made known to the network. |

It is possible to have more than one link to the partner on different ports. The router will always use the best link available. You should remember this if changes are made. The old entry may still be valid under circumstances. It is also possible to link partners with the same callsign, or a callsign covered by the SSID range of the node. This is interesting for mailboxes, service computers, DX clusters and similar systems. Using this feature, only the node is forwarded to the network and not every single SSID of the different computers. This helps keeping the D-list in the network smaller.

Example:

MYCALL DB0AIS 0-10\\ 
L 1 DB0AIS-8  @   (Mailbox)\\ 
L 2 DB0AIS-9  @   (Cluster)\\ 
L 3 DB0AIS-10 @   (TCP/IP)\\ 

Only DB0AIS 0-10 is known to the network. If there is a connect request to DB0AIS-8, it is sent out on port 1 to the BBS.  The links are not tested as usually. If the link is not available, the user gets connected to the node itself. Here, the user should get to know what is wrong, perhaps by the C-text. This routing method works on user ports, too. In our example, if DB0AIS would have a user port, the node may be connected as DB0AIS or as DB0AIS-3, and the BBS DB0AIS may be directly connected without digipeaters.

More examples:

L 3 DB0KT\\ 
All frames to DB0KT will be sent on port 3\\ 

L 1 DB0KT\\ 
L 1 DB0FUL\\ 
On port 1, 2 link partners are reachable, so the setup has both calls on port 1.\\ 

There is a principle which says that if no SSID's are specified behind the link callsign, all SSID's are routed via this port. But when a SSID is specified, only the SSID is routed. Example:

L 1 DB0KT\\ 
All frames route to DB0KT, i.e. also the frames to DB0KT-1, DB0KT-2 are routed to port 1.\\

L 1 DB0KT-7\\ 
Only the frames to DB0KT-7 are sent to port 1. Other SSID's are routed by the D-List, when no other links to DB0KT are specified. For FlexNet partners the SSID-Range is automatically adapted.

To remove an entry from the link list, a "-" is given instead of the port number as the first parameter.

Example:\\ 
DB0ODW has the links

1: DB0KT\\ 
2: DB0EAD\\ 
3: DB0IE\\ 
"L - DB0KT" deletes the routing entry for DB0KT. If there is more than one link to the partner, the command has to be given several times to delete every entry. Always only the first entry is removed from the table. Links to NET/ROM partners should be set up as shown in the appendix.

__**4.2.5. <MO>de**__

Syntax: MO <port> <mode> <CR>

This command sets the operating parameters of a specified port. The mode parameters are:

|<num>  |baudrate (on internal clock) |
|"d"    |fullduplex (halfduplex is default) |
|"t"    |external TX Clock (depends on hardware) |
|"p"    |(instead of "d") switches to fullduplex with a holding time of one minute; the PTT watchdog must be disabled! |
|"r"    |external RX Clock (depends on hardware) |
|"z"    |NRZ mode (depends on hardware, NRZI mode is default) |
|"c"    |KISS: CRC mode; HDLC: Soft-DCD (depends on  hardware) |
|"m"    |DAMA master |
|"s"    |synchronize channel with other "s"-channels |
|"u"    |user port, activates for example TxDelay measurement |
|"y"    |auto sysop: Stations which connect on this port without digipeaters in their path are automatically sysops. For security reasons, on RMNC this may only be defined in the EPROM. |
|"-"    |deactivate port |
|"."    |dummy, if there are no arguments needed on special hardware |

The parameters baudrate, "d", "t", "r", "z" and "c" depend on hardware. Check out the hardware or driver documentation. Examples:

<code>
MODE 3 19200d      ;port 3 19200 baud fullduplex
MODE 3 38400trz    ;port 3 38400 baud ext. clock, NRZ
MODE 3 -           ;special case: turn off port 3
</code>

When a MODE command is entered, all Layer1 modules of all channels get initialized. This is not problematic, only frames currently being transmitted or received are involved. QSOs are not affected. A Mode-Command may reinitialize "hanging" SCCs. Therefore you should always try a Mode-Command first before a RESET or RESTART since all QSOs get lost in this case. The port number is not relevant, a "MO 11" will  do the job.

__**4.2.6. <M>ail**__

Syntax: M <call> <CR>

With this command, a BBS callsign is assigned to the node, which can be reached by the users issuing the "M"-Command. It must be reachable in a single step and known to the autorouter.

__**4.2.7. <MY>call**__

Syntax: MY <call> [<ssid1> <ssid2>] <CR>

The MYCALL-Command is used to set up the callsign of the node. With the optional SSID's a range may be defined by which the node can be connected. The SSID range must include the SSID's of every port, no port SSID must be outside the SSID range defined by MYCALL.

Example:

M DB0ODW 0 7

The node callsign is set to DB0ODW. The node may be connected as DB0ODW-0 to DB0ODW-7. When the MYCALL is changed, this will affect only new QSO's. Existing connections stay valid under the old callsign. The internode communication is re-initialized completely, since the change of the callsign needs to be forwarded to the network immediately.

__**4.2.8. <P>arameters**__

|Syntax:  |P I <value> |
|     or  |P S <value> <port> |
|     or  |P T <value> <port> |

The PARAMETER command is used to set up the TxDelay, SSID and the node timeout of a specified port.

|"P I <n>"          |sets the node timeout to <n> minutes where a range from 60 to 255 is valid. n=0 (recommended) disables the timeout. |
|"P T <n> <port>"   |sets the TxDelay of port <port> to <n> in 10ms units. |
|"P S <n> <port>"   |sets the SSID of port <port> to <n>. When an already-set SSID has to be deleted, <port> has to be 16. |

Why do we need SSID's ? They do two jobs: Only on ports which do have a SSID, everyone is allowed to connect. Exclusive interlink ports therefore should not have SSID's (exception: links to NET/ROM partners, see appendix).
The SSID is also needed for routing purposes, if a user who is not in the MHeard-list shall be connected on a specified port. The connect then needs to go via the according SSID, i.e. via <nodecall>-<port-SSID>.

__**4.2.9. <RESET>**__

Syntax: RESET <CR>

This command cold-reboots the node. All QSOs, parameters in the RAM and the text files get lost. The default parameters as stored in the RMNC master EPROM are set. You should use this command only when your parameters got disordered and you want to reset to EPROM defaults. This command is available only on RMNC systems.

__**4.2.10. <RESTART>**__

Syntax: RESTART <CR>

The RESTART-Command basically does the same as the RESET command. However, parameters and text files remain in memory, so usually you should use this command instead of RESET. You should use both commands only in emergency, since all QSO's and the routing information get lost. This command is also available only on RMNC systems.

__**4.2.11. <SY>sop**__

Syntax: SY <CR>

Starting with RMNC Version 3.3h and PC/FlexNet Version 3.3g the sysop authorization has changed. The system now uses a procedure similar to the BayCom BBS.

The SYSOP-Command is used to do the sysop authorization. When a remote request is sent to the node from the sysop to enter the sysop mode, the node answers with random numbers. These numbers correspond to the  characters in the password string of the parameter file (see 7.4.2) or the password file in case of PC/FlexNet. The password string must have a minimum length of 10 and a maximum length of 80 characters. It may contain any printable character between $20-$7E and $A0-FE except the quotation mark ("). How does it work ?

Assuming the password string would be the following:

"Thisisanicepasswordstringforournodeonthehill"

<code>
=>SY <CR>             <- enter sysop command

DB0DA> 41 12 34 7 16 <- numbers returned from the node
</code>

DB0DA answered with five numbers that correspond to the characters: "hpdaw". You can either enter these characters followed by a <CR> or for security reasons embed them in a larger string:

Gjdjg/hj7efjdencDfjef__hpdaw__WfhjgflhlevBcne3d)fj <CR>

Now you gained sysop status (provided, your calculation was OK). After a successful login as sysop no message is returned. You may now try out whether it went all right using a harmless command like TIMEOUT. If you are logged in as sysop, the node timeout is not valid for you anymore, i.e. you may stay connected to the node as long as you wish. The sysop authorization is removed by disconnect, reconnect (link reset) or a Connect-Command. It is possible that more than one sysop is logged in at the same time.

__**4.2.12. <TR>ace**__

Syntax: TRACE <ch> [<call>] [<] [>] [#] [$] <CR>

By using the TRACE-Command, you can monitor the traffic on a given port. This of course only works as long as the buffers do not overflow. When your own QSO is fast enough, you may monitor for a longer time. Compressed QSO's are shown only if your node is the source or the final destination of the QSO. The command is cancelled if the buffers overflow or you type another command. Only one sysop may monitor only one port at one time. You should note that this command needs a large amount of memory and bus capacity, which will slow down specially the monitored channel. Therefore, you should not use it too often and under no circumstances permanently. This command is only available on Solomaster systems.

^Options: ^
|#        |do not display RR/RNR/REJ-Frames |
|$        |suppress the I and UI texts, i.e. display only frame headers |
|<call>   |trace only this callsign. Only source and destination callsigns of a frame, i.e. no digipeater calls are checked. SSID is taken into account if specified. |
|>        |only frames sent |
|<        |only frames received |

__**4.2.13. <W>rite**__

Syntax:  WRITE <A|B|C|H|I|L|S> <CR>

By using the WRITE-Command, the texts for L(A)test news, (B)eacon, (C)-Text, (H)elp, (I)nfo, (LO)cal and (S)etsearch may be entered. All texts except (B)eacon and (S)etsearch may have any desired format. The C-text is sent after the standard system prompt at the beginning of a connect. Standard prompt is "xxxx/FlexNet Vx.x". The C-Text is shown after this.

After any Write-Command, the amount of available memory on the RMNC is shown.

We recommend the following usage of the texts:

|LATEST NEWS:  |recent information about the node and things every user should know |
|INFO:         |general information about the digipeater. QTH, hardware, antennas, use of IO-ports etc. You should not forget to mention the user QRG's. |
|LOCAL:        |this text is appended to the C-Text, when the user comes direct, i.e. without digipeaters in the path. This is the right place for information about the channel access method and other information which is only interesting for local users. |
|HELP:         |A short user's guide to the system with the most important commands |

The text files cannot be saved in the EPROM due to space limitations. The end of the text is marked by either /EX or Ctrl-Z. The text is saved up to the last line before the /EX. Since many PR-stations use "split screen" programs, it is recommended to begin every text except the C-Text with a single <CR>. This looks much better.

The Beacon-file has a special format. You may set up any beacon on any port. The file format is as follows:

# <t> <p> <tocall> [via [via ...] ] :Beacon\\ 
text..........................#

|<#>       |delimits the different beacon information |
|<t>       |time between two beacon transmissions, in minutes. (1..255 minutes) |
|<p>       |port number where the beacon is to be sent |
|<tocall>  |Destination call of the beacon, for example "BEACON", "RMNC", "FLXNET", "TEST" or similar , there may be up to 8 digipeaters specified, via which the beacon will be sent. |

Example:

<code>
10 0 RMNC:Digi Odenwald * JN49IQ * Krehberg/Odw. *#
30 1 RMNC DB0KT DB0ODW:DB0KT QRV#
5  0
FLXNET:Testbeacon DB0ODW
</code>

Our example consists of 3 beacons, each delimited by a "#". (beacon1...#beacon2...#beacon3...) Between the single statements there may be <CR>s to improve readability. It is not important whether the callsigns are upper- or lowercase. Source callsign of the beacon is always the mycall of the node. When no beacon-text has been entered since the last cold-reboot, the default-beacon is sent every 3 minutes:

#3 0 FLXNET:RMNC/FlexNet V3.3d

All beacons are sent as UI (Unproto-Information) with the command bit set.

The SETSEARCH-file has a special format, too. There may be as many search paths as you like. The limit is dependent upon the available memory. The number of the digipeaters is limited to 7. The format is:

<call1>\\ 
<call1> [ <call2> [ <call 3> [ <call 4> [ <call 5> ]]]]

The SETSEARCH-file contains all paths via which the FIND-Command sends its UI-Frames. The first callsign in the line is the digipeater which shall send the UI to the user, the following digipeaters specify the path to the destination digi. These paths should always be identical to the path a user will use. This means, digipeaters on the route to the destination should be left out, the autorouter will know the way.

Example:

<code>
DB0ODW
DB0DA via DB0ODW
DB0KT via DB0ODW
DB0AAI via DB0ODW
</code>

First line says that the UI-frame is sent via the local user port. Second line demonstrates how a path to DB0DA is set up. DB0DA is reachable from DB0ODW via autorouter.

__**5.Command Overview**__

Statements inside [] are optional.

__**5.1. User Commands**__

|A                  |display text LATEST NEWS |
|B                  |display beacon-file |
|C                  |start conversation mode |
|  /w               |list node users |
|  /w n             |list convers users on channel n |
|  /c               |display convers channel number |
|  /c n             |switch to channel n |
|  /s call text     |send private msg to user |
|  /q               |quit conversation mode |
|C call [v] [digi]  |connect further on |
|D [*] [call]       |display destination table, path to destination |
|F <call>           |FIND-command, look for <call> |
|H                  |display text HELP |
|I                  |display text INFO |
|IO                 |In/Out - status |
|L                  |display Interlink information |
|LO                 |display text LOCAL |
|M [?]              |connect next BBS |
|MH [...]           |display Heard-list [selectively] |
|MY                 |display Mycall and SSID-range |
|P                  |display parameters and statistics |
|Q                  |quit, end of connection |
|S                  |SETSEARCH, display search-paths |
|T <call> <text>    |send text to other users |
|U [*] [port/"="]   |display user table [selectively] |

__**5.2. Sysop Commands**__

|CAL <ch> [min]          |port <ch> sends calibration signal |
|IO <bit_nr> 0<nowiki>|</nowiki>1         |set Output bit nr. <bit_nr> to 0<nowiki>|</nowiki>1 |
|K <QSO_no>              |kill QSO nr. <QSO_nr> |
|L <ch> <call>           |route <call> to <ch> |
|L <viacall> <call>      |route <call> via <viacall> |
|L - <call>              |delete link <call> |
|M <call>                |assign local BBS |
|MY <call> [ssid1 ssid2] |set mycall and SSID range |
|MO <ch> <x>             |set port <ch> to mode <x> |
|P I <x>                 |set node timeout to <x> minutes |
|P S <ssid> <ch>         |set SSID <ssid> on port <ch> |
|RESET                   |cold reboot |
|RESTART                 |warm reboot |
|SY                      |sysop authorization |
|TR <ch> [...]           |monitor port <ch> (solomaster only) |
|W <A/B/C/H/I/L/S>       |write text-files (end: /ex) |
|  A                     |text LATEST NEWS |
|  B                     |text BEACON |
|  C                     |text C-Text |
|  H                     |text HELP |
|  I                     |text INFO |
|  L                     |text LOCAL |
|  S                     |text SETSEARCH |

__**6. Legal Terms   -   License Agreement**__

The following restrictions have only the purpose to guarantee the quality and the development of the software and, of course, to avoid commercial use of it, except in special cases agreed on with the author of each module. By experience, on uncontrolled distribution it happens that only parts of the software or obsolete versions of it are spread. This results into problems at the end-user's and into unnecessary and annoying checkbacks. Bad experiences cause the list to grow constantly...

RMNC/FlexNet, PC/FlexNet and the accompanying utilities and the documentation are products of Gunter Jost, DK7WJ. Exceptions are marked as such. All rights reserved by the author. The user is granted the right to use the software under the following conditions:

  * The software is used only for non-commercial purposes within amateur (HAM-) radio. All other usages, especially in other radio services, need a written consent by the author in each separate case.
  * The legal rules of amateur radio operation are strictly followed.
  * Commercial copying and sale of the software is not allowed without prior written consent of the author.
  * No changes must be made at the software which are not explicitly agreed with the author. This does NOT apply for setting specific parameters.
  * Copyright marks and copyright messages of the software modules must not be changed or removed.
  * The software must not be distributed via BBS systems or public accessible bulletin boards, neither in part nor as a whole.
  * Neither the author nor the distributors of the software may be liable for any damages, no matter of what kind, which may occur when using the software. THE RISK OF USING THE SOFTWARE IS ENTIRELY YOUR OWN!

Under this conditions you may make as many copies of the distribution disk as you wish and give them away, where you always have to state the original source (FlexNet-Gruppe Darmstadt, G. Jost, DK7WJ). The sourcecode of the software is not available.

__**6.1. Disclaimer**__

Neither the author nor the distributor of the software may be liable for any damages that may eventually occur when using the software RMNC/FlexNet or PC/FlexNet. The software is provided "AS IS", without warranty of any kind, including but not limited to the warranties of merchantability and fitness for a particular purpose. No features should be taken for granted. The documentation may contain errors or mis-translations.

By using the software you agree to the conditions above.

__**7. Installing  RMNC/FlexNet**__

__**7.1. The RMNC**__

The RMNC consists of an port controller card for each port on a euro-sized board (100 * 160 mm). Additionally a so called reset card is needed which contains the system watchdog and the In/Out-ports for supervisor and control reasons. The cards are run in master/slave mode, i.e. one card is the master (meaning it doesn't carry a radio port), the other cards are the slaves. The whole communication on the system bus is controlled by the master, that means the master polls every slave for information and mediates them where they belong. The only hardware difference between the cards is that the master contains a different EPROM. This has the advantage that only the master needs to be configured, all slaves receive their configuration information from the master. After a reset, the master determines the number and the addresses of the attached cards. Then these cards get initialized with their parameters. If there is a malfunction at one of the port controller cards, the master gets to know this after the watchdog-reset which will occur. The defective card will not be polled anymore, and the node will still work - provided that the damage does not block the bus.

After the reset, all controller cards are ready to accept QSO's. A connection via the digipeater counts as a QSO, too. The software on the controller cards will manage the complete L2 connection on its own and mediates all data directly to the according controller card.

__**7.2. The RMNC-Solomaster**__

Since RMNC/FlexNet Version 3.3h a master is mandatory (see 7.1). The expression "solomaster" is therefore obsolete.

__**7.3. Card Addresses**__

When installing the RMNC/FlexNet software, the card addresses need to be configured. Attention, the master card has no address, i.e. all DIP-switches need to be open! For addressing the other cards, please refer to the hardware manual. The cards may be addressed in any desired order, gaps do not matter.

In the parameter table (P-command) the master always is port 0. When using a Solomaster, then no port 0 is shown. Now the EPROMS can be installed on their boards. Only ONE master EPROM has to be installed, all other cards must be equipped with (identical) slave EPROMS.

The RMNC should be ready for use now. Immediately after the reset, the first beacon is transmitted on the master port or on solomaster systems on port 1.

__**7.4. Generating a MASTER EPROM**__

The software is distributed unconfigured. To configure it, you need at least an EPROM programmer capable of programming 27C512 EPROMS, and an IBM compatible PC.

__**7.4.1. Parameter Compiler**__

The master EPROM is configured with a PC program. With the aid of this compiler and a parameter file, a configured binary file will be created which is ready to be programmed into the EPROM. The slave EPROMS do not need to be configured as they are the same on every RMNC. To get the compiler to make the binary file, you have to create the parameter file first. The parameter file is a plain ASCII file which can be made with any editor. This file contains all necessary parameters. The syntax of the file is similar to the syntax of the sysop commands. When you have finished making the file, you can start the compiler. If you are lucky you now have a file with the same name as that of the text file, but with the extension ".BIN" in the directory. This file also exists when warnings occur there. If the compiler detects syntax errors, no .BIN-file will be created. For control reasons a second file with the extension ".LST" is produced. You should have a look at it to ensure that the compiler understood everything. The .BIN file can be burned into a 27C512 EPROM now.

Syntax of the compiler:

MRMNC <parmfile> [<binfile>] <CR>

The first command line parameter is the file name of the parameter file with extension. Specification of the <binfile>-name is optional and will only be necessary if the name desired is different from the name of the text file. If a file with the same name exists, the compiler will ask if you want to overwrite it. The compiler creates a list file (".LST") which contains all default parameters.

__**7.4.2. Structure of a parameter file**__

Everywhere in the file, except inside of commands, comments are allowed. Everything which stands behind a "*" or a ";" is ignored. Empty lines are ignored, too. The syntax of the commands is the same like entering the commands into the digipeater. The file is not case sensitive. It is recommended that you note down everything carefully. This makes changes easier later.

You should pay attention to the commands SPEED and END, which can only be given in the parameter file, and not as commands online. The WRITE-command does not work either, texts can be entered only online. Differences to the normal syntax occur at the  SYSOP-command. Here the password string for the node is entered.

Example:

<code>
* Configuration of DB0ODW
* date:  1st Apr. 1998

SPEED 8                    * The master runs at 8 Mhz clock speed
                           * (4/8/12/16 Mhz are possible here)
Mycall  DB0ODW 0 7         * Mycall of the node, SSID range 0-7

Sysop "Thisisthepasswordstring"     * Password string for sysop access
                                    * must be be between 10 and 80 charak-                                 
                                    * ters; starting and ending with 
                                    * quotation marks

P SSID  0 1                * Userport is port 1 with SSID -0
P SSID  2 5                * 2nd Userport (-2) on port 5

L 2 DB0KT                  * Interlink to DB0KT
L 3 DB0AAC                 * Interlink to DB0AAC
L 4 DB0IE                  * Interlink to DB0IE
L 5 DK7WJ-8 #              * Testlink to DK7WJ-8 not to be forwarded
                           * to the network

IO 7 1                     * set IO-bit 7  (turn on PA to DB0IE)

mode 1 96t                 * Port 1 with 9600bd and external
                             TX-Clock
mode 2 96d                 * Port 2 with 9600bd fullduplex
mode 3 96d                 * Port 3 with 9600bd fullduplex
mode 4 24                  * Port 4 uses 2400bd

P I 0                      * No timeout for the node (Infobox)

* Layer1-parameters

parm TxDelay 25 1          * User ports need a higher TxDelay
p t 6 2                    * Interlinks only need 60 ms
p t 6 3
p t 6 4
parm TxDelay 25 1          * this is another Userport

END                        * The END command must be the last one!
</code>

__**7.5. Slave-EPROMS**__

The slaves need not to be configured. The EPROM file RM_SLAVE.BIN is intended for programming into an 27C128 EPROM. When a 27C256 EPROM is being used, the file must be placed at the upper half, beginning at $4000.

__**7.5.1. EPROM Patch Slaves 9-15**__

The RMNC2 controller cards contain only a 3bit address switch, thus you can only address a maximum of 8 cards (1 master and 7 slaves). For the slaves 9 - 15, the byte $3F00 ($7F00 on 27C256) must be patched to a value different to $FF. This adds "8" to the address setting of the DIP switches. On RMNC3 cards this is not necessary anymore, here the address can be set directly.

__**7.5.2. KISS-Slave**__

It is possible to use the KISS protocol directly with the node. There is no separate KISS EPROM anymore, on the RMNC2 you have to add a single wire between pins 18 and 39 of the 6522. On RMNC3 you have to short the jumper JP1. Since the KISS protocol is not secure, a CRC mode was added. It can be activated by a MODE-command. Specifications of this new mode are available from the author.

__**8. Installing PC/FlexNet**__

PC/FlexNet runs completely in the background as a TSR, that means that other applications can run simultaneously if there is enough memory left. However, the FlexNet infobox and the beacon generator may not be serviced under some circumstances, so that a dialogue with the node is impossible. This only happens when using badly programmed applications. QSO's via the digi and the internode communication are not affected and should always work, whatever the PC has to do. Probably things get slowed down a little bit.

__**8.1. Hard- and Software Requirements**__

  * PC/XT, better AT with at least 512kB RAM
  * PC/FlexNet needs 200kB RAM, plus space for the L1 drivers and applications
  * Operating system MS-DOS 3.1, better 5.0 or 6.2. Tests with MS-DOS 6.0 caused problems, we have no experiences with DR-DOS or other DOS versions. We recommend the use of MS-DOS 5.0 or 6.2, here most modules can be loaded into the UMB's, provided there is enough memory available.
  * IO-ports as necessary, according to the L1 drivers available

Principally, a PC/XT will work. The gained performance mostly depends on the speed and the throughput of the L1 hardware drivers. PC/FlexNet supports several loadable L1 drivers. They are installed in the memory by simply calling them. This makes it easy to support any hardware. A "driver development kit" for interested developers is available from the author. The port numbers derive from the order of the driver installation. A single driver can support more than one port depending on the hardware. FlexNet, however, is limited to a maximum of 16 ports, the last port (15) is reserved for internal purposes. The port drivers are included on the distribution disk, depending on which drivers are available. For every L1 driver there is a appropriate *.DOC-file which explains the installation. By starting the drivers with the option /?, you will get a short help as well. Many people on different places are working on PC/FlexNet at the same time. Thus, there always new versions of kernels, drivers and
applications. It is always a good idea to ask for new versions if there occur any problems. Changes, even in the installation procedure, may happen. Please read the *.DOC-files carefully!

__**8.2. Installation and Configuration**__

At the beginning, all files must be copied into a directory which should be in the DOS search-path. The start of PC/FlexNet should be done via a batch file because most of the L1 drivers need additional command line arguments. Occurring errors should abort the batch file. A sample batch file is on the distribution disk and can be easily changed to fit your needs.

FLEXNET.EXE must be loaded first, then - if a node is to be installed - FLEXDIGI.EXE. Pure endpoints (Terminal, Cluster, BBS and so on) should not use it. Then the L1 drivers follow in the order you require. At last, the activation of the modules is made by the utility "FLEX". After doing this, no more port drivers can be installed.

FLEXNET.EXE has an optional parameter, which specifies how many RAM may be used by FlexNet. Default is 15kb, but this lasts only for few QSO's. The minimum for nodes with several ports is about 80kb. Depending on how many ports you use, you should experiment with this value. FlexNet loves memory more than everything else and runs best when it has about 30kb per port and additional 20kb for administration.

To load the modules, generally (from DOS 5.0 onwards) you should use the "LOADHIGH" or "LH" command. It does not do any harm if there is not enough memory in the UMB; the file is loaded into conventional memory then. You still gain a little memory, since the environment blocks do not fragment the memory. You may check this by using the "MEM /D" command.

Calling FLEX.EXE with the argument "/U" uninstalls all L1 drivers and removes FLEXNET.EXE from memory. As usually on DOS, no other TSRs should be loaded after FlexNet, otherwise your machine might crash.

The first start of FLEXNET.EXE creates an empty parameter file. Port 15 is generally the interface for applications. The parameter AUTOSYSOP ("y") is set on this port, you should not change it. Now you should set the sysop secret code using "FLEXPASS.EXE". With "TNC.EXE" you can connect the node and continue in setting the parameters. If you made a mistake, you could simply delete the file "FLEXNET.FPR" and begin again. "TNC.EXE" is a simple TNC emulation. With "<ESC> H <CR>" you get a short help. The node can be connected with "<ESC> C <CR>".

The parameter setting of the software can be done now either by the TNC emulation or via remote control. Please check the documentation of the L1 port drivers. Like always on FlexNet, the rest of the parameter settings is very easy and can be finished in a short time.

A remark to the utility "FLEXPASS.EXE": this utility needs an ASCII-file as an argument that contains the password string.

Before you decide to build a digipeater using PC/FlexNet, you should think about the following: The RMNC is still the preferred platform for FlexNet, and something that does not work there will not work on the PC either, except from some bagatelles. The user shall find a uniform and well known (from the RMNCs) user interface. Who prefers the optimum of reliability and performance for minimal costs and maintenance should use the RMNC.

__**9. Appendix**__

__**9.1. Protocol version AX25 V2**__

FlexNet understands QSO's with AX25 version 1 and AX25 version 2. A QSO with the node itself can only be done using version 2. When the node encounters a SABM to it with V1, it replies with DM. When station A is trying to connect a station B via the digi using V2, and the other station responds with V1, the connection happens in V1. However, hop-to-hop acknowledgement is disabled for this QSO, it is not even mentioned in the user list.

__**9.2. Unproto-Frames**__

All UI- (unproto) frames are transmitted and routed, even frames using protocol version 1. This makes it possible to run TCP/IP without any problems, since most TCP/IP programs send their UI-frames in AX25 V1. The length of the I-field of the UI-frames must not exceed 256 bytes.

__**9.3. RNR-Behavior/Recovery**__

Because the memory of the node is limited, it may happen that a user is set to RemoteBusy (RNR) from the digipeater. FlexNet works very defensively in this matter to ensure that there is not too much memory used for one single QSO. It makes no sense anyway to buffer more than about 10 frames for one QSO. RNRs therefore do not mean that the memory of the node is short, but only that there are enough frames buffered to service the QSO fluently. This ensures a fair partition of the channel resources to the QSOs. RNRs often happen in convers mode when one of the partners has a slow link. When the RNR condition has gone, the braked station gets a RR frame with the poll bit set. This causes a RR-final from the station, but only this ensures that the status change is detected by that station. On many AX25-implementations only a RR without poll is sent, which causes hangs of several minutes when it gets lost.

__**9.4. Reconnects**__

A special problem on digipeaters with hop-to-hop acknowledgement are reconnects. A reconnect does mean that a station tries to (re-) establish another connect to its partner using the same calls (and SSID's) and the same or a different path. When this connection happens on a different path, problems may arise. The digi holds the running QSO in his table. When there are no unacknowledged frames, nothing happens. The "zombie-QSO" dies after 15 minutes. However, if there is still data to be sent, the digi tries to service the other station. But since the QSO was reestablished using the other path, the sequence numbers of the original QSO do not match with the new ones. This causes a FRMR (frame reject) and the connection is aborted. The best way to avoid this trouble is to end an existing connection properly before establishing a new one.

__**9.5. I-Polling Method**__

During a connection, it often happens that an I-frame is not acknowledged correctly. In this case, AX25 V2 says that a poll frame (RR) has to be sent in order to query whether the I-frame was received correctly. If not, the I-frame is retransmitted, otherwise the next frame is sent. However, it is provable that this method causes a useless load to the channel, when the I-frame in question is a very short one. With the I-polling method, the short I-frame is repeated immediately with the poll bit set. This is a mixture of the old V1 and the new V2-protocol version. For statistical reasons, the threshold of this method is set to 40 bytes. Any I-frame with fewer than 40 bytes length is repeated immediately when it was not acknowledged within the FRACK-time (T1). The I-poll method is only used at the first 3 retries, then normal polls are applied.

__**9.6. Channel Access Method**__

Up to FlexNet V3.1 the p-persistence algorithm was used. This had the disadvantage that the send-willingness of the station could only be adjusted manually. Since V3.2 there has existed a fully adaptive channel access method, which adapts itself by determining the number of users and the channel allocation to calculate an optimal compromise between throughput and the collision-probability. Variables used:

|B   |Baudrate (1/s) |
|TxD |Tx-Delay (s) |
|R   |Random number (1 .. 10) |
|U   |Total of the users on the channel |
|K   |channel allocation |
|t1  |waiting time after transmission (s) |
|t2  |waiting time between two TX-tries |

<code>
        19200/s
K = (-----------  + 1 ) * (U + 1)
          B
</code>

If K > 255, then K is set to 255. This prevents an increase of t1 on more than twenty users on 1200Bd.

t1 = K * (R+1)*8 * TxD

If t1 > 10s, then t1 is set to 10s, this can only happen on baudrates below 1200Bd.

t1 starts when its own transmission has ended. t1 is stopped as long as the channel is busy. As long as t1 is active, the TX is blocked. When t1 has expired, and the node wants to transmit, the DCD is checked in t2 intervals. If there is only one user, t2 becomes 0.

t2 = 2*TxD * (U-1)

When the channel is busy after the expiration of t2, t2 starts again, otherwise the transmission is started. t2 is not interrupted by the DCD.

__**9.7. Layer 2 States**__

The second column of the user list shows the actual L2 states. They shall be briefly explained here. For more information, please refer to the AX25-V2 protocol specification. Attention, we are using other numbers for the single states. Only the numbers 1-7 are the same as in the specification. The other states, which are only relevant for BUSY (NR) states, have been done by using bit masks, i.e. there are offsets added.

^State        ^Description ^
|1            |disconnected |
|2            |link setup |
|3            |frame reject |
|4            |disconnect request |
|5            |information transfer |
|6            |REJ frame sent |
|7            |waiting acknowledgement |

__Disconnected__

This state is the default state. No QSO exists at the moment, therefore it is not shown in the user list.

__Link Setup__

A connection is being set up, i.e. SABM-frames are being transmitted, the acknowledge (UA) has not been received yet.

__Frame Reject__

Due to a sync error a FRMR-frame was sent, the connection is restarted. This may happen due to a software error or due to two stations with the same callsign.

__Disconnect-Request__

A connection is being disconnected, i.e. DISC-frames are being sent. The acknowledge (UA) has not been received yet.

__Information Transfer__

Hopefully, the most seen state. The connection is established, info-frames are being exchanged.

__REJ Frame sent__

A REJ-frame was sent, because a received frame was not in the correct order. A retransmission is requested.

__Waiting Acknowledge__

The link is being polled, either because I-Frames have not been acknowledged or because the link has to be checked.

__Busy-States__

When the station is busy, i.e. cannot receive any more packets, 8 is added to the state number. When the opposite station is busy, 16 is added to the state. When both stations are busy, 24 is added. Thus, numbers up to 31 may occur.

__**9.8. Header Compression**__ --> Only available on Solomaster systems!

In the address field of the L2 protocol, up to eight digipeaters can be specified, which identify the path of a frame. In contrast to other node concepts (Net/ROM), FlexNet uses these fields for the routing of the frame to avoid a separate L3 header. All routing information is put into this address field. A disadvantage is, that this address field may grow very long, since every callsign allocates 7 bytes. Due to the VirtualCircuit-concept, however, this becomes redundant when a L2 connection is established. So with FlexNet V3.2 a compression of these headers was introduced. Instead of the 14 - 70 Byte, the header is now only 7bytes long, which causes a significant increase in performance. Especially short frames (RR, short I-Frames) shrink to 10 - 25% of the original length, which speeds up some interlinks to the double speed! Of course, this method can only be used if both partners of the interlink are capable of the protocol used. Address fields are only transmitted completely during link setup, during the QSO itself only the shortened addresses are used. Another shrinking of the header would be possible but could be dangerous if used on non exclusive channels. An obvious callsign needs to be transmitted to avoid mistakings. During the link setup, the own QSO number is sent behind the control field as a 14bit integer. As opposite to the address field, this number is transmitted right-justified. In the UA frame, the QSO number is transmitted also. Now every partner knows the QSO number of the other node. As soon as the connection is established, the compression kicks in. In the compressed address, the callsign and the QSO number of the receiving digipeater is transmitted.

Format of the compressed addressfield:

<code>
--------+---+---+---+---+---+---+---+--------
Flag    ! H ! L ! C ! C ! C ! C ! C ! CTRL   ........
--------+---+---+---+---+---+---+---+--------
                                       ^-- normal control field
                  ^---^---^---^---^------- compressed callsign + SSID
          ^---^--------------------------- QSO number + C-bit + final-bit
</code>

format of the callsign (example DB0ODW)

<code>
byte0000000011111111222222223333333344444444
bit 7654321076543210765432107654321076543210

    ddddddbbbbbb000000ooooooddddddwwwwwwSSID
</code>

Every character represents the ASCII code minus 0x20. In the first both bytes of the address field, the QSO number, C-bit and F-bit are encoded. The explicit setting of the Final-bit (bit 0) makes sure that the frame is not confused with the conventional AX25 address field.

<code>
    7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
    q q q q q q q q q q q q q q C F   -   final-bit (always 1)
                                ^------   command/response
                                          command = 1
                                          response = 0
    ^-^-^-^-^-^-^-^-^-^-^-^-^-^--------   QSO-number (shifted left 2 bit)
</code>

Specialities:

  * Internode communication generally runs uncompressed. This would be very difficult to implement, since the ability of doing compression is transmitted within the internode communication. Compression here is not too useful, since there are no digipeaters in the path, and if, compression could not be done. Besides, this ensures the transmission of the callsigns in regular intervals to comply the laws.
  * When for a running QSO a single conventional (uncompressed) address field is received, this QSO has to be switched to uncompressed mode (exception: link reset SABM with compress offer).
  * When an internode reset is received (O-Frame), then ALL QSO's to this node are switched to conventional addressing mode.
  * At the beginning of the internode-QSO it is announced in the O-frame, whether compressed addressing is possible. It is only used when both nodes are capable of it.
  * Both free bits in the SABM and the UA are always set to 0 to allow later extensions.
  * When receiving a number per SABM, it has to be checked if this number is already used in an other QSO. This may happen when the originating node had a reset. In this case, the older QSO has to be killed immediately.
  * When a compressed frame is received for uncompressed QSO, this frame is discarded. This may happen if there was a reset and the QSO number is now given to an other QSO.
  * Compressed SABM's or UI's are not generated but ignored: SABM's should always contain the complete path. UI's can only very seldom be treated as a QSO, so compressing the callsigns is of no use.
  * Header compression is only available on Solomaster systems. If you do not like it, you may deactivate it by using fullmaster software.

__**9.9 Clock options**__

__**9.9.1. Operating modes of the SCC**__

The ZILOG 8530 SCC contains two separate serial ports, every channel has its own clock generator. Since a HDLC channel needs two different clocks (x and 32times x), the clock generator of the second port (port B) is used to generate the single clock(x). Thus, port B is not usable for data transmission. If you had used both ports for data transmissions, the RX-Clock would have needed to be generated externally and additional parts would have needed on the card. When using RMNC2 cards with their own AFSK modem, the clock is derived from the PCLK supplied from the reset card (RMNC3 has a local oscillator). Port A of the SCC is used for data transmission. The clock generator A supplies the clock for the DPLL of the receiver(32*x), the clock generator B supplies the TX-Clock(x). On RMNC3, the A-port supplies the 32*x-Clock needed for the FSK modem. The TX-Clock is generated by the modem. Thus, "external clock" needs to be set here.

__**9.9.1.Clock Options**__

During the development of RMNC3 it proved necessary to change the clock options. Especially affected is the combination of external TX and internal RX clock. However, who uses some of the clocks on the RMNC for attached modems should have a close look at the following table. The new options and pin functions are as follows:

^Mode: ^
|--: |internal RX and TX |I: Input |
|t:  |external TX        |O: Output |
|r:  |external RX        | |
|tr: |external RX and TX |SCC-Pins: TRxCA=14, RTxCA=12, TRxCB=26 |

^Mode ^TRxCA  ^RTxCA  ^TRxCB  ^comment ^
| --  | O F32 | I TxC | O TxC |short-circuit TRxCB - RTxCA needed! |
|  t  | O F32 | I TxC | O F32 |ATTENTION NEW: Put clock to RTxCA ! |
|  r  | O TxC | I RxC | O F32 |as usual, but swapped the clocks |
| tr  | I TxC | I RxC | O F32 |no changes |

On RMNC2, almost everything stays as usual. On RMNC3, internal clock is set, when the AFSK modem is used. When using the FSK modem or the AFSK option with echo, external clock must be used. When using an external modem, either Tx and/or Rx-Clocks can be supplied from outside. Between these options you can switch by using the MODE-command. Since the external modem must supply the single Rx-Clock, the internal DPLL of the SCC is not used. The different clocks are injected via the modem-disconnect connector. Take care, between RMNC2 and RMNC3 there are different mappings ! On RMNC2 TRXcA is the input for the Tx-Clock (pin 16 of the modem connector), RTXcA is the input for Rx-Clock (pin 18). On the RMNC3, there are only TxC and RxC. Be careful about the following, too: Under normal usage (internal modem), TRXcA/TxC is an output line, when using an external modem, this line becomes an input line! If you have connected an external modem, and you switch to normal mode, probably two outputs work against each other. On the RMNC2, RTXcA is short circuit with TRXcB. Via this circuit the A DPLL gets its 32x-clock. When using an external modem, you have to cut this connection.

__**9.10. Links to Net/ROM partners**__

FlexNet V3 makes it possible to link Netrom neighbors and to forward these interlinks, provided they are working. For the following explanations, we assume that our FlexNet node DB0FLX has an interlink to the NETROM node DB0NR. The Netrom node consists of several TNC's with different SSID's. The user port usually has the SSID -0. DB0FLX is on DB0NR-4 for example. Obviously, we should add DB0NR-4 to the link table of DB0FLX as it was done in V2. However, this has disadvantages:
  * The Netrom node perhaps has other FlexNet neighbors. If they forward their DB0NR-x information, too, DB0NR appears more than once in the FlexNet D-tables. This makes the D-tables very uncomprehensive.
  * When a user wishes to connect DB0NR, he does not know which path to DB0NR the best is, since FlexNet may route the different DB0NR-x a different way. However, it is possible to solve the problem with proper entries in the link list. The idea is, that for the network it is enough to know that DB0NR exists. How the single TNC's of DB0NR are reached is only of interest for the neighbors of DB0NR. The link entry of DB0FLX has to be as follows (provided that DB0NR is on port 5)

|L 5 DB0NR-4 -   |the "-" means that the link is checked, but not forwarded to the network |
|L DB0NR-4 DB0NR |this is the trick: The link to the user port DB0NR-0 is checked and forwarded to the network as ssid-range 0-15 |

FlexNet now knows a way to DB0NR, but only DB0FLX knows that it has to go to DB0NR-4 directly, and to the other SSID's of DB0NR via DB0NR. In the D-lists only a DB0NR (0-15) appears. The user port DB0NR-0 is directly reachable. If there would exist a Convers-TNC DB0NR-8, it could be directly reached, too. The thing becomes even more Wizzardly when DB0NR has a second FlexNet neighbor. We assume DB0ZZZ is reachable via DB0NR-2. We add the following two link entries:

|L DB0NR-4 DB0NR-2 $ |indirect link. Not tested, not forwarded, but displayed in the link list |
|L DB0NR-2 DB0ZZZ    |Link to FlexNet via DB0NR. Will be tested and used by FlexNet. |

That has been the good news, and now the bad news:
  * The D-command shows a route to DB0NR-14 now, even if it does not exist. The Link-command is only capable of linking single (-0 -1 -2) or all (0-15) SSID's...
  * The Netrom linkports have to turn on L2 digipeating. When accessing DB0NR-0, this should cause no trouble, since the diode matrix works without collisions.

Furthermore, the link as set up via this trick suffers from the not available hop-to-hop-acknowledgement. This compromise is acceptable when looking at the advantages of the network: When the links are working 100%, it has no disadvantages, hop-to-hop-acknowledgement is not necessary if there are no RETRIES. If the link is bad, FlexNet uses a better route, if available. When the Netrom sysop is stupid and still wants L2 digipeat turned off on the interlinks, the link still should be set up as described. Then the NETROM node is not forwarded and the users have to
find their way themselves. As soon as the digipeating is turned on, everything will work OK again.

__**9.11. Subscription Service**__

For the FlexNet software, a subscription service is available to sysops. All sysops get always the new versions without looking out for it everywhere. This service is provided free of charge, but cannot be guaranteed. It depends on whether there come in enough donations for funding this service, also there is not always enough time to do it. If
you are interested in subscribing, ask the author.

__**9.12. Correspondence**__

The FlexNet-Group of Darmstadt, and therefore the authors and the maintainers of the software are reachable by mail :

FlexNet-Gruppe Darmstadt\\ 
Gunter Jost, DK7WJ\\ 
Lichtenbergstr. 77\\ 
D-64289 Darmstadt\\ 
Germany\\ 

Or via AX25 Email:   DK7WJ@DB0GV.HES.DEU

The manual was translated by Mario Lorenz, DG0JAB @ DB0JES.#SAA.DEU.EU, Internet-Email: ml@donald.bsz.szb.sn.schule.de. As I am not a native English, this translation surely contains mistakes. Please send bug reports or suggestions to the my Email-address. Thanks.

__**10. Index**__

===== Deutsch DG9DBQ/DL1BKU =====
Allgemeines:

Diese Anleitung wurde unter Verwendung der Sysop-Dokumentation zu RMNC/FlexNet, Software Version 3.2, erstellt. Sie bezieht sich auf die RMNC/Flexnet-Version 3.3h. Der Text stammt zum grossen Teil von dg9dbq (Verantwortlicher von db0fbb) und wurde stark von dl1bku modifiziert und um alle mir bekannten User-Befehle erweitert.

RMNC (Rhein-Main-Network-Controller) ist ein Digipeatersystem auf der Basis eines 6809-Prozessors. Die FlexNet-Software ist ein Produkt von Gunter Jost, (D)K7WJ.

Diese Anleitung will etwas Klarheit in die Parameter eines Flexnet-Systems bringen. Ich habe mich bemueht, auch exotische Eintraege zu beleuchten.

Die Ueberarbeitung des Textes beansprucht eine Menge Zeit und geschah aus dem Gedaechtnis. Auch die Beispiele wurden nicht nachvollzogen und ich habe die Flexnet-Anleitung verschusselt. Daher sind Auslassungen und Fehler wahrscheinlich. Ueber ergaenzende Hinweise freue ich mich und auch Rueckmeldungen via PR sind willkommen, falls jemand durch den Text unverhoffte Einblicke bekommen hat.

Aufgabe von RMNC/Flexnet ist es, die schnellste Verbindung zwischen zwei Stationen a und b herzustellen und eine gesicherte Datenuebertragung zu gewaehrleisten. Das Ganze moeglichst einfach und ausfallsicher. MEHR NICHT!

Joerg (dl1bku)


__**(I) Inhaltsverzeichnis:**__
<code>
Allgemeines
Inhaltsverzeichnis   . . . . . . . . . . . . . . . . . . .  (I)
Hardware   . . . . . . . . . . . . . . . . . . . . . . . .  (II)
Eingabe der RMNC-Befehle     . . . . . . . . . . . . . . .  (III)
Kurzuebersicht der Befehle     . . . . . . . . . . . . . .  (IV)
Erklaerung der Befehle
  Aktuell    . . . . . . . . . . . . . . . . . . . . . . .  (V)
  Baken    . . . . . . . . . . . . . . . . . . . . . . . .  (VI)
  Help     . . . . . . . . . . . . . . . . . . . . . . . .  (VII)
  Info     . . . . . . . . . . . . . . . . . . . . . . . .  (VIII)
  Local    . . . . . . . . . . . . . . . . . . . . . . . .  (IX)
  Mycall     . . . . . . . . . . . . . . . . . . . . . . .  (X)
  IO     . . . . . . . . . . . . . . . . . . . . . . . . .  (XI)
  Find     . . . . . . . . . . . . . . . . . . . . . . . .  (XII)
  Setsearch    . . . . . . . . . . . . . . . . . . . . . .  (XIII)
  Parameter    . . . . . . . . . . . . . . . . . . . . . .  (XIV)
  Links    . . . . . . . . . . . . . . . . . . . . . . . .  (XV)
  Destinations     . . . . . . . . . . . . . . . . . . . .  (XVI)
  Users    . . . . . . . . . . . . . . . . . . . . . . . .  (XVII)
  Connect    . . . . . . . . . . . . . . . . . . . . . . .  (XVIII)
  Convers    . . . . . . . . . . . . . . . . . . . . . . .  (XIX)
  Talk     . . . . . . . . . . . . . . . . . . . . . . . .  (XX)
  Quit     . . . . . . . . . . . . . . . . . . . . . . . .  (XXI)
  Mail   . . . . . . . . . . . . . . . . . . . . . . . . .  (XXII)
  Mheard   . . . . . . . . . . . . . . . . . . . . . . . .  (XXIII)
  PW/SYS   . . . . . . . . . . . . . . . . . . . . . . . .  (XXIV)
Fehlermeldungen    . . . . . . . . . . . . . . . . . . . .  (XXV)
</code>

__**(II) Einfuehrung in die Rechnerhardware:**__

Die verwendeten Rechner sind als Eurokarten ausgefhrt und besitzen folgende
Merkmale:

  * Eine 6809-CPU wahlweise NMOS/CMOS mit 4,8,12 oder 16MHz Takt (siehe Befehl Parameter). Die 16MHz werden mit uebertakteten 12MHz-Bausteinen erreicht. Der Takt wird intern durch 4 geteilt, die Peripherie muss aber mit dem schnelleren Takt zurechtkommen. Die Leistungsfaehigkeit gegenueber dem Z80 ruehrt aus einer Fuelle von Registern und Adressierungsarten sowie der Faehigkeit her, viele Befehle in wenigen Taktzyklen zu bearbeiten. Die Beschraenkung auf eine 8Bit-CPU stellt kaum einen Nachteil dar, weil die Verarbeitung der Daten ohnehin byteorientiert ist. 
  
  * Eine SCC (Serial Communications Controller) 8530 mit 6,10,16 oder 20MHz Takt. Es wird nur ein serieller Kanal dieses HDLC-faehigen Bausteins verwendet. Bei 76800Bit/s ist beim RMNC durch die Interruptlast der SCC (jedes Byte ein IRQ) das Ende der Fahnenstange erreicht. Fuer Rechnerschnittstellen geht aber noch 115kBit/s.

  * Das parallele Interface zu den anderen Karten wird mittels einer VIA 6522 realisiert.

  * Auf jeder Karte befinden sich 64kByte RAM und ein Eprom.

Eine RMNC-Karte dient als Master (Karte 0). Beim Start des Systems werden aus dem 64kByte-Eprom dieser Karte die anderen Rechner entweder mit einer Software fuer einen Datenkanal (KISS mit/ohne CRC, HDLC) oder fuer Servicezwecke mit einer Terminalsoftware geladen (Bei DB0NON Karte 8). Der Master regelt ausserdem das Routing, ermittelt die Laufzeiten und bedient die Infobox. Bis Flex3.3g konnte der Master zusaetzlich als Funkport eingesetzt werden.

Jeder andere Rechner bedient einen seriellen Kommunikationskanal. Es gibt maximal 15 Karten (dann ist das 19" Rag auch voll). Jeder sogenannte Port im RMNC stellt also einen Einplatinenrechner dar. Ist ein QSO erst einmal her-
gestellt, so fliessen die Daten dieser Verbindung nicht mehr ueber den Master, sondern die sogenannten Slaves reichen die Frames direkt ueber den Bus weiter.

Kommerziell werden 3 verschiedene Platinen fuer den RMNC angeboten. Die aelteren RMNC2-Karten haben zusaetzlich noch ein AFSK-Modem an Bord und einen eigenwillig belegten Stecker fuer externe Modems vorgesehen. Mittlerweile sind etliche Modifikationen notwendig, um diese Karten einzusetzen. Die von HB9ATU gerouteten Karten enthalten neben der Einarbeitung vieler Modifikationen ein FSK-Modem nach DF9IC in der urspruenglichen Variante, sind aber sonst mit den RMNC2-Karten identisch. Die RMNC3-Karten koennen mit verschiedenen Bestueckungen versehen werden und erhalten so zusaetzlich eine RS232-Schnittstelle, ein AFSK-Modem, ein recht gutes FSK-Modem oder koennen einfach als Master eingesetzt werden. Weitere Features sind eine Echoregenerierung sowie staerkere Bustreiber mit dem Versuch einer Anpassung. Ein weiterer Gimmik ist die veraenderte Anwendung des Bitratengenerators der SCC und der Einsatz von skalierbaren (SC)-Filtern im FSK-Modem, wodurch die Datenrate auf den Links in Grenzen einstellbar ist. Es koennen verschiedene Modems ueber den High-Speed-Connector angeschlossen werden.

Bei db0non kommen Karten von dh6ial/dl1bku zum Einsatz, die neben dem Rechner wahlweise eine serielle Schnittstelle und eine Resetschaltung oder nur den High-Speed-Connector zum Anschluss seperater Modems aufweisen.

__**(III) Eingabe der RMNC-Befehle:**__

Verbindet man sich mit einem Flexnet-Knoten, so gelangt man in die Infobox. Die Eingabe der Befehle erfolgt immer in der Form, dass in Ihrem PR-Programm am Zeilenanfang der jeweilige Befehl eingegeben wird (meist reicht auch
der bzw. die ersten Buchstaben des Befehls, s.u.). Bei einigen Befehlen kann (bzw. muss) dahinter noch eine Option angegeben werden. Die Optionen werden immer durch Leertasten von den Befehlen getrennt und mit <CR> abgeschlossen.
<CR> steht fuer RETURN, ENTER, oder "Eingabetaste", wie immer diese Taste an Ihrem Computer bezeichnet ist. Gross- und Kleinschreibung ist dabei nicht von Bedeutung. Sind mehrere alternative Eingaben moeglich, so sind diese innerhalb der eckigen Klammern durch eine Pipe "|" getrennt.

Beispiele:

|(A)ktuell <CR>        bedeutet:|"A" tippen, dann RETURN. |
|(P)arms [port] <CR>   bedeutet:|"P" tippen, dann KANN eine Portnummer eingegeben werden (muss aber nicht), ENTER. |
|(F)ind call <CR>      bedeutet:|"F" tippen, dann muss ein Rufzeichen eingegeben werden, Eingabetaste. |
|(U)sers [call<nowiki>|</nowiki>=]      bedeutet:|"u" tippen und entweder dahinter ein Rufzeichen ODER "=" |

Steht eine Option wie z.B. "port" in Klammern, so kann sie eingegeben werden. Ist die Option aber ohne Klammern angegeben, so muss sie eingegeben werden. Um einen Befehl einzugeben, reicht meist der erste Buchstabe des Befehls aus. Die Angabe "(F)ind" bedeutet, dass fuer diesen Befehl nur das "F" eingegeben werden muss (es wird Tipparbeit gespart, wenn man es nicht ausschreibt). Die Angabe "(LO)cal" bedeutet dementsprechend, das mindestens "LO" fuer diesen Befehl eingegeben werden muss. Die Zeichen "(", ")", "[", "]" und " werden natuerlich nicht eingegeben. Sie dienen hier nur zur besseren Erklaerung. In den einzelnen Beispielen kommt der Text in Klammern nicht vom Digi, sondern gehoert zur Erklaerung des Befehls.

__**(IV) Kurzuebersicht der Benutzerbefehle:**__

|(A)ktuell                        |Abrufen der aktuellen Informationen|
|(B)eacons                        |Abrufen der eingestellten Baken|
|(H)elp                           |Abrufen des Hilfetextes|
|(I)nfo                           |Abrufen der allgemeinen Informationen|
|(LO)cal                          |Abrufen der lokalen Informationen|
|(C)onvers                        |Den Convers-Mode starten (QSO-Runden)|
|(C)onnect call [v] [digi] [port] |Weiterconnecten|
|(D)estinations [call]            |Ausgabe der bekannten Ziele, Weg zum Ziel|
|(F)ind call                      |Nach einem Rufzeichen suchen lassen|
|(IO)                             |Ausgabe der Ein- und Ausgabeports|
|(L)inks [*]                      |Ausgabe der Linkinformationen|
|(My)call                         |Ausgabe des Digi Rufzeichen mit SSID Bereich|
|(M)ail [?]                       |Verbinden mit der Mailbox|
|(P)arms [port]                   |Ausgabe der Parameter und der Statistik|
|(S)etsearch                      |Ausgabe der Suchpfade fuer den (F)ind Befehl|
|(U)sers [port] [call] [=] [*]    |Ausgabe der momentanen Benutzer auf dem Digi|
|(T)alk call [text]               |Einen Text an andere Benutzer ausgeben|
|(Q)uit                           |Verbindung beenden|
|(Mh)eard                         |Anzeigen der zuletzt gehoerten Stationen|
|(PW)/(SY)sop                     |Authentisierung als Sysop|

**Erklaerung der Befehle:**

__**(V) Aktuell:**__

Eingabe: (A)ktuell <CR>

Der Befehl (A)ktuell gibt einen vom Sysop eingegebenen Text aus, der aktuelle Informationen ueber den Digi enthaelt. Bei DB0NON wird bereits in der Connectzeile das Datum der letzten Aenderung vermerkt und ist ein FIFO-Speicher, d.h.
es wird nur etwas geloescht, wenn der Textspeicher mal wieder ueberquillt. Sollte es nichts "Aktuelles" geben, kommt nach der Eingabe nur das Prompt "=>" zurueck.


__**(VI) Baken:**__

Eingabe: (B)eacons <CR>

Dieser Befehl gibt die eingestellten Baken aus. Aus diesen Daten ist ersichtlich, welche Bake auf welchem Port mit welcher Haeufigkeit gesendet wird.

Beispiel:

<code>
=>B <CR>

#10 3 FLXNET:Digi Nordhorn (JO32NK) - Link Rheine
 !  !   !     !
 !  !   !     +-> Bakentext
 !  !   +-------> Zielrufzeichen z.B. "BAKE", "TEST", "FLXNET",....
 !  +-----------> Kartenadresse, auf der die Bake ausgesendet wird
 !                z.B. hier Port 3 (eine Interlinkkarte)
 +--------------> Zeit zwischen den Bakenaussendungen in Minuten
</code>

__**(VII) Hilfe:**__

Eingabe: (H)elp <CR>

Der Befehl (H)elp gibt einen Hilfetext aus. Dieser Text soll dem Benutzer eine kurze Hilfestellung fuer die Benutzung des Digipeaters geben. Er entspricht etwa der "Kurzuebersicht der Befehle" in dieser Anleitung. Sollte
kein Hilfetext vorhanden sein, kommt nach der Eingabe von (H)elp nur das Prompt "=>" zurueck.

__**(VIII) Info:**__

Eingabe: (I)nfo <CR>

Der Befehl (I)nfo gibt allgemeine Informationen ueber den Digi aus. Dieser Text enthaelt Infos ueber den Knoten wie z.B. Standort, Betreiber, Verantw., Geraete, Antennen usw. Sollte kein Infotext vorhanden sein, kommt nach der Eingabe von (I)nfo nur das Prompt "=>" zurueck.

__**(IX) Lokale Info:**__

Eingabe: (LO)cal <CR>

Der Befehl (LO)cal gibt lokale Informationen ueber den Digi aus. Dieser Text wird auch nach dem Connecttext bei einem Verbindungsaufbau auf einem Benutzerport ausgegeben (siehe Parameter). Erfolg der Connect ueber einen
anderen Netzknoten, wird dieser Text nicht gesendet. Sollte kein lokaler Text vorhanden sein, kommt nach der Eingabe von (LO)cal nur das Prompt "=>" zurueck.

__**(X) Mycall:**__

Eingabe: (My)call <CR>

Nach Eingabe dieses Befehls wird das Rufzeichens und der SSID-Bereich ausgegeben, unter dem das System angesprochen werden kann. Der SSID (secondary station identifier) ist die Zahl hinter dem Rufzeichen. Kein SSID ist gleich-
bedeutend mit SSID 0. Als Bonbon bietet Flexnet die Moeglichkeit, unter dem gleichen Rufzeichen und innerhalb des SSID-Bereiches des Digipeater z.B. eine Mailbox als Link einzutragen. Somit taucht die Mailbox dann nicht im Routing
anderer Digipeater auf. Bei Ausfall des Links wird man beim Verbindungsaufbau automatisch mit der Infobox des RMNC verbunden.

Beispiel:

<code>
=>MY <CR>

mycall: DB0NON SSIDs: 0-10          (Also DB0NON, DB0NON-1, ..., DB0NON-10)
</code>

__**(XI) In/Out:**__

Eingabe: IO <CR>

Der IO Befehl gibt die Zustaende der 16 moeglichen Ein- bzw. Ausgabeports des Systems aus, die zu Steuerzwecken verwendet werden koennen. Bei DB0NON wird dieses Feature genutzt, um die eingebaute Temperatursicherung manuell aus-
loesen zu koennen und so den Digipeater komplett abzuschalten. Dieser Zustand kann natuerlich nicht abgelesen werden.

Beispiel:

<code>
=>IO <CR>

I: 0000 0000 0000 0000        O: 1111 0000 0000 0000
</code>

D.h. alle Eingaenge sind "0". Die Ausgaenge 1-4 sind "1", alle anderen "0".

__**(XII) Find:**__

Eingabe: (F)ind call <CR>

Der (F)ind Befehl ermoeglicht es, eine bestimmte Station zu suchen, die auf dem gleichen oder einem anderen Digi QRV ist. D.h. die gesuchte Station muss nicht mit dem Knoten verbunden sein. Es reicht, wenn der OM seine PR-Station
auf der Eingabe eines in (S)etsearch angegebenen Digis eingeschaltet hat. Wird ein solcher (F)ind Befehl mit einem Rufzeichen eingegeben, wird auf den Nachbar-Digipeatern nach dem eingegebenen Rufzeichen gesucht und ein UI-Frame
an diese Station gesendet. Ist die gesuchte Station bereits ueber den Digi verbunden, auf dem man den Befehl abgesetzt hat, unterbleibt der Suchruf und eine Meldung wird ausgegeben. Ist die gesuchte Station mit einem anderen Digi connected, der in (S)etsearch aufgefuehrt ist, wird auf diesem Digipeater kein Suchruf abgestrahlt und es
erfolgt eine Rueckmeldung. Beantwortet eine gesuchte Station das empfangene UI-Frame mit einem DM-, wird
eine Antwort an den Absender des Befehls generiert, falls das DM-Paket nicht verlorenging. Sollte auf den (F)ind Befehl keine Antwort kommen (die Antwort kann ein paar Sekunden dauern), kann das Suchpaket verloren gegangen sein. Eine erneute Eingabe fhrt vielleicht zum Erfolg, wenn die gesuchte Station auf einem in (S)etsearch angegebenen Digipeater QRV ist.

Der (F)ind Befehl ist aber nicht gedacht, um nach anderen Digipeatern oder Mailboxen suchen zu lassen. Dafuer ist der (D)estinations Befehl mit der Angabe des gesuchten Digis oder Mailbox wesentlich sinnvoller.

Beispiel:

<code>
F DD1BR <CR>
=>                                 (Bestaetigung der Eingabe)
                                   (Wenn nach einigen Sekunden nichts kommt,
                                    wurde die Station nicht gefunden)

F DD1BR                            (Zweiter Versuch, nach DD1BR zu suchen)
=>                                 (Bestaetigung der Eingabe)
=>*** DD1BR found via DB0NON-1     (DD1BR wurde auf DB0NON, Port mit der SSID 1
                                    gefunden (seit 12.02.98 geht das Beispiel
                                    nicht mehr...)
</code>

Im Monitorfenster eines PR-Programms sieht das je nach Software etwa so aus:

<code>
fm [DAMA] PI1DRS to DD1BR via DL1BKU DB0NON-1* ctl UI+
FlexNet-Search

fm DD1BR to PI1DRS via DB0NON-1 DL1BKU ctl DM-
</code>

Der (F)ind-Befehl wurde von dl1bku bei pi1drs eingegeben.


__**(XIII) Setsearch:**__

Eingabe: (S)etsearch <CR>

Der (S)etsearch Befehl zeigt die Digipeater an, auf denen beim (F)ind Befehl nach dem entsprechenden Rufzeichen gesucht wird.

Beispiel:

<code>
S <CR>

-
DB0NON-0
DB0NON-1
DB0RWN DB0NON
PI1DRS
1 - db0iy-0
DB0EA-9 -
p0 DB0DAM -
</code>

Es wuerde also auf den Digipeatern db0non, db0rwn, pi1drs, db0ea, db0dam & db0iy gesucht und ggf. ein Suchruf ueber die Karten mit der SSID 0 bei db0rwn, db0non und db0dam (hier als Baycom-Digi-Beispiel) abgestrahlt. Zusaetzlich wird auf der Karte mit der SSID 1 bei db0non und auf der Karte mit der SSID 9 bei DB0EA gesucht. Das "-" ist eine Abkuerzung fuer das eigene Rufzeichen und bewirkt somit, dass automatisch auf der Karte mit der SSID 0 bei db0non zwei Suchrufe abgestrahlt werden (Eintraege "-" und "db0non-0"). Die anderen "-" sind guter Stil und optional wie auch der via-Eintrag "db0rwn db0non". Dadurch wird verhindert, dass bei Nichterreichbarkeit des Nachbarknotens die Suchbake auf dem Benutzereinstieg ausgestrahlt wird. Seit Flexnet 3.3h sieht man auch Eintraege wie "1 - db0iy-0". Dies bewirkt, dass der Suchruf mit Sicherheit auf Port 1 von db0iy mit der SSID 0 abgestrahlt wird und nicht ueber mheard-Liste geroutet wird.

Einige Spezialisten tragen auch Suchrouten ueber Autorouter ein. So kommt dann z.B. ein "<nowiki>***</nowiki> DL1BKU found via DB0KLN" heraus, weil db0kln das ui-Paket an die letzte bekannte Route zu dl1bku (z.B. via db0aac) umadressiert.

__**(XIV) Parameter und Statistik:**__

Eingabe: (P)arms [*] [port] <CR>

Der (P)arms-Befehl gibt die Liste der derzeit eingestellten Parameter, sowie eine kleine Kanalstatistik aus. Zusaetzlich werden die auf diesem Kanal eingetragenen Links angezeigt, wie sie auch mit dem (L)ink Befehl abgerufen
werden koennen. Der Kanal, auch Port genannt, entspricht einer mittels Drahtbruecken eingestellten Adresse auf den einzelnen RMNC-Karten. Da fuer jede Linkstrecke und fuer jeden Einstieg eine eigene RMNC-Karte (Platine) benoetigt wird, ist diese Adresse (Portnummer) die Unterscheidung der einzelnen Karten. Um die Daten von nur einem Port zu erhalten, muss hinter dem (P)arms Befehl als Option die entsprechende Portnummer eingegeben werden. Um zusaetzlich noch eine Statuszeile ueber Laufzeit der Software, Anzahl der Resets, der Softwareversion und die Anzahl der Digipeater zu erhalten, muss zusaetzlich noch ein "*" eingegeben werden.

Beispiel:

<code>
p * <CR>

(r:7 d:590 v:0 t:109d, 5h) infobox timeout: 60 minutes
po id td qso usr tifr rifr tkby rkby qty   mode       links  ssids    time
 1  0 25   1   1   68   16   12    1  81   1200smu+   USER70                  
 2  1  0   0   0    0    0    0    0 100    ---
 3 -- 12  14   1  120  195   14   29  98   9600trz+   DB0RWN  0-10     7/7    
 4 --  0  18   1  264  357   25   49  97  19200ptrz+  PI1DRS  0-15     3/3    
 5 -- 12   9   2  116   62   16    1  98   9600trz+   DB0SM   0-0      7/9    
 6                                                    PI1PWD                  
 8 --  0   1   1    0    0    0    0 100   9600yd+    TERM
         
=>

P 5 <CR>                 (Nur die Eintraege von Karte "5" ausgeben lassen)

=>infobox timeout: 60 minutes
po id td qso usr tifr rifr tkby rkby qty   mode      links
 5 --  6   7   1  369  137   92   34  99   9600t+    DB0NNP  0-10     5/6
</code>

Stichwortartige Erklaerung der einzelnen Anzeigen:

1.Zeile:
|r:7       |Der Digipeater hat seit Einschalten der Stromversorgung 7 Resets hinter sich gebracht.|
|d:590     |Es sind zur Zeit 590 verschiedene Ziele bekannt (nur D-Liste)|
|v:0       |Es handelt sich um Version 0 (z.B. RMNC/Flexnet3.3h, Version 0)|
|t:109d, 5h|Seit dem letzten Reset ist soundsoviel Zeit vergangen.|

Die Zeile "infobox timeout: 60 minutes" bedeutet, dass der Digipeater nach 60 Minuten die Verbindung trennt, falls vom Benutzer in dieser Zeit nichts zum Digi gesendet wurde. Dies geschieht aber nur, wenn man ausschliesslich mit der Infobox connected ist. Wurde bereits weiterconnected, z.B. zu einer Box oder einer anderen Station, wird kein Disconnect nach dieser Zeit ausgeloest.

Die einzelnen Spalten bedeuten :

|po     |Portnummer (Kartenadresse der einzelnen Platinen)|
|id     |Port-SSID. Ist eine SSID eingetrage, so darf jede gehoerte Station auf dieser Karte ueber den Digi Verbindungen herstellen. Ansonsten koennen nur eingetragene Linkpartner connecten.|
|td     |Eingestelltes TXDelay in 10ms-Einheiten|
|qso    |Anzahl der QSOs, die derzeit auf diesem Kanal laufen (Es handelt sich meistens um 2-way-QSOs. Hin- und Rueckweg werden also doppelt aufgefuehrt).|
|usr    |Gehoerte Stationen auf diesem Kanal (seit 3 Minuten)|
|tifr   |Gesendete Daten-Pakete (I-Frames) innerhalb der letzten 10 Minuten|
|rifr   |Empfangene Daten-Pakete (I-Frames) innerhalb der letzten 10 Minuten|
|tkby   |Gesendete Kilobytes innerhalb der letzten 10 Minuten|
|rkby   |Empfangene Kilobytes innerhalb der letzten 10 Minuten fehlen diese Angaben, so ist die Karte gar nicht eingesteckt, sondern es existiert nur ein Linkeintrag (Hier bei pi1pwd)|
|qty    |Qualitaet des Kanals in Prozent (wird alle 10 Minuten aktualisiert. Eine QTY von 50% bedeutet uebrigens fuer einen semiduplex-Link quasi das Aus - Duplexstrecken sind wohl noch brauchbar - man muss allerdings Vergleiche mit den Laufzeiten anstellen). Eine Laufzeit von 100% bei sonst keiner erkennbaren Datenuebertragung deutet darauf hin, dass dieser Link gerade zwar nicht laeuft, aber irgendwann mal funktioniert hat. Steht alles auf 0, so ist zwar die Karte installiert, der Link tat aber nie seit dem Letzten Power-On.|
|mode   |Eingestellte Baudrate fuer diesen Port (9600r+ => 9600 Bit/s)|
|       |Weitere Parameter:|
|       |d: Vollduplex|
|       |p: Vollduplex, aber der Sender bleibt staendig getastet. Dadurch ist keine Flagsendung mehr erforderlich und das TXDelay 0 ist moeglich.|
|       |t: Externer TX-Takt (sonst intern durch SCC erzeugt)|
|       |r: Externer RX-Takt (ACHTUNG! Wenn auf externen Takt eingestellt ist, wirkt sich die Einstellung der Datenrate auf der Karte nur auf die Zeitmessungen der Software aus / Die wirkliche Rate ist ja extern vorgegeben.)|
|       |z: NRZ/NRZI-Wandlung eingeschaltet ja nach Modemeingang.|
|       |m: Aktivierung von DAMA (DAMA ist ein Verfahren zur Verhinderung von Kollisionen auf dem Einstieg. Der Benutzer wird vom Digipeater aufgefordert zu senden, soll also nicht von sich aus senden (DAMA-Slave). Dieses Verfahren kann auch zur Koordinierung von zwei Linkpartnern auf einer QRG eingesetzt werden. Dabei werden aber nur die Internode-QSOs verwaltet. Wird versucht, ueber einen ungenutzten Link zu connecten, so wird dieses QSO selten bedient.)|
|       |u: Kennung fuer Benutzerzugang:|
|       |* Kanal geht nie in den DAMA-Slave-Mode (DAMA-Slave bedeutet, das der Benutzer auf einem DAMA Einstieg automatisch in einen Modus geht, bei dem er nicht mehr von sich aus senden soll (Es waere z.B. nicht wuenschenswert, wenn die Sendetaetigkeit von DB0NON bei Ueberreichweiten durch DB0HE koordiniert werden muesste)). |
|       |* Permanente Messung des TXDelays. Abwurf bei Werten, die mehr als 100ms groesser sind als notwendig (Das trifft vor allem die Handfunkenbesitzer, da die PTT-Tastung meist mikroprozessorgesteuert ablaeuft und daher die Auftastzeit stark schwankt - Der Eintrag "u" ist bei DB0NON leider nicht zu vermeiden (s.o.). |
|       |* Abwurf bei haeufigen Verstoessen gegen das DAMA Protokoll (Das ist dann der Fall, wenn ein Benutzer nicht in den DAMA-Slave Modus geht und ohne Aufforderung zum Digi sendet.) |
|       |c: Es wird eine Pruefsumme gebildet und ausgewertet (CRC-Check) |
|       |s: synchronisierte Kanaele zur Realisierung von Dual-Baud-Einstiegen (Alle Karten, die ein "s" eingetragen haben, werden gegeneinander verriegelt.) |
|       |y: Automatische Sysop Privilegisierung. Alle Stationen, die auf dieser Karte einsteigen, sind automatisch Sysop.|
|     |<nowiki>---</nowiki>: Die Karte ist zwar eingesteckt, aber deaktiviert. |
|     |+: Karte arbeitet mit  8 MHz Prozessor-Takt |
|     |!: Karte arbeitet mit 12 MHz Prozessor-Takt |
|     |#: Karte arbeitet mit 16 MHz Prozessor-Takt |
|     |Veraltet: Vor Flex3.3a "*" - Karte hat 64kByte RAM, danach obligatorisch |
|     |Veraltet: Vor Flex3.2 "++" - Karte laeuft mit 12 MHz |
|links  |Siehe (L)inks-Befehl|


__**(XV) Links:**__

Eingabe: (L)inks [*] <CR>

Der (L)inks Befehl gibt die eingetragenen Linkstrecken aus. Ausserdem ist die Art der Behandlung des Partners ersichtlich sowie die Laufzeit(en). Bei Eingabe des "*" werden zusaetzlich die 16 zuletzt gemessenen Laufzeiten ausgegeben, ueber die die gesendete Laufzeit gemittelt wurde sowie die von (P)arms bekannte Statuszeile.


Beispiel:

<code>
=>l * <CR>
(r:7 d:616 v:0 t:109d, 5h) 
USER70                           P 1 
DB0RWN  0-10    12/8     96d,22h P 3 
                 8 11 5 6 8 22 15 18 5 34 6 17 14 5 5 6
PI1DRS  0-15     3/2     15d,20h P 4 
                 3 2 7 2 2 2 9 2 7 2 2 2 2 2 2 2
DB0SM   0-0      8/7      5d, 1h P 5 
                 5 5 6 9 8 5 6 5 6 6 5 6 28 11 6 5
PI1PWD                           P 6 
TERM                             P 8 
</code>

In der ersten Spalte steht das Rufzeichen des Linkpartners. Der Eintrag "USER70" ist tatsaechlich ein Linkeintrag und soll hier nur den Userport als solchen kennzeichnen. Dahinter folgt der SSID-Bereich, unter dem der Partner erreichbar ist, danach die gemittelten Laufzeiten in Hin- bzw. in Rueckrichtug (z.B. NON->RWN/RWN->NON) sowie die Dauer der Verfuegbarkeit der Strecke von diesem Digi aus gesehen und die Portnummer. In der naechsten Zeile stehen die einzelnen ermittelten Laufzeiten. Eine Laufzeitmessung von DB0NON in Richtung DB0RWN sieht so aus, dass ein 256 Zeichen umfassendes I-Paket wie jedes Benutzerpaket auch zu DB0RWN geschickt wird. Die Laufzeit ist nun die Zeit bis zur Bestaetigung mittels eines Infopaketes durch DB0RWN, welches seinerseits die ueber 16 derartige Messungen gemittelte Laufzeit in Gegenrichtung enthaelt. Faellt die Linkstrecke einseitig aus, so kann es vorkommen, dass nur eine Laufzeit verfuegbar ist (wenn die andere Seite es nicht schafft, ein komplettes Laufzeit-Paket zu uebertragen). Faellt eine Strecke aus und erscheint wieder, so wird die Laufzeit mit 600 vorinitialisiert.


Beispiel:

<code>
=> l <CR>

USER70                  P 1 
DB0RWN  0-10    12/9    P 3
PI1DRS  0-15     2/2    P 4 
DB0SM   0-0      8/7    P 5
PI1PWD           ---    P 6 
TERM                    P 8 
DB0DOZ  7-15    (---)   P10 -
DB0NON  8-8      2      P11 @
DB0XYZ  0-10   (20/30)  P12 >
</code>

In der ersten Spalte stehen die Digipeater bzw. Mailboxen, die diesem Digi als Linkpartner bekannt sind. In der zweiten Spalte wird der SSID-Bereich des Linkpartners angegeben. In der dritten Spalte stehen die aktuell gemessenen Laufzeiten zum Linkpartner in 1/10s Schritten.

|"   "   |Keine Zahl bedeutet, dass kein Test der Laufzeit vorgenommen wird. |
|---     |Drei Bindestriche bedeuten, dass der Link nicht zur Verfuegung steht. |
|(---)   |Drei Bindestriche in Klammern bedeuten, dass der Link nicht zur Verfuegung steht, jedoch ein anderer Weg zu dieser Station bekannt ist. |
|3       |Eine Zahl bedeutet, dass der Partner das FlexNet-Protokoll nicht beherrscht (z.B. eine Mailbox), (3 = 0,3 sec.). |
|(95)    |Steht dieser Wert in Klammern, so kennt der Digipeater z.Zt. einen besseren Weg zum Ziel, d.h. der direkte Weg wird nicht benutzt. |
|4/5     |Stehen zwei Zahlen, getrennt durch einen Schraegstrich, handelt es sich um einen FlexNet-Partner. Die erste Zahl ist die Laufzeit, die vom Digi selbst gemessen wurde, die zweite Zeit wurde vom Linkpartner gemessen und dem Digi, auf dem man sich befindet, mitgeteilt. |
|(34/28) |Stehen diese Werte in Klammern, so kennt der Digipeater z.Zt. einen besseren Weg zum Ziel, d.h. der direkte Weg wird nicht benutzt. |

In der vierten Spalte steht die Portnummer (Kartenadresse) der Linkstrecke. In der fuenften Spalte stehen besondere Optionen fuer die Linkstrecken :

|"@"  |Zangseinstufung des Partner in die Kategorie "dumm". Die einzige Laufzeit wird ermittelt, indem nach dem Aufbau einer Verbindung diese moeglichst schnell wieder beendet wird. |
|"-"  |Der Partner wird dem PR-Netz nicht bekanntgegeben, von ihm gemeldete Ziele aber schon. |
|">"  |Dem Partner werden zwar Flexnet-Ziele gemeldet, aber die von ihm ermittelten Ziele und der Partner selbst werden nicht in das Netz weitergegeben. |
|"!"  |Der Partner wird weitergemeldet, aber seine Ziele nicht. |
|"$"  |Harter Link. Der Partner wird ohne wenn und aber auf dieser Karte geroutet. Es wird kein Internode-QSO aufgebaut. |

__**(XVI) Destinations:**__

Eingabe:  (D)estinations [call] [*|>] <CR>

Der (D)estinations Befehl zeigt die dem Digipeater bekannten Ziele mit ihrem SSID-Bereich und der gemittelten Laufzeit. Nach dem verwendeten "Sink-Tree-Routing-Verfahren" ist die Gesamtuebersicht aller Verbindungen im Netz selbst gespeichert und aendert sich staendig, so dass auch Nachbardigipeater durchaus unterschiedlicher Ansicht ueber Pfade sein koennen. Alle Ziele koennen durch Verwendung des (C)onnect-Befehls erreicht werden.

Beispiel:

<code>
=>D <CR>

DB0AAA  0-15 1733   DB0AAB  0-9  1808   DB0AAC  0-10  861   DB0AAI  0-7   703
DB0AMU  0-9   115   DB0ANP  0-15  512   DB0APO  0-14  768   DB0ASF  0-15  456
F6KVE   0-4  1043   HB9AK   0-15 1227   HB9AU   0-15 2356   HB9CF   0-5  1514
HB9CGB  0-5  1274   HB9CGB  8-8  1227   HB9EAS  0-6   861   HB9EAS  7-7   892
OE7XAR  0-15 2371   OE7XKJ  0-15 2608   OE7XKR  0-7  1318   OE7XPR  0-7  2978
PI8JOP  0-0   463   PI8NYM  0-7    75   PI8VRZ  0-15  282   SR6DOP  0-15 2976
  !      !     !
  !      !     +-> Laufzeit in 1/10 sec.  (463 = 46,3 sec.)
  !      +-------> SSID Bereich
  +--------------> Rufzeichen des Ziel-Digipeaters / Mailbox / ...
</code>

Wird zusaetzlich zum (D)estination-Befehl ein Zeichenfolge angegeben, so werden nur die Ziele ausgegeben, in deren Call die Zeichenfolge enthalten ist.

Beispiel:

<code>
=>D HB9 <CR>

HB9AK   0-15 1227   HB9AU   0-15 2356   HB9CF   0-5  1514   HB9CGB  0-5  1274
HB9CGB  8-8  1227   HB9EAS  0-6   861   HB9EAS  7-7   892
</code>

Ist die Zeichenfolge ein gueltiges Zielrufzeichen, so wird zusaetzlich zur normalen Ausgabe ein Paket zu diesem Ziel geschickt, um den Pfad zu erforschen. Jeder vermittelnde Digipeater fuegt sich in diesen Pfad ein und nach einigen Sekunden wird die so ermittelte Route ausgegeben. Dabei sind Flexnet-Digipeater in Grossschrift vermerkt, normale L2-Digipeater in Kleinschrift. Treten "????" auf, so findet gerade eine Umordnung der Route statt und ein Connect-Befehl ist eventuell erfolglos.

Beispiel:

<code>
=>d hb9w-1 <CR>
*** HB9W-1 (1-1) T=663
=>
*** route: DB0NON PI1DRS DB0HSK DB0DOZ DB0PRA ON4EME ON4CP on1kul-2 PI4TUE
           hb9f-7 HB9F-14 HB9N HB9ZRH HB9AK HB9W HB9W-8 HB9W-1
</code>

Folgt einem gueltigen Call noch ein >, so werden so viele Routing-Pakete losgeschickt, wie Digipeater in der Kette sind und die Laufzeiten zwischen den einzelnen Digis ausgegeben. Diese Funktion ist nuetzlich, um herauszufinden, wo es genau hakt. Allerdings erzeugt sie sehr viel Betrieb auf den Links und sollte sparsam eingesetzt werden. Laufzeiten koennen seit Flexnet 3.3g ermittelt werden.

Beispiel (gekuerzt):

<code>
=>d hb9w-1 >
*** HB9W-1 (1-1) T=663
*** route: DB0NON (3) PI1DRS HB9W-1
=>
....
*** route: DB0NON PI1DRS DB0HSK DB0DOZ (135) DB0PRA HB9W-1
....
*** route: DB0NON PI1DRS DB0HSK DB0DOZ DB0PRA ON4EME ON4CP on1kul-2 PI4TUE 
 hb9f-7 HB9F-14 HB9N HB9ZRH HB9AK HB9W (9) HB9W-8 HB9W-1
=>
*** route: DB0NON PI1DRS DB0HSK DB0DOZ DB0PRA ON4EME ON4CP on1kul-2 PI4TUE 
 hb9f-7 HB9F-14 HB9N HB9ZRH HB9AK HB9W HB9W-8 (7) HB9W-1
</code>

Die Summe der Einzellaufzeiten ist uebrigens ungleich der Laufzeit, da pro verwendetem Link ein multiplikativer Faktor zur Gesamtlaufzeit geschlagen wird, der eine Beurteilung der Anzahl der Linkstrecken erlaubt.

Die letzte Option des D-Befehls ist weniger bekannt und gibt die zu den Partnern weitergemeldeten Laufzeiten aus. Sind diese Laufzeiten negativ (Normalfall), so ist die Route zum Ziel auf uns gerichtet. Und zwar vom Partner aus gesehen mit der bereits gewichteten Laufzeit. Sind mehrere Laufzeiten positiv, so befindet man sich an einem Verzweigungspunkt und es wird die bessere Laufzeit genommen.

Beispiel:

<code>
=>d hb9w-1 * <CR>
*** HB9W-1 (1-1) T=663:
    DB0RWN      675
    PI1DRS      663
    DB0SM      -761
    PI1PWD     -870
    DL1BKU     -760
</code>

(eingegeben bei DB0NON bedeutet dies): Die Route zu HB9W-1 wird ueber PI1DRS mit der Laufzeit 663 gewaehlt. DB0RWN kennt ebenfalls eine Route zu HB9W-1, die von DB0NON wegfuehrt. Diese wird aber nicht genommen, da sie schlechter ist als die ueber PI1DRS. DB0SM wird die Laufzeit zu HB9W-1 mit 761 bewerten. Von PI1PWD aus ist die Laufzeit 870. In beiden Faellen fuehrt der Weg ueber DB0NON. Negative Laufzeiten werden grundsaetzlich den Partnern nicht weitergemeldet. Ist ein versteckter Link mit Internode-QSO eingetragen, so kann er mit diesem Befehl aufgespuehrt werden.

Ein letztes Beispiel:

<code>
D DB0SOS <CR>

=>*** no route to DB0SOS
</code>

Der Digi konnte keinen Weg zum Ziel (Route) finden.


__**(XVII) Users:**__

Eingabe: (U)sers [*] [=] [port] [call] <CR>

Der (U)sers Befehl zeigt die Benutzer an, die derzeit ein QSO mit oder ueber den Digi fuehren. Dazu werden noch zusaetzliche Informationen angezeigt. Die einzelnen Optionen koennen miteinander kombiniert werden, so dass eine Liste erzeugt werden kann, die nur bestimmte Informationen enthaelt. Die Optionen haben folgende Bedeutung:

|[port]  |Es werden nur QSOs ausgegeben, die auf diesem Port laufen. |
|[call]  |Es werden nur QSOs ausgegeben, in denen dieses Rufzeichen vorkommt. |
|[=]     |Es werden nur QSOs von Stationen ausgegeben, die ausschliesslich mit dem Digi verbunden sind. Also keine QSOs, in denen bereits weiterconnected wurde. |
|[*]     |Es werden zusaetzliche Informationen zum jeweiligen QSO ausgegeben. |

Beispiel:

<code>
=>U <CR>

 1537: S7  U2  P10: DB0FBB>DG8DBQ
 1538: S3  U1  P9 : DB0FBB-9>DJ5OO

 1539: S5  U5  P10: DB0FBB>DC6MH
 1067: S13 U7  P3 : DB0HAG-9>DB0SGL-9 v DB0FBB*
  770: S5      P3 : DC6MH>DB0HAG v DB0FBB*     <-- (DC6MH ist ueber DB0FBB
   !   !   !   !    !                               mit DB0HAG verbunden.)
   !   !   !   !    +-> Rufzeichen und Digipeaterpfad
   !   !   !   +------> Port (Kanalnummer)
   !   !   +----------> Anzahl der noch zu sendenden Daten-Pakete
   !   +--------------> QSO-Zustand (s.u.)
   +------------------> Interne Verwaltungsnummer des QSOs

=>U * <CR>

 1537: S7  U2   F32  M7 P10: DB0FBB>DG8DBQ
 1538: S3  U1   F82  M1 P9 : DB0FBB-9>DJ5OO

 1539: S5  U5   F32  M4 P10: DB0FBB>DC6MH
 1067: S13 U7 ! F41  M7 P3 : DB0HAG-9>DB0SGL-9 v DB0FBB*
  770: S5       F26  M2 P3 : DC6MH>DB0HAG v DB0FBB*
              !  !   !
              !  !   -> Anzahl der maximal nacheinander gesendeten Pakete
              !  +----> Wartezeit fuer Wiederholungen in 1/10 sec. Der Digi
              !         bestimmt die Zeit, die eine Station durchschnittlich
              !         bis zur Bestaetigung eines Paketes braucht und nimmt
              !         dieses als Wartezeit auf eine Bestaetigung.
              +-------> Das "!" steht fuer Headerkompression der Verbindung.
                        Zwischen zwei Flexnet-Partnern werden fuer diese
                        Verbindung in einem komprimierten Paket nur noch
                        die Rufzeichen der Partner auf diesem Link sowie die
                        Verwaltungsnummer ausgetauscht, um Uebertragungszeit
                        und Rechenzeit zu sparen.
</code>

Die Leerzeile zwischen der QSO-Nummer 1538 und 1539 steht als Trennung fuer die Stationen, die nur mit dem Digi connected sind (oberhalb, entspricht der Option "=") und Stationen die bereits weiterconnected haben (unterhalb).

Anmerkung: Bei einem DAMA-Einstieg steht an Stelle des Frack-Wertes eine Level-Anzeige. Stationen mit Level 12 werden in jeder Runde gepollt. Je niedriger der Level, desto seltener wird bei der Station nachgefragt, ob Infodaten vorliegen. Der hoechste Level wird wieder erreicht, wenn einmal Datentransfer stattgefunden hat. Verbindet sich eine Station mehrfach mit dem Digipeater, so wird die Sendezeit pro Verbindung reduziert.

Beispiel:

<code>
=>U = * <CR>

 1537: S7  U2   F32  M7 P10: DB0FBB>DG8DBQ
 1538: S3  U1   F82  M1 P9 : DB0FBB-9>DJ5OO
</code>

Nur erweiterte Informationen ueber Stationen, die mit der Infobox (hier DB0FBB) verbunden sind.

Beispiel:

<code>
=>U 10 *  <CR>

 1537: S7  U2   F32  M7 P10: DB0FBB>DG8DBQ
 1539: S5  U5   F32  M4 P10: DB0FBB>DC6MH
</code>

Erweiterte Informationen ueber Stationen auf Karte 10

<code>
=>U DC6MH  <CR>

 1539: S5  U5  P10: DB0FBB>DC6MH
  770: S5      P3 : DC6MH>DB0HAG v DB0FBB*
</code>

Zeigt alle Verbindungen von dc6mh ueber diesen Netzknoten.


QSO-Zustand :

|S1:  |Disconnected |
|     |Dieser Zustand ist der Ausgangszustand einer jeden Verbindung. Er wird verlassen, wenn eine Verbindung aufgebaut wird. |
|S2:  |Link Setup |
|     |Eine Verbindung wird aufgebaut, d.h. es wird versucht eine Station zu connecten, aber die Bestaetigung wurde noch nicht empfangen. |
|S3:  |Frame Reject |
|     |Es wurde ein Protokollfehler begangen, d.h. eine der beiden Stationen hat sich nicht an das festgelegte Protokoll im Packet-Radio gehalten. Dies fuehrt in jedem Fall zum Abbruch der Verbindung. Grund dafuer koennte z.B. ein Softwarefehler sein. |
|S4:  |Disconnect Request |
|     |Die Verbindung soll getrennt werden, d.h. es wird derzeit versucht die Station zu disconnecten, die Bestaetigung wurde noch nicht empfangen. |
|S5:  |Information Transfer |
|     |Der hoffentlich haeufigste Zustand. Die Verbindung ist zustande gekommen und beide Stationen tauschen Daten-(Pakete) miteinander aus. |
|S6:  |REJ Frame sent |
|     |Es wurde ein sog. Reject-Frame gesendet, d.h. ein empfangenes Paket ist nicht in der richtigen Reihenfolge gekommen oder es wurde bei der Uebertragung beschaedigt. Es wird dadurch das entsprechende Paket nochmals angefordert (eine Wiederholung von der jeweiligen Station gesendet). |
|S7:  |Waiting Acknowledge |
|     |Die Verbindung wird gepollt, d.h. es wird nach der noch ausstehenden Bestaetigung eines Daten-Paketes gefragt, oder die Verbindung zur anderen Station geprueft (ob sie noch besteht). |

Sollten Werte ueber "S7" beim QSO-Zustand stehen, so entspricht dies der oben genannten Bedeutung, jedoch mit einer zusaetzlichen Information (vgl. AX25-Protokollbeschreibung).

Wenn die Station (in dem Fall der Digi) "Busy" ist, wird zu der oben angegebenen Zahl 8 addiert (entspricht also S9 bis S15). Wenn die Gegenstation (also der Benutzer) "Busy" ist, wird zu der oben angegebenen Zahl 16 addiert (entspricht also S17 bis S23). Wenn beide Stationen (Digi und Benutzer) "Busy" sind, wird zu der oben angegebenen Zahl 24 addiert (entspricht also S25 bis S31)

Busy bedeutet, dass die Station keine weiteren Daten-(Pakete) mehr aufnehmen kann. Dies ist z.B. dann der Fall, wenn die maximale Anzahl der zwischengespeicherten Pakete der jeweiligen Verbindung erreicht ist. Einfach gesagt, der TNC (oder was halt verwendet wird) ist "vollgelaufen".

__**(XVIII) Connect:**__

Eingabe: (C)onnect call [v] [digi] [port] <CR>

Der (C)onnect Befehl dient zum Weiterverbinden aus der Infobox heraus. Bei Flexnet wird aus Transparenzgruenden allerdings das direkte Routing lieber gesehen (also bei TNCs:"ESC-c dl1bku db0non db0aac", um dl1bku von db0non aus ueber db0aac zu erreichen).

Das Routing erfolgt zunaechst nach Ziel-Tabelle (also die D-Liste wird durchsucht). Wird kein Eintrag gefunden, wird die Link-Tabelle durchsucht. Es folgt die Mheard-Liste. Wird wiederum kein Eintrag gefunden, so wird nach SSID geroutet. 

Umgangen werden kann das Routing durch Eingabe des Ports, auf dem die Verbindung erstellt werden soll.

Die Optionen "via" und "digi" sind wie vom L2-Routing her gewohnt zu verwenden.

Die Eingabe "C DC6MH v DG8DBQ <CR>" bedeutet, dass DC6MH "via" DG8DBQ connected werden soll. Die Station DG8DBQ hat die Funktion eines Vermittlers zwischen beiden Stationen.

Im Folgenden liege diese Konfiguration vor:

<code>
po id td qso usr tifr rifr tkby rkby qty   mode      links
 1  0 20   2   3  192   14   43    2 100   1200u+    USER70
 2  1 20  12  14  163   38   32    5  92   9600tu+   USER96
</code>

Wie beim (P)arms Befehl schon erklaert wurde, gibt die erste Spalte "po" die Portnummer und die zweite Spalte "id" das eingetragene SSID an. Hier bedeutet das, dass auf der Karte mit der Portnummer 2 und dem SSID 1 der 9k6-Einstieg
liegt und dass auf der Karte mit der Portnummer 0 und dem SSID 1 der 1k2-Einstieg liegt. Wenn der Digipeater jetzt eine Station connecten soll, die ihm nicht bekannt ist, muss er das auf irgendeiner Karte machen. Dabei geht der Digipeater folgendermassen vor:

Der Digipeater fuehrt eine interne Liste der ca. 200 zuletzt gehoerten Benutzer Stationen. Dort ist verzeichnet, wo dieser Benutzer zuletzt gehoert wurde (auf welchem Port). Wird der Benutzer, der connected werden soll, in dieser Liste gefunden, wird der Connect auf dem entsprechenden Port ausgestrahlt. Findet der Digi ihn nicht in dieser Liste, muss ein anderes Kriterium gefunden werden, nachdem der Port ausgewaehlt wird.

Das naechste Kriterium ist das eingetragene SSID, unter dem der Digi connected wurde. In der Regel connected man nur das Digi-Rufzeichen, was allerdings DB0FBB-0" entspricht. Die "-0" wird einfach weggelassen. In der (P)arms Liste ist nun ersichtlich, dass die "0" als SSID auf dem 70cm-Einstieg eingetragen ist. D.h., dass ein Connect an eine unbekannte Station jetzt auf dem 70cm-Einstieg versucht wird. (Der SSID, mit dem der Digi connected wurde, stimmt mit dem SSID in der (P)arms Liste ueberein.) Soll es aber auf dem 23cm-Einstieg versucht werden, muss man mit DB0FBB-1 verbunden sein, da die 1 als SSID auf dem 9k6-Einstieg eingetragen ist. Das SSID muss also geaendert werden. Die Verbindung muss dazu aber nicht beendet und erneut mit DB0FBB-1 aufgebaut werden, sondern der SSID kann waehrend der Verbindung gewechselt werden. Dies geschieht mit:

(C)onnect [ssid] <CR>

Wenn man mit DB0FBB (-0) verbunden ist, kann durch Eingabe von "C -1" der SSID auf DB0FBB-1 geaendert werden. Wenn jetzt ein Connect an eine unbekannte Station gehen soll, wird es auf dem 9k6-Einstieg versucht. Der SSID "1" ist ja auf dem 9k6-Einstieg in der (P)arms Liste eingetragen.
Hier noch mal das Wechseln des SSID:

Vom momentanen SSID zu SSID 1 wechseln :

<code>
=>C DB0FBB-1 <CR>

=>*** DB0FBB-9: ssid ok
</code>

Und wieder nach DB0FBB(-0) zurck :

<code>
C DB0FBB <CR>

=>*** DB0FBB: ssid ok
</code>

Anstatt des kompletten Rufzeichens mit SSID, kann auch nur das gewuenschte SSID eingegeben werden.

Beispiel:

<code>
C -1 <CR>       (fuer DB0FBB-1)
C -0 <CR>       (fuer DB0FBB)
</code>

Wem das Wechseln des SSID zu umstaendlich ist, der kann beim (C)onnect Befehl gleich den Port angeben, auf dem versucht werden soll, die Station zu connecten. Aber Achtung! Es wird in jedem Fall versucht, die Station auf
diesem Port zu erreichen. Auch wenn der Digi bei evtl. bekannten Rufzeichen einen anderen Port nehmen wuerde.

Beispiel:

<code>
C DG8DBQ 9  <CR>

=>link setup...               ( Bestaetigung der Eingabe, Verbindungsaufbau
                                erfolgt jetzt ueber Port 9, unabhaengig von
                                anderen, dem Digi bekannten Wegen)
</code>

(Dieses "harte" routing geht auch im Pfad: "c dl1bku db0non db0aac 9" erzwingt einen connect via db0non, db0aac und dort auf Karte 9.)

ACHTUNG: Das "link setup..." kommt seit der Version 3.3f verzoegert. D.h. konnte die Verbindung schneller als in einer Sekunde hergestellt werden, so entfaellt diese Ausgabe.

Beim Weiterconnecten erhaelt man einige Informationen vom Digipeater, die im folgenden Beispiel erklaert werden. Der Benutzer ist mit DB0FBB verbunden.

Beispiel:

<code>
C DB0DOZ <CR>                   (Eingabe des Benutzers, Verbindungswunsch)
=>link setup...                 (Bestaetigung der Eingabe, Verbindungsaufbau)
*** connected to DB0DOZ         (Verbindung konnte hergestellt werden)
C DB0FBB <CR>                   (Eingabe des Benutzers, Verbindungswunsch)
*** DB0DOZ: loop detected       (Erklaerung siehe unten.)
C DB0FN  <CR>                   (Eingabe des Benutzers, Verbindungswunsch)
*** DB0DOZ: can't connect twice (Erklaerung siehe unten.)
C HB9EAS <CR>                   (Eingabe des Benutzers, Verbindungswunsch)
*** failure with HB9EAS         (Verbindung konnte nicht hergestellt werden)
C DB0SGL <CR>                   (Eingabe des Benutzers, Verbindungswunsch)
*** busy from DB0SGL            (Gegenstation war besetzt, besch„ftigt)
C DB0SOS <CR>                   (Eingabe des Benutzers, Verbindungswunsch)
*** DB0DOZ: can't route         (Der Digi konnte keinen Weg zur Zielstation
                                 finden. Wenn der Digi allerdings einen Einstieg
                                 besitzt, wird er es dort versuchen)
*** DB0FBB: Link failure        (Die Verbindung ist abgerissen, siehe unten)
*** reconnected to DB0FBB       (Das QSO wurde wieder vom letzten Digi
                                 uebernommen, mit dem man connected war)
</code>

Erklaerung zu "<nowiki>***</nowiki> DB0DOZ: loop detected" :

"Loop detected" bedeutet soviel wie "Schleife gefunden". D.h., der Digi hat beim Verbindungswunsch nach DB0FBB erkannt, dass dadurch eine Schleife gebildet wuerde. In diesem Beispiel kann man also nicht von DB0FBB nach DB0DOZ
connecten und dann den gleichen Weg wieder zurueck. Damit wird verhindert, dass unsinnige Verbindungen entstehen, wie z.B. Verbindungen die hin und hergehen, oder eben eine Schleife bilden. Mit anderen Worten: Ist der Port, auf
dem weiterconnected werden soll, gleich dem Port, ueber den man gekommen ist, wird eine Schleifenbildung gemeldet. Um dennoch weiterconnecten zu koennen, muss die Verbindung zum derzeitigen Digi beendet werden (mit <Q>uit). Der
Benutzer wird dann zum davorliegenden Digi zurueckverbunden (reconnected) und kann den Verbindungswunsch erneut eingeben.

Erklaerung zu "<nowiki>***</nowiki> DB0DOZ: can't connect twice" :

"can't connect twice" bedeutet soviel wie "kann nicht zweimal connecten". Eine Station kann immer nur einmal mit dem gleichen Rufzeichen und SSID connected werden. Diese Meldung bedeutet, dass die Station, zu der eine Verbindung aufgebaut werden soll, schon einmal mit dem gleichen Rufzeichen und SSID connected wurde. In seltenen Faellen kann es vorkommen, dass der Benutzer nur einmal auf dem Digi ist und dennoch diese Meldung bekommt. Grund dafuer kann ein Absturz, ploetzlicher Ausfall eines Links oder aehnliches sein.

Erklaerung zu "<nowiki>***</nowiki> DB0FBB: Link failure" :

"Link failure" bedeutet soviel wie "Linkstrecke verloren". D.h. der Linkpartner, zu dem weiterconnected wurde, kann nicht mehr erreicht werden. Wenn eine Linkstrecke ausgefallen ist, wird die Verbindung von dem Digi wieder uebernommen, mit dem man als letztes verbunden war (der Letzte, vor dem, der ausgefallen ist).


__**(XIX) Convers:**__

Eingabe: (C)onvers <CR>

Der (C)onvers Befehl startet den sog. Convers-Mode. Dieser Mode erlaubt einer grossen Anzahl von Stationen, eine Gespraechsrunde aufzubauen. Dabei sind 255 verschiedene Runden moeglich. Nach Eingabe von "C <CR>" zeigt der Digi
die derzeit connecteten Stationen an und erwartet die Eingabe einer Nummer, die die gewuenschte Gespraechsrunde auswaehlt (0 bis 255).

Waehrend des Convers-Mode stehen folgende Befehle zur Verfuegung :

|/w            <CR> | Zeigt alle mit dem Digi connecteten Stationen an |
|/w kanal      <CR> | Zeigt alle Convers Benutzer auf Kanal "kanal" an |
|/c            <CR> | Zeigt die aktuelle Kanalnummer an |
|/c kanal      <CR> | Der Benutzer wechselt zum Convers-Kanal "kanal" |
|/q            <CR> | Der Convers-Mode wird beendet |
|/s call text  <CR> | Sendet eine private Nachricht "text" nur an "call" |
|/m call text  <CR> | Genau das Gleiche wie "/s call text" |


In den folgenden Beispielen werden die einzelnen Befehle sowie die Meldungen erklaert, die man im Convers-Mode erhalten kann. Um den Convers-Mode starten zu koennen, muss folgendes eingegeben werden:

C <CR>

Vor dem Start des Convers-Mode erhaelt man z.B. folgende Einschaltmeldung :

<code>
users:
---: DJ5OO     0: DC6MH   ---: DG8DBQ   73: DK7WJ
channel?
</code>

D.h., DC6MH ist in der Convers-Runde 0, DK7WJ ist in der Runde 73 und DJ5OO sowie DG8DBQ sind nur mit dem Digi connected, aber nicht im Convers-Mode. Der Benutzer muss jetzt eine Kanalnummer eingeben, um den Convers-Mode zu
starten. Er kann z.B. eine "0" eingeben, um auf den gleichen Kanal zu gehen wie DC6MH, oder "73" um zu DK7WJ gelangen, oder natuerlich eine ganz andere Nummer eingeben, um eine neue Runde zu eroeffnen. Soll der Convers-Mode doch nicht gestartet werden, drueckt man einfach <CR>. Als Bestaetigung erhaelt man das Prompt "=>" wieder. Starten des Convers-Mode, z.B. :

0 <CR>

<nowiki>***</nowiki> starting convers; exit: /q             (Bestaetigung des Convers-Mode)

Alles was jetzt zum Digipeater gesendet wird, wird an alle Stationen weitergeleitet, die auf dem gleichen Kanal sind wie man selbst.

Beispiel:

<code>
Hallo du da...  <CR>              (Eingabe von DG8DBQ)

<DG8DBQ>: Hallo du da...          (Ausgabe an alle Stationen, die auf dem
                                   gleichen Convers-Kanal sind)
</code>

Soll ein Text nur von einer Station in der Runde gelesen werden, so kann dies mit dem "/s call text  <CR>" bzw. "/m ...  <CR>" Befehl eingegeben werden. Auch, wenn diese Station nur mit der Infobox verbunden ist!

Beispiel:

<code>
/s DC6MH Hallo Du...  <CR>        (Eingabe von DG8DBQ)

*DG8DBQ*: Hallo Du...     (Diese Zeile wurde vom Digi nur an DC6MH gesendet.
                           Alle anderen Stationen haben nichts bekommen. Als
                           Kennung, dass diese Zeile nur an DC6MH gesendet
                           wurde, steht das Rufzeichen des Absenders in
                           Sternchen (sonst in Klammer "<call>").)
</code>

Um sich einen Ueberblick zu verschaffen, welche Stationen z.Z. mit dem Digi connected sind, muss "/w  <CR>" eingegeben werden.

Beispiel:

<code>
/w <CR>                                     (Eingabe von DG8DBQ)

users:
---: DJ5OO     0: DG8DBQ    0: DC6MH        (Ausgabe an DG8DBQ)
</code>

Sollen nur die Stationen ausgegeben werden, die auf einem bestimmten Kanal sind (z.B. dem eigenen), muss "/w (kanal) <CR>" eingegeben werden.

Beispiel:

<code>
/w 0 <CR>                                   (Eingabe von DG8DBQ)

users:
  0: DG8DBQ    0: DC6MH                     (Ausgabe an DG8DBQ)
</code>

Falls vergessen wurde, auf welchem Kanal man selber ist, kann die aktuelle Kanalnummer mit "/c  <CR>" abgefragt werden.

Beispiel:

<code>
/c <CR>                                     (Eingabe von DG8DBQ)

convers: channel 0                          (Ausgabe an DG8DBQ)
</code>

Soll der aktuelle Kanal gewechselt werden, so muss "/c [kanal] <CR>" eingegeben werden. Dabei ist "kanal" der Kanal, auf den gewechselt werden soll.

Beispiel:

<code>
/c 73                    (Eingabe von DG8DBQ)

convers: channel 73      (Bestaetigung, dass der Kanal gewechselt wurde)
</code>

Um den Convers-Mode zu verlassen, muss "/q <CR>" eingegeben werden.

Beispiel:

<code>
/q  <CR>                 (Eingabe von DG8DBQ)

=>                       (Bestaetigung, dass der Convers-Mode verlassen wurde.)
</code>
 
Folgende Meldungen kann man waehrend des Convers-Mode erhalten :

Wenn z.B. DG8DBQ auf einen Kanal geht, auf dem bereits eine Runde besteht, erhalten alle Stationen auf dem Kanal diese Meldung :

<DG8DBQ>:  <nowiki>***</nowiki> Logon


Verlaesst DG8DBQ den Kanal, erhalten alle noch beteiligten Stationen diese Meldung :

<DG8DBQ>:  <nowiki>***</nowiki> Logoff


Wechselt DG8DBQ auf einen anderen Kanal (z.B. 73), erhalten alle Teilnehmer des urspruenglichen Kanals diese Meldung :

<DG8DBQ>:  <nowiki>***</nowiki> switched to channel 73"



__**(XX) Talk:**__

Eingabe: (T)alk call [text] <CR>

(Vergleiche mit convers, Befehl /s.)

Der (T)alk Befehl sendet einen Text an einen anderen Benutzer. Diese Station darf aber nur mit dem Digi connected sein, also noch nicht weiterconnected haben. Als "call" wird das Rufzeichen der entsprechenden Station angegeben.
Als "text" ein beliebiger Text. Das ganze sollte allerdings nur eine Zeile lang sein, da es sonst beim Empfaenger "zerstueckelt" ankommen kann. Entfaellt der Text, so wird alles Folgende an "call" geschickt bis zur Eingabe von "/q <CR>".

Beispiel:

<code>
T DC6MH Hallo Christian, kennst Du schon den "Talk" Befehl? <CR>
</code>

Der Empfaenger bekommt:

<code>
*DG8DBQ*: Hallo Christian, kennst Du schon den "Talk" Befehl?
</code>

Als Bestaetigung, dass der Text vom Digipeater weitergeleitet wurde, erhaelt man das Prompt "=>" wieder. Wenn der eingegebenen Text nicht an die entsprechende Station weitergeleitet werden kann, erhaelt man folgende Meldung:


<nowiki>***</nowiki> DC6MH not connected!


Die Station "DC6MH" ist entweder nicht mit dem Digi verbunden oder hat bereits zu einem anderen Digi o.a. weiterconnected.


__**(XXI) Quit:**__

Eingabe: (Q)uit <CR>

Der (Q)uit-Befehl beendet die Verbindung mit dem Digipeater. Wurde von einem FlexNet-Digi aus weiterconnected, erfolgt automatisch ein Reconnect zum letzten Digi, mit dem man connected war. War man bereits mit dem "letzten"
Digi verbunden (Einstiegsdigi), erfolgt die Meldung "73!" und der Disconnect.


__**(XXII) Mail:**__

Eingabe: (M)ail [?] <CR>

Durch Eingabe dieses Befehls wird man umgehend mit der naechsten Mailbox verbunden. Welche das ist, erfaehrt man durch Eingabe von "m ? <CR>".

__**(XXIII) Mheard:**__

Eingabe: (Mh)eard [call] [port] [count] <CR>

Der Digipeater fuehrt eine 200 Rufzeichen umfassende Mheard-Liste, um zwischen verschiedenen Usereinstiegen unterscheiden zu koennen. Um in diese Liste aufgenommen zu werden, reicht es, wenn der Digi ein Packet der 
Station hoert. Wird zusaetzlich ein Port angegeben (0-15), so werden nur die gehoerten Stationen auf dieser Karte angezeigt. Entsprechend wird bei der Eingabe eines Rufzeichens nur eine Ausgabe fuer dieses Rufzeichen (aber
davon alle SSIDs) ausgegeben. Es werden immer die letzten 30 passenden Eintraege ausgegeben, falls vorhanden. Sollen mehr oder weniger Eintraege gelistet werden, so ist diese Anzahl mit anzugeben (bei einziger Angabe von "count" muss diese Zahl > 15 sein). Es wird die Zeit seit dem letzten Hoeren dieser Station zusammen mit dem Port ausgegeben, auf dem die Station gehoert wurde.

Beispiel:

<code>
=>mh <CR>

  0m, 1s P5  DB0SM       0m, 1s P1  DG8YFM      0m, 1s P1  PI1PWD   
  0m, 3s P4  PI1DRS      0m, 4s P1  DF3BN-1     0m, 8s P3  DB0RWN   
  0m,17s P1  DG8YFM-8   13m,42s P4  PI1DRS-6   14m,33s P1  DG8YFM-9 

=>
</code>

Ausgabe aller gehoerten Stationen. DB0SM wurde vor einer Sekunde auf Port 5 gehoert.

<code>
=>mh 1 dg8yfm

  0m, 3s P1  DG8YFM      6m,18s P1  DG8YFM-1   12m,40s P1  DG8YFM-8 
 27m,36s P1  DG8YFM-9 
</code>

Ausgabe alle gespeicherten Informationen zu dg8yfm.

__**(XXIV) PW/Sysop:**__

<code>
Eingabe: (PW) <CR>
         (SY)sop <CR>
</code>

Umschaltung in den Sysop-Mode, in dem weitere Befehle vorhanden sind. Bei Flexnet < 3.3h erfolgte die Ausgabe einer 5-stelligen Zahl. Stellenweise Multiplikation mit einer geheimen Passwortzahl und anschliessende Quersummenbildung ergab die gesuchte Antwort. Es erfolgt keine Rueckmeldung ueber Erfolg oder Misserfolg. Ab Flexnet 3.3h erfolgt die Ausgabe von 5 Zahlen, die die Position der zur Authentifizierung einzugebenen Zeichen in einem 80 Zeichen langen Passwort-String enthalten. 


__**(XXV) Fehlermeldungen:**__

Wird ein Befehl falsch eingegeben, oder etwas anderes zum Digi gesendet, was nicht als Befehl Interpretiert werden kann, erhaelt man folgende Meldung:

=>invalid command


Im Convers-Mode erhaelt man dann:

invalid command; exit: /q


so, das war's.. etwas durcheinander, aber hoffentlich hat es etwas gebracht. 73 de Joerg und tnx an dg9dbq und dk7wj fuer die Vorlagen.

===== Deutsch DF2VO =====
'Sysop-help' fuer PC/FlexNet-Digipeater Version 3.3

(teilweise auch fuer RMNC/FlexNet geeignet)

erstellt von Michael Bloch, DF2VO @ DB0HOM.#SAR.DEU.EU, am 31. Juli 1998

zuletzt ueberarbeitet am 04.11.1998

(Nachfolger der 'Kurzdoku' vom Silvester 1995)

**Index**

  1. Vorwort
  2. Befehlslisten
     2.1. USER-Befehle
     2.2. SYSOP-Befehle (im Sysop-Modus zusaetzlich nutzbar)
  3. Installation
     3.1. Die Installation auf einem PC
     3.2. Gleichzeitiger Betrieb von PC/FlexNet und einer Mailbox
     3.3. User-Version von PC/FlexNet statt Digipeater
  4. Einstellen der Parameter / Konfiguration
     4.1. Parametrierung
     4.2. Der MODE-Befehl
     4.3. Der PARMS-Befehl
     4.4. Der LINKS-Befehl (Linkeintraege)
     4.5. Eingabe der Texte A, B, C, H, I, L und S
     4.6. Sysop-Authentisierung
     4.7. Hinweise zum TRACE-Befehl
  5. Anhang
     5.1. Erklaerung der Ausgaben einzelner Befehle
     5.2. Listen der benoetigten Dateien
     5.3. Blockdiagramm einer PC/FlexNet-Station
     5.4. Literaturquellen

__**1. Vorwort**__

Dies ist keine vollstaendige Dokumentation, sondern eine  Zusammenfassung der fuer die Installation noetigen Infos fuer Digi-Sysops. Der folgende Text enthaelt daher lediglich eine Auflistung aller  Befehle und Parameter sowie eine Anleitung zur Installation und Konfiguration. Er enthaelt keine allgemeine Beschreibung des FlexNet-Konzeptes, seiner Routing-Verfahren, der Funktionen und Feinheiten. Deshalb sei an dieser Stelle ausdruecklich auf die Original-Sysop-Dokumentation zu RMNC/FlexNet von Gunter Jost, DK7WJ, verwiesen! Ohne diese koennen die vielfaeltigen Moeglichkeiten von PC/FlexNet nicht optimal genutzt werden.

Diese 'Sysop-help' gilt fuer die Digi-Versionen V3.3e vom Januar 1996 und V3.3g vom Juli 1998 (beide unter DOS). Bis auf die Installation und die Dateilisten kann sie auch fuer RMNC-Digis V3.3h verwendet werden; die Befehlslisten  (Kap. 2), die Parametrierung (Kap. 4) und die Ausgaben (Kap. 5.1.) enthalten auch die von PC/FlexNet abweichenden Angaben fuer RMNC/FlexNet.

Der Text ist so aufgebaut, dass die haeufiger zum Nachlesen benoetigten Befehlslisten am Anfang stehen, die seltener benutzte Anleitung zur  Installation und Konfiguration weiter hinten. Die 'Sysop-help' kann entweder vollstaendig ausgedruckt (dafuer ist das Deckblatt vorgesehen) oder als Textfile auf der Festplatte des Digi-PC's gespeichert werden. Dafuer sollte das Deckblatt mit einem Texteditor entfernt werden, dann stehen die Befehlslisten beim Aufruf weiter vorne. Damit die Datei ohne spezielle Textverarbeitung gelesen werden kann, enthaelt sie ausser CR/LF keine  Steuerzeichen; vor dem Ausdrucken ist daher ggf. noch eine Formatierung (Seitenumbrueche) durchzufuehren.

Verwendete Symbole und Abkuerzungen:

<code>
   [...]    - Angaben in [ ] koennen weggelassen werden, sie sind optional.
   <...>    - Angaben in < > muessen angegeben werden, sie sind Platzhalter
              fuer Rufzeichen, Rufzeichenfragment ('Teilcall'), SSID, Port,
              Text, Anzahl, Kanalnummer usw.
   " "      - Zeichen in " " sind keine Platzhalter; sie muessen direkt in
              der angegebenen Syntax eingegeben werden.
   |        - das Zeichen '|' bedeutet 'oder' (entweder der Parameter vor
              oder der Parameter nach dem '|' kann verwendet werden).

   call     - Rufzeichen allgemein (Digi, Mailbox, User,...)
   teilcall - Rufzeichenfragment / Rufzeichengruppe (z. B. DB0)
   ssid     - secondary station identifier 'SSID' (Wertebereich: 0..15)
   port     - hardwaremaessige Portnummer (0..15); entspricht den Hardware-
              kanaelen / Kartenadressen beim RMNC
   n        - logische Kanalnummer im Convers
   num      - Uebertragungsgeschwindigkeit in Bit/s (fuer MODE-Befehl)
   opt      - Kanal-/Portoptionen (fuer MODE-Befehl)
   wert     - Zahlenwert (fuer PARMS-Befehl)
</code>

__**2. Befehlslisten**__

__**2.1. USER-Befehle**__

Befehlsuebersicht fuer PC/FlexNet-Digipeater V3.3:

<code>
  Aktuell                 Aktuelle Infos abrufen (Aktuell-Text)
  Beacons                 Baken-Text abrufen
  Connect <call> [Opt.]   Station <call> connecten; moegliche Optionen:
                          <digi>     : Weg via <digi> benutzen
                          <digi-ssid>: Weg via <digi> mit <ssid> benutzen
                          <port>     : Weg via <port> benutzen
                          (max. 6 dieser Optionen koennen angegeben werden)
  Connect -<ssid>         zum (User)port mit der SSID <ssid> wechseln
  Convers                 Anzeige aller Conversteilnehmer (mit Kanalnummer)
                          und Benutzer in der Infobox (mit '---').
                          Nach Abfrage 'channel?' antworten mit:
                          RETURN-Taste -> direkt zurck zum Prompt '=>'
                          oder Kanalnummer -> schaltet zu dem Converskanal
                          Befehle im Conversmodus:
          /w                 alle Benutzer in Convers und Infobox anzeigen
          /w <n>             alle Benutzer im Converskanal <n> anzeigen
          /c                 die aktuelle Kanalnummer im Convers anzeigen
          /c <n>             zu Kanalnummer <n> im Convers wechseln
          /s <call> <text>   den <text> an den User <call> senden
          /t <call>          Talkmodus an den User <call> starten
          /t                 Talkmodus beenden
          /q                 Quit, Conversmodus bzw. Talkmodus beenden
  Destinations            Destinations-Tabelle abrufen (Liste Zieldigis);
                          (mit SSID-Bereich und Laufzeit in Zehntelsekunden)
  Destinations <teilcall> wie D, nur Zieldigis mit Zeichengruppe <teilcall>
                          z. B. selektiert nach Prefix oder Suffix
  Destinations *          wie D, auch nicht schleifenfrei erreichbare Ziele
  Destinations * <teilcall>  Kombination aus "D *" und "D <teilcall>"
  Destinations <call>     Laufzeit und gewaehlten Weg zu <call> anzeigen
                          (Kleinschreibung: Digis ohne FlexNet-Routing)
  Destinations <call> *   Laufzeiten ueber verschiedene Wege anzeigen
  Destinations <call> >   Laufzeiten auch zwischen einzelnen Digis zeigen
  Find <call>             nach Station <call> suchen (evtl. mehrfach!)
  Help                    diesen Hilfe-Text abrufen
  Info                    Informations-Text ueber diesen Digi abrufen
  (IO                     Ausgabe der Ein-/Ausgangszustaende; nur bei RMNC)
  Links                   Link-Informationen abrufen
  Links *                 wie L, mit Einzellaufzeiten der letzten 16 Tests
  LOcal                   Local-Text abrufen (lokaler Connect-Text)
  Mail                    die eingestellte (lokale) Mailbox connecten
  Mail ?                  das Call der eingestellten Mailbox abfragen
  MHeard [Optionen]       MHeard-Liste abrufen; moegliche Optionen:
                          <call>|<teilcall>: Rufzeichen / Rufzeichengruppe
                          <port>   : nur MH auf <port> (0..15) anzeigen
                          <Anzahl> : letzte 16..300 Eintraege anzeigen;
                                     Default ohne Anzahl = 30 Eintraege
                          "*" : max. Anzahl 300 (alle passenden Eintraege)
  MYcall                  Digi-Rufzeichen mit SSID-Bereich anzeigen
  Parms                   Parameter anzeigen (die Layer-1/2-Parameter)
  Parms *                 wie P, mit Zusatzinformationen (s. u.)
  Parms [*] <port>        wie P oder "P *", nur fuer Port <port>
  Quit                    Verbindung mit dem Digi beenden
  Setsearch               Suchpfade fuer FIND abrufen (Setsearch-Text)
  STat                    interne Portstatistik anzeigen (nicht bei RMNC)
  Talk <call> <text>      Talkmodus, den <text> an User <call> senden
  Talk * <text>           den <text> an alle eingeloggten User senden
  Talk <call>             Talkmodus an <call> starten; im Talkmodus sind
                          die gleichen Befehle wie im Conversmodus aktiv
  Users [Optionen]        Userliste anzeigen; moegliche Optionen:
                          "*" : Parameter Maxframe und Frack mit anzeigen
                          "=" : nur QSOs mit dem Digi selbst (Infobox)
                          <port> : nur QSOs auf Port <port> anzeigen
                          <call> : nur User <call> anzeigen
</code>

Bei den Befehlswoertern genuegt die Eingabe der Grossbuchstaben.

Informationen der zusaetzlichen Zeile bei "L *" und "P *":

<code>
   (d:544 v:1 t:12d,14h)
    |     |   +---------- Laufzeit (uptime) seit dem letzten Start/Reset
    |     +-------------- Software-Revision (kleinere Updates)
    +-------------------- Anzahl in der Routingliste gespeicherter Ziele
                          (ueber FlexNet-Routing erreichbare Destinations)
</code>

__**2.2. SYSOP-Befehle**__  (im Sysop-Modus zusaetzlich nutzbar)

<code>
  CAl <port> [min|0]       Calibriersignal der Dauer <min> Minuten senden;
                           Defaultdauer ohne Zeitangabe = 1 Minute;
                           "0" beendet laengeres Calibrate auf Port <port>
  (IO <port> 0|1           Setzen/Loeschen eines Ausgabebits; nur bei RMNC)
  Kill <QSO-Nr.>           das QSO <QSO-Nr.> aus der Usertabelle loeschen
  Links <port|link> <call> [Option]
                           Linkpartner <call> auf Port <port> oder
                           via Linkeintrag <link> routen;
                           ggf. mit Option (siehe Kapitel 4.4.)
  Links - <call>           den Linkeintrag <call> loeschen
  Mail <call>              Boxcall <call> als (lokale) Mailbox eingeben
  MYc <call> [ssid1 ssid2] Rufzeichen <call> als Digicall eingeben,
                           ggf. mit SSID-Bereich von <ssid1> bis <ssid2>
  MOde <port> <[num][opt]> Modus fuer den Port <port> einstellen;
                           moegliche Einstellungen siehe Kapitel 4.2.
  Parms I <min|0>          Parameter Infobox-Timeout einstellen
  Parms S <ssid> <port|16> Parameter SSID <ssid> auf Port <port> setzen
  Parms T <txdelay> <port> Parameter TX-Delay auf Port <port> einstellen
  (RESET                   Kaltstart: Ruecksetzen des Digis auf EPROM-
                           Defaultwerte; nur bei RMNC)
  (RESTART                 Warmstart des Digis; nur bei RMNC)
  SYsop                    Sysop-Authentisierung/Privilegierung anfordern
  PW                       entspricht "SY" ab V3.3g und RMNC/FlexNet V3.3h
  TRace <port> [Optionen]  den Port <port> tracen/monitoren;
                           moegliche Optionen:
                           <call> : nur Rufzeichen <call> tracen
                           "#" : RR/RNR/REJ-Frames unterdruecken
                           "$" : Infoframe-Inhalte (Texte) unterdrcken
                           ">" : nur gesendete Frames anzeigen
                           "<" : nur empfangene Frames anzeigen
                           "*" : auch TX-Delay-Rest und QSO-Nr. anzeigen
  TRace                    Trace ohne Portangabe: Tracemodus beenden
                           (Trace wird auch durch Eingabe einer Leerzeile
                            oder eines neuen Befehls beendet)
  Write <A|B|C|H|I|L|S>    Textfiles schreiben (Ende mit /ex oder Ctrl-Z)
         A                 Text AKTUELL schreiben
         B                 Text BEACON schreiben
         C                 Text C(onnect)-TEXT schreiben
         H                 Text HELP schreiben
         I                 Text INFO schreiben
         L                 Text LOCAL schreiben (lokaler C-Text)
         S                 Text SETSEARCH schreiben
</code>

Ausfuehrliche Anleitung zur Parametrierung mit Hilfe der Sysop-Befehle sowie Hinweise zu den Befehlen "TRACE", "PW" und "SY" siehe Kapitel 4!

__**3. Installation**__

__**3.1. Die Installation auf einem PC**__

Die Installation erfolgt sinnvollerweise in folgender Reihenfolge:

1. Installationsverzeichnis anlegen (z.B. C:\PCFLEX) und die PC/FlexNet-Files hineinkopieren (ggf. nach Entpacken des Archivs).

2. falls Parameter- und Textfiles in einem anderen Verzeichnis (z.B. Subdirectory) stehen sollen, dieses vorher von Hand anlegen und im Batchfile (siehe Beispiel unten) mit der Variablen FLEXNET angeben. Syntax: SET FLEXNET=<pfad>

3. die einzelnen Module in folgender Reihenfolge laden, am Besten mit LH (LOADHIGH) in den oberen Speicherbereich:

a) FLEXNET.EXE (optionaler Parameter: insgesamt benutzte RAM-Groesse in kByte; default ohne Angabe = 15 kB). Fuer die RAM-Groesse reichen 15 kB pro Port/HF-Kanal aus; nur bei einem stark frequentierten Port (z. B. Mailbox) sind bis zu 30 kB sinnvoll. Beispiel fuer 7 Ports und 1 Mailbox: 7 * 15 kB + 1 * 30 kB = 135 kB

b) die einzelnen Hardware-Kanaltreiber (z.B. SER12.EXE fuer 1 Port oder USCC.EXE fuer 4 bzw. 8 Ports) ggf. mit Optionen (siehe Hilfe jeweils mit "<treibername> /?") in der gewuenschten Reihenfolge. Achtung: Die Portnummern ergeben sich aufsteigend allein durch die Reihenfolge des Ladens der Kanaltreiber! Sollen Portnummern freigelassen/uebersprungen werden, den Dummytreiber DUMMY.EXE (Parameter: Zahl der freien Ports) laden.

c) fuer Digipeaterbetrieb den eigentlichen FlexNet-Digi FLEXDIGI.EXE

d) zum Abschluss FLEX.EXE zur Aktivierung des Systems.

4. Jetzt koennen (muessen aber nicht) die Parameter fuer MODE (s.Kap. 4.2.) und TXDELAY mit dem Utility FSET.EXE voreingestellt werden.

|Syntax:   |FSET MODE <port> <[num][opt]>|
|          |FSET TXD <port> <txdelay>|
|Beispiel: |FSET MODE 2 9600d  (Port 2 mit 9600 Bit/s vollduplex)|
|          |FSET TXD 3 12      (Port 3 mit TX-Delay = 120 ms)|

Diese Werte werden dann bei jedem Neustart unabhaengig von der Parameterdatei FLEXNET.FPR wieder gesetzt. Achtung: Die Parameterdatei wird nur von FLEXDIGI.EXE verwendet.´Bei der User-Version (ohne FLEXDIGI incl. Zubehoer, s. Kapitel 3.3.) gibt es diese nicht; hier muessen die Einstellungen immer neu mit FSET gesetzt werden.

5. Die Parametrierung bei Flexdigi-Betrieb erfolgt ueber eine Applikation, z. B. TNC.EXE oder das BayCom-Terminal BCT.EXE:
Die gewuenschte Applikation starten, damit den Digi connecten (MYCALL des Digis vor der Konfiguration: 'FLXNET') und im automatisch aktiven Sysop-Modus die Konfiguration (siehe Kapitel 4) in beliebiger Reihenfolge vornehmen.

6. Zusaetzlich sollte bei Digibetrieb ein Sysop-Passwort eingegeben werden (nur einmal noetig), siehe auch Kapitel 4.6.:

a) bei PC/FlexNet bis V3.3e ist das Passwort eine  5-stellige 'Geheimzahl' (0...65535); die Eingabe erfolgt mit dem Utility SYSNUM.EXE. Syntax: SYSNUM <geheimzahl (0..65535)> [<parameterpfad>]

b) bei PC/FlexNet ab V3.3g ist das Passwort ein max. 80 Zeichen langer String, der alle druckbaren Zeichen ausser '"' enthalten darf. Dieser muss in einer gesonderten Passwortdatei abgespeichert werden; die Uebernahme erfolgt dann mit dem Utility FLEXPASS.EXE. Syntax: FLEXPASS <passwort-dateiname>

Erfolgt der Aufruf von SYSNUM bzw. FLEXPASS vor dem ersten Start von FLEXDIGI.EXE, so wird die fehlende Parameterdatei FLEXNET.FPR nach Abfrage (j/n) automatisch angelegt.

Noch einige Hinweise zur Installation:

  * Die Parametrierung wird (nur bei Digibetrieb) einschl. dem Sysop-Passwort automatisch in der Parameterdatei FLEXNET.FPR abgespeichert. Diese wird (nur) von FLEXDIGI.EXE ausgewertet und darf nicht editiert werden! Es empfiehlt sich, eine Sicherheitskopie (Backup) anzulegen, z.B. FLEXNET.BAK. Bei fehlerhafter Eingabe einfach FLEXNET.FPR loeschen und neu beginnen!

  * Die Angabe des Parameterverzeichnisses sowie das Laden der Module und der Applikation (obige Schritte 2. bis 5.) erfolgt sinnvollerweise mit einem Batchfile, z.B. PCFLEX.BAT. Hier ein Beispiel dafuer:

<code>
rem Beispiel-Konfiguration fuer PC/FlexNet-Digi von DF2VO, 07/98
@ECHO OFF
rem Verzeichnis-Pfad fuer Konfigurationsdateien angeben
SET FLEXNET=C:\PCFLEX\PARA
rem ins PC/FlexNet-Verzeichnis wechseln
CD \PCFLEX
rem FlexNet mit 120 kB RAM-Speicher einrichten
LOADHIGH FLEXNET 120
IF ERRORLEVEL 1 GOTO ENDE
rem Kanaltreiber fuer BayCom-USCC-Karte mit 4 Ports laden
LOADHIGH USCC /P=0x300 /I=5 /C=4 /B=40 /T=0
IF ERRORLEVEL 1 GOTO ENDE
rem Kanaltreiber fuer KISS-Schnittstelle laden (default: COM 1)
LOADHIGH KISS
IF ERRORLEVEL 1 GOTO ENDE
rem Digipeater-Modul laden (nur bei Flexdigi-Betrieb, s. Kapitel 3.3.)
LOADHIGH FLEXDIGI
IF ERRORLEVEL 1 GOTO ENDE
rem FlexNet starten
LOADHIGH FLEX
IF ERRORLEVEL 1 GOTO ENDE
rem Konfiguration vorgeben (bei Flexdigi optional, s. Kapitel 3.1.4.)
FSET TX 0 20
FSET TX 1 20
FSET TX 2 12
FSET TX 3 12
FSET MODE 0 1200c
FSET MODE 1 1200c
FSET MODE 2 9600trz
FSET MODE 3 9600trz
rem BayCom-Terminal als Vordergrund-Anwendung starten
BCT DF2VO-8
:ENDE
rem FlexNet aus Speicher entfernen
FLEX /U
</code>

  * PC/FlexNet stellt bis zu 15 Ports (P0 bis incl. P14) fuer externe Verbindungen ueber Hardware-Kanaltreiber zur Verfuegung. Der sog. interne Port P15 ist die 'SHELL' bzw. 'FlexNet-Applikations-Schnittstelle' fuer alle Anwendungen, die gleichzeitig mit PC/FlexNet auf dem PC betrieben werden, z.B. Terminalprogramme wie BCT.EXE oder TNC.EXE, Mailboxen, DX-Cluster, TCP/IP-Programme, Netzconvers usw. Dafuer ist ggf. ein weiterer Treiber noetig, z.B. der Hostmode-Adapter TFEMU.EXE (siehe Kap. 3.2.) oder der Ethernet-Emulator ETHEREMU.EXE (siehe entsprechende Dokumentationen).

  * Um bei Netzknoten (mit FLEXDIGI.EXE) speziell bei Remote-Betrieb eine hohe Betriebssicherheit zu gewaehrleisten, sollte keine weitere Applikation ausser BCT.EXE, SERV.EXE oder einer Mailbox geladen sein.

__**3.2. Gleichzeitiger Betrieb von PC/FlexNet und einer Mailbox**__

Zum gleichzeitigen Betrieb der BayCom-Mailbox und PC/FlexNet auf einem einzigen Rechner wird kein gesonderter Treiber benoetigt. Nach dem Starten des FlexNet-Systems mit FLEX.EXE wird die Mailbox  einfach als Vordergrund-Applikation anstatt des Terminals (z. B. TNC.EXE) gestartet.

Soll dagegen ein Programm fuer WA8DED-Hostmode/TheFirmware (z. B. GP, SP, DieBox, FBB-Mailbox, DX-Cluster) gleichzeitig mit PC/FlexNet auf einem gemeinsamen Rechner betrieben werden, ist der Hostmode-Treiber TFEMU.EXE (C) HB9JNX notwendig. Naehere Informationen finden sich in der  dazugehoerigen Dokumentation TFEMU.DOC.

Hinweise zum gleichzeitigen Betrieb einer Mailbox mit FLEXDIGI.EXE:

  * Beim Installieren einer Mailbox und PC/FlexNet in der Digi-Version auf einem Rechner wird der RAM-Speicher sehr knapp. Damit die Mailbox ueberhaupt genug RAM bekommt, muessen alle Programme und Treiber aus der Konfiguration des Rechners entfernt werden, die nicht unbedingt zum Betrieb benoetigt werden: z.B. der nationale Tastaturtreiber, Maustreiber, CD-ROM-Treiber und evtl. die VGA-Grafikkarte, da die Farbgrafik unnoetig viel RAM belegt. Eine Schwarzweiss-Darstellung mit Herkules-Karte braucht deutlich weniger Speicher und genuegt fuer diesen Zweck vollkommen.

  * Allgemein sollte bei groesseren Netzknoten (ab etwa fuenf Ports) fuer den Digipeater ein eigener Rechner (PC mit PC/FlexNet oder RMNC mit  RMNC/FlexNet) verwendet werden. Die Mailbox wird dabei auf einem getrennten Rechner betrieben (z.B. mit PC/FlexNet in der User-Version, siehe Kap. 3.3.) und ueber einen (Draht-)link an den Digi angebunden.

__**3.3. User-Version von PC/FlexNet statt Digipeater**__

Die meisten Dateien koennen auch fuer die User-Version (ohne FLEXDIGI.EXE und Zubehoer) verwendet werden; dabei arbeitet PC/FlexNet als universeller Modemtreiber fuer die Vordergrund-Applikation(en). In der User-Version ist PC/FlexNet selbst nicht connectbar und hat keine Infobox. Die Applikation(en) wird/werden direkt ueber die externen  Ports angesprochen; die Kupplung ist unsichtbar. Hinweise zur Installation von Applikationen mit PC/FlexNet siehe Kapitel 3.2.

Lediglich FLEXDIGI.EXE und die direkt damit zusammenarbeitenden Programme wie SYSNUM.EXE bzw. FLEXPASS.EXE werden nicht benoetigt; von dieser 'Sysop-help' sind dann nur noch dieses Kapitel 3 sowie Teile des MODE-Befehls (Kapitel 4.2.) gueltig. Die Einstellungen fuer MODE und TXDELAY muessen bei jedem Start mittels FSET.EXE neu gesetzt werden (siehe Kap. 3.1.4. und Beispiel PCFLEX.BAT in Kap. 3.1.).

Zusaetzlich ist in FLEXNET.EXE ab V3.3e ein sog. Multiband-Digipeater integriert, der Digipeating-Betrieb in der Userversion ohne FLEXDIGI ermoeglicht. Zur Aktivierung muss ein Digicall mit FSET.EXE gesetzt werden; siehe auch FLEXNET.DOC. Syntax: FSET DIGI <digicall>. Beispiel: FSET DIGI DF2VO-3.

__**4. Einstellen der Parameter / Konfiguration**__

__**4.1. Parametrierung**__

Nach der Installation muessen folgende Einstellungen fuer Flexdigi-Betrieb vorgenommen werden:

a) eigenes Digipeater-Call incl. SSID-Bereich mit dem Befehl MYCALL (siehe Kapitel 2.2.),

b) ggf. Call der lokalen Mailbox mit dem Befehl MAIL (s. Kapitel 2.2.),

c) Parameter der einzelnen Ports  mit  den  Befehlen MODE (Kapitel 4.2.) und PARMS (TX-Delay, SSIDs und Infobox-Timeout, siehe Kapitel 4.3.),

d) Link-Eintraege mit dem Befehl LINKS (siehe Kapitel 4.4.),

e) Texte mit dem Befehl WRITE oder einem Editor (siehe Kapitel 4.5.).

__**4.2. Der MODE-Befehl**__

Mit dem MODE-Befehl werden die Uebertragungsgeschwindigkeiten und die Portoptionen fuer jeden Port einzeln eingegeben.

Syntax: MODE <port> <[num][opt]>

|num | Uebertragungsgeschwindigkeit in Bit/s (gueltig bei internem Takt). Die moeglichen Einstellungen sind Vielfache von 300 Bit/s; die beiden Nullen koennen weggelassen werden. |
|opt | steht fuer die folgenden Portoptionen (pro Port koennen eine oder mehrere Optionen angegeben werden): 
|"a" | Auto-Link (nur Ethernet !) |
|"c" | treiberabhaengig: erzwingt CRC bei KISS-Link oder aktiviert Software-DCD (z. B. bei 1200-Bit/s-Modem) |
|"d" | vollduplex-Port |
|"m" | DAMA-Modus aktivieren (Port ist Master) |
|"r" | externer, hardwaremaessiger Empfangstakt (z.B. fuer G3RUH-Modem) |
|"s" | Portsynchronisation (fuer mehrere Zugaenge auf einer Frequenz: alle Ports mit "s" sind gegeneinander verriegelt); |
|"t" | externer, hardwaremaessiger Sendetakt (z.B. fuer G3RUH-Modem) |
|"u" | Benutzerzugang (Ueberwachung User-TX-Delay-Rest < 100 ms aktiv; Port wird nie DAMA-Slave; bei DAMA-Port Poll-Ueberwachung aktiv) |
|"y" | Auto-Sysop (immer privilegiert ohne Passwort-Eingabe) |
|"z" | NRZ-Kodierung (z. B. fuer DF9IC-Modem) |
|"-" | Port ganz abschalten (die Funktion ist treiberabhaengig) |
|neu ab FlexNet V3.3g: |  |
|"p" | vollduplex-Port mit quasi Dauer-PTT (Haltezeit: 1 Min.): spart das TX-Delay bei Folgepaketen und entlastet  den Empfaenger von Rauschen. Im Modem evtl. Hardware-Watchdog deaktivieren! |

Beispiele:

1. MO 2 1200cmu (1200-Bit/s-Benutzerzugang mit seriellem BayCom-Modem und DAMA-Modus auf Port 2)\\ 
2. MO 3 96dtrz  (9600-Bit/s-Vollduplexlink mit FSK-Modem nach DF9IC auf Port 3)\\ 
3. MO 4 yc      (aktiviert Auto-Sysop und CRC auf dem KISS-Link Port 4)\\ 
4. MO 5 -       (schaltet den Port 5 ganz ab; funktioniert nicht mit jedem Treiber)\\ 

Noch einige Hinweise zu den Einstellungen:

  * Die Angabe der Uebertragungsgeschwindigkeit ist nur bei internem Takt gueltig; bei Modems mit extern erzeugtem Hardwaretakt (Option "r" bzw. "t") ist die Einstellung ohne Wirkung. Sie muss trotzdem korrekt gesetzt werden, da sie die Haeufigkeit der Laufzeitmessungen bestimmt.

  * Die genaue Wirkung der Optionen ist vom verwendeten Treiber abhaengig; gleichlautende Optionen koennen bei verschiedenen Treibern unterschiedliche Bedeutungen haben. Nicht jede Option funktioniert mit jedem Treiber.

__**4.3. Der PARMS-Befehl**__

Der PARMS-Befehl dient zum Einstellen der TX-Delays und SSIDs auf den einzelnen Ports sowie des Infobox-Timeouts.

Syntax: PARMS <T|S|I> <wert> [port]

a) Einstellen des TX-Delay auf Port <port>:

|Syntax:       |P T <txdelay> <port> |
|Wertebereich: |0...255 [10-msec-Schritte] |
|Beispiel:     |P T 10 2  (stellt ein TX-Delay = 100 ms auf Port 2 ein) |

b) Setzen einer SSID auf Port <port>:

|Syntax:       |P S <ssid> <port<nowiki>|</nowiki>16> |
|Wertebereich: |innerhalb des mit MYCALL eingestellten SSID-Bereichs |
|Beispiel:     |P S 7 3  (setzt die SSID 7 auf den Port 3) |

Eine gesetzte SSID wird geloescht, indem sie auf den (nicht existierenden) Port 16 gesetzt wird: P S <ssid> 16

SSID's haben folgenden Sinn: Nur Ports mit gesetzter SSID koennen von jedem connectet werden, daher ist fuer Userports und Anbindungen ohne FlexNet-Routing bzw. -Gateway eine SSID notwendig. Bei Digis mit mehreren Userports benoetigt jeder Userport eine eigene SSID, z.B. fuer den 70-cm-Zugang '-0' und den 23-cm-Zugang '-2'. Das Auswaehlen der Userports erfolgt mit dem Connect-Befehl, z.B. schaltet "C -2" zum Userport mit der SSID 2. Man kann aber auch direkt auf diesem Port connecten mit "C <call> <digicall>-2".

Exklusive Interlink-Ports sollten dagegen keine SSID haben (Ausnahme: Linkpartner ohne FlexNet-Routing oder -Gateway, z.B. reine TheNet/NetRom-Partner, Mailboxen, DX-Cluster, TCP/IP-Applikationen usw.).

c) Einstellen des Infobox-Timeout:

|Syntax:       |P I <min<nowiki>|</nowiki>0> |
|Wertebereich: |60...255 [min] |
|Beispiel:     |P I 90  (stellt das Infobox-Timeout auf 90 Minuten ein) |

Das Infobox-Timeout wird in Minuten angegeben, wobei 0 Minuten kein Timeout bedeutet. Empfaengt der Digi innerhalb dieser Zeit keine Information vom  Benutzer, disconnectet er die Verbindung. Dies gilt nur fuer Verbindungen mit dem Digi selbst ('Infobox') und nicht fuer solche ueber den Digi.

__**4.4. Der LINKS-Befehl**__ (Linkeintraege)

Die Festlegung der Linkpartner erfolgt durch Eintraege mit dem LINKS-Befehl. Dabei koennen auch SSIDs mit angegeben  werden. Maximal koennen 20 Links eingetragen werden.

Syntax: LINKS <port|link> <call> [Option]

Die Linkoptionen bedeuten im Einzelnen:

a) einfache Links ohne Streckentest:

|"$" | kein Streckentest |
|"#" | kein Streckentest; Linkeintrag unsichtbar fuer normale  Benutzer; (z. B. zur Anbindung eines Service-Terminals) |

b) Links mit Streckentest:

|" " | ohne Option: normaler Streckentest und Weiterleitung/Austausch der Routinginformationen (Standardeintrag) |
|"@" | einfacher Test zur Laufzeitmessung fuer Anbindung von Nachbarn ohne FlexNet-Routingprotokoll (z.B. TheNet-Partner, Mailboxen) mit Weiterleitung des Linkpartners |
|"-" | der Linkpartner selbst wird lokal gehalten und nicht weitergeleitet, die Ziele des dahinterliegenden Subnetzes (Nachbarn) werden jedoch weitergeleitet (z. B. fuer Testanbindungen) |
|">" | der Linkpartner und die Ziele des dahinterliegenden Subnetzes werden nicht weitergeleitet (z.B. fuer interne Hausnetze) |
|"!" | der Linkpartner selber wird weitergeleitet, nicht jedoch die Ziele des dahinterliegenden Subnetzes |
|")" | der Nachbar bildet Subnetz; Linkeintrag unsichtbar fuer normale Benutzer (= Kombination aus ">" und "#") |

Linkpartner ohne Optionen und Linkpartner mit den Optionen "!" und "@" werden, wenn aktiv, in die Destinationstabelle (siehe Kapitel 2.1.) des FlexNet-Routers aufgenommen und an andere Digis weitergemeldet.

Beispiele:

1. L 2 db0dig      (setzt den FlexNet-Linkpartner DB0DIG auf Port 2)\\ 
2. L 6 df2vo-7 #   (setzt den unsichtbaren Testlink DF2VO-7 auf Port 6)\\ 
3. L 15 db0hom-9 ) (setzt die unsichtbare S&F-SSID '-9' fuer die Mailbox DB0HOM auf Port 15)\\ 
4. L db0dig db0psc (setzt den Link DB0PSC via den bereits eingetragenen Link DB0DIG)\\ 

Soll eine Mailbox (o.ae.) unter dem gleichen Call wie der Digi betrieben werden, bietet FlexNet eine besondere Moeglichkeit: Die Mailbox wird innerhalb des SSID-Bereichs des Digis als Link mit SSID und der Option "@" (mit Streckentest) eingetragen. Beispiel: Digicall DB0HOM; SSID-Bereich 0-10; Boxcall DB0HOM-8. Die Box kann von aussen (auch vom Userport!) direkt mit "C DB0HOM-8" ohne Angabe 'via DB0HOM' connectet werden.

Noch einige Hinweise zu Linkeintraegen unter dem Digicall:

  * Eine so eingetragene Box taucht nicht als eigenstaendige Station im Routing (Destinationstabelle) anderer Digis auf.
  * Sie kann von aussen quasi direkt mit ihrem Call incl. SSID (oder ohne SSID wenn SSID = 0) connectet werden; der Digi braucht nicht mit "via" angegeben zu werden.
  * Ist die Box (oder der Link) ausgefallen, wird man beim Connect automatisch mit der Infobox des Digis verbunden.

__**4.5. Eingabe der Texte A, B, C, H, I, L und S**__

Beim FlexNet-Digi sind die folgenden 7 Textfiles vom SysOp zu erstellen:

|A - Aktuell-Text:   |aktuelle Informationen ueber den Digi |
|B - Beacons-Text:   |Definition der Baken (Texte, Pfade, Zeitabstaende) |
|C - C(onnect)-Text: |Begruessungstext (Ausgabe beim Connect des Digis) |
|H - Help-Text:      |Anleitung/Befehlsuebersicht fuer den Digi |
|I - Info-Text:      |Informationen ueber den Digi (Stationsbeschreibung) |
|L - Local-Text:     |Lokaler C-Text (Erweiterung des C-Textes; Ausgabe nur bei direktem Connect ohne Zwischendigi) |
|S - Setsearch-Text: |Suchpfade (Rufzeichen) fuer den FIND-Befehl |

Bei PC/FlexNet werden diese Textfiles auf Festplatte im FlexNet- oder einem spezifizierten anderen Verzeichnis (siehe Kapitel 3.1.) unter dem jeweiligen Filenamen '<textbuchstabe>.FPR' abgespeichert. Bei RMNC/FlexNet erfolgt die Speicherung natuerlich nur im RAM. Die Texte koennen nach Connect des Digis online im Sysop-Modus mit dem Befehl "WRITE <textbuchstabe>" eingegeben werden. Bei PC/FlexNet koennen sie auch mit einem beliebigen Texteditor erstellt und direkt unter dem jeweiligen Filenamen abgespeichert werden.

a) Die Textfiles A.FPR, C.FPR, H.FPR, I.FPR und L.FPR:

Diese Files koennen beliebigen Text enthalten; es gibt keine speziellen Vorschriften fuer den Aufbau. Allerdings sollte am Anfang jedes  Files (ausser beim C-Text C.FPR) eine Leerzeile (bzw. ein CarriageReturn) stehen, damit die Texte bei der Ausgabe immer am Anfang einer neuen Zeile beginnen. Fuer den Help-Text H.FPR kann die Befehlsuebersicht (Kapitel 2.1.) mit einem Texteditor ausgeschnitten und direkt als Help-File verwendet werden (fuer PC/FlexNet-Digi die Zeile mit dem IO-Befehl loeschen !).

b) Das Bakenfile B.FPR:

Beim BEACONS-File gelten besondere Vorschriften fuer den Aufbau des Textes. Es koennen beliebige Baken auf allen Links programmiert werden. Jeder Bakeneintrag in einem solchen File hat folgende Struktur:

<min> <port> <tocall [via <call> [<call>...]]> : <text> #

|     "#"      |trennt verschiedene Bakeninformationen; |
|     <min>    |ist die Zeit in Minuten zwischen zwei Bakenaussendungen (Wertebereich: 1...255 [min]; 0 bedeutet keine Bake); |
|     <port>   |ist der Port, auf dem die Bake abgestrahlt werden soll; |
|     <tocall> |ist das Zielrufzeichen der Bake, hier koennen beliebige Calls stehen, z.B. "BAKE", "RMNC","FLXNET","TEST" oder aehnliches; |
|     "via"    |mit "via" koennen bis zu 8 Digipeater angegeben werden, ueber die die Bake laufen soll. |

Beispiel:

#10 0 FLEX:Digi Homburg - JN39PJ - Homburg/Hoecherberg - R 61\\ 
#30 1 FLEX DB0DIG DB0HOM:Interlink DB0HOM-DB0DIG QRV\\ 
#5  0 FLXNET:Testbake....\\ 

Das File besteht im Beispiel aus 3 Baken, die jeweils mit "#" getrennt sind (bake1...#...bake2...#...bake3).

  * Das Wort "via" in der Digipeaterliste kann ersatzlos entfallen um Speicherplatz oder Tipparbeit (hi) zu sparen.
  * Zwischen den einzelnen Angaben koennen, wie im Beispiel, auch CRs (CarriageReturns) stehen, um das File besser lesbar zu machen.
  * Sinnvoll ist, die "#" wie im Beispiel jeweils an den Zeilenanfang zu setzen, damit die Baken alle ein CR am Ende haben.
  * Gross- und Kleinschreibung spielt bei den Rufzeichen keine Rolle, es kann beides verwendet werden.
  * Das Absenderrufzeichen einer Bake ist immer das eingestellte MYCALL des Digipeaters mit der niedrigsten SSID.
  * Ohne Eingabe eines Bakenfiles sendet der PC/FlexNet-Digi ueberhaupt keine Baken aus. (Im Unterschied dazu sendet ein RMNC/FlexNet-Digi alle 3 Minuten eine Default-Bake auf dem Userport mit SSID 0 aus!)

c) Das Setsearchfile S.FPR:

Auch beim SETSEARCH-File gelten besondere Vorschriften fuer den Aufbau des Textes. Es koennen beliebig viele Suchbefehle abgestrahlt werden. Die Anzahl der via-Digipeater ist auf 7 begrenzt. Die Struktur eines solchen Files ist:

<call1>
<call1> [via <call2> [<call3> [<call4> [<call5>]]]]

Beispiel einer Setsearchdatei: Suchpfade fuer FIND-Befehl

DB0HOM\\   
DB0HOM-2\\ 
DB0DIG via DB0HOM\\ 
DB0ZDF via DB0ODW\\ 

In der ersten Zeile steht, dass der Suchbefehl ueber den eigenen Digi (Userport mit SSID 0) abgestrahlt wird. Die zweite Zeile bewirkt, dass der Suchbefehl auch ueber den Port mit der SSID -2 (hier zweiter Userport) abgestrahlt wird. Die dritte Zeile zeigt, wie ein Suchpfad zum Nachbardigi DB0DIG eingetragen wird. Genauso koennen auch zu nicht direkt erreichbaren Digis Suchpfade eingegeben werden; DB0ZDF ist im obigen Beispiel von DB0HOM aus ueber den FlexNet-Autorouter zu erreichen.

  * Das MYCALL des Digis kann einfach mit "-" abgekuerzt werden; vor dem Strich muss immer ein Leerzeichen stehen. Dies geht uebrigens bei allen Befehlen an den Digi. Vor allem beim RMNC, wo die Texte im knappen RAM gespeichert werden, ist das sinnvoll. So bleibt mehr Speicherplatz fuer den Aktuell- und Info-Text. Dazu kann auch wie beim Bakenfile das Wort "via" in der Digiliste entfallen.

  * Soll auf Kanaelen mit SSID gesucht werden, sind diese als gesonderte Eintraege anzugeben (wie 'DB0HOM-2' bzw. '-2' in den Beispielen).

Beispiel fuer die Kurzform: Suchpfade fuer FIND-Befehl

-\\ 
-2\\ 
DB0DIG -\\ 
DB0ZDF -\\ 

Bei Digis mit zwei Einstiegen (z.B. oben DB0HOM und DB0HOM-2) gibt es mit dieser Art der Setsearchliste Probleme mit Stationen, die bereits in der MH-Liste des Digis stehen. In diesem Falle hat bekanntlich das Routing nach MH-Liste Vorrang vor dem Routing nach SSID. Dadurch werden beide Such-Frames auf dem (gleichen) Port ausgesendet, auf dem die Station zuletzt gehoert wurde. Soll jedoch immer auf beiden Ports gesucht werden, um z.B. auch Stationen mit haeufigem Portwechsel durch den Suchbefehl zu erfassen, muss zwangsweise auf beiden Ports gesucht werden. Dazu wird einfach die Portnummer wie ein Rufzeichen beim via-Connect mit angegeben.

Mit Port 6 fuer SSID 0 und Port 4 fuer SSID 2 sieht das im Bsp. so aus:

6 -\\ 
4 -2\\ 
DB0DIG -\\ 
DB0ZDF -\\ 

Nun hat auch DB0DIG zwei Einstiege, und auch hier soll auf beiden gesucht werden. Der 1k2-Einstieg auf Port 15 (bei einem RMNC-Digi ist P15 keine SHELL, sondern ein normaler Port) hat die SSID 0 und der 9k6-Einstieg auf Port 14 die SSID 7. Da die Reihenfolge der Eingabe bei der Setsearchliste nicht ganz der Reihenfolge der Rufzeichenkette beim via-Connect entspricht, muss man bei der Eingabe genau aufpassen. Die Portnummern werden wie Rufzeichen beim via-Connect behandelt, und als erstes 'Rufzeichen' muss das Ziel, also die Portnummer bei DB0DIG, stehen. Dann der Startdigi, also der eigene Digi, und danach erst der naechste Digi auf dem Weg.

Konkretes Beispiel dafuer:

6 -\\ 
4 -2\\ 
15 - DB0DIG\\ 
14 - DB0DIG-7\\ 
DB0ZDF -\\ 

Da die Portnummern und der zugehoerige Digi so weit auseinandergezogen sind, sieht das Ganze etwas verworren aus, funktioniert aber ufb!

d) Die MH-Liste MH.FPR:

Die MH-Liste wird nicht von Hand eingegeben, sondern von Flexdigi automatisch alle 10 Minuten in das File MH.FPR geschrieben. Dieses File darf nicht mit einem Texteditor editiert werden! Wenn MH.FPR fehlt, legt der Digi das File  selbsttaetig an; darum braucht sich der Sysop nicht zu kuemmern.

__**4.6. Sysop-Authentisierung**__

Das Umschalten in den Sysop-Modus (Aktivieren der Sysop-Befehle) erfolgt mit dem Befehl "SY"; bei neueren Versionen alternativ auch mit "PW":

a) bei PC/FlexNet bis V3.3e und RMNC/FlexNet bis V3.3g:

Nach Eingabe von "SY" liefert der Digi eine 5-stellige Zufallszahl. Diese muss mit einer Zahl beantwortet werden, die wie folgt berechnet wird: Die ausgegebene Zahl wird stellenweise mit der Sysop-Geheimzahl (siehe Kapitel 3.1.6.a) multipliziert und anschliessend die Summe der Produkte gebildet. Diese Zahl ist die Antwort.

Beispiel: SY liefert die Zufallszahl 24531. Mit der Sysop-Geheimzahl 12345 lautet die Berechnung:

1. Multiplizieren der einzelnen Stellen:\\ 
2 4 5 3 1   <- Zufallszahl\\ 
1 2 3 4 5   <- Geheimzahl\\ 

2*1 = 2; 4*2 = 8; 5*3 = 15; 3*4 = 12; 1*5 = 5\\ 

2. Aufsummieren der Produkte:

2 + 8 + 15 + 12 + 5 = 42  <- fertig! 42 ist die Antwort.

b) bei PC/FlexNet ab V3.3g und RMNC/FlexNet ab V3.3h:

Nach Eingabe von "PW" (alternativ zu "PW" kann weiter "SY" verwendet werden) antwortet der Digi mit fuenf zufaelligen Zahlen. Diese geben die Positionen der zur Authentisierung einzugebenden Zeichen im Passwortstring (siehe Kapitel 3.1.6.b) an. Als Antwort muss eine Zeichenkette gesendet werden, die an beliebiger Position die entsprechenden Zeichen des Passwortstrings enthaelt. Dieses Verfahren ist auch von TheNet/NetRom-Digis her bekannt.

Beispiel: PW liefert die Ausgabe: DB0HOM> 29 16 3 42 8

Mit dem Passwortstring (hier im Bsp. kuerzer als 80 Zeichen):
<code>
lgtB517R6MvapKREGoK8Tpr1CsJo4Pb8c996EBxVhijZWZGPjdB7VoR4p0
  |    |       |            |            |
  3=t  8=R    16=E         29=4         42=i
</code>
lauten die Zeichen fuer die Antwort: 4EtiR

Diese koennen zur Verschleierung in einen beliebigen anderen String eingefuegt werden, der dann als Antwort gegeben wird, z. B.: ltuzE58vmv__4EtiR__78nfiv4vGfh

Noch einige Hinweise zur Sysop-Authentisierung:

  * Um Mitlesern das Ermitteln des Passworts zu erschweren, kann der SY/PW-Befehl mehrfach gesendet werden. Die Antwort muss nur einmal richtig sein (Achtung bei Terminals mit automatischer Passwortfunktion!).
  * Es erfolgt keine Rueckmeldung ueber Erfolg oder Misserfolg. Das Testen, ob die Antwort richtig war, kann mit einem harmlosen Sysop-Befehl wie P I (Timeout) oder L (Anzeige auch verdeckter Links) geschehen.
  * Im Sysop-Modus ist das Infobox-Timeout deaktiviert; ein Sysop kann beliebig lange mit dem Digi verbunden bleiben.
  * Die Sysop-Berechtigung bleibt bis zu einem Disconnect,  Reconnect (link reset) oder einem Connect-Befehl bestehen.
  * Zur gleichen Zeit koennen mehrere Sysops eingeloggt sein.

__**4.7. Hinweise zum TRACE-Befehl**__

Zur gleichen Zeit ist immer nur ein Trace moeglich. Ist (oder war) schon´eine Applikation (Terminal usw.) ueber P15 am gleichen Rechner mit eingeschalteter Monitor- bzw. Trace-Funktion aktiv, so ist der Sysop-Befehl TRACE von PC/FlexNet nicht nutzbar. Dieser wird von der Applikation abgeschaltet, wenn deren eigener Monitor-/Tracemodus aktiv ist. Zu erkennen ist der abgeschaltete TRACE von PC/FlexNet daran, dass beim Eingeben von TRACE im Sysop-Modus direkt der Prompt '=>' zurueckkommt. Um den FlexNet-Trace wieder freizugeben, muss die Monitor-/Tracefunktion der Applikation abgeschaltet werden. Zum Beispiel beim BayCom-Terminal BCT.EXE mit ":MONITOR OFF" oder ":TRACE OFF",  bzw. bei Programmen, die den TFEMU-Treiber nutzen, mit "ESC M N" oder aehnlich. Ein in PC/FlexNet abgeschalteter  TRACE-Befehl wird nicht automatisch wieder aktiviert, wenn die Applikation mit eingeschaltetem Monitor entladen wird und FlexNet weiterlaeuft. Vielmehr muss die Monitorfunktion vor dem Entladen abgeschaltet oder PC/FlexNet neu  gestartet werden, damit TRACE von FlexNet wieder freigegeben wird.

__**5. Anhang**__

__**5.1. Erklaerung der Ausgaben einzelner Befehle**__

a) Bakentexte beim BEACONS-Befehl (vgl. Kapitel 4.5.):

<code>
 #10 4 FLXNET:Digipeater Homburg QRV auf R61 in JN39PJ
  |  |   |     |
  |  |   |     +-- Bakentext
  |  |   +-------- Zielcall, z. B. "BAKE", "TEST", "FLXNET",...
  |  +------------ Portnummer, auf der die Bake ausgesendet wird
  |                z. B. hier Port 4 (ein Userport)
  +--------------- Zeit zwischen den Bakenaussendungen in Minuten
</code>

b) Laufzeitangaben beim LINKS- bzw. PARMS-Befehl:

Die Ziffern sind die Laufzeiten (= Antwortzeiten) in 1/10 sec.

|      4/5  | zwei Zahlen: Normalfall, der Linkpartner ist ein FlexNet-Digi oder FlexNet-kompatibel. Die erste  Zahl ist die vom Digi selbst gemessene Laufzeit (in TX-Richtung), die zweite  Zahl die vom Linkpartner gemessene und mitgeteilte (RX-Richtung). |
|    (12/9) | zwei Zahlen in Klammern: der Digi kennt z.Zt. einen besseren Weg zum Partner, d.h. der direkte Link wird nicht benutzt. |
|       3   | eine Zahl: der Partner beherrscht nicht das FlexNet-Protokoll (z.B. ein reiner NetRom-Node oder eine  Mailbox) oder ein  FlexNet-QSO in der Initialisierungsphase (nach einem Start). |
|     (95)  | eine Zahl in Klammern: der Digi kennt z.Zt. einen besseren Weg zum Partner, d.h. der direkte Link wird nicht benutzt. |
|     "   " | keine Zahl: es wird kein Test von Link/Laufzeit vorgenommen. |
|      <nowiki>---</nowiki>  | drei Striche: der Link steht nicht zur Verfuegung, und der Partner ist auch nicht ueber anderen Weg erreichbar (defekt ?) |
|     (<nowiki>---</nowiki>) | drei Striche in Klammern: der Link steht nicht zur Verfuegung, aber der Partner ist ueber anderen bekannten Weg erreichbar. |

c) connectete User beim CONVERS-Befehl:

<code>
users:
 42: DF4IAE   42: DL4VCK   76: DG9TM   76: DL4VCN   ---: DF3VI
channel?
</code>

DF4IAE und DL4VCK sind im Conversmodus auf Kanal 42 aktiv; DG9TM und DL4VCN auf Kanal 76. DF3VI ist nicht im Convers, aber in der Infobox des Digis eingeloggt und kann mit dem TALK-Befehl angesprochen werden (z.B. Einladung zum Convers: /T DF3VI Hallo, wir sind auf Kanal 42!).

d) Ziele beim DESTINATIONS-Befehl:

<code>
  DB0CZ   0-15   33   DB0DA   0-15   23   DB0DAM  0-7   189   DB0DAR
    |      |     |
    |      |     +-- Laufzeit in 1/10 sec. (Beispiel: 33 = 3,3 sec.)
    |      +-------- SSID-Bereich des Ziel-Digipeaters
    +--------------- Call des Ziel-Digipeaters / Mailbox / ...
</code>

   * Ausgabe bei "D <call>": Ist <call> ein gueltiges Zielcall aus der Destinationsliste, so werden die Gesamtlaufzeit zu <call> und die Route ausgegeben. Zur Ermittlung der Route wird ein Paket zum Zielcall geschickt, wobei sich jeder Zwischendigi in den Pfad einfuegt. Dabei werden Digipeater mit FlexNet-Routing in Grossschrift  vermerkt; L2-Digipeater ohne FlexNet-Routing (z.B. TheNet) in Kleinschrift. Die Ausgabe '???' bedeutet, dass der Link abgerissen ist und die Route neu ermittelt wird. Ein Connect-Befehl ist dann meistens erfolglos.

Beispiel: Bei DB0HOM liefert die Eingabe "D DB0ZDF" diese Ausgabe:

<code>
*** DB0ZDF (0-12) T=22
*** route: DB0HOM DB0AAC DB0AAI DB0ZDF
</code>

   * Ausgabe bei der Option "D <call> >": Folgt einem gueltigen Zielcall ein ">", so werden die Laufzeiten zwischen den einzelnen Digis ermittelt und mit ausgegeben. Damit kann herausgefunden werden, wo es genau hakt. Allerdings erzeugt diese Option viel Betrieb auf den Links und sollte daher sparsam eingesetzt werden.

Beispiel: Bei DB0HOM liefert die Eingabe "D DB0ZDF >" diese Ausgabe:

<code>
*** DB0ZDF (0-12) T=22
*** route: DB0HOM (8) DB0AAC DB0ZDF
*** route: DB0HOM DB0AAC (3) DB0AAI DB0ZDF
*** route: DB0HOM DB0AAC DB0AAI (6) DB0ZDF
</code>

Die Gesamtlaufzeit ist ungleich der Summe der Einzellaufzeiten, da jede einzelne Linklaufzeit mit einem  Gewichtungsfaktor zur Gesamtlaufzeit addiert wird. Dies erlaubt, die Anzahl der einzelnen Links mit in die Beurteilung der Route eingehen zu lassen.

   * Ausgabe bei der Option "D <call> *": Damit erfolgt zusaetzlich die Ausgabe der zu den Linkpartnern  weitergemeldeten Laufzeiten. Eine positive Laufzeit bedeutet, dass die Route vom eigenen Digi wegfuehrt und somit als Weg in Frage kommt. Bei mehreren positiven Laufzeiten befindet man sich an einem Verzweigungspunkt, und es wird der Weg mit der kuerzeren Laufzeit gewaehlt. Negative Laufzeiten bedeuten, dass die Routen zum Ziel 'rueckwaerts' auf den eigenen Digi gerichtet sind. Und zwar vom Partner aus gesehen mit der bereits gewichteten Laufzeit. Negative Laufzeiten werden den Partnern nicht weitergemeldet. Ist ein versteckter Link mit Internode-QSO eingetragen, so kann er mit diesem Befehl aufgespuert werden.

Beispiel: Bei DB0AAC liefert die Eingabe "D DB0ZDF *" diese Ausgabe:

<code>
*** DB0ZDF (0-12) T=28:
    DB0AAI       28
    DB0GE       -50
    DB0HOM      -38
    DB0DAR       37
</code>

Das bedeutet, die Route zu DB0ZDF wird ueber DB0AAI mit der Laufzeit 28 gewaehlt. DB0DAR kennt ebenfalls eine  Route zu DB0ZDF, die von DB0AAC wegfuehrt. Diese wird aber nicht genommen, da sie mit der Laufzeit 37 schlechter ist als die ueber DB0AAI. DB0GE wird die Laufzeit zu DB0ZDF mit 50 bewerten; von DB0HOM aus betraegt die Laufzeit 38. In beiden Faellen fuehrt der Weg ueber DB0AAC.

e) Statistik beim PARMS-Befehl:

1. Zeile (nur bei "P *"):
|r:2        | Anzahl der Restarts seit dem letzten Kaltstart bzw. seit Einschalten der Stromversorgung (nur RMNC !) |
|d:544      | Anzahl gespeicherter Routing-Ziele in Destinationsliste |
|v:1        | Software-Revision (kleine Updates innerhalb Versionsnr.) |
|t:12d,14h  | Laufzeit (uptime) seit dem letzten Start bzw. Reset |
|po         | Portnummer (entspricht der Kartenadresse beim RMNC) |
|id         | Port-SSID: Mit eingetragener SSID kann jede Station auf diesem Port connecten, ansonsten nur eingetragene Linkpartner mit FlexNet-Routing oder -Gateway (siehe Kap. 4.3.b). |
|td         | eingestelltes TX-Delay in 10-ms-Einheiten. |
|qso        | Anzahl der QSOs, die gerade auf dem Port laufen. QSOs ueber den Digi werden doppelt gezaehlt, da Hin- und Rueckwege getrennt in den Userlisten aufgefuehrt sind. |
|usr        | Anzahl gehoerter Stationen auf diesem Port (seit 3 Minuten). |
|tifr       | gesendete Datenpakete (I-Frames) im letzten 10-Min.-Intervall |
|rifr       | empfangene Datenpakete (I-Frames) im letzten 10-Min.-Intervall |
|tkby       | gesendete Kilobytes im letzten 10-Minuten-Intervall |
|rkby       | empfangene Kilobytes im letzten 10-Minuten-Intervall Fehlen diese Angaben und existiert trotzdem ein  Linkeintrag, so ist der Port hardwaremaessig nicht aktiv (bei PC/FlexNet kein Kanaltreiber bzw. bei RMNC/FlexNet keine Kanalrechnerkarte da) |
|qty        | Qualitaet des Kanals in % (wird alle 10 Minuten aktualisiert): Anzahl der beim ersten Versuch bestaetigten I-Frames bezogen auf die Anzahl aller gesendeten I-Frames in Prozent. Eine qty von 100% ohne erkennbare Datenuebertragung bedeutet, dass der Link gerade nicht laeuft, aber einmal funktioniert hat. Steht alles auf 0, ist zwar der Treiber/die Karte installiert, aber der Link hat nie funktioniert seit dem letzten Start. |

Spalten 'mode','links','ssids','time': siehe MODE- bzw. LINKS-Befehl!

evtl. Zusaetze bei der 'mode'-Angabe:
|     "<nowiki>---</nowiki>"  |Port abgeschaltet, aber hardwaremaessig aktiv (Treiber/Karte da) |
|     "+"    |Kanalrechnerkarte mit 8 MHz Taktfrequenz (nur RMNC !) |
|     "!"    |Kanalrechnerkarte mit 12 MHz Taktfrequenz (nur RMNC !) |
|     "#"    |Kanalrechnerkarte mit 16 MHz Taktfrequenz (nur RMNC !) |
|            |(sonst:Kanalrechnerkarte mit 4 MHz Taktfrequenz (nur RMNC !)) |

f) Fehlerstatistik beim STAT-Befehl:

1. Zeile:
|uptime   | Laufzeit seit dem letzten Start bzw. Reset |
|total    | fuer FlexNet reservierter Speicher (Parameter beim Starten) |
|max      | seit dem Start maximal von FlexNet benutzter Speicher in kB |
|used     | momentan von FlexNet benutzter Speicher in kB (von 'total') |
|po       | Portnummer |
|device   | Name des (Hardware-)Kanaltreibers (SHELL ist FLEXNET.EXE) |
|version  | Versionsnummer des (Hardware-)Kanaltreibers |
|txframes | Anzahl gesendeter Frames seit dem letzten Start / Reset |
|rxframes | Anzahl empfangener Frames seit dem letzten Start / Reset |
|rerr     | receive errors: Anzahl NICHT CRC-bedingter Empfangsfehler (z.B. erzeugt Empfangsrauschen staendig CRC-Fehler) auf HDLC-Ebene. Alle Frames, bei deren Empfang auf HDLC-Ebene etwas schiefgegangen ist, z.B. RX-Overruns. Starkes Auftreten von rerr's ist meist ein Hinweis auf einen zu langsamen Rechner. |
|terr     | transmit errors: Anzahl Sendefehler. NICHT: Anzahl fehlerhaft gesendeter Frames! Summe der Frames, bei denen beim Senden ein Fehler aufgetreten ist, so dass das Frame mit einem HDLC-Abort abgebrochen werden musste, z.B. TX-Underruns. Auch haeufig auftretende terr's deuten auf einen zu langsamen Rechner hin. |
|rberr    | receive buffer errors: Anzahl aufgrund von Speicherknappheit im Treiber verworfener Frames. Treten auf, wenn ein Frame auf HDLC-Ebene korrekt empfangen wurde, der Treiber aber keinen Platz hatte, die Daten zu speichern. Sollten auf Funkstrecken selten sein. Beim USCC-Treiber aber bedeuten sie in der Regel, dass die Bufferzahl beim  Start des Treibers zu klein gewaehlt wurde. |
|ioerr    | in and output errors: Hier werden alle I/O-Fehler gezaehlt. Werden dann angezeigt, wenn die Hardware Probleme macht. Bei intakter Hardware sollte hier selten etwas angezeigt werden. |

g) Ausgaben beim USERS-Befehl:

<code>
     1537: S7  U2  P4 : DB0HOM>DL8FQ
      947: S3  U1  P6 : DB0HOM>DL4VCN

      862: S5      P6 : DB0HOM>DF3VI
     1067: S13 U7  P3 : DB0PSC-8>DB0HOM-8 v DB0HOM*
      770: S5      P2 : DF3VI>DB0AAC v DB0HOM*   <-- DF3VI ist ueber DB0HOM
       |   |   |   |    |                            mit DB0AAC verbunden.
       |   |   |   |    +-- Calls und Digipeaterpfad
       |   |   |   +------- Portnummer (Hardwarekanal)
       |   |   +----------- Anzahl unbestaetigter, noch zu sendender Pakete
       |   +--------------- QSO-Zustand ('Layer-2-State', s. u.)
       +------------------- interne Verwaltungsnummer des QSOs (fuer KILL)
</code>

Die Leerzeile zwischen den QSO-Nummern 947 und 862 steht als Trennung fuer die Stationen, die nur mit der Infobox des Digis connected sind (oben, entspricht der Option "=") und Stationen, die ueber den Digi weiterverbunden sind (unten).

Die QSO-Zustaende (Layer-2-States) bedeuten in Kurzform (zur genauen Erklaerung der einzelnen Zustaende sei auf  die  AX.25 Version 2 Protokoll-Spezifikation verwiesen):

^State ^ Bezeichnung ^
|1     | Disconnected - keine Verbindung; Ausgangszustand |
|2     | Link Setup - Verbindung wird gerade aufgebaut |
|3     | Frame Reject - Protokollfehler; fuehrt zum Abbruch der Verb. |
|4     | Disconnect Request - Verbindung wird gerade getrennt |
|5     | Information Transfer - laufende Verbindung, Datenaustausch |
|6     | REJ Frame sent - Empfangsfehler, Paket nochmals anfordern |
|7     | Waiting Acknowledge - Abfrage, ob Verbindung noch steht |
|      | Diese States werden ggf. um folgende Werte erhoeht: |
|8     | Device Busy - die Station ist busy, d.h. sie kann kein Paket mehr empfangen (RNR-Zustand) |
|16    | Remote Device Busy - die Gegenstation (der User) ist busy |
|24    | Both Devices Busy - beide Stationen sind busy |

Mit diesen Kombinationen sind States bis einschliesslich 31 moeglich.

  * erweiterte Ausgaben bei "U *":

<code>
     1537: S7  U2   F32  M5 P4 : DB0HOM>DL8FQ
      947: S3  U1   F82  M1 P6 : DB0HOM>DL4VCN

      862: S5       F21  M4 P6 : DB0HOM>DF3VI
     1067: S13 U7 ! F41  M6 P3 : DB0PSC-8>DB0HOM-8 v DB0HOM*
      770: S5     ! F26  M7 P2 : DF3VI>DB0AAC v DB0HOM*
                  | |    |
     +------------+ |    +-- Maxframe : Anzahl der maximal nacheinander
     | +------------+                   gesendeten Daten-Pakete
     | |
     | Frack: Wartezeit fuer Wiederholungen in 1/10 sec. Der Digi bestimmt
     |        die Zeit, die eine Station durchschnittlich bis zur Bestaeti-
     |        gung eines Pakets braucht und benutzt diesen Wert selbst als
     |        Wartezeit.
     +- "!" : Verbindung mit 'Headerkompression' zwischen FlexNet-Partnern:
              Zwischen zwei FlexNet-Partnern werden Pakete mit komprimier-
              ten Headern ausgetauscht. Diese enthalten nur noch die Calls
              der Partner auf dem Link sowie die Verwaltungsnummern der
              QSOs, um Uebertragungs- und Rechenzeit zu sparen.
</code>

Bei einem DAMA-Einstieg steht an Stelle des Frack-Wertes ein 'Level'. Stationen mit Level 12 (max.) werden in jeder Runde gepollt. Je niedriger der Level, desto seltener wird bei der Station nachgefragt, ob Infodaten vorliegen. Der hoechste Level wird wieder erreicht, wenn Datentransfer stattgefunden hat. Connectet eine Station den Digi mehrfach, so wird die Sendezeit pro Connect reduziert.

__**5.2. Listen der benoetigten Dateien**__

Diese Listen sind Zusammenstellungen von Programmen mehrerer Autoren einschl. der Systemdateien von Flexdigi. Sie sind wegen staendiger Neuentwicklungen von Treibern usw. nicht vollstaendig; einzelne Programme koennen von neueren Versionen ersetzt sein, von manchen gibt es mehrere Versionen. Die Programme von vor Maerz 1997 sind meist nur fuer MS-DOS geeignet. Daher sollen die Listen nur einen Ueberblick geben, welche Dateien zum Betrieb unbedingt erforderlich sind und welche zusaetzlich verfuegbar. Eine aktuelle Dateiliste fuer die User-Version (ohne FLEXDIGI.EXE und Zubehoer) ist im Internet unter Adresse 'http://db0ais.ampr.org' abrufbar.

Zu den meisten Programmen geben die Autoren Informationen in einer .DOC-Datei (in deutsch, englisch oder machmal auch franzoesisch); diese wird gewoehnlich zusammen mit dem Programm in einem Archiv (meist LZH) gepackt geliefert. Eine Kurzhilfe bzw. Parameteruebersicht zu einem bestimmten Programm erhaelt man in der Regel mit dem Aufruf "<programm> /?".

a) benoetigte Basis-Dateien unter MS-DOS:

|FLEXNET.EXE   |FlexNet-Kernel (zentrales PC/FlexNet-Modul) |
|FLEXDIGI.EXE  |PC/FlexNet-Digipeater, nur fuer Netzknoten mit Infobox |
|FLEX.EXE      |Start- und Entladeprogramm fuer PC/FlexNet |
|SYSNUM.EXE    |Setzen des Passworts (bis Flexdigi V3.3e) |
|FLEXPASS.EXE  |Setzen des Passworts (ab Flexdigi V3.3g) |
|FSET.EXE      |Setzen von Parametern von der Kommandozeile aus |
|CALIB.EXE     |Kanaele zwecks Abgleich auf (quasi) Dauersendung schalten |
|STAT.EXE      |Anzeigen der Treiberstatistik |

Dazu sind minimal ein Hardware-Kanaltreiber und eine Applikation (ggf. mit TFEMU.EXE, s. Kap. 3) fuer die Bedienung/Konfiguration vor Ort noetig.

Version fuer Windows95 (ab PC/FlexNet V3.3g):

|FLEX95.LZH    |Archiv mit FlexNet-Controlcenter und zugehoerigen Dateien |
|FLEX95IP.LZH  |Archiv mit VXD-Treibern zur Vorspielung einer  Netzwerkkarte fuer Windows95 |

b) fuer Flexdigi-Betrieb: vom Sysop zu erstellende sowie automatisch von FLEXDIGI.EXE erzeugte Systemdateien *.FPR (s. Kapitel 3.1. und 4.5.):

|A.FPR         |Aktuelles-Text (Aktuelle Infos) |
|B.FPR         |Bakentexte (mit Pfaden und Zeitabstaenden) |
|C.FPR         |Connecttext (Begruessngstext beim Connect) |
|H.FPR         |Hilfetext (Anleitung/Befehlsuebersicht) |
|I.FPR         |Infotext (Stationsbeschreibung) |
|L.FPR         |Lokaler Connecttext (zusaetzlich, nur bei direktem Connect) |
|S.FPR         |Suchpfade fuer den FIND-Befehl |
|FLEXNET.FPR   |Parameterdatei (automatisch erzeugt, nicht editieren!) |
|MH.FPR        |Mheard-Liste (automatisch erzeugt, nicht editieren!) |

c) Hardware-Kanaltreiber incl. Treiber fuer softwaremaessig erzeugte Ports (laden vor dem Start von FlexNet mit FLEX.EXE, siehe Kap 3.1.):

|SER12.EXE     |serielles BayCom-Modem 1200 Bit/s AFSK an COM-Port;  Vers. 1.2b, 1.4, 1.5a und 1.6 fuer unterschiedliche Ausfuehrungen des COM-Port --> testen! |
|PAR96.EXE     |paralleles BayCom-Modem 9600 Bit/s FSK an LPT-Schnittst. |
|USCC.EXE      |alle BayCom-USCC- und DigiSCC-Karten (2, 4 oder 8 Kanaele) |
|XSCC.EXE      |alle SCC-Karten (mindestens alle BayCom-USCC- und DigiSCC- sowie PA0HZP-OptoSCC-Karten; noch im Beta-Test) |
|DUMMY.EXE     |Lueckenfueller (inaktive Hardwarekanaele) |
|LPBCK.EXE     |reservierter Port fuer internen Selbstconnect |
|PIF.EXE       |Verbindung zweier Rechner ueber LPT-Ports |
|VANESSA.EXE   |Sepran/Vanessa-Karten-Treiber incl. EPROM-Update |
|KISS.EXE      |nur fuer Rechnerkopplung, nicht fuer TNC-Ansteuerung geeignet mit 16550-Unterstuetzung, optional RMNC-CRC |
|6PACK.EXE     |6PACK-Protokoll fuer TNC-Ansteuerung\\  6PACK.BIN TNC2-EPROM dazu |
|IPXPD.EXE     |IPX ueber Packet-Treiber (Ethernet) |
|IPXN.EXE      |IPX auf NOVELL(R)-IPX-Shell |
|IPPD.EXE      |AXIP ueber Packet-Treiber (Ethernet)\\ IPPDCFG.EXE  Konfigurationsprogramm dazu (FlexNet aktiv) |
|ETHER.EXE     |Ethernet-Multicast-Kopplung wie von G8BPQ als Ethernet-Standard vorgeschlagen |
|ETHER32.EXE   |Ethernet Win32 Socket-Protokolle W95\\ ETHER32.DLL   Datei dazu\\ ETH32CFG.EXE  Konfigurationsprogramm dazu (FlexNet aktiv) |
|PSADRVR.EXE   |AFSK/FSK-Modem mit DSP-Soundblaster:\\ - Echo Corp. Personal Sound System\\ - Cardinal DSP16\\ - Orchid Soundwave 32\\ - Wearness Beethoven |
|DSK.EXE       |DSP TMC320C2x : Texas Instruments DSP Starters Kit fuer 1k2 AFSK und 9k6 FSK |
|DSK50.EXE     |DSP TMS320C5x : Texas Instruments DSP Starters Kit fuer 1k2 AFSK und 9k6 FSK |
|DG1SCR.EXE    |DG1SCR-DSP-Board AFSK/FSK |
|EZKIT.EXE     |Analog Devices EZKIT Lite DSP Board |
|WSS.EXE       |AFSK mit Windows Sound System |
|WSS_9K6.EXE   |FSK mit Windows Sound System |
|SB*.EXE       |FSK/AFSK mit allen Soundblastern, Testvers., problematisch |
|SM*.EXE       |Soundcard Modem, Dateiserie fuer 1k2 und 9k6 |
|YAMSER.EXE    |FSK 9k6 YAM-Modem via COM-Schnittstelle |
|YAMSMD.EXE    |FSK 9k6 YAM-Modem via COM-Schnittstelle, SMD-Version |
|FEVM56K.EXE   |DSP 56002 Evaluation Module Motorola 1k2 AFSK\\ FSK1200.CLD Datei dazu |

d) Hilfsprogramme und Applikationen (laden nach dem Start von FlexNet):

|SHOW.EXE      |Monitorprogramm mit Anzeige von PTT und DCD fuer alle Kanaele |
|KILLAPPL.EXE  |Selektives Entladen von FlexNet-TSR-Applikationen |
|TNC.EXE       |sehr primitive TNC-Emulation |
|SERV.EXE      |komplette PC-Fernsteuerung fuer unbemannt laufende Stationen |
|TFEMU.EXE     |DRSI/Hostmodetreiber fuer Hostmode-Programme, z. B. DieBox, FBB-Box, DX-Cluster, GP, SP, TSTHOST, TOP usw. |
|TFETERM.EXE   |Einfachst-Terminal fuer Hostmode-EMU (TFEMU) |
|TFESER.EXE    |Zugriff auf TFEMU via serielle Schnittstelle |
|ETHEREMU.EXE  |Emulation einer PKT-Schnittstelle fuer TCP/IP-Anwendungen, Ethernet-Emulator mit Konfigurationsprogramm EEMUCFG.EXE |
|AXPDDRVR.EXE  |AX.25 Packet-Driver Emulator mit AXPDSTAT.EXE Testprogr. |
|SNDDIAG.EXE   |Diagnose-Utility fuer Soundblaster und WSS-Treiber |
|CONVERSD.EXE  |Pingpong-Convers |
|PACSRV.EXE    |PACSAT-Broadcast |
|BCT.EXE       |BayCom-Terminal (Testversion mit FlexNet-Schnittstelle) |
|BCM.EXE       |BayCom-Mailbox (BBS) |
|DVMS.EXE      |Sprachmailbox |
|MONIPCF.EXE   |Programm zum Monitoren und Loggen von Packet-Verkehr |
|DIGIMON.EXE   |Hilfsprogramm zur automatischen Linkueberwachung unter Win95 |
|MCUT.EXE      |Terminal/PBBS-Programm fuer User |
|PCFLOG.EXE    |Lochbuchfuehrung |

__**5.3. Blockdiagramm einer PC/FlexNet-Station**__

Das folgende Bild zeigt eine beispielhafte Zusammenfassung mehrerer Moeglichkeiten; es enthaelt nicht alle verfuegbaren Applikationen. Auch ist es nicht moeglich, alles Gezeigte gleichzeitig zu betreiben.

<code>
               +--------+ +-------+ +----------+ +--------+
               |   GP   | |  FBB  | |Commercial| |  *NOS  |
  Applications |        | |       | |  TCP/IP  | | TCP/IP |
               |Terminal| |Mailbox| | Program  | |Programs|
               +--------+ +-------+ +----------+ +--------+
                  +-+  +------+   +-------+     +-----+
               +---------+ +------------+ +------------+ +--------+ +-------+
     FlexNet   | WA8DED  | |Ethernet PD ¦ ¦  AX 25 PD  ¦ ¦BayCom- ¦ ¦BayCom-¦
  Applications |Emulator | |  Emulator  ¦ ¦  Emulator  ¦ ¦Terminal¦ ¦Mailbox¦
               |TFEMU.EXE| |ETHEREMU.EXE¦ ¦AXPDDRVR.EXE¦ ¦BCT.EXE ¦ ¦BCM.EXE¦
               +---------+ +------------+ +------------+ +--------+ +-------+
                    +-------+ | +----------------+            |         |
                            | | | +---------------------------+         |
                            | | | | +-----------------------------------+
                            | | | | |
          +---------+    +-------------+    +------------+ +------------+
          ¦Starter &+----¦   Kernel    +----¦ Digipeater-¦ ¦FLEXPASS.EXE¦
          ¦unloader ¦    ¦             ¦    ¦   module   +-¦   *.FPR    ¦
          ¦FLEX.EXE ¦  +-¦ FLEXNET.EXE +-+  ¦FLEXDIGI.EXE¦ ¦(SYSNUM.EXE)¦
          +---------+  ¦ +-------------+ ¦  +------------+ +------------+
          +---------+  ¦    ¦¦¦¦¦¦¦¦¦    ¦  +-------------+
          ¦Parameter¦  ¦    ¦¦¦¦¦¦¦¦¦    ¦  ¦Controlcenter¦
          ¦ -setter +--+    ¦¦¦¦¦¦¦¦¦    +--¦for Windows95¦
          ¦FSET.EXE ¦       ¦¦¦¦¦¦¦¦¦       ¦ FLEXCTL.EXE ¦
          +---------+       ¦¦¦¦¦¦¦¦¦       +-------------+
                            ¦¦¦¦¦¦¦¦¦
                            ¦¦¦¦¦¦¦¦+------------------------------+
                            ¦¦¦¦¦¦¦+-----------------------+       ¦
                            ¦¦¦¦¦¦+------------------+     ¦       ¦
                            ¦¦¦¦¦+-------------+     ¦     ¦       ¦
                  +---------+¦¦¦+--------+     ¦     ¦     ¦       ¦
                  ¦    +-----+¦+---+     ¦     ¦     ¦     ¦       ¦
                  ¦    ¦      ¦    ¦     ¦     ¦     ¦     ¦       ¦
             +--------+¦+---------+¦+---------+¦+---------+¦+--------------+
             ¦ BayCom ¦¦¦ BayCom  ¦¦¦ BayCom  ¦¦¦  TNC2   ¦¦¦  Soundcard   ¦
             ¦  USCC  ¦¦¦PICPAR9k6¦¦¦   1k2   ¦¦¦         ¦¦¦WSS.EXE/SM.EXE¦
             ¦USCC.EXE¦¦¦PAR96.EXE¦¦¦SER12.EXE¦¦¦6PACK.EXE¦¦¦  SBLAST.EXE  ¦
  (Hardware) +--------+¦+---------+¦+---------+¦+---------+¦+--------------+
     L1           +----+     +-----+     +-----+      +----+
   Drivers   +--------+  +--------+  +--------+ +-----------+ +------------+
             ¦ PA0HZP ¦  ¦Wirelink¦  ¦  AXIP  ¦ ¦  Winsock  ¦ ¦ Configura- ¦
             ¦OptoSCC ¦  ¦PIF.EXE/¦  ¦        ¦ ¦ Windows95 +-¦ tion prog. ¦
             ¦XSCC.EXE¦  ¦KISS.EXE¦  ¦IPPD.EXE¦ ¦Ether32.EXE¦ ¦ETH32CFG.EXE¦
             +--------+  +--------+  +--------+ +-----------+ +------------+
                                     +--------+
                                     ¦ Packet ¦
                                     ¦ Driver ¦
                                     +--------+
</code>

__**5.4. Literaturquellen**__

Zum Erstellen dieser 'Sysop-help' wurden folgende Vorlagen verwendet:

  - Sysop-Dokumentation zu RMNC/FlexNet V3.1a von Gunter Jost, DK7WJ, 01.05.1992
  - Dokumentationen (FLEXNET.DOC und FLEXDIGI.DOC) zu PC/FlexNet V3.3e (18.01.1996) und V3.3g (01.07.1998) von Gunter Jost, DK7WJ
  - Dokumentation zum FlexNet-TNC 'FTNC' V0.6I von Fred Baumgarten, DC6IQ, 12.03.1995
  - User-Dokumentation zu PC/FlexNet V3.3c von Gerd Puschmann, DG2GGP, Dirk Rapp, DL2GRD, und Patrick Sesseler, DF3VI, 04.06.1995
  - Optimierte Setsearch-Liste: Tips zur Konfiguration von FlexNet-Digis von Wolfgang Kippels, DK4EK, 04.08.1996
  - Persoenliche Mitteilungen, Anregungen und Tips (korrekturgelesen) von Wim Hoek, PA3AKK, April-Juli 1998
  - Anleitung zu RMNC/FlexNet V3.3h von Joerg Zastrau, DL1BKU, 05.04.1998
  - Erlaeuterungen zur Fehlerstatistik (ST-Befehl) bei PC/FlexNet von Matthias Welwarsky, DG2FEF, Juli 1997

Ein besonderer Dank auch fuer die vielen Tips geht an die Korrekturleser George Nashan, DL4VCN, und Joerg Zastrau, DL1BKU.
Hamradio

User Tools

Site Tools

Page Tools
