[aprssig] Packet Node on 144.390 ?
Gregg Wonderly
gregg at wonderly.org
Tue Sep 12 07:46:49 EDT 2006
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
More information about the aprssig
mailing list