-
Notifications
You must be signed in to change notification settings - Fork 4
/
Copy pathcallsigns.txt
102 lines (78 loc) · 4.25 KB
/
callsigns.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
*** APRS Callsigns ***
APRS was originally built on top of AX.25, which limited each station to
a six character callsign with an additional four bit secondary station
identifier (SSID). This limit still exists on AX.25, but APRS stations
operating exclusively on the APRS-IS Internet system aren't as limited.
That being said, a common mistake when building exclusively RF based nodes
is to not support non-AX.25 APRS callsigns, which will cause problems when
trying to exchange APRS messages with IP-based stations.
Callsigns are written in what is called the TNC2 format, so although the
AX.25 header supports the SSIDs 0-15, you will not see callsigns such as
CALLSN-0. By convention, the zero callsign is dropped and written as CALLSN.
Callsigns for AX.25 must:
* Consist of only upper case letters and numbers
* Have a base callsign before the SSID at least three characters long
* Have a numeric SSID which falls in 0 - 15
* Have a base callsign before the SSID no longer than six characters
Callsigns for APRS must:
* Consist of only upper case letters and numbers
* The base callsign (before the SSID) must be at least three characters long
* The base callsign must be no more than nine characters long
* The callsign in total must be no more than nine characters long
* Optionally include one hyphen with a 1-2 character alphanumeric SSID suffix
* The SSID may not start with '0'
Callsigns should be:
* Globally unique
In this context alphanumeric is defined as any ASCII values in the range:
* decimal [65 - 90] - 'A'-'Z'
* decimal [48 - 57] - '0'-'9'
SSIDs are important for most APRS operators since it enables a user to have
more than one station operating under the same callsign. There are several
conventions for how to select SSIDs for specific stations, with the most
popular one being the APRS 1.1 addendum: http://www.aprs.org/aprs11/SSIDs.txt
It is important to realize that while this convention is suggested, nothing in
APRS should depend on a specific meaning of specific SSIDs, so users are free
to select any valid SSID they like for any station.
In addition to station licensed callsigns and tactical calls (which simply
require adding a license callsign in the comment field), APRS defines
additional calls which fall in these categories:
* Blacklisted callsigns
* Terminal Node Controller Identifiers
* Routing aliases
* Special path elements
*** Blacklisted Callsigns ***
The following callsigns are used for documentation and should be dropped
or disallowed as early as possible if a user attempts to use them for their
station callsign:
* NOCALL
* N0CALL
* MYCALL
* SERVER
*** Terminal Node Controller Identifiers ***
The destination station field may optionally be used to identify the hardware
or software being used, in which case the destination callsign will begin with
"AP". Experimental devices may use the "APZ" prefix without contacting Bob B.
Relevant links:
* http://aprs.org/aprs11/tocalls.txt
* https://github.com/hessu/aprs-deviceid
*** Routing Aliases ***
Many callsigns may be used in the routing path to request service from
groups of digipeaters instead of individual specific digipeaters.
Each of these aliases consists of two to five characters, an 'n' original
hop specifier, and an 'N' hops remaining specifier as the SSID.
* Neither n nor N may be greater than seven.
* n must always be greater than or equal to N
* N must be decremented by every digipeater handling a packet
The most widely supported alias is WIDEn-N
Many regions standardize on additional local aliases, which are often referred
to as SSn-N aliases, since the idea originated with state-wide groups for
smaller east coast states. These groups allow local users to flood the network
with SS7-7 aliases without packets traveling outside the intended service area.
See your local regional APRS interest group for more information.
*** Special Path Elements ***
The last hop in a routing path may be a special path element which
instructs other stations to handle the packet in a specific way:
* RFONLY - Do not I-gate this packet to the APRS-IS backbone
* NOGATE - Do not I-gate this packet to the APRS-IS backbone
* TCPIP - Packet originated from Internet source, do not I-gate
* TCPXX - Packet originated from unverified Internet source, do not I-gate. Deprecated