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

[Borja Marcos]

> On 17 Aug 2023, at 22:27, 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.

Oops, I made a mistake by answering on a thread that was going in a different direction. I am not defending some sort of Opentrac
integration or whatever. Just evolving APRS but stil being APRS :)

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

Indeed, I agree 100% with this! Sorry if it seemed otherwise.

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

It depends. Software shouldn’t crash because of corrupt packets. If it does, it is buggy and that means it may have a serious security vulnerability.

But what I was defending wasn’t that. It was just extending the databse backend infrastructure of APRS-IS so that it can store more useful data
and accomodate different transmission schemes for APRS.



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

I am not talking about originating what I agree, would be QRM, of course!

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

Protocols come in layered architectures since many years ago for very good reasons. So, you can do APRS changing the physical layer by transmitting on
different frequencies with different modulation schemes. Still you can converge them on the backend database infrastructure so that, for example, I can send
a short message from a LoRa terminal (say, EA2EKH-15) to a VHF terminal (EA2EKH-7, Kenwood TH-D74) and it will work. It does, I tried.

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

The thing is. Does APRS imply using only one of the very few modulation schemes defined from the beginning? When the Internet was young IP begun working on 
synchronous serial lines. Is IP over Ethernet, or IP over ATM, or IP over FDDI still IP? That’s my point. Of course you can’t pretend to connect an ATM fiber to an Ethernet
port. It won’t work! ;)


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

What I propose is not replacing, but evolving and it doesn’t mean hurting the present infrastructure at all. It also means doing some standardization effort before developers
steer in diverging directions and interoperability is lost.


73,




Borja / EA2EKH