| |
ZL3AI > APRDIG 01.03.03 09:37l 252 Lines 9757 Bytes #999 (0) @ WW
BID : 955-ZL3AI
Read: GUEST
Subj: TAPR Digest, Feb 26, 4/7
Path: DB0FHN<DB0ZWI<DB0HST<ON0DXC<WA7V<RZ6HXA<SP7MGD<VK7AX<VK3TE<VK6HGR<
ZL2BAU<ZL3VML
Sent: 030228/1306Z @:ZL3VML.#80.NZL.OC #:60646 [Chch-NZ] FBB7.00i $:955-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Holy Grail of APRS Network Performance
From: Bill Vodall - WA7NWP <wa7nwp@yahoo.com>
Date: Wed, 26 Feb 2003 12:15:29 -0800
X-Message-Number: 22
>if somone does try to hear DX on 144.39, the channel is so saturated that
>no one could ever hear a DX packet anyway..
>
>Bob
Ah - but one of the advantages of NOID along with an archive of the raw,
non-dupe filtered packets, is that it's possible to "data mine" for DX
packets. This could be developed as much as desired to the point of
looking for changes by time of day, by season or even ringing a big bell if
there's a current openings.
Bill, WA7NWP
----------------------------------------------------------------------
Subject: Re: Holy Grail of APRS Network Performance
From: Miller Scott Contr 30SCS/FTI <Scott.Miller@vandenberg.af.mil>
Date: Wed, 26 Feb 2003 20:17:07 -0000
X-Message-Number: 23
Is there any behavior defined for the receiver if the transmitter exceeds
the specified number of packets per hour? Due to message traffic or
queries, for example? What criteria should the receiving station use to
determine if a packet counts against the expected rate?
Scott / N1VG
----------------------------------------------------------------------
Subject: Another report element
From: Miller Scott Contr 30SCS/FTI <Scott.Miller@vandenberg.af.mil>
Date: Wed, 26 Feb 2003 20:21:41 -0000
X-Message-Number: 24
I've just added a 'country code' element to the OpenTRAC spec and I wanted
to get opinions on its use.
It's defined simply as an ISO 3166-1 2-digit country code, optionally
followed by an ISO 3166-2 subdivision code (e.g., for indicating state or
province.) So far, the spec just states that it should indicate the country
from which a station is operating, or for a ship, its country of registry.
(Or should that be flag? Is there a difference?)
I think this might apply more to BEACONet. Ev, any thoughts?
Scott / N1VG
----------------------------------------------------------------------
Subject: Re: More APRS weather
From: "Ronald Reams" <wa4mjf@worldnet.att.net>
Date: Wed, 26 Feb 2003 15:32:29 -0500
X-Message-Number: 25
Every ship has a callsign. US Navy ships are Nxx. US flagged
merchantmen, as well as passenger liners, would have a FCC assigned call.
73 de Ronnie
----------------------------------------------------------------------
Subject: Re: 144.39 channel loading
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Wed, 26 Feb 2003 21:25:56 +0100
X-Message-Number: 26
At 07:31 25-2-03 -0600, hasan schiers wrote:
>A typo....250 to 280 packets per TEN minutes. Sorry.
That's 25 packets a minute. I could say "impressive" but I will not because
the only way I see this is possible if somebody is dumping packets from the
IS stream with a lot of power, blowing everybody else away. Mulit channel
access under ALOHA conditions is max 18% channel utilisation, but with
single channel access you can reach 100% utilisation; i.e. one station
claiming the whole channel and transmitting continuesly...
>That would be an average of 14.6 packets per minute.
Still looks quite high to me.
18% of 60 is 10 seconds, so every 60 seconds you can have 10 seconds worth
of data. So these 14.6 packets should together shall not take more than 10
seconds to transmit. That is 680 ms per packet. Subtract 250 ms TX delay,
then the duration of the data part is 430 ms.
You send with 1200 bits/second. In this 430ms you can therefore send 1200 *
0.43 = 516 bits; this are 516/8 = 64 bytes on avarage per packet.
Assume a path with 2 digi calls, you need:
flag: 1 byte
destination call: 7 bytes
originator call: 7 bytes
digi one: 7 bytes
digi two: 7 bytes
UI primitive: 1 byte
PID: 1 bytes
CRC: 16 bytes
flag: 1 byte
That's 48 bytes; that leaves 16 bytes for the data part of the packet.
Conclusion: it is possible to send very short packets like that and have
14.6 in a minute within the physical channel limit for ALOHA type access.
But only under these conditions. You can fit a position report in 16 bytes...
If you have a kenwood which already claims 500 ms TX delay then you only
have 180 ms left for the packet, not enough to send a UI packet... That's
why I calculate with 1.5 seconds per packet. With 10 seconds to spend in
every minute you can send 10 / 1.5 = 7 packets. That's reasonable I think.
With 1.5 seconds I keep on the safe side; Bob's one second per packet is
also fair when using a "normal" TX delay, but not with the half second TAPR
TNC2 default TXD that is a fixed setting for the TH-D7E in APRS mode...
With 14.6 packets/seconds I can only assume you have a strong station in
the area that just blows the other stations away, which is another way to
defeat collisions (at the expense of weaker stations)....
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Re: 144.39 channel loading
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Wed, 26 Feb 2003 21:53:46 +0100
X-Message-Number: 27
Hello Bob,
At 11:59 25-2-03 -0500, Bob Bruninga wrote:
>equally get heard) peaks and then goes terribly worse. SO packets per
>minute is a meaningless number unless it is also compared to RELIABILLITY
>of any one station to be heard.
What you measure is not channel load but channel throughput. So it is
correct that you get a low figure because on your overloaded channel the
throughput is bad. It is also correct to conclude from the measured
thoughput that the channel can be utilized better, you only do not know if
you have to increase or decrease the number of packets to achieve that :-).
I think the best to determine the channel load is not to detect packets but
to detect noice or carriers, or te reverse: detect silence. In every minute
you shall have 18% or 10 seconds noice or 82% or 50 seconds silence for
optimal usage under ALOHA conditions.
Just counting packets makes assumptions about the used TXD and average
packet length. When detecting noice you will also detect 100% channel load
when it is 800% overloaded. You can also count the received packets and
calculate the channel throughput percentage, it will be far below the 18%
if the channel is 800% overloaded.
Practical problem to detect noice or carries is that TNC's block a direct
view to the radio channel. This problem was already found years ago when
people wanted to make AX.25 protocol stacks with adaptive parameters that
adjust itself depending on the channel load. That did not work with
unmodified TNC's. That is why people invented 6pack and such to pass the
information from the channel to the protocol stack to allow it to adapt its
parameters. The FlexNet group in Germany got very far with this with good
results. You can steal some ideas from them, but I think they will not fly
in an environment dominated by TNC's with factory firmware.
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: RE: Holy Grail of APRS Network Performance
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Wed, 26 Feb 2003 21:58:42 +0100
X-Message-Number: 28
At 12:50 25-2-03 -0500, Ramon F. Kolb wrote:
>has an inherit mechanism to indicate the number of transmissions per
>hour (the to-call SSID is used for this).
Oeps! I want to add the generic digipeating rules for BEACONet to DIGI_NED
but this is realy killing the idea. In APRS the destination call SSIG is
used for digipeating so I cannot have APRS and BEACONet at the same time.
Thanks for the remark, I think I have to include a specific rule file for
BEACONet now instead of adding it to the APRS rules...
I just saw that this TX number is on originator call, but the SSID on the
desitination call is used for an antenna pointing vector. Anyway, not
available for digipeating...
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: RE: Holy Grail of APRS Network Performance
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Wed, 26 Feb 2003 22:00:03 +0100
X-Message-Number: 29
At 13:08 25-2-03 -0500, Bob Bruninga wrote:
>Yes, a great idea, but unfortunately that use of SSID is one of the two
>main incompatibilities between APRS and Beaconnet. Because in APRS, the
What is the other incompatibility?
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Re: Holy Grail of APRS Network Performance
From: Bob Bruninga <bruninga@usna.edu>
Date: Wed, 26 Feb 2003 16:18:14 -0500 (EST)
X-Message-Number: 30
On Wed, 26 Feb 2003, Miller Scott Contr 30SCS/FTI asked about the new PHGR
format for evaluating network Performance:
>Is there any behavior defined for the receiver if the transmitter exceeds
>the specified number of packets per hour? Due to message traffic or
>queries, for example? What criteria should the receiving station use to
>determine if a packet counts against the expected rate?
Normally PHG is only included in POSITION packets and position packets
are usually sent at a known rate. But you have raised a GOOD point about
QUERY responses. SOLUTION:
If a non-standard PHGR position packet is sent out of normal timing, the
"R" digit of the PHGR format is stuffed with a "0". On receipt, any PHGR
packet with an "R" value of "0" is ignored for the purpose of channel
reliability statistics... (or both the number transmitted and the number
received that hour are both incremented by 1. The choice is up to the
process doing the data collection...)...
And I have updated my SPEC ERRATA page to add this PHGR discussion.
http://www.ew.usna.edu/~bruninga/aprs/errata.html
Bob
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
