?

Again, question #1: are you able to transmit your own beacon? If not, then solve that problem before trying to digipeat other stations' packets.

-------- Original message --------
From: Ian Morrison <imorrison@...>
Date: 5/15/20 19:16 (GMT-05:00)
To: yaac-users@groups.io
Subject: Re: [yaac-users] What can you add to APRS?

?

This is independent of your earlier question about setting up a digipeater. Since you "qualify" as being in an area needing a digipeater, then go for it. I'm talking about areas like where I live where there are almost too many digipeaters.?

?

-------- Original message --------
From: Ian Morrison <imorrison@...>
Date: 5/15/20 14:36 (GMT-05:00)
To: yaac-users@groups.io
Subject: Re: [yaac-users] What can you add to APRS?

Greetings.

After looking at yet another email about adding digipeaters, the thought came up of "What do we really need to add to APRS?"

Except in certain areas, we generally have good coverage with digipeaters, so we don't usually need more of them.

What we need is content. To quote the old Bruce Springsteen song, "there's 57 channels and nothing's on." So what are you adding to APRS? More fixed beacons don't really add value and mobile trackers (unless some other station wants to track that specific mobile) aren't much more useful.

But services, they add value. The QRU service is a simple capability of announcing on demand what services are in the area. So, if someone's driving through and looking for a good 2-meter voice repeater for a rag-chew, they should be able to send to QRU a request for RP2M (two-meter analog repeaters) and get an answer of Objects identifying local repeaters (preferably in correct syntax so a Kenwood radio can one-button tune to the repeater). YAAC supports defining Objects and associating them with QRU categories, so your station could answer a QRU query. To avoid channel clutter, you don't need to be transmitting those Objects all the time, just when someone asks for them. And there are dozens of QRU categories. One category is the INFO category, which allows you to ask local QRU servers what categories of information they provide.

Of course, every one in the neighborhood shouldn't report the same information. Say, each one provide the RP2M or RP70 for their own club's repeater, so all clubs with open repeaters are supported from multiple QRU servers, instead of one Single Point Of Failure announcing all repeaters. This is a little different from Bob Bruninga's Local Info Initiative that expects one high-level digipeater to do it all periodically instead of on-demand, but with the amount of local info that could be available, cluttering the channel with Objects the locals know about is a waste of bandwidth, but announcing it for transient mobiles on-demand is much more effective use of the channel.

Similarly, there are services on the APRS-IS that are useful to RF stations, but they can't be accessed unless there is a transmit-capable I-gate within range of the RF station. Without a Tx I-gate, the service's answer won't make it back to the RF station. So running a Tx I-gate (instead of the less useful receive-only I-gate) expands the usability of RF stations (which is really what Amateur Radio [as opposed to the Amateur Internet] is all about).

Andrew, KA2DDO
author of YAAC

?

Greetings.

?

After looking at yet another email about adding digipeaters, the thought came up of "What do we really need to add to APRS?"

?

Except in certain areas, we generally have good coverage with digipeaters, so we don't usually need more of them.

?

What we need is content. To quote the old Bruce Springsteen song, "there's 57 channels and nothing's on." So what are you adding to APRS? More fixed beacons don't really add value and mobile trackers (unless some other station wants to track that specific mobile) aren't much more useful.

?

But services, they add value. The QRU service is a simple capability of announcing on demand what services are in the area. So, if someone's driving through and looking for a good 2-meter voice repeater for a rag-chew, they should be able to send to QRU a request for RP2M (two-meter analog repeaters) and get an answer of Objects identifying local repeaters (preferably in correct syntax so a Kenwood radio can one-button tune to the repeater). YAAC supports defining Objects and associating them with QRU categories, so your station could answer a QRU query. To avoid channel clutter, you don't need to be transmitting those Objects all the time, just when someone asks for them. And there are dozens of QRU categories. One category is the INFO category, which allows you to ask local QRU servers what categories of information they provide.

?

Of course, every one in the neighborhood shouldn't report the same information. Say, each one provide the RP2M or RP70 for their own club's repeater, so all clubs with open repeaters are supported from multiple QRU servers, instead of one Single Point Of Failure announcing all repeaters. This is a little different from Bob Bruninga's Local Info Initiative that expects one high-level digipeater to do it all periodically instead of on-demand, but with the amount of local info that could be available, cluttering the channel with Objects the locals know about is a waste of bandwidth, but announcing it for transient mobiles on-demand is much more effective use of the channel.

?

Similarly, there are services on the APRS-IS that are useful to RF stations, but they can't be accessed unless there is a transmit-capable I-gate within range of the RF station. Without a Tx I-gate, the service's answer won't make it back to the RF station. So running a Tx I-gate (instead of the less useful receive-only I-gate) expands the usability of RF stations (which is really what Amateur Radio [as opposed to the Amateur Internet] is all about).

?

Andrew, KA2DDO

author of YAAC

?

?