[aprssig] Packet Node on 144.390 ?

[Gregg Wonderly]

Bill Vodall wrote:
> In an area with one or two or three active users total - it wouldn't
> be cost effective to build two separate systems when one would
> work just fine.  Any more users and activity would make sense
> to build a separate system to carry the additional load.
> 
> It all comes down to the airtime usage.

I think its important to step back from this being an APRS on 144.390 issue and 
consider what is really going on.  What is really going on is packet radio 
traffic using existing digipeaters.  The PID in the AX.25 packet is about 
specifying packet content type.  APRS is supposed to be using a predefined 
value, and some implementations don't.  When TCP/IP was prevalent on packet 
radio, there wasn't a separate network for FTP vs telnet vs ...  Because they 
all shared a common protocol base, and because the system components had no 
problems with interpreting what was in the packet because of AX.25 PID, IP 
protocol and TCP protocol types, everyone got along.

Having new/different PIDs on the APRS network is only an issue because of two 
things. Either additional, unacceptable loading in a area, or because there is 
an application which is not using PID at the AX.25 level.  KISS is the level 
where PID is visible to software that the user is in control of.  If a user is 
using conversational mode TNC functions, then it's the TNC that decodes the 
AX.25 and manages the PID issue.

Probably 1200bps packet radio on 144.390 is of limited use for most data 
applications of any substantial TX time because the hidden transmitters will 
clobber a lot of packets.  That's probably the strongest argument against using 
anything on 144.390, except APRS.

But, I'd say that local needs prevail, and if, in your area, you can get by with 
the desired results for the users of the network in that area, then using 
existing resources is probably more cost effective anyway.

Gregg Wonderly
W5GGW