Previous- Index- Web- next- page



The DIGI_NED user manual

The DIGI_NED user manual, Version: 1.00-030 Date: September 13, 2001 By: PE1MEW (pe1mew@qsl.net).


About this manual

Preamble.

This is the DIGI_NED user 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 user manual
    1. Introduction
    2. DIGI configuration and his owner
    3. What is possible in a DIGI_NED digi.
      1. Digipeating.
      2. MHeard
      3. DX broadcasts and DX queries.
      4. APRS and DIGI_NED queries
      5. Information and objects
      6. Satellite tracking
      7. Telemetry

This document contains portions of

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


The DIGI_NED user manual

This manual is dedicated to the APRS user.

Introduction.

This manual as it lies in front of you or is on your screen is intened to be informing about the capebilities of a DIGI_NED digipeater. This type of digi can be situated in your area or QTH and probably it offers you the full range of services available in the software. And here we point at one important issue. Your neighbouring digi can be configured in many different ways. Her lies the strength of the digipeater software DIGI_NED.

DIGI configuration and his owner.

A DIGI_NED digi can be configurated in many differtent way's. This depends on the needs of your area and which services the owner of the digd wishes to provide.

Why do we speak from the "owner"? This lies in the fact that the software has 2 statuses for users. The two known statuses are:

The owner is given special permissions. These vary from maintenance related commands to commands related to experiments running on the digi. The user can not give these commands.

In a later development a DIGI_NED digi will have one more user type: the member. Members will be users who participate in experiments but are not allowed to give maintenance related commands. This status is not available yet !

This brings us to the main goal of DIGI_NED. DIGI_NED creates the posibilities to do experiments using APRS. One of the experiments is to create APRS digipeater software. So, DIGI_NED is not a full finished product. It is stable software that does it task properly. As developments continue DIGI_NED will evolve.

What is possible in a DIGI_NED digi.

A DIGI_NED digi can do several things.

Digipeating.

The first and primary thing a DIGI_NED digi can do is digipeating. But not just simply digipeating. DIGI_NED is a very flexible configureable digipeater. a DIGI_NED digi does support:

Using digipath manipulation it is possible to create new digipeater rules or algorithems. Mainly your digi-owner will configurate the basic digipeat rules as they are published by the APRS committee.

You do not have to contact the digi about digipeating. Digipeating and the digipeater path is set in the APRS client program. For information about how to configure your APRS client we refer to the manual of your APRS client. Beacuse we do deliver a default configuration to the DIGI_NED package we can say something about digipeating:

NOTE 1: These pages are copied from the DIGI_NED tour introducing you to DIGI_NED on the internet. This is reachable via the DIGI_NED portal at http://www.qsl.net/digi_ned

NOTE 2: 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.

Generic digipeating with call substitution.

In APRS the digipeater-path is constantly manipulated. An APRS station uses generic calls out of your "via" list the digipeater path, such as 'RELAY', 'TRACE', 'WIDE' etc. This will be picked up by the digipeater, replaced by the digipeater's own call-sign 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 which responds to 'WIDE' will pick it up; there can be more digipeaters who do this at the same time. .

Intelligent digipeating: WIDEn-n TRACEn-n

The WIDEn-N format needs some special handling which is done by so called "intelligent" digipeaters such asDIGI_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.

All kind of manipulation can be done on the digipeater path, such as replacement with a completely new path, addition of digipeater calls to the via list etc.

SSID routing.

When mobile or portable the range of your transmitter is limited due to fysical limitations of the surrounding area. In that case it is importand to increase the chance of the reception of your packets bij a RELAY or even a WIDE. This can be obtaind by creating a packet radio frame as short as possible. The common frame with all digipeaters is not short so SSID digipeating is a solution.

Even using the 'mike-encoded' or compressed APRS format it is possible to use the SSID of the address.

Using SSID routing it is also possible to give your APRS packets a direction.

