Previous- Index- Web- next- pag



The DIGI_NED owner manual

The DIGI_NED user manual, Version: 1.03-032 Date: January 14, 2002 By: PE1MEW (pe1mew@qsl.net).


About this manual

Preamble.

This is the DIGI_NED owner manual. This manual is intended to be the reference for APRS users using the near-by DIGI_NED digipeater and for DIGI_NED digipeater owners who wish to build and maintain their DIGI_NED APRS digipeater.

Contens of this MANUAL.

This Manual is separated in to different parts:

  1. About this manual
    1. Preamble
    2. Contens of this manual
    3. Manual availability and version number
    4. Disclaimer
    5. Comments and contributions
  2. The DIGI_NED owner manual
    1. Introduction
    2. Make DIGI_NED up and running
      1. Set-up of DIGI_NED in DOS
        1. AX25_MAC
        2. AX25_MAC parameters
      2. Set-up of DIGI_NED in LINUX
      3. DIGI_NED
    3. DIGI_NED Basic functionality
      1. digipeating
      2. Sending broadcasts
    4. DIGI_NED at the keyboard
    5. APRS Queries,
    6. DIGI_NED specific functionalities.
      1. DIGI_NED queries (Tiny-Web-Pages)
      2. DX Functions
      3. Telemetry
        1. input (reading data)
        2. output (writing data)
      4. Weather functions
      5. Satellite tracking
      6. Serial line data
    7. DIGI_NED administration
      1. Remote Control
      2. Remote update using 3rd party programs
    8. Appendixes
      1. The DIGI_NED syntaxes.
      2. The DIGI_NED configuration examples

Manual availability and version number.

This manual uses the available documentation released with the DIGI_NED executeable and source distribution. In the top part of each page you can find the version number and release date.

Disclaimer.

This manual is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Comments and contributions.

If you have any additional comments or corrections to this documentation feel free to contribute.

To verify and add your contibution stick to these little rules:

Send your comments to the DIGI_NED team: digi_ned@qsl.net


Introduction to DIGI_NED.

This is DIGI_NED, a rule driven digipeater using an INI file and containing special functions for use with APRS.

APRS is a registered trademark of Bob Bruninga, WB4APR. His homepage can be found at: http://web.usna.navy.mil/~bruninga/aprs.html.

Why this digipeater? The functions of this digipeater are comparable to other rule based digipeaters. Still there were good reasons to build a new one.

  1. Existing digipeaters do not exactly do what we wanted it to do,
  2. Some digipeaters stop running on illegal frames, most notably frames with more than 8 digipeaters in it,
  3. We want to have source code to be able to add hardware options later, like connecting a Radio Direction Finder,
  4. The digipeater should run on a 286 with something simpler than BPQ,
  5. Suitable for rock-table 24/7 use,
  6. Ability to add functions as we want to,

The source of this digipeater has been made available under the terms of the General Public License.

DIGI_NED, as the digipeater is called (Digipeater from the Netherlands) has the following properties:

DIGI_NED can be used with all modems that can also be used by TFPCX (oh wonder, how is that possible...) so including the BPQ protocol over Ethernet, KISS, BayCom, YAM, SCC (PA0HZP, PE1PET, USCC) etc. In LINUX, DIGI_NED users the kernel interface; anything connected to this should work.

A general philosophy for DIGI_NED is the ability for a user to make his own configuration. The default configuration provided in the distribution is made as useful and correct as possible, but the end-user determines in the end how the digipeater will behave and look like.

A word from Henk, pe1dnn:

The first attempt to generate documentation was found in the early distributions. I just collected stuff and parts I wrote. From that I assembled documentation in Dutch. Due to more international interest I continued this documentation in English. I dropped the Dutch documentation. Volunteers are welcomed to generate docs in other languages. French documentation is at the time of writing available at the site of MAPG, the Moselle APRS Packet Group in France. The addres of this site is: http://mapg.ifrance.com/mapg/index.htm .This will be the only document I will put in my distributions to avoid to much rework for each revision. This document will grow over-time as I add new bits and pieces.

I would like reports and suggestions for enhancements. This DIGI is under our own control and can be adapted to our wishes. I want however to stick closely to the APRS specification! If you encounter any violation of this in the program and default .ini file please report it! Note that this reporting is important, if my default .ini file is wrong it will spread all-over the world!

Kind regards, Henk.

Make DIGI_NED up and running

In the following chapters we will let pass all primary items for building your DIGI_NED digi.

Set-up of DIGI_NED in DOS.

As it is our first goal, DIGI_NED runs in DOS on cheap 286 class PC's (or better) and on Linux using all kind of modems, from cheap BayCom/BayPack and YAM modem to KISS TNC's and SCC cards.

Due to the fully different architecture of DOS and LINUX both operationg systems need a different approach. For the DOS environment we choose for the use of a TSR. This TSR takes care of the AX25 protocol-side of the digi.

AX25_MAC.

DIGI_NED makes use of a TSR program that drives the modems etc. This program is AX25_MAC. MAC is an abbreviation for Medium Access Control which is a common name in protocol software for the part driving the hardware. You always need to run this TSR when using the DOS version of DIGI_NED, without this TSR present DIGI_NED will refuse to start.

This AX25_MAC is a MAC layer for AX.25. What it does is take raw frames of data, add a CRC and transmit as a HDLC packet to the hardware. Read frames are, when the CRC is correct, passed on in raw form to the program that uses the MAC layer. There is no intelligence in the MAC layer, it will transmit everything that is fed to it.

AX25_MAC must be loaded into memory using parameters as also used for the TFPCX program. In 'run.bat' an example is given for the BayCom style 1k2 modem I use for testing.

AX25_MAC parameters.

In short the parameters:

Usage:

AX25_MAC [ -N ] [ <load options> | -U ]

<general options>
-N no messages
-U unload

<legend>
[] optional
| alternative

x hex digit
n dec digit

<load options>
-P<port>[:xxx:nn:nnnn] packet port [addr:IRQ:<clock>]
-Bnnnn[:nnnn ...] baud rate (1 number/port)
-F[file] read init file
-D debug mode
-C[xx] show DCD [color]
-Ixx AX25_MAC interrupt
-L interLock - one TX at a time (only for half-duplex ports)
-BU[nnnn] number of buffers

<port> COMn | LPTn | PARn | YAMn | BPQnn | KISSn | DSCC | OSCC | USCC
(n = 1-4, for BPQ n= 60-80)

<clock> 0 = disable 2 = hardclock 4 = PA0HZP port
(1 digit/1 = softclock 3 = DF9IC modem 5 = PA0HZP timer channel)

This overview is also presented when invoking AX25_MAC the following way:

AX25_MAC -?

Parameters for configuring and adjustment to the used hardware are the same as for TFPCX. The documentation (English) for AX25_MAC is included in the package, in this document you can read more about about it. The document will also point out some of the restrictions for correct working. For example you cannot use BayCom modems in a DOS box under windows because in that case AX25_MAC needs strict timing and access to the PC's timer-chip.

Adjustment of access parameters of the ports (TXDelay and the like) is done by means of AX25_MAC.INI. At the start of AX25_MAC the -F option shall be specified, otherwise the file is not read and default values will be used.

AX25_MAC.INI contains parameters that also exist in TFPCX, only the parameters that are of interest for a MAC layer are present however.

Many parameters that exist in TFPCX are therefor vanished. For more detailed information see AX25_MAC.TXT.

Here is an example how to set AX25_MAC up with a KISS TNC.
This is what you have to do:

  1. Kick the TNC into KISS mode, how this is done depends on the TNC type.
  2. If applicable change AX25_MAC.INI to set TX-Delay to match your TRX.
  3. Load AX25_MAC the following way:

AX25_MAC -PKISS1 -B9600 -L -F -C17 -BU50

(you may want to change 'run.bat' to have a startup batch-file)

