[OZAPRS] APRS Channel Traffic Limits.

[Richard Hoskin]

Hi All,

I read this on the APRS Sig and though it would be of interest to local
APRS
users in VK.

Darrly's comments (below) can be verified by calculations I did some time
ago on APRS traffic channel limits. These calculations and other APRS
channel information can be found at
http://vk3.aprs.net.au/rfbandwidth.shtml

Cheers
Richard.
VK3JFK

----------------------------------------------------------------------

Subject: RE: Ver.2: Another thing I'd like to see...
From: "Darryl Smith" <Darryl at radio-active.net.au>
Date: Sat, 26 Apr 2003 18:01:51 +1000
X-Message-Number: 4


"Ev Tupis (W2EV)" <w2ev at arrl.net> Commented on
>BobDonnell at arkalmus.com wrote:
>>
>> Then you need the whole AX.25 protocol stack, and APRS software isn't
>> designed to support connected-mode operations.
>
>I wonder why APRS hasn't exploited the advantages of connected mode
more.  Hmmm.
>
>Ev, W2EV

Just in case this is not tounge in cheek, I will note why this IS NOT a
good idea.

Well, lets think about the advantages. You have a guarentteed delivery,
at the expense of increased channel utilization.

If a packet gets though then you have just killed the channel for 100%
more time than just transmitting. If the packet does not get through for
some reason, the same data needs to be transmitted a 2nd time, and will
retry until it is in range. This might be 10 times, each maybe 5-10
seconds apart if there are no digis in range. This is not good as
packets are likely to be corrupted thanks to the hidden transmitter
problem with transmitters often getting a lot further than a receiever.
And some station has forgotten to turn the volume on the receive on the
radio up you have problems.

I a HIGHLY distributed network running ALOHA you can run at about 19%
maximum channel use if you want packets to actually all get through on
average. [With a slight mod of having packets start on the 1PPS second
mark that could be 38%]. Any more than this and packets will get
corrupted very quickly. [10base2 could get about 86% from memory thanks
to some other measures including Collision Detection]

Once you add ack's and retries the availability of the channel goes down
significantly. Assuming that EVERY packet is acknowledged, then the
maximum utilization of the channel cannot exceed 10% with position
reports before the channel is too full. That is 6 position packets per
minute. If just one station is transmitting but not getting into the
digi, and had 5 retries per transmission - and one beacon per minute,
then just 3 other users could use the channel.

With APRS as it is we can have about 12 positions per minute before
problems start to occour. If slotting was implemented we could get 24...
If we assign each transmission to a particular timeslot - a technique
commonly used in events (I used it in the Olympics (Working for
Winemiller www.winemiller.com) and in IronMan (Working for Lateral
Linking www.lateral-linking.com.au)) - we can get 100%

During the oympics I found one company using some GPS positiining
equipment, and they had 1 channel per GPS, and it was connected mode.
Oh, and it didn't work from memory..


Darryl




_______________________________________________
ozaprs mailing list
ozaprs at marconi.ics.mq.edu.au
http://marconi.ics.mq.edu.au/cgi-bin/mailman/listinfo/ozaprs