[aprssig] Open Source/Commercial Use acceptable APRS Alternative?

[Bacon At Taha]

What about freezing APRS 1.x as it is now, maybe with minor tweaks (like adding PM10, PM2.5, and similar to the weather report structure), and start work together towards establishing APRS 2.0? Maybe have APRS 2.0 generally follow the 1.x packet paradigm, but distinguish the version somewhere in the packet and ‘clean up’ the fields (removing deprecated features, simplifying and reorganizing the packet structure) from 1.x in 2.0?

That could give a good backwards compatibility path while opening up potential for improvements and innovation.

Erik, N7FYO.

Sent from my iPhone

> On Aug 17, 2023, at 16:49, Steve Dimse <steve at dimse.com> wrote:
> 
> 
> 
>> On Aug 17, 2023, at 12:28 PM, Borja Marcos <ea2ekh at gmail.com> wrote:
>> 
>>> 
>>> The problem with this is "Do we let backwards compatibility kill innovation"?
> 
> It is not an either-or. OpenTrac can be as innovative as they want, but on their infrastructure.
>> 
>> I would begin by defining "what is APRS infrastructure". The digipeater network? The underlaying servers?
> 
> Certainly the digipeaters, and the frequency that coordinates 144.39 as "APRS", and existing streams on the APRS Internet System. The servers are capable of running more than one instance of software to serve OpenTrac streams, so any APRS-IS server owner that wants to support both can do so easily, you just need to pick different port numbers. They do not need to be mingled! If there is interest, a gateway might be developed between the APRS streams and OpenTrac streams. But combining them on one stream means exposing legacy software to packets of types never tested. On RF, it means taking up bandwidth for data that is not APRS as Bob defines it, and that is QRM.
> 
> If you develop a new system, each operator of an RF node would also have a choice of staying on 144.39 or switching to an OpenTrac frequency, or supporting both. Free choice, rather than everyone on 144.39 having to have their bandwidth used by an incompatible system.
>> 
>>> What if, as a bunch of hams, make something that uses the APRS infrastructure (most of which was never actually owned by Bob), and then extends on it, and maybe even breaks a lot of it.   No one owns a frequency, and these days, there seems to be a lot of open frequencies anyway
> 
> The issue is interference. If I put a voice beacon on 144.39 that speaks positions, weather, and messages it is doing the same thing as APRS, but on the same frequency it will cause interference and does not benefit existing users. If I start sending MP3 streams of my voice data on the APRS IS who knows how the existing software will respond. What if I send data packets that freeze one of the common clients? Would the users know I caused it? Would I know I caused a problem? Is that kind of interference acceptable? Even if it don't crash anything, is it OK to use APRS IS bandwidth for it?
>> 
>> Frankly I don't see how it would break anything. 
> 
> But you don't know it won't. Why risk a working system, when it is easy to run it on its own streams where it won't interfere?
> 
>> 
>> To begin with, the original APRS supports three different modems: the 300 bps FSK on HF, 1200 bps AFSK on VHF and 9600 bps. So, what is the problem with
>> adding other transmission systems such as LoRa or VARA which were not available, let alone feasible (at least at an affordable price) 20 years ago?
> 
> All three of those use an identical text format. OpenTrac is incompatible with that format. If you transmit it on 144.39 if you use AX25 the software or firmware will see text packets that look like garbage to it. If you aren't using AX25, you are causing QRM to an existing network frequency.
>> 
>> You can do real APRS using different modulation schemes. 
> 
> Absolutely. But if my "voice APRS" starts speaking APRS data it is unusable to the existing users on 144.39, and causes QRM to them. 
>> 
>>> So someone comes up with "NGPRS" (Next Generation Packet Reporting System) that say, runs on UHF (or even say on the licensed part of the Wifi Band - Humm, even allow non hams in maybe?) that is compatible with the best parts of APRS, drops all the backwards kludges - maybe the stuff that is the old KPC (not KPC+) stuff  or whatever
> 
> A new system on UHF or WiFi is great. Having your own streams are great. But putting it on existing RF networks and streams at best causes QRM and at worst puts the existing users at risk.
>> 
>> 
>>> "OK, it isn't APRS" - You are right.  But when was the last time you saw a Gopher Server vs HTTP?  
> 
> But when HTTP came out they didn't use Gopher's port, they got their own, and the two networks coexisted for a while until the better one won. I'm all in favor of you trying to do that. Just don't hurt the existing network as you try.
> 
>>> Eventually, APRS "Goes away" - sort of.  If everyone has moved on, there will be some diehards left behind (Heck, they even dropped mandatory support for Group 1 fax eventually).  We might even use different modulation etc.  Ham radio is SUPPOSED to be about innovation, so let's innovate - Go with Bob's vision (maybe) expanded for the 21st century, starting say with a clean slate
> 
> Go for it. No one is saying don't innovate. Bob never told other people not to innovate outside of APRS. While he was alive he did not allow that kind of innovation to carry his trademark of "APRS". He had every right to do that. That restriction is gone practically if not actually legally, and if you want to call it APRS 2.0 you won't get sued. Personally I think that disrespects Bob, and if I were involved in that effort I would come up with another name (which among other things would allow you to get your own domains that match). 
> 
> I know Bob would agree with me that an effort to replace APRS should not degrade or risk the existing system in any way. As long as you don't do that I have no objections, and if you don't use his trademark I know he would not have objected either.
> 
> 
> Steve K4HG
> 
> 
> 
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org