At this point you have a driver running. You can have more ports than one, the parameter '-C17' is responsible for the indicator you see in the top-right corner. It should follow the reception of data. If you don't like it just leave the parameter '-C17' out. The parameter '-B9600' sets the speed to 9600 baud, this is also the default for kiss so you could leave it out. The '-L' parameter prevents simultaneous transmission if you have more than one port, you can leave that out as well since with one port it does nothing.

The '-F' causes the AX25_MAC.INI to be read to program the TX-delay etc. If you leave that out some defaults will be used. The -BU50 specifies that up to 50 frames can be buffered in the TSR. A very simple startup would be:

AX25_MAC -PKISS1

I know it doesn't sound simple at first, but using this AX25_MAC driver really covers a lot of hardware and makes DIGI_NED itself hardware independent.

Now you have the TSR running and can proceed with the setup of DIGI_NED itself which will be described in a minute.

AX25_MAC can be unloaded from memory by starting AX25_MAC once more but this time only with the '-u' flag.

Set-up of DIGI_NED in LINUX.

The version for LINUX is almost identical to the DOS version. For Linux AX25_MAC is not needed, this function is embedded in the Linux kernel.

Instead '-p' options have to be used to specify which AX25 ports should be used. The possible ports are define in the /etc/ax25/axports file, see the AX25-HOWTO for details.

You have to compile the Linux version yourself. The makefile is setup for use with the old kernel tools for 2.0.36 kernels. For use with the new kernel-tools the Makefile has to be changed; remove the '#' on de "DEFS = -DNEW_AX25" definition.

Building DIGI_NED is as usual for Linux: "make depend" followed by "make". This results in an executable "digi_ned". This executable uses just like the DOS version a digi_ned.ini file, exact the same file as for DOS can be used. '\' characters in file-paths will be interpreted as '/' for Linux (and '/' will be interpreted as '\' in DOS...).

Port '1' is linked to the first port defined with the '-p' option, port '2' is linked to the second specification etc. Up to 8 ports can be uses. A start example:

./digi_ned -p 1k2 -p lfbb -v

In this example "1k2" will be port 1 and "lfbb" port 2. The '-v' option enables verbose output. DIGI_NED only works with kernel interfaces, using that you can connect almost everything, read the AX25-HOWTO how to do that.

Note that DIGI_NED has to run under 'root' privilege to be able to listen on a socket for incoming packets, just like 'listen', 'net2kiss' and other programs that listen for connectionless traffic on a socket.

To exit the program under LINUX signal SIGINT has to be send to the program. Normally this signal is generated by Ctrl-C, but it does not need to be so. For more information see the "stty" command. A simple shell script is provided to start DIGI_NED in background.

DIGI_NED.

When AX25_MAC has been loaded then DIGI_NED can be started. At the start DIGI_NED reads the DIGI_NED.INI file. Another .INI can be loaded by supplying its name at startup.

C:\APRS\> DIGI_NED MYDIGI.INI

The line above loads MYDIGI.INI instead of DIGI_NED.INI. When no alternative 'DIGI_NED.INI' file is supplied the DIGI_NED will read the DIGI_NED.INI which is present in the same directory as the .EXE file.

You can supply the '-v' option for verbose output, or '-h' for help.

Alternatively you can specify '-a' if you want to monitor the activity of message queries and telemetry message generation or '-d' to monitor DX message generation.

Before starting DIGI_NED you have to exchange the call in the DIGI_NED.INI with the call you want to use for the digipeater. The call is only present in one place; at the end of the DIGI_NED.INI you will find:

digi_call: PE1DNN-2

All DIGI_CALL fields that are present in DIGI_NED.INI will be replaced at runtime by the call supplied with the digi_call setting, in my case this is PE1DNN-2.

As owner of the digipeater you have to supply your own call, this way the ?id query will return who is responsible for the digipeater. On top of that the owner will be able to execute the ?exit command when he or she wants to. You can assign more owners. The first one you assign will be used for the ?id query, but the others will be able the execute the ?exit command too. These other calls can be your own with a different SSID or a call of a co-maintainer.

The text in digibcon.ini will be transmitted as beacon. Currently it contains an APRS message with the position of the DIGI. The syntax of this message and how to set it up can be found in the APRS specification. Do not forget to change the location, I have seen some strange stations at my QTH lately :-). Be aware that some characters are not allowed according to the specification!

The text in digi_id.ini will be transmitted as station identification. It is just a plain text message for people watching with their AX.25 monitor and wonder which station is transmitting all the data they see. Don't forget to change the file so it contains your callsign.

In DIGI_NED.INI you will find a "send:" command which specifies the interval for these beacon transmissions, from which file the beacon texts shall be read and on which ports it should be transmitted. Also the destination and digipeater calls are specified there. When the file for the beacon is specified without any path then DIGI_NED looks for it in the same directory as where the program is located.

For DX message generation you need to specify the position of the digipeater in "digi_pos:".

DIGI_NED Basic functionality

Now what does the digipeater exactly do and how? In this brief example we use the provided default "digi_ned.ini" file.

