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

开云体育

开云体育

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

Andrew,

As someone who is new to APRS, this sort of information is very valuable.
I am very impressed with the depth and breadth of YAAC.

Many thanks,
Jim, AG5VQ

You can also read:



which includes a list of recommended common groups.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

开云体育

开云体育

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

开云体育

Somehow I missed this over the past few weeks, but it's a great question.? APRS has traditionally been a network of "push" information...the assumption has always been that the digipeater sysops know the local area better than anyone and are best-suited to provide relevant local information.? Of course almost 40 years after the advent of APRS in the amateur community, the proverbial tables have turned.? Now "the computers" know all the local area information better than any single one person could every hope to, and so the paradigm has shifted from a "push" to a "pull" mindset, particularly given the limited bandwidth of the traditional APRS channel.? This begs a few questions in my mind:

1)? What information is still relevant to the sysadmin "push" paradigm?? Location information probably bubbles to the top of my list, but as Andrew indicates...not all location information is created equal.? Being able to "pull" repeater information via the QRU service is arguably a better system than clobbering up channel bandwidth with packets received largely by folks who already know where those repeaters are (and probably have them programmed into their radios).? Other "push" information which is still relevant:? NWS Weather Alerts, Bulletins, and Emergency packets.

2)? So what is relevant in a "pull" paradigm?? Pretty much anything else...traffic speed "signposts", ham radio supply store locations, coffee shop locations, status queries...the list is as long as your imagination...the only question is can you get the information from one source, effectively compress it into an APRS message, and efficiently get it back to the requester?? Standardizing popular data types into a common format (XXXX IN AN OBJECT format) helps drive commonality in radio manufacturers, but as more radios transition to software, this becomes less important as hams learn to process information outside the radio firmware.? (YAAC is a perfect example of this for me...my FTM-400 has a basic packet processor inside the radio and displays location/direction/weather/etc. information on the radio display, but I prefer to export the data out of the radio into YAAC where I can manipulate it much more freely.)? Also in the "pull" paradigm category would be services like SMSGTE, EMAIL2, WHO-IS, QRU, etc.? These services are initiated by the end-user when information is either needed, or information is needed to be sent to another data network.? One might consider services like SMSGTE and EMAIL as a 3rd paradigm..."translator" services between APRS and other data networks.

While many urban areas have significant digipeater coverage, here in the desert Southwest terrain still provides limitations to 2m APRS coverage and 1200 baud digis may not be adequate to provide the quality and reliability of coverage experienced by most urban/suburban APRS users.? As such, providing the ability to more efficiently/effectively utilize APRS on HF bands provides an enormous "service" to those of us who have a "4x4" selector in every vehicle we own.? Andrew has done great work in this respect by implementing the ability to connect YAAC to W1HJK's Fldigi software using KISS TCP.? This has created the possibility for new life to APRS over HF; however, what is needed is standardization of operating mode and frequencies to enable end-users to get their data routed to both APRS-IS and distant destinations.? Direwolf provides similar functionality using KISS TCP, but utilizes the legacy 300 baud AFSK standard originally used for HF APRS.? Other software may provide even more transport options...commonality is what makes a network work.

One piece of software with which I've been experimenting is Jordan Sherer's .? Jordan has provided a UDP port in JS8Call which utilizes JSON to move information in/out of JS8Call, as well control some features of the software.? JS8 mode provides excellent weak-signal performance, and in its normal mode decodes quite nicely down to around -20dB SNR.? I've been running a copy in my truck utilizing a RaspberryPi and a 7" touchscreen for about 8 weeks now and have been impressed with how reliable and seamless the JS8 data comes streaming in...even at the bottom of Cycle 24.? My is truly impressive on most days.? Jordan has implemented some basic APRS functionality into JS8Call which allows the user to send raw APRS packets on-air which receiving stations can port into APRS-IS.? While the functionality is currently only one-way, my experiments with it have yielded the conclusion that JS8 may very well make a decent transport for APRS on HF.? For those of us who spend a lot of time in remote/austere back-country travel, the implementation of a reliable HF solution using APRS would be very welcome.? As such, I've begun preliminary work on coding a "translator" interface which will ultimately connect a YAAC KISS TCP port to JS8Call UDP, allowing JS8Call to function as a Layer 1 modem to move APRS packets over HF.? While the data rate is slower than classic 300 baud packet, the narrow signal bandwidth and weak-signal reliability of JS8 make it an interesting tool for moving APRS data over the air.? The multi-speed modem functionality of JS8Call may provide a way for future development of a "path-aware" modem with self-throttling capability.? The built-in ability to automatically change bands based on time-of-day/propagation conditions adds even more reliability to the "connectivity" puzzle.

Getting back to Andrew's question, there is still plenty to be done to bring "services" to APRS...whether it's aggregating information from other data networks and moving it to APRS "on-demand", or whether it's innovating transport mechanisms to fuse the diligent efforts of multiple existing open-source software developers.? While coding skills are required at some point in the process, ideas are just as essential to give focus to the effort.? Where do you see APRS headed in the next 20 years?

Kurt, KE7KUS