Duplicate checking.

To prevent APRS frames from 'singing around' due to faulty digipeater paths a intelligent digipeater is capeable of checking wethever a frame is repeated or not. A DIGI_NED digi uses for this two mechanisms:

Call substitution: By replacing the digipeater call or alias in the digi-path for his own callsign the digi prevents it self from transmitting a frame which it did send allready. the digi checks if his own call is in the digipath it will not transmit it again.

Duplicate checking: From every frame a DIGI_NED digi is transmitting the checksum is stored in a table. When a frame is received which should be re-transmitted it's checksum is compared to the one in the table. When there is a match the frame is already transmitted and so discarded.

MHeard service.

The MHeard serivice in DIGI_NED is the first group of queries available.

A DIGI_NED digi keeps a list of all direct heard stations in memory. The number of stored call-signs is configured by the owner.

The following commands are available:

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.

The following commands are available:

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 the DX measured (all, 24h, 1h) is specified by the digi owner.

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. 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.

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.

APRS and DIGI_NED queries

There are 2 types of queries recognised in APRS. The first group is standarised in the APRS specifications. The second group is application dependant. In this case DIGI_NED related.

This are the queries that are sandarised in APRS:

The following queries are DGI_NED related:

As an addition to the standarised APRS queries a DIGI_NED digi can be configured as a source of information. This information can be of any kind:

Just ask the digi using your THD7 or APRS program and the info appears on your screen.

A DIGI_NED digi is able to send you information as text but can also create objects.

The object shows you where to go.

All this information is configureable. And it depens on what the owner of the digi has created what will be available.

If you don't know what is available just send the "help" query to the digi and it will guide you to the required information.

Satellite tracking.

DIGI_NED has a service build in for tracking satellites. It is expected that when this service is available at your digi it is announced through a broadcast.

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 APRS messages.

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 DIGI_NED. 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.

Telemetry.

Part of the DIGI_NED digipeater software is the telemetry module. This module is separated in to three parts:

As the telemetry module is widely configureable every configuration of a digi will be different. When you want to see what is possible surf to the following url's. Here you can see some nice examples:

Remote control.

Through the telemety module the owner of the wide is able to control ports on the digi. This is not yet made available to users. In a later development a DIGI_NED digi will have a user type named member. Members will be users who participate in experiments but are not allowed to give maintenance related commands. This status is not available yet !

Telemetry broadcasts.

DIGI_NED can broadcast telemetry at regular intervals and has 2 type of transmissions available:

These transmissions depend on each other and are needed for a proper display of the values.

The first transmission contains the actual status of the telemetry inputs.This frame looks like this:

:PE1DNN-2: Tlpt1,000,999,999,999,999,00000000: DIGI_NED telemetry.

This transmission is used in a short interval. Depending on the needs of the owner can it vary from minutes to hours. The tranmission contains 5 analoge inputs and 1 digital input.

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 and transmitted as a beacon.

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'.

A typical APRS telemetry datagram discribing the telemetry configuration could look lake this:

:PE1DNN-2 :PARM.Battery,Btemp,None,None,None,Busy,Ack,PE,Sel,Err,NC,NC,NC
:PE1DNN-2 :UNIT.volt,deg.C,None,None,None,high,high,hig,hig,hig,hi,hi,hi
:PE1DNN-2 :EQNS.0,0.0625,0,0,1,0,0,1,0,0,1,0,0,1,0
:PE1DNN-2 :BITS.11111111,DIGI_NED Telemetry

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.

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 queries

To find the actual status of the telemetry ports you can query the digipeater with the command:

?TLM

As argument you have to supply which telemetry info you want. This can be A1 to A5 or B1 to B8. The A stands for analogue and the B for bit. 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.

When the owner of the digi has put a "lamp" on port "B1" and configured the name properly we can find out the status of the lamp using the command:

?TLM B1

The DIGI_NED digi 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.

 


Top of this page