Order Tray | Contact Us | Home | SIG Lists

[aprssig] NOSaprs update - cross port digi with callsign substitution

Robert Bruninga bruninga at usna.edu
Wed Jun 22 19:05:17 UTC 2005

>>> <maiko at pcs.mb.ca> 06/22/05 2:08 PM >>>
>Did it occur to anyone that perhaps a key issue 
>is that the APRS sender (user) has too much 
>control over their routing ?

Yep, and that is the basis for the New-N Paradigm,
to at least get control over abusive paths and to
greatly simplify to one basic construct.  Then we can
tell the users the basic rules and let them use the
network while respecting the needs of others.

>The system should do the routing, the sender 
>should only need to provide the APRS packet. 
>The system could manage traceability via user 
>interfaces or utilities.

But that approach is based on one thing:
*having the network KNOW what you want 
  done with the packet*

There are many sysops who are quite happy to 
define where your packets should go, and will
happily make a network do it.  But that kind of
approach on an ad-hoc come-as-you-are
kind of system that APRS is supposed to fullfil
is full of pitfalls and kills the kind of flexibility
that APRS was intended to provide, and that is
to use it for what you need at the time.

>If I'm sitting at my desk, all my IP packets go through
>a default router in our department and out to the rest of
>the world. I certainly don't need to add the equivalent
>of a WIDE2-2 or ECHO or whatever. I let the system do
>that for me.

The internet has infinite bandwidth.  APRS only has 
1200 baud and can hardly handle sending your packets to
the whole state much less flooding the world with it.

>If a local user did not want the system to digi it out
>any further, they could OPT OUT (there's a concept) by
>perhaps doing a VE4KLM > APRS via NODIGI or something.

No the problem is the opposite.  The network cannot
handle the flooding of everyone everywhere.  therefor
the network will cut the range of communications down
to only a very limited area in order to handle the load
and then the end users may be denied the path they
need to do the job at hand.

>I personally can't see any reason for me to decide that
>I only want my packets to go a specific distance. 

Because you want to share the channel with your
fellow ham and not use any more bandwidth than
is required for that transmission.  Limiting power
(range) is the fundamental rule of HAM radio.

>It's of no concern to me. I just want to be able to 
>talk to the person that I'm looking for. 

Ah, but that is point-to-point packet and there are
plenty of other networks and frequencies to do that
on.  That is not APRS.   APRS was designed not for 
that application but for sharing real-time digital data 
with everyone in a limited common ad-hoc network.
Not point-to-point in most cases.

>Let the system do it, and then there is no chance of 
>me overwhelming the network

Ah, but Do what?  Many people have very different needs
for their APRS packets, and very different ideas about 
how they want their packets to be used.  Trying to force 
ham radio operators into a one idea, one-app system has
the potential to kill the system.  HAM interests
are too varried to try to take those draconian steps.

>> No, its like you calling CQ on 3650 and having
>> someone in  California, Colorado and Alabama
>> patching it over to their local VHF repeater.
>> Your name and call would be mud.
>That's not a realistic example :-)

I think it is.  It is taking a transmission of mine
which I have full knowledge of its content and
its caapacity for distribution and then relaying
it to another area, system, channel or what 
have you without my knowledge and having it
arrive in those new areas as if it was sent their
by me with my intentions.  That is the
same thing in my mind about modifying somneone's
chosen path in their AX.25 packet.


More information about the aprssig mailing list