(note: the type of routing mechanism is subject of change ! For up to date information about the routing mechanism check the APRS SIG (Special Interest Group) on http://www.tapr.org.)

digipeating.

In APRS the digipeater-path is constantly manipulated. An APRS station uses generic calls in the "via"" list, such as 'RELAY', 'TRACE', 'WIDE' etc., which will be picked up by the digipeater, replaced by the digipeaters own callsign and retransmitted. The clue is that an APRS station doesn't need to know which name a nearby digipeater has. The station just sends its frame with 'WIDE' in the via path and any digipeater in the area that responds to 'WIDE' will pick it up; there can be more digipeaters who do this at the same time.

The WIDEn-N format needs some special handling which is done by so called "intelligent" digipeaters such as DIGI_NED. When a station starts with a digipeater like WIDE5-5 in the via path, the first "intelligent" digipeater that takes this frame will be change the call to WIDE5-4 as soon as it passes it. On the second "intelligent" digipeater it will become WIDE5-3 and so on until after the 5th digipeater the call has become WIDE5-0 (in other words WIDE5). Then the "digipeated" bit will be set (visible in most monitors by a '*' indication) and the next digipeater call in the via list will become due. TRACEn-N works similar. There is a lot to talk about this but that's out of context here. The default DIGI_NED.INI file executed the intelligent digipeating rules as we think they are meant to be.

The behavior has been verified with the APRS SIG on http://www.tapr.org.

Lets just look how this works using one rule from the DIGI_NED.INI file:

digipeat: 1 relay 2

This means: digipeat packets that arrive via port one and where the name of the digipeater that should be handled is 'RELAY' and send those back out via port two. For example an incoming frame via port 1:

from 1: PE1DNN > APRS via PE1MEW-2*, RELAY, WIDE

This frame was already digipeated by PE1MEW-2, the next digipeater in the via list is RELAY and that matches with the call in the digipeat: rule; this one should go to port two. In the digipeat rule nothing is specified after the '2', this is 'normal' digipeating. In that case

the call is substituted by the digipeater call, e.g. PE1DNN-2. The transmitted frame to port 2 becomes:

to 2: PE1DNN > APRS via PE1MEW-2*, PE1DNN-2*, WIDE

That will be transmitted. Port specification 'all' means 'from all ports' and 'to all ports' So:

digipeat: all relay all

When receiving a frame from port 1:

from 1: PE1DNN > APRS via PE1MEW-2*, RELAY, WIDE

this will be transmitted using this rule:

to 1: PE1DNN > APRS via PE1MEW-2*, PE1DNN-2*, WIDE
to 2: PE1DNN > APRS via PE1MEW-2*, PE1DNN-2*, WIDE

So transmission will be to both output ports when there are two (the number of ports depends on how may hardware ports are setup in AX25_MAC).

You can do all kind of manipulation on the digipeater path, such as replacement with a completely new path, addition of digipeater calls to the via list etc. You can even handle digipeaters out of order or create a simple 'cluster'. What you can do is explained in the comment in the the appendix: DIGI_NED configuration examples. Be warned, it is a lot! Your imagination has to do the rest. The verbose output and logging are helpful to analyze your experiments.

If you want to know more, read also the DIGI_NED FAQ document.

Sending broadcasts

After you have read about basic digipeating rules the second primary function comes. This function makes you known to the world as you transmit your position frame with it. At the other hand this function can also be used to transmit other kand of data.

Basically DIGI_NED transmits the contens of a file in both send and beacon rules.

send: 20 all DIGI_DEST,WIDE,TRACE6-6
digibcon.ini

beacon: 20 all DIGI_DEST,WIDE,TRACE6-6
digibcon.ini

In the shown examples the contens of the file digibcon.ini is transmitted every 20 minutes to the value DIGI_DEST. Common that is the version of the software release. In our case somtehing like APNDxx.als the digi-path is given. In this case WIDE,TRACE5-5. Be aware that as I wrot this the discussions are on-going and subject of change.

The difference between "send:" and "beacon:" is that only beacons specified with "beacon:" will be send upon reception of an ?APRS? broadcast from a user.

The contens of the file can be of all kind. Primary you can use it to broadcast a standard position frame used in APRS:

digibcon.ini:
=5213.03N/00600.08E_PHG3230/DIGI_NED Weerstation http://connect.to/digi_ned
<eof>

But also compressed position information, status, or bulletins can be transmitted using DIGI_NED. See for this the SEND syntaxes.

DIGI_NED at the keyboard.

While DIGI_NED is running you can use:

On the keyboard you can also do the same queries as you can do via APRS messages. So if you type "help" you will get the help text... If you are running in verbose-mode than you can switch that off with ALT-V to be able to see the responses. When finished you can switch verbose mode on again with ALT-V.

When you are logging to a logfile then you can stop logging with ALT-L. The logfile will be closed so you can shell to DOS to remove or rename it without a problem. When hitting ALT-L gain the logging will restart, new data will be append to the existing logfile. When stopping and starting a timestamp and a visible separator is written to the logfile.

The same function as for the logfile also exists for the TNC logfile, this is a logfile in 'tnc' format that can be read by other programs too. To toggle the file off and on use ALT-T (T for TNC...).

With the "-a" flag you can switch on activity display to see who is sending queries to the digi. You can switch this on and off by the keyboard also using ALT-A (A for Activity).

If you can't remember all the keystrokes just remember one simple one, ALT-H. ALT-H will give you a list of all key combinations that are possible in either DOS or Linux.

Under Linux this all doesn't work unless you sepecify the '-k' flag at the commandline. The implementation is restricted with respect to terminal types, for example backspace only works when it uses ASCII code 0x08. On my RedHat 5.2 system you can use the ALT-<key> combination.

If that doesn't work on your system you may press ESC followed by the desired letter instead, e.g. press and release ESC followed by a press and release of H gives you the keyboard help.

Under Linux you cannot use ALT-D to start a shell, use a different virtual console or different Xterm window instead! You don't realy need the keyboard commands in Linux since you can run may things simultaneously anyway and you can do queries through an internal loopback connection with XASTIR for example (that's how I test my stuff also). I found it however convinient during testing of the queries and the satellite support since it works much faster then commands via the loopback or via RF.

APRS queries:

As a APRS user you can ask DIGI_NED some questions through APRS messages. This is similar functionality as the Tiny-Web-Pages suggested by Bob Bruninga, WB4APR.

In DIGI_NED the query mechanism works with normal standardized APRS messages. To start with DIGI_NED responds to the ?APRS? broadcast message; DIGI_NED will transmit all its beacons. All other messages must be addressed to DIGI_NED. Most of the responses have to be acknowledged by the receiver.

DIGI_NED repeats responses up to 10 times, doubling the interval at each attempt. Of course these retransmissions cease when a acknowledgement has been received.

The following commands are recognized by DIGI_NED:

The '?' can be omitted and is supported for APRS specification compatibility.

Note that some commands cause beacon transmissions or transmission of object data and item locations instead of a return message. Commands like "?aprsm" do not return anything if there are no pending messages for you. "?ping" and "?aprst" send messages which do not need to be acknowledged. If reception fails you will not see an answer either.

A specific command from a user is only accepted once in "message_keep_time:" seconds, default: 900 seconds. When a user sends the same command within this time again then DIGI_NED will not respond, only acknowledge the message.

This means for example that a user cannot send two "?info" commands to DIGI_NED within this time, on the second command DIGI_NED will not respond and only acknowledge the message. If the user tries the "?info" command again after 900 seconds then the user will get a normal response on the "?info" command. After sending an "?info" command a user can send another command without any problems, for example "?up" will work normally. A second "?up" command will not field a response however.

The reason for this behavior is to avoid problems when two auto-responding systems are starting to respond to each other, this will go on infinity if nothing is done about it. With this measure a message will Ping-Pong only once and then it will be silent again. If a quarter of an hour is not sufficient in your case then increase the "message_keep_time:" value.

There is one-time bypass for this. If you really want the execution of the same command again you can add or omit the '?' in front of the command, DIGI_NED duplicate filtering will in that case see a difference, although the response will bet exactly the same with or without the '?'. So in the above example you can use "info" and get a response if the previous command you used was "?info". Note also that for example the Kenwood TH-D7 suppresses duplicate answers, you may not see the answer if you already have it!

The ?exit command is meant for the owner of the digipeater. The command "?exit" has some restrictions; the following must be true for the command to work:

  1. The command must be enabled in DIGI_NED.INI.
  2. The message must originate from the DIGI_NED owner.
  3. The frame must be received directly without digi's in the path.

When one or more of the conditions are not true then DIGI_NED will send the default help information.

After reception and recognition of the ?exit command the digipeater will send a "shutdown" message without any digipeaters in the path (the receiver shall to be local and receive the digipeater directly).

When this message is acknowledged the digipeater will shutdown. The "shutdown" message is repeated up to 3 times; if an 'ack' is still not received after the third attempt the digipeater will go back to normal operation as if it never received an ?exit command.

DIGI_NED uses a number of exit-codes that may be useful in .bat file. An example of this can be found in "run.bat" which is in the distribution.

The exit-codes are:

Optionally a number between 0 and 255 can be used with the ?exit command; e.g. "?exit 10". In that case the supplied value will be used as exit-code. This way all kind of other programs can be started with a batch file after stopping the digipeater. Look at "run.bat" for an example that uses the standard exit-codes. This can be extended to start other programs such as NetCHL to remotely maintain the system on which DIGI_NED runs and add new settings and software.

For Linux this also works, but because with Linux you can run many programs in parallel without any problem anyway this feature is not really needed. But it works.

The paths used for replies and acks are defined in DIGI_NED.INI. For each port a "message_path:" can be defined; 'all' can be used too use the same path for all ports. Also ports can be combined, e.g."message_path: 1,3 WIDE,TRACE6-6" sets the path for ports 1 and 3.

Definition of a "message_path:" for each port makes it possible to transmit responses through different paths. It is even possible to define more than one path for a port, this results obviously in more traffic! This is needed when a digipeater in the path through which the response needs to be transmitted is not an APRS style digipeater; the exact station call is needed. When a message has to be delivered through 2 such digipeaters 2 different paths are needed. This is conflicting with the idea of "generic digipeating", but it is possible.

The "owner" of the digi also has the right to execute a few other functions. Later these will be replaced by a "member" feature but since this is still experimental only the owner(s) (you can supply more calls on the "digi_owner:" line, see sample digi_ned.ini).

The extra commands for the owner are, besides "?exit" the commands "!clear" and "!out". "!clear" is used to remove entries from the "mheard" list. There are three options. "!clear" on its own cleans the whole "mheard" list.

When used with a port number, e.g. "!clear 2" then all entries for the given port are cleared from the "mheard" list. When used with a call, e.g. "!clear pe1dnn-7" then the given call is cleared from the "mheard" list.

For information about "!out" see the "Remote Control" section later.

DIGI_NED specific functions.

DIGI_NED adds specific functions to APRS. These functions can be specified in the APRS specifictaions but can also be value added to the APRS community.

