¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io

Re: What can you add to APRS?


 
Edited

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

Join [email protected] to automatically receive all group messages.