| |
ZL3AI > APRDIG 01.03.03 09:37l 292 Lines 10802 Bytes #999 (0) @ WW
BID : 956-ZL3AI
Read: GUEST
Subj: TAPR Digest, Feb 26, 5/7
Path: DB0FHN<DB0ZWI<DB0HST<ON0DXC<WA7V<WB0TAX<W4JAX<IK6PYS<VK3TE<VK6HGR<
ZL2BAU<ZL3VML
Sent: 030228/1309Z @:ZL3VML.#80.NZL.OC #:60647 [Chch-NZ] FBB7.00i $:956-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: RE: Holy Grail of APRS Network Performance
From: Bob Bruninga <bruninga@usna.edu>
Date: Wed, 26 Feb 2003 16:51:03 -0500 (EST)
X-Message-Number: 31
On Wed, 26 Feb 2003, Henk de Groot wrote:
>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.
>
>What is the other incompatibility?
Beacon Net does not use a standard APRS TOCALL. (APxxxx, CQxxxx, BEACON,
QSTxxx, ALLxxx, or any of the other standard ones)... Thus BeaconNet
packets are ingnored by any APRS compliant system which filters them out
(in order to preserve ALTNETS). I had suggested that BeaconNet use
CQxxxx but BeaconNet wanted to use all 6 bytes to carry information.
THis comes home to you sometimes when you are bored with APRS and want to
tune your mobile over to the BEaconnet frequency to listen for any DX.
With the APRS compliant D700 and D7, you can't decode anything because of
these two bytes.
Im not knocking BeaconNet. It has its purpose, but it is frustrating to
have APRS equipment and software and not be able to monitor BeaconNet
during a meteor shower or any other propogation enhancing event, without
having to use special software. (because of two bytes)...
Bob
----------------------------------------------------------------------
Subject: Re: More APRS weather
From: "Spider" <spider@rivcom.net>
Date: Wed, 26 Feb 2003 15:19:47 -0700
X-Message-Number: 32
Scott,
FireNet reports Ships and Buoy's as well as C-man stations.
Jim, WA6OFT
----------------------------------------------------------------------
Subject: RE: More APRS weather
From: Miller Scott Contr 30SCS/FTI <Scott.Miller@vandenberg.af.mil>
Date: Wed, 26 Feb 2003 22:21:19 -0000
X-Message-Number: 33
Got any samples of what they report and how?
----------------------------------------------------------------------
[commercial content deleted]
----------------------------------------------------------------------
Subject: PCSAT BBS is OFF
From: Bob Bruninga <bruninga@usna.edu>
Date: Wed, 26 Feb 2003 18:10:58 -0500 (EST)
X-Message-Number: 35
PCSAT BBS experiment ENDS
As PCsat is only 36 hours away from re-entering its eclipse season, we
must make sure that NO ONE attempts to use the PBBS any more, as it drains
the batteries, and once we loose it, then we lose it for the next 2 months
or more. SO we are asking to get the word out that the BBS experiment on
PCSAT is over.
Please return to normal ops. This means.
NO CONNECTIONS TO or THROUGH PCSAT and no CONNECTIONS to PCSAT's BBS.
Please use UIDIGIPEATS only and for routine operations, avoid opertions
after dark and before sunrise..
Last time, we maintained FULL ops over a MONTH into eclipses until she got
overloaded over Europe. We hope to do this again as long as no one runs
her down with a BBS attempt... It only takes one to go into negative
power budget.
We have had two resets today, and that is scary. Thus this termination.
Thanks
Bob
----------------------------------------------------------------------
Subject: TXD (Final answer?)
From: Bob Bruninga <bruninga@usna.edu>
Date: Wed, 26 Feb 2003 18:31:54 -0500 (EST)
X-Message-Number: 36
What is the shortest TXD that works RELIABLY through an OPEN-SQUELCH TNC,
such as the Kantronics KPC-3 or similar?
Has any one extensively doceumented this?
One person is needing to handle over 100 trackers. I'm thinking Mic-E
formats and shortest possible TXD's and using SSID routing. (Thought this
would require UIDIGI or DIGI_NED).
We need to engineer this detail to get best performance (not on 144.39!)
Bob
----------------------------------------------------------------------
Subject: once upon a stolen car?
From: wes@johnston.net
Date: Wed, 26 Feb 2003 15:59:35 -0800 (PST)
X-Message-Number: 37
I remember about a year ago, there was a SUV stolen around Sioux City and
was recovered in a meth lab south of town. Can anyone tell me know the ham
who owned it was and a date?
Have searched the aprs archives on tapr, and as usual, they aren't pulling
it up for me.
Thanks!
Wes
----------------------------------------------------------------------
Subject: Re: once upon a stolen car?
From: "hasan schiers" <schiers@netins.net>
Date: Wed, 26 Feb 2003 18:30:54 -0600
X-Message-Number: 38
Hi Wes
That would be Dave Kaplan WB0WNX (our neighbor to the west) I don't know the
date.
73, hasan
----------------------------------------------------------------------
Subject: RE: TXD (Final answer?)
From: <BobDonnell@arkalmus.com>
Date: Wed, 26 Feb 2003 17:00:44 -0800
X-Message-Number: 39
Hi Bob, and all,
TXD is incredibly dependent on the T/R switching characteristics of the
radio. To give you an example, in about 1985 K7VE and I did some tests
with radios that had very rapid T/R and R/T switching times, because
these radios did not need to re-lock the PLL between transmit and
receive conditions. I was using an Icom IC-22S and AEA PKT-1. John was
using a Wilson WE-800 (with the internal amp disabled) and GLB PK-1(?).
John's GLB TNC had better granularity in terms of TXD settings - he was
able to get down to 28 mS for transmit time, and I had the PKT-1 (with
40 mS granularity) running at 40 mS, as low as it would go. This made
our connected-mode ack packets shorter than most other stations' TXDs.
Both stations were operated open-squelch, or connected directly to the
discriminator, and dependent on the demodulator chip's lock detect
output for DCD - not quite as robust as TrueDCD, but much better than
the energy detect and radio squelch switch that closed-squelch operation
uses.
If you want to find out how quickly the TNC itself can respond, you can
test any TNC combination "on the bench" by wiring the TX and RX audio
paths together, some times referred to as a loop-back configuration.
With appropriate cables and adapters, several TNCs can share an audio
"LAN" this way - I used to do this regularly when I worked at AEA, to be
able to cause connections and data transfers to happen between TNCs, and
frequently with a 3rd or 4th TNC in the loop to monitor the "on air"
signaling.
73, Bob, KD7NM
----------------------------------------------------------------------
Subject: Re: TXD (Final answer?)
From: Jeff King <jeff@aerodata.net>
Date: Wed, 26 Feb 2003 19:17:13 -0600 (CST)
X-Message-Number: 40
Impossible question to answer Bob because TXD length is a function of
transmitter lockup as well as flag times.
On the Kenwood APRS HT, at 1200 baud, reliable decodes can occur with a TXD
of around 70-80ms. I commonly run my Kenwood 7950 at 100ms.
I'd say the TXD would be a function of about 2-3 flag times and then TX
lockup time. At 1200 baud, that would be about 20-30ms + TX lockup.
----------------------------------------------------------------------
Subject: Re: TXD (Final answer?)
From: Jeff King <jeff@aerodata.net>
Date: Wed, 26 Feb 2003 19:19:51 -0600 (CST)
X-Message-Number: 41
Oh, another trick I have used in AVL (not APRS) is to advance the transmit
keyip time by the amount of time the radio's PLL takes to lock. Most (all)
radios will not enable TX until the PLL locks, and this can be measured. So
if you are running a slotted system, you can "overlap" the frames by the
amount of time the transmitter's PLL takes to lockup. That can often buy
you 50-80ms making a effective TXD of 30ms (at 1200 baud).
----------------------------------------------------------------------
Subject: Re: TXD (Final answer?)
From: "Steve Slay" <snslay@swbell.net>
Date: Wed, 26 Feb 2003 20:10:30 -0600
X-Message-Number: 42
I can run my Pico Packet with my Kenwood 541 at 15ms.
Steve Slay
KC5MVY
Where am I now? http://www.findu.com/cgi-bin/find.cgi?call=KC5MVY
See the weather RADAR
http://www.findu.com/cgi-bin/find.cgi?call=KC5MVY&radar=LBB
"Only two things are infinite, the universe and human stupidity, and I'm not
sure about the
former." Albert Einstein
----------------------------------------------------------------------
Subject: Handling 100 3-min trackers
From: Bob Bruninga <bruninga@usna.edu>
Date: Wed, 26 Feb 2003 21:54:46 -0500 (EST)
X-Message-Number: 43
I was asked how I would handle 100 3-min trackers in a 3 digi event:
Easy:
1) Use Mic-E packets, (220 ms)
2) Short TXD's (100 ms)
3) SSID Routing (UIDIGI or DIGI_NED digipeaters) (total packet 330 ms)
4) Crossband dual port digis (36% CSMA capacity instead of 18% ALOHA)
DETAILS: 330ms packets yields 3 packets per second or 180 packets per
minute for 100% channel capacity. Times 18% is 33 per minute or 100
packets in 3 minutes. Just on the optimum for an APRS ALOHA channel.
Note, SSID routing accounts for 20% of the savings since each packet is 7
bytes shorter than with WIDE3-3.
CROSSBANDING: This is the key point to minimize QRM on the uplink
channel:
1) DIGIS all listen on tracker VHF channel and digipeat full
duplex on UHF channel 1 using SSID routing (3 hops).
2) All 3 digis also have UHF receiver and all hear each other for carrier
sense collision avoidance and relaying the second and third hops.
Thus the digis do not add QRM to the uplink channel. The digis all use
CSMA because they all hear each other, and they then have TWICE the
throughput (CSMA has 36%, twice the ALOHA 18% capacity). Thus the entire
100 trackers (a full ALOHA channel) are only taking up half of the
available UHF channel. So the UHF system still has much available
capacity for all the other traffic. Plus, due to CSMA hold off, and the
fact that they have TWO receivers bundling packets, waiting for the
channel to clear, these bundled frames save 100ms of TXD each, or 33% of
the packet load!
Several dozen of additional fixed and two-way messaging stations can be
added to that extra capacity on the UHF channel. Or if you want to take
even better use of this availble double capacity, add a second VHF receier
at each digi on VHF channel B. Put another 100 trackers or fixed statios
there too, all combiningonto the one UHF channel.
Again, their packets see no inbound collisions, and yet their TXD is saved
because they get bundled on the UHF output. Still anyone/everyone can see
EVERYTHING by monitoring the UHF channel. But they uplink on either the
tracker or the support VHF uplink.
That can make a very reliable 1200 baud channel system that will fly.
Thats 200 3 minute trackers. Or a total througput of 65 packets per
minute compared to less than 12 if you do it the normal way...
Now, what is all the software or hardware digis that can handle 2 or 3
simultaneous 1200 baud inputs and one full duplex 1200 baud output and
supports SSID routing?
de WB4APR, Bob
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