DIGI_NED queries

There can be many more messages then the preset build in APRS specified messages. DIGI_NED offers a way to create your own Tiny-Web-Pages.

All the messages returning a static text are stored in a file which you can modify to suit your needs. The file is defined with "message_file:" in digi_ned.ini, default is digi_ned.mes.

The layout of the digi_ned.mes file is explained in the sample file, which is shipped with DIGI_NED. Also you can find this description in the DIGI_NED syntaxes.

DX Functions

DIGI_NED has a DX function build in. First of all you can get distance information through queries. This works with the command ?DX. It works like ?MH - with port number or call. It uses the entries in the MHEARD list, so when the MHEARD list is small the DX will also not give much.

DX with port number 1 returns for example the next 3 messages:

DX-P1 of all 263.3 km D0BRP DO4BH-1
DX-P1 of 24h 161,4 km DO4BH-1 PD0JBR-1
DX P1 of 1h 123.9 km PA3ESK-2 PE1ABT-15

The first is the best DX for all entries available in the MHEARD list. It shows the distance to best DX station, the call of the best DX station and second-best DX station.

The second and third lines are almost the same, but the second is for the stations received in the last 24 hours and the last for stations received in the last hour.

If there is no second best DX station then only one call is shown.

The duration over which is measured (all, 24h, 1h) is specified in the .ini file, this can be changed in steps of one hour.

Tip: ports are numbered 1 to 8, number 0 can be used to mean "all ports". This also works for the MHEARD command by the way We can zoom in on a station with "DX <call>" for example

DX PD0JBR-1

This returns:

PD0JBR-1 138.1 km bearing 026 degrees

It shows distances and bearing from the digipeater to this station. Distance uses a great-circle calculation, bearing is based on a flat earth model. Bearing "0" is True North. The DX <call> not only works on calls returned by DX <port> command but on all calls in the mheard list. Like MH also port 0 is accepted to mean 'any port'. If there is no distance and bearing information the returned message will say so.

When a station is received which is the 'best DX' over a period of time then is will be announced by means of a DX bulletin which can be caught by a TH-D7 or TM-D700 radio for example. There is a threshold value defined in the .ini file, which specifies the minimum distance for DX.

Distances below this value are never DX. The period of time over which the 'best-DX' is determined is as specified in the .ini file. The rule with which this is specified is "dx_level:". This can be set for each port, because DX on for example 6 meters is a totally different distance then DX on 70cm.

With "dx_path:" the destination call and path can be specified which is used for the DX announcements. This can be set differently for each port.

After a DX announcement has been send a new announcement it will not be send if the same station is heard again within a period of time. This period is determined by the "keep_time:" parameter, the same, which is also used for duplicate checking. If after this period the same station is heard again and this station is still the best DX, then a new DX announcement is transmitted. If a better new DX is received within the "keep_time:" period (or after..) then is announced immediately. This mechanism only avoids duplicate transmissions of exactly the same DX message and does not delay new data.

Even in a AX25 environment where transmission failures not exist. It is possible to have errors in the DIGI_NED DX-list. Stations that are next doors can appear as thousends of kilometers away due to wrong position frames. These stations can be cleared by the digi owner using the '!clear < call >' command.

Telemetry

Input (reading data).

DIGI_NED is capable of transmitting telemetry data with fixed intervals. The telemetry data is transmitted as an APRS type 'T' identifier. With this type of message an APRS station can transmit 5 analog sources and an 8 bit digital source. In DIGI_NED a command "telemetry:" can be added to the startup .ini file. With this command the frequency of the transmission can be specified, the ports where this telemetry has to be send to. Then a list of sources can be supplied, fist the 5 analog sources and as last the digital source. A source can be used multiple times if you want.

There are currently 3 sources:

This will give the status of the bits 'Busy', 'Ack', 'Paper Empty', 'Select' and 'Error'. The bits represents the logical value on the parallel port's pins. 'Busy' is inverted by hardware, but this is compensated in DIGI_NED. The low order 3 bits of the status register are always set to '0'.

First the 'strobe' output is made logical low and the 4 bits are read from the 'Busy', 'Ack', 'Paper Empty' and 'Select' bits.
These bits represent the lower 4 bits of a byte. Then the 'strobe' output is made logical high and the same 4 bits are read for the high nibble of the byte. When connecting a simple 8 to 4 multiplexer TTL chip you now can easily create an 8 bit input.

The lpt<n>_8 device contains support for multiplexing via the lpt port. When reading the port the port number (which is 0 based and runs from 0 to 5) is put on bits 1, 2 and 3 of the control port. These bits correspond with the "Auto Linefeed", "Initialize Printer" and "Select Printer" outputs of the LPT port.

The association of port numbers put on the 3 bit address lines of the control port can be overruled. For example to completely reverse the numbers, so the first value is read from address 5, the next from 4 etc, you can specify:

telemetry: 20 all lpt2_8/5,lpt2_8/4,lpt2_8/3,lpt2_8/2,lpt2_8/1,lpt2_8/0...
(path truncated to be able to fit the example on 1 line...)

The 3 bit address on the control port can take values 0..7.

For more information about the use of the LPT port see also the web site: http://www.beyondlogic.com/. The LPT inputs are TTL level.

The analog values in the APRS telemetry command are numbered A1..A5, the binary bits are numbered B1..B8.

When using the LPT port as analog source the value read from the LPT status port, or the 8-bit value from the multiplexer, are used put into the analog field as decimal value (0..255).

When using the LPT port as binary source the following mapping is used:

APRS 5 bit input 8 bit input
B lpt<n> lpt<n>_8
B1 pin 11 (Busy) pin 11 (Busy) when pin 1 = '1'
B2 pin 10 (Ack) pin 10 (Ack) when pin 1 = '1'
B3 pin 12 (Paper Out) pin 12 (Paper Out) when pin 1 = '1'
B4 pin 13 (Select In) pin 13 (Select In) when pin 1 = '1'
B5 pin 15 (Error) pin 11 (Busy) when pin 1 = '0'
B6 '0' pin 10 (Ack) when pin 1 = '0'
B7 '0'

pin 12 (Paper Out) when pin 1 = '0'

B8 '0' pin 13 (Select In) when pin 1 = '0'

APRS has a method of specifying what all the telemetry information means. This is done by means of an APRS message, which is addressed to the digipeater itself. In this version of DIGI_NED it is just transmitted as a beacon. To use this you have to change the beacon file to have call of your digipeater in it.

If the APRS program you use supports it, it will show the telemetry data with the correct labels and units. It can even do some equations and determine if a '1' bit in a binary value means 'active' or 'inactive'.

With PARM. the 'label' or 'name' of the parameters are specified. Each analog value can have a name and each bit of the binary value too. In the example digi_tlm.ini file for example 'A1' has the name 'Battery' and 'B1' has the name 'Busy'. You could change 'Busy' to 'Lamp' for example.

With UNIT. the unit in which the parameter should be expressed is defined. For Battery the unit is for example 'volt'. If the analog field is for example '12' then this could be displayed as: 'Battery 12 volt' using the information from our example. For binary values the word 'is' can be used for active and 'not' for inactive bit values. Without modification 'B1' could be displayed as: 'Busy is high', but when changing the 'Busy' name to 'Lamp' and unit 'high' to on this would be 'Lamp is on', now it is clear what this bit means!

Now you can also do some simple equations. For each analog value 'x' the equation:

value = a x^2 + b x + c

is used, where 'a', 'b' and 'c' are defined for each port using an EQNS. message. Default are 'a' and 'c' zero and 'b' one, so there is no change to the analog value.

With the EQNS. message this can be changed. For example say the analog value is expressed in tenths of volts for the battery and has a start value of 6 volts. Then you may want to divide the value by 10 before displaying. If you have analog value 60 then you mean that the battery potential is 12 volts. In this case you want to multiply the value by 0.1 (value for 'b') and add 6 volts to the measured value ('c'). 'a' shall stay zero.

