开云体育

Greetings, Nigel.

This will be a rather long and rambling treatise to cover your questions.

The important thing to know about APRS is that it was designed for local tactical information over low-bandwidth radio links, not global messaging over the Internet. The APRS-IS Internet backbone is a useful extension to APRS, but it is merely a cool extra feature; it is by no means an essential part of APRS.

As such, it is perfectly expected that APRS networks will be entirely on RF over a contiguous geographical region. For example, a local charity bicycle ride event I work covers about 4 counties and uses APRS entirely over RF on a non-standard frequency (partially because they don't want ambulance-chasing lawyers and mass-media reporters heading to any problems that might occur, but mostly so they don't have to wade through irrelevant [to them] users of APRS to find their information or lose their information due to channel congestion). This radio network has no Internet connection at all. Similarly, our county ARES group runs APRS weather stations all over the county to provide micro-climate data to county Emergency Management. It runs entirely over RF to get the data to the county offices, and then over their in-building intranet to get to their GIS systems from our co-located I-gate.

Similarly, there is no "global server" in APRS. Like almost every other mode in amateur radio, there is no central control managing the field stations, unlike, for example, cellular telephones managed by the regional central switching office that also controls the cell tower base stations. APRS is an arbitrary peer-to-peer network, rather than a star-topology hub-to-leaf-nodes network. Some people have implemented specific services on APRS (such as the ANSRVR, WHO-IS, and EMAIL-2 pseudo-stations), but they are just other callsign-identified arbitrary points on the network that just happen to be located on the Internet backbone so they can be reached globally.

An RF-only station can easily set up a service, but it would only be reachable by stations within RF contact (directly or via digipeater), or via a Tx I-gate from more distant locations. For example, the APRS QRU service is deliberately intended to be a local RF service, not an Internet service. It is intended that a local RF user can send a text message to QRU with an information request (ex.: RP2M to find a list of local 2-meter analog repeaters), and any nearby stations that support QRU service and have this information will respond. The local RF user initiating the request has no need for a QRU response from the opposite side of the globe (and such a response would be totally useless anyway).

Most of the information in APRS is collected directly from the originators, not from central servers. Referring to the bicycle event again, the consumers (both redundant Net Control stations) receive the position reports from each support vehicle mobile station directly or via digipeater; the data isn't routed through a global server on the Internet. As such, each local peer in the APRS network is not only capable of sending its traffic via undirected multicast to all nearby stations, but can hear all other nearby stations (and digipeater relays for more distant stations) directly and use the pieces of information it hears as it chooses without needing to get the data via some central gate-keeping (and Single Point Of Failure) server.

Note that I specifically designed my YAAC software to function in the "off the Internet" mode. That is why it carries its own local copy of the map data instead of downloading it constantly from an Internet server. Yes, it can connect to the APRS-IS Internet backbone and use some other Internet-based services, but it is fully capable of functioning without them (and most other APRS client programs are, too).

When you hear the term "digipeater", it refers exactly to the "parrot type simplex repeater" you asked about in your message, although they are somewhat smarter than a dumb relay so as to avoid unnecessary retransmissions of packets (see Bob Bruninga's explanation of the New-N paradigm for digipeating to understand why). There are many different implementations of digipeaters available, either using commercially manufactured TNCs with alternate firmware, to software TNCs with digipeater capabilities, to conventional TNCs with custom applications behind them to perform the digipeating operations. The only thing they have in common is having a radio transceiver attached to them. Of course, such automated relay stations require appropriate authorizations from your national governmental authority (what authorizations are required vary with the jurisdiction).

aprs.fi is an Internet-based consumer of APRS packet data. It does not produce anything back to the APRS network (not an APRS data source); rather, it is a data assembler, combining received historical APRS packet data with Google Maps and several other data sources to provide a composite display. But any good APRS client does the same job to some extent.

So, if you want to provide an APRS data "service", you need to define what that service is going to provide and how clients are going to ask for it (such as the WHO-IS service accepting a callsign as input and responding with the name, licensing jurisdiction, and license class of the callsign holder), and then have your APRS software be prepared to recognize service requests when they come in and answer them, just as the QRU service does. And it shouldn't matter what path your clients use to request the service, just as it doesn't matter on the Internet what kind of technology your Internet service provider used to link you to the rest of the Internet.

I hope this helps explain APRS and remove some of the misconceptions about it being an Internet-dependent system (which it is not).

Andrew, KA2DDO
author of YAAC
________________________________________
From: [email protected] <[email protected]> on behalf of Nigel <zs6rn@...>
Sent: Sunday, January 12, 2020 3:43 AM
To: [email protected]
Subject: [yaac-users] Stand alone (no internet) field APRS 'service'

Hello from sunny South Africa :-)
Recently I posted a question on another APRS forum and unfortunately have received only one response and regrettably that reply has not fully answered my query (as an aside it was as a P.M. so it seems that none of the forum members willing to share their knowledge). Am now asking here (YAAC users) in the hope that someone will be able to respond so that I can better understand what is required for a stand alone APRS 'service'.

Advance apologies for showing my ignorance but I figure that if I do not ask the question, then I will remain in the dark regarding how APRS works overall...

1st my current understanding of 'how APRS works':
When using an APRS client e.g. APRSDroid, YAAC or similar, data packets are exchanged with a global server via the Internet via whatever transport medium is enabled e.g. RF and an IGate, Data via the cellular network or even audio from a recording (how I plan on experimenting <smile>) and then to the Internet or perhaps using an Internet connection at a home base.
These data packets convey the information necessary to enable the plotting of objects / stations / whatever on a map positioned according to the appropriate location co-ordinates derived via GPS or entered manually. Other traffic such as messaging is also carried by the data packets and the resulting 'text' displayed in the appropriate 'fields'.
So far so good (I hope).
Now the part I would like to better understand / specific question. What is / are the 'service(s)' being provided at the 'server' end of the APRS infrastructure e.g. and how can a 'standalone' (no internet available / required) service utilising only RF be facilitated so that LOCAL participants can track and be tracked using APRS features e.g. During a local event remote from cellular / data services.
I can visualise a scenario with there being an RF IGate assuming that there is some path to an Internet connection from said gateway, but if there is no Internet available and local tracking of resources and text messaging between stations is required?
Would a RF 'relay' of whatever received (a parrot type simplex 'repeater') provide desired functionality and if yes, what software could be used to implement (Linux preferred)?
Again my apologies for taking up bandwidth with what is probably considered something that is known by even the newest of newcomers to APRS, but I want to learn (and one day implement a portable standalone RF based APRS 'server') so hence the post and exposing my ignorance.
BIG thanks in advance for any and all feedback.
73 Nigel ZS6RN ex G8DEV