To achieve this the values 0,0.1,6 have to be supplied for A1. All 5 analog ports can be specified this way in sequential order.

The last message that gives information is BITS. This one tells when a bit should be regarded as active. The BITS. message has 8 bits. If the first bit is '1' that means that the B1 value is regarded as active when it is logical high. A '0' means that a logical low is active. So if you connect a lamp-on detection to B1, which is low when the lamp is on, then the bit in the BITS. value shall be '0'. Default is BITS.11111111 which means that on all bits a '1' means active. For our inverting lamp detection this should be changed to BITS.01111111. Now a telemetry aware program will say 'lamp is on' when the B1 value is '0' or 'lamp is off' when the B1 value is '1'.

Telemetry is send at the interval specified with the "telemetry:" rule. Now you may want information now, or don't transmit at all. In that case you can query the digipeater with ?TLM. As argument you have to supply which telemetry info you want. This can be A1 to A5 or B1 to B8. To query for example the first digital value you send the query "?TLM B1" to the digipeater. The digipeater will respond with "B1 not high" or "B1 is high" depending on the state of B1.

Now we just specified all these beacons which tells more about the telemetry information, these can be used by DIGI_NED itself too.

When you supply the filename of the beacon file containing the telemetry information to the "tele_info:" rule then DIGI_NED will use this information (PARM., UNIT., EQNS. and BITS.). This can also be found in the DIGI_NED syntaxes. When we have put our "lamp" example in the information the "?TLM B1" will return "lamp not on" or "lamp is on". Likewise "?TLM A1" can return for example "Battery 13.5 volt".

These queries are independent of the beacon transmissions. If you only want to query, but do not want any telemetry transmitted you can specify the interval on the "telemetry:" rule as '0'. Then telemetry is never transmitted. You can also stop sending the telemetry information, but still feed the beacon file to the "tele_info:" rule to get the nice responses.

A word of warning: The names you specify in PARM. and UNIT. are limited in space. And the number of characters you may use differs with each label. Therefore to make APRS compliant beacons it is needed to consult the APRS specification on http://www.tapr.org.

Output (writing data)

For writing data to the outputs of the telemetry port the 8 address lines of the associated lpt-port are used.

The !out command is the restricted domain of the owner of a DIGI_NED digi. This command from other users is rejected. The '!out' command can be found at the remote control chapter in this manual.

Weather functions.

This functionality is used to make all kinds of packets based on telemetry information. Primary reason for creating this function is to build a weather station (with home-made sensors!). All data is retrieved from an LPT port. It uses the same type of multiplexing as the telemetry ports.

The WX functionality is split into two rules. First a definition is made using the 'wx_var' rule. Then the variable is used in a broadcast on air using the 'wx' rule.

The WX_VAR rule

The way it works is with variables (a symbol a..z or A..Z etc), which are associated with a port. They are creates with a "wx_var:" rule. Besides its association with a telemetry port each variable has specific properties. First of all the kind of variable. It can use the raw value but also a maximum or minimum value over an amount of time. It can also sum up differences between measurements to support rain-meters etc. The period is selectable in minutes, up to 32676 minutes timespan.

Secondly the variable has a set of equation parameters. Using the formula "a (x*x) + b x + c" where "x" is the value read from the telemetry port the variable has constants for "a", "b" and "c" to convert the read to the value of the variable.

The variables created this way can be embedded in a string which is send my a new rule called "wx:". You can use different types of formatting to create exactly the output string you want. Say your variable is "v" and has the value 123. The following formatting instructions yield the following output:

"%v" -> formatted to "123" (takes as much space as needed)
"%4v" -> formatted to " 123" (always 4 characters)
"%-4v" -> formatted to "123 " (always 4 characters, left aligned)
"%04v" -> formatted to "0123" (always 4 characters, zero padding)
"%02v" -> formatted to "23" (always 2 characters, truncates the value)
"the value of v=%v" -> "the value of v=123"

There is also a second kind of variables. These do not read data from a telemetry port but are used to display the current date and time. There are a number of formats available, but by truncating the variables during formatting you can create other formats too. Both zulu and local time are supported, note that these only generate correct values when either the timezone information (TZ) is set correctly or the digi_utc_offset: is filled in (DOS only)

The following kind of variables can be created using the "wx_var:" rules:

val -> direct value
max -> max since midnight
min -> min since midnight
sum -> sum since midnight
avg -> average since midnight
max60 -> max over 60 minutes, passed 1 hour
min60 -> min over 60 minutes, passed 1 hour
sum60 -> sum over 60 minutes, passed 1 hour
max120 -> max over 120 minutes, passed 2 hours
min120 -> min over 120 minutes, passed 2 hours
sum1440 -> sum over 1440 minutes, passed 24 hours
avg60 -> average over 60 minutes
dhm -> day, hour, minute value
hms -> hour, minute, second value
ymd -> year, month, day value
ydm -> year, day, month value
dmy -> day, month, year value
mdy -> month, day, year value
mdh -> month, day, hour value
mdhm -> month, day, hour, minute value

When you want to use this functionality some planning is needed. You have to know which values are present on which ports. Then you need to find the equations to calculate the values as they should appear on the output. It is also good to plan which variables you use. Variables van be "a-z", "A-Z" (case sensitive!) and symbols like "#", "$" etc. If you want to include a % sign in the output use \%, the "\" is an escape character. To include a backslash use "\\". Planning of variables is needed to avoid using the same variable twice. If you define a variable twice, only the last one will be evaluated.

To illustrate how it works I created a configuration example below with several equations. The final string is a positionless WX string as described in the APRS specification (You need a copy of this to create a correctly formatted string for WX use). Due to the flexibility use of this WX mechanism is not restricted to weather stations. Use your imaginations, this can couple any data from an LPT port to a beacon transmission. At the end you find a example where periodically the maximum and minimum temeparture is transmitted each hour as a bulletin.

Composing a datagram using the WX variable

Here a example configuration for a WX station using many sensors connected to a multiplexing interface on the LPT port.

When a WX variable is used in "wx:" but is not defined with "wx_var:" the program issues a warning at runtime.

For more information about interfacing to the LPT port look at the DIGI_NED web-site which can be reached via http://www.qsl.net/digi_ned. Also look at the links on this site. There are projects by other hams which can now be supported through this interface.

Sole purpose is to stimulate home made equipment. Building a weather station and connect it to APRS is very rewarding!

Note: don't take a too narrow view! This functionality can also be used to transmit information from direction finders, formatted telemetry data etc, it doesn't have to be WX at all!

Having said this, here is the example of a possible APRS DIGI_NED weather station!

Assume a telemtry module on LPT1 with 8 multiplexed ports

lpt1 port 0:
lpt1 port 1: temperature in centigrade
lpt1 port 2: course in steps of 30 degrees (0 = 0, 1 = 30, 2 = 60 etc)
lpt1 port 3: encounting rainfall value in mm
lpt1 port 4: humidity in steps of 10%
lpt1 port 5: barometric pressure, in hPa offset 900 (100 = 1000 hPa)
lpt1 port 6:
lpt1 port 7: wind speed in beaufort

course from lpt1 port 2, multiply by 30 to get degrees

wx_var: c,val,lpt1_8/2,0,30.0,0

speed from lpt1 port 7, minimum over last min, convert from beaufort to mph aproximation beaufort to knots: 0.3*(x*x)+2.2*x+0 multiply with 0.8689762 to get from knots to mph final formula beaufort to mph: 0.2607*(x*x)+1.9117*x+0

wx_var: s,min1,lpt1_8/7,0.2607,1.9117,0

gust from lpt1 port 7, maximum over 5 min, convert from beaufort to mph

wx_var: g,max5,lpt1_8/7,0.2607,1.9117,0

temperature from lpt1 port 1, convert from centigrade to fahrenheit

wx_var: t,val,lpt1_8/1,0,1.8,32

rainfall last hour from lpt1 port 3, convert from mm to 100rths of inch

wx_var: r,sum60,lpt1_8/3,0,3.937,0

rainfall last 24 hours from lpt1 port 3, convert from mm to 100rths of inch

wx_var: p,sum1440,lpt1_8/3,0,3.937,0

rainfall since midnight from lpt1 port 3, convert from mm to 100rths of inch

wx_var: P,sum,lpt1_8/3,0,3.937,0

humidity from lpt1 port 4, multiply by 10 to get percentage

wx_var: h,val,lpt1_8/4,0,10.0,0

barometric pressure from lpt1 port 5, 10ths of hPA: multiply by 10 add 9000

wx_var: b,val,lpt1_8/5,0,10.0,9000

raw rain counter, convert mm to 100rths of inch

wx_var: #,val,lpt1_8/3,0,3.937,0

time variable type MDHM in zulu time

wx_var: D,mdhm,zulu

Positionless WX string, use in conjunction with a normal position beacon

wx: 5 all APRS,WIDE,WIDE
_%08Dc%03cs%03sg%03gt%03tr%03rp%03pP%03Ph%02hb%05b#%03#xDned

Example complete WX string (if you use this, shut down the normal beacon, this WX packet will replace that function!):

time variable type DHM in zulu time

wx_var: T,dhm,zulu

wx: 5 all APRS,WIDE,WIDE
@%06Tz5213.61N/00600.00E_%03c/%03sg%03gt%03tr%03rp%03pP%03Ph%02hb%05b#%03#xDned

Time formats example:

Using wx variables in DIGI_NED it is possible to configure all kind of information frames. One intresing example is the use of time in your broadcasts. Below a number of configuration examples:

Supported formats DHM, HMS, YMD, YDM, DMY, MDY, MDH, MDHM zulu or local time

A number of variables in Zulu time

wx_var: T,dhm,zulu
wx_var: S,hms,zulu
wx_var: Y,ymd,zulu
wx_var: W,ydm,zulu
wx_var: F,dmy,zulu
wx_var: M,mdy,zulu
wx_var: O,mdh,zulu
wx_var: D,mdhm,zulu

A number of variables in Local time

wx_var: U,dhm,local
wx_var: R,hms,local
wx_var: Z,ymd,local
wx_var: X,ydm,local
wx_var: E,dmy,local
wx_var: N,mdy,local
wx_var: Q,mdh,local
wx_var: G,mdhm,local

wx: 5 all WX,WIDE,WIDE
>time: %06Tz (DHM) %06Sz (HMS) %06Yz (YMD) %06Wz (YDM)

wx: 5 all WX,WIDE,WIDE
>time: %06Fz (DMY) %06Mz (MDY) %06Oz (MDH) %08Dz (MDHM)

wx: 5 all WX,WIDE,WIDE
>time: %06Ul (DHM) %06Rl (HMS) %06Zl (YMD) %06Xl (YDM)

wx: 5 all WX,WIDE,WIDE
>time: %06El (DMY) %06Nl (MDY) %06Qz (MDH) %08Gl (MDHM)

By using combinations and restricting the output of a variable other strings can be build... Example:

wx: 5 all WX,WIDE,WIDE
>date: %02Y-%02W-20%02F time: %02O:%02T:%02S zulu

Other broadcasts using WX variable.

In this example we show a special broadcast to be done every hour reporting the last 30 minutes maximum windspeed in Beaufort, and the maximum and minimum temperature over the last 24 hours from the moment it is broadcasted.

; temperature from lpt1 port 5, converted to centigrade
wx_var: T,val,lpt1_8/5,0,0.0989,-8.3419
wx_var: m,min1440,lpt1_8/5,0,0.0989,-8.3419
wx_var: M,max1440,lpt1_8/5,0,0.0989,-8.3419

; Wind maximum over 30 minutes from lpt1 port 6, convert pulses/sec to BF
wx_var: W,max30,lpt1_8/6,-0.0062,0.5361,0.9187

wx_var: Y,dhm,zulu
wx: 61 all DIGI_DEST,WIDE :BLN%1Y :WX @ %04Y: Wind: %2WBF Tmin:%3m'C Tmax:%3M'C

wx 1 all DIGI_DEST,WIDE :BLN%1YWX :1est test te2t test test3test test t4st test

About formatting a bulletin or announcement please read the chapter about the 'send' variable.

Satellite tracking in DIGI_NED

Satellite tracing is donated to the DIGI_NED project by Alex Krist, KG4ECV. Alex wrote two papers with information about this function, "Sattrack.txt" and "Sattrack.doc" which are included in the distribution.

Alex presented his implementation of satellite tracking in DIGI_NED at the Charleston, SC Hamfest February 3, 2001. In this chapter many of the information out of his documents is copied.

Objectives.

The objective of the Satellite Tracking module in DIGI_NED is to give APRS users a tool to track satellites on APRS without having to invest time and/or money in satellite tracking software. APRS users can use their APRS client software to obtain satellite-tracking information. The only requirement on the client side is that the APRS client must be able to send regular APRS messages.

To minimize channel load, the module has been implemented in such a way that tracking is only done on demand. No bandwidth is wasted by loading the channel with information that no one requested. The software is designed so that the tracking module can be excluded from DIGI_NED in order to minimize the size of the executable in case this functionality is not desired and/or if the size of the executable is of concern.

General The tracking module has three main functions. These are,

Satellite Inquiry.

An APRS user can inquire DIGI_NED for information about a particular satellite by sending a message query to DIGINED. The satellite-tracking module in DIGI_NED uses the 4 position Amsat designator to specify satellites (i.e. Sunsat is so35). Such a query could look like:

sat ao40

Upon reception of this message, DIGI_NED will send back a message informing the user whether or not the satellite is in range, and an object containing information about the satellite. This object will be displayed by the APRS client software on a map. The status text of the object will contain AOS (Acquisition Of Signal) information if the satellite is not in range. For example:

AOS@2-3 12:00 LOC

This means that the next pass will be as 12 noon on February third, local time. The time can also be indicated in UTC, and is configurable by the digi owner. If the satellite is in range, the status text will contain information necessary to track the satellite. For example:

U145.823 7D435.398 1 E71 A123 MB

This status text informs the user of the doppler-corrected uplink and downlink frequencies (U145.823 D435.398), the elevation angle (E71), the azimuth (A123) and in which mode the satellite is operating (MB, Mode B). The extra 7 and 1 in the status text are for display purposes only on a Kenwood TH-D7A(G)/E. This allows for display of elevation and azimuth together on the first screen of the object information display on this particular radio. In case the satellite does not exist or if the query is not correctly formulated, DIGI_NED will send an appropriate error message back to the APRS user.

Satellite Tracking Tracking is actually very similar to Satellite Inquiry. An example of a tracking query is:

trk ao40

The main difference between inquiry and tracking is that after sending the initial in range/out of range message and initial object, DIGI_NED will be put in tracking mode. This means that DIGI_NED will continuously transmit objects with updated satellite information up to a maximum allowed time set by the digi owner. The interval between the transmission of objects depends on whether or not the satellite is in range. If the satellite is out of range, an object is only transmitted every 15 minutes.
As soon as the satellite comes in range DIGI_NED will transmit a new object every minute. When the satellite disappears below the horizon again, DIGI_NED will resume transmitting objects at the long interval.
These intervals can be configured by the digi owner. The information in the status text of the object changes dynamically also. While the satellite is out of range it will contain AOS information, and tracking information when the satellite is in range.

Updating Satellite Information.

In order for Satellite Inquiry and Satellite Tracking to be meaningful, the satellite database containing the keppler elements of each satellite needs to stay current.

Just download a new keppler sets in TLE format from the Amsat website (http://www.amsat.org) or from the ARRL website (http://www.arrl.org). Copy this into the update file specified by the update_tle_file rule and issue the "utle" command. Do this about every two weeks. Every week is better. You can also subscribe to a mailing list on both sites which will send you a new file every week. Take advantage of these services so that you will be reminded to update your satellite database on a regular basis.

Don't worry if the file you are downloading also contains satellites or other space objects that you have not defined in your satellite database. The update command will simply ignore these objects. Also, if the file you download does not contain a satellite you have in your database then the satellite will not be deleted from your database.

To update the satellite database, one can put a NASA Two Line Element (TLE) file in a specified directory on the DIGI_NED computer (remotely if necessary) and then send the update command to DIGI_NED. This command is:

utle

This stands for Update Two Line Element. Once this command is issued, DIGI_NED will read the TLE and extracts the information needed to update its satellite information database.

This command can only be issued by the digi owner and the file names and directories can be specified in the DIGI_NED configuration file.

The availabilty of satellites in the sattelite service depends to what is made available bij the DIGI_NED owner. The following satellites and spacecrafts are a example of what could be available in the satellite information database:

OSCAR-10 AO10 OSCAR-11 UO11 OSCAR-14 UO14 PACSAT AO16 WEBERSAT WO18 LUSAT LO19 OSCAR-20 FO20 OSCAR-22 UO22 OSCAR-23 KO23 OSCAR-25 KO25 ITAMSAT IO26 OSCAR-27 AO27 OSCAR-29 FO29 OSCAR-36 UO36 TECHSAT GO32 TMSAT TO31 SEDSAT-1 SO33 RS-12/13 RS12 RS-15 RS15 AO-40 AO40 SAUDI-1A SO41 SAUDI-1B SO42 MIR MIR_ ISS ISS_

The underscores are necessary when the designator is only 3 characters long. DIGI_NED expects a 4-letter designator.

Necessary files.

Actually, the satellite-tracking module needs only one file, besides the sources of course if you compile it under Linux. This file is the Satellite Information Database. This file contains 24 satellite entries. A fully functional and up to date (as of March 2001) database is included with this distribution of DIGI_NED. The name of the file is "digi_ned.sat".

Another file that is of interest and is included with this distribution is the "digi_ned.tle file". This file contains update information for the Satellite Database.

Compilation (DOS):

Standard the satellite option is compiled in the distribution. But for some reason it might be necessary to do it manually.

When compiling with BCC3.1 the sattrack files need to be added to the project file. To do this, open the project menu, this can be done through the menu Window->Project. Press insert in the Project window. A dialog window appears. In the Name field first type "sat.c" and then press tab. Click the Add button. Then enter "predict.c in the Name field and hit TAB. Click the Add button. Now the dialog can be closed, click Done. At this point we have added the new

sources to the project. Now we have to add the definition _SATTRACKER_. Otherwise, DIGI_NED will still compile without this function. To do this open the Options Menu. Select

Compiler. Choose the entry Code generation... Now you have a dialog with a number of fields. One of them is a field with the label "Defines". There you fill in _SATTRACKER_. After you're done, press OK. In the project file shipped with the DIGI_NED source the sattracker is

already enabled. If you don't want to use the sat tracker remove the _SATTRACKER_ definition in the Options->Compiler->Code generation... dialog. You can build the code by selecting "Build all" from the Compile menu.

Compilation (Linux):

Near the top of the Makefile file you will find the following section:

# if satellite tracker needs to be included then uncomment the next line
#DEFS += -D_SATTRACKER_

To include the satellite-tracking module in DIGI_NED make sure that the pound sign (#) preceding the "DEFS += -D_SATTRACKER_" line is removed.

Then issue a "make clean" to remove old code and then issue a "make depend" to resolve code dependencies. Finally run "make" (no parameters) to build the executable.

In the current distribution de '#' is removed by default. If you don't want to use the sat tracker then add the pound sign (#) as shown above.

Configuration of the satellite tracking module:

The satellite tracking module is fully configurable through the *.ini file which is read at startup of DIGI_NED. This module introduces several new rules, which I will describe below. I'll also include an example of the rules section.

The first rule is actually not a new one, but one that was introduced when the dx functionality was implemented in DIGI_NED. This is the digi_pos: rule. The satellite tracking module uses this rule to determine the position of the digi and uses it in the calculation necessary to predict passes of a satellite. See the DIGI_NED documentation for an explanation of these rules. Example:

digi_pos: 5213.61N 00600.00E

The position may also be defined in through the digi_pos_file (see DIGI_NED documentation) as:

digi_pos_file: digibcon.ini

The altitude rule indicates at what altitude, in meters, the digi resides. It's not a very critical parameter but we do need it for the calculations. 1 meter is approximately 3.28 feet. Example:

digi_altitude: 10

As a digi owner you also need to decide if you want the information AOS time information to be displayed in either UTC or local time. This has nothing to do with the time of creation of the object. That will always be displayed in UTC per APRS Specifications. This rule accepts two values. "1" for local time, "0" for UTC. If one chooses local time, then AOS information will be displayed in the object as "AOS@08-02 17:00 LOC". If UTC is chosen then the

info will be displayed as "AOS@08-02 22:00 UTC" Example:

digi_use_local: 1

For satellite tracking you also need to specify the UTC offset for the digi. For EST this would be -5. Make sure you correct this for daylight savings.Example:

digi_utc_offset: -5

To specify the interval at which objects should be transmitted when a satellite is in range, use the sat_in_range_interval rule. The inteval is specified in minutes. Example:

sat_in_range_interval: 1

To specify the interval at which objects should be transmitted when a satellite is out of range, use the sat_out_of_range_interval rule. The interval is specified in minutes. Example:

sat_out_of_range_interval: 10

You can set the maximum time you want a satellite to be tracked with the

track_duration rule. It takes most FM birds to orbit the earth in about one and a half hour. So a good choice is something just above that. This rule has been introduced to prevent DIGI_NED from having to track a satellite indefinitely when someone requests it. If a person needs to track it longer than they can just reissue the request. Track duration is specified in minutes. Example:

track_duration: 105

The file containing the satellite database can be defined by the satellite_file rule. You can specify a path if you want. If you don't, then the module will assume it's located in the same directory as the DIGI_NED executable. Example:

satellite_file: digi_ned.sat

The file containing Two Line Element (TLE) information from which DIGI_NED can update its satellite database is specified through the update_tle_file rule. The same goes as for the satellite database file specification; you can specify a path, but if you omit the path, DIGI_NED will assume it is located in the same directory as the DIGI_NED executable.

update_tle_file: digi_ned.tle

In the DIGI_NED configurtion examples the satellite tracking default values are also given

A suggestion would be to issue a bulletin or announcement to the local APRS network announcing that you have this service available. In fact it may be a good idea to do this if you have an active Tiny Web Pages server on your DIGI_NED digi. This is pretty much the only way to inform people that you have this service available (besides the regular status text in your posit of course).

Serial line data

DIGI_NED can be used transmit data from the serial line to any of the configured output ports. DIGI_NED expects serial data in the form of "sentences". These are <CR> terminated ASCII lines. DIGI_NED will pick up selected lines based on the first characters in the line. DIGI_NED will transmit at regular intervals the latest received complete line of data.

With this DIGI_NED can send data from a GPS, Ultimeter or other devices connected via a serial line. You can sent multiple sentences if you want. DIGI_NED will automatically do a checksum-check if a checksum is present. Checksums terminate a "sentence" with "*xx" where "xx" is the hexadeximal sum. If the asterix is found in the third position before the end of the line DIGI_NED assumes a checksum is present.

The checksum is compared with an internally calculated checksum.

Sentences that fail will be ignored. The calculation follows the NMEA standard used for GPS devices among others. The checksum is an EXOR operation staring at the second character up to, but not including, the "*".

If no checksum is present the data is accepted as is. An examples of a start of a sentence is:

If the wanted type of sentence is not specified (empty line following the "serial:" rule) all the data on the serial input is accepted (if

it doesn't fail the checksum). Note that DIGI_NED will only output the most recently read complete line in this case. Normally DIGI_NED transmits a packet for every specified sentence, so if you specified "$GPRMC $GPGGA" then both the $GPRMC and $GPGGA sentence will be transmitted.

DIGI_NED will convert any control character on the serial line into a dot ".", except <CR> which is the line terminator and <LF> which is discarded.

The interface is always 8 bit, no parity, one stopbit. Accepted speeds are 1200, 2400, 4800 and 9600 baud. This covers the mutlitude of serial inputstreams, including NMEA. The interface uses hardware flowcontrol on send an receive. For a 3 wire connection shortcut RTS and CRS and shortcut DTR, DSR and DCD in the connector at the DIGI_NED side of the wire.

Software-flowcontrol (Xon/Xoff) is not used.

DIGI_NED administration.

Remote Control.

The !clear command

These commands are the restricted domain of the owner of a DIGI_NED digi and similar commands from other users are rejected. The '!out' command is related to the telemetry functionality in DIGI_NED and the '!clear' command is used with the DX functionality.

The !out command.

With Telemetry you can read out analog and digital values. It is also possible to set binary values. For this the up to three LPT devices can be used. Each LPT device supports 8 TTL level outputs, which can be set using an "!OUT" message to the digipeater. These TTL outputs are D0 to D7 (pin 2 to pin 9 on the parallel port).

The !OUT message needs 2 parameters. The first is the LPT port number (1, 2 or 3), the second is the bit-pattern you want to output.

You can specify 1 to 8 bits. Each bit can be '0' to change the bit into logical low, '1' to change the bit to logical high, 'p' will toggle the indicated bit for 1 second. Can be used as 'reset' pulse. The value 'x' or '/' can be used to leave a bit unchanged.The allocation is as follows:

!OUT 1 10xxPx11

The '/' character does the same as 'x' and its supported because it is conveniently located below the ASCII '0' which makes it easier for a TH-D7 user.

On the !OUT command you don't have to specify all 8 bits, if you only want to change the output on D0 then you can leave out the specification of all other bits. The bits which are not specified keep their current value.

In response to the "!OUT" command the digipeater will tell if the command was accepted and the resulting pattern on the LPT port. This bit pattern is arranged the same way as the on the !OUT command, so first D0, then D1, D2...D7.

Since this function is experimental, the !OUT command is only accepted from the digipeater owner specified with the "digi_owner:" rule. More owners for a DIGI are allowed, see the sample digi_ned.ini file.

The !ptt command.

The digi-owner can send a message with the command "!ptt 111011x1". The commands disables or enables transmission on a port. The left most digit is for port 1, then port 2 up to port 8. Binary "0" means disabled, binary "1" means enabled. In the example transmission on port 4 is disabled. Values "x" and "/" are used as "don't change". With the previous example port 7 doesn't change value, if it was "0" it will stay "0", if it was "1' it will stay "1". If you only need to provide the number of digits for the ports you have or want to change. For example to change only port 2 to "1" you may want to use "!ptt x1"; the not mentioned ports will not change.

P.S. note that if you shut-off the PTT bit for the port you are using to send this command also an ack will not be send back! You can still send messages however because the receiver is still active! Since the reciever is active it will still digipeat received data to other ports if the rules define this.

Tip: with the "command:" rule you can make a port read-only immediately at startup.

Remote update using 3rd party programs.

This chapter is copied from the DIGI_NED website which can be reached through the DIGI_NED portal at http://www.qsl.net/digi_ned

The APRS network very often uses digipeaters on high locations in rural areas or buldings in urban areas who cannot be entered easy due to owners restrictions or security policy's. In this case it is needed to be able to do some maintenance to the system without being there. Mantenance can vary from small parameter changes to updates of software.

In the situation of the DIGI_NED digi PI1APA, it was not possible te access the building during evening and night. So the remote access was required. The here discribed solution can be copied but needs adaption to your own specific configuration !

The basics of the DIGI_NED remote access are simple:

Starting the support program.

As the system boots the autoexec.bat runs the default sub from the menu. This DOS menu enables attended mantenance to boot without the digi software.

<Autoexec.bat>
:default
PATH C:\DOS;c:\util
PROMPT $p$g

goto %config%

:dos
goto end

:digined
PROMPT DIGI_NED $p$g
cd \digi_ned
wait 5
ax25_mac.exe -poscc:158:5:4444 -b1200:1200:1200:1200 -L -F -C17 -BU50
digi_ned -v
if errorlevel 4 goto net_start
goto boot

:net_start
\digi_ned\ax25_mac -u
cd \net
980201u2
goto boot

:boot
@echo type ctrl-c to exit
sleep 10
boot

:end

<EOF>

After DIGI_NED has stopped, the exit commando lets the batch-file select the next step. In our case exit code 4 starts the support software NETchl. All other exit codes makes the system reboot.

When NET is stopped the "autoexec.bat" runs a program named "boot" after a short wait program. this program, wait or pause, as you have available, enables the sysop to interfer with the normal programma loop as the system is attended.

The support software for example NETchl provides services for file transfer and to execute dos commands like copy and delete on the remote system.

As NETchl is a tcp/ip package for amateur use in a DOS environment it fits completely to our needs.

Due to complexity of the package the full functionality will not bediscribed in this documentation. A full sample configuration is available for download including doc's.
The available package
at the DIGI_NED web-site is 800 Kbyte and contains some documentation.

Keep in mind that you need some experience of tcp/ip in combination with AX25 amateur packet radio !

The features used from the NETchl package are:

FTP, File Transfer Protocol must be clear. RCMD is a telnet session to a specific port in NETchl (459). This port uses 'Baycom authentification' from a text string in a file in "c:\net\rcmd\remote_host_name". After this the console prompt of the remote system is offerd to you.

It is also possible to use other packet-radio programs for this purpose. The minimum requrement is that you have to be able to reset the system remotely.

Isues on transferring data on APRS frequencys:

In the PI1APA system 2 ports are available. 1 port on VHF and 1 port on UHF. When in service mode, digi_ned is stopped and NETchl is running, we use the quiet UHF APRS frequency for up and downloading. It is good to have a separte frequency for up and downloading. Think of what happens when we load the APRS QRG with heavy tcip/ip up- or down-load traffic ! In such a case all resources will be used by the up- or down-load and nothing is left for the APRS users. Keep in mind that a wide commonly is placed at high altitude ! and has large coverage !

Practice learned that uploading digi_ned.exe at 1200 bps simplex takes about 30 minutes ! You can decrease required upload time by takin out all comments in the configuration files.

In case you do not have 2 or more ports available think seriously of some way to make your transmitter go QSY for the period required to do maintenance !

If you have more than one port it is also possible to equip the APRS transmitter with both a 1200 bps AFSK modem and a 9600 bpq G3RUH modem. It will decrease upload time and load on the APRS QRG !

As you can see there are many possible solutions. Probably you can think of more !.

Resetting the system and watchdogs. After the maintenance the system has to be reset to make the changes active. In NETchl a 'exit !' commando is available. Also the 'shell /c boot' command makes the system reboot.

In case the support software is not able to do so you have to reset the system by some other command. The packet radio node PI1VRZ and dx-cluster PI8DXW can be reset using a ZVEI tone code sequence ( sel-call ). It is even possible to use DTMF commands. On these topics you imagination is the limit !

To be sure the system not hangs we also use a watchdog. Some watchdog examples are available at the VrzApDxw web-site.

Due to the high flexibility of DIGI_NED on all items DIGI_NED is the solution in many cases. In the folowing cases we will discribe what DIGI_NED can do.

 

Appendixes.

 

The DIGI_NED syntaxes.

This documentation contains all syntaxes which are used in DIGI_NED. DIGI_NED uses several syntaxes on a per file-type basis. documentation about the following files is available:

  1. digi_ned.ini
  2. digibcon.ini, digi_id.ini (as these come with the distribution)
  3. digi_ned.mes
  4. digi_tlm.ini
  5. digi_ned.sat
  6. digi_ned.tle

    The DIGI_NED configuration examples.

The purpose of these examples is to show what is possible with DIGI_NED and how you can change DIGI_NED rules to your own needs.

click here to go to the DIGI_NED configuration examples.

 


Top of this page