| |
ZL3AI > APRDIG 03.10.03 09:38l 220 Lines 9268 Bytes #999 (0) @ WW
BID : 2069-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 30, 12/16
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<WB0TAX<N1UAN<ZL2BAU<ZL3VML
Sent: 031002/1447Z @:ZL3VML.#80.NZL.OC #:9566 [Chch-NZ] FBB7.00i $:2069-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: APRS in a coke can...
From: "Scott Miller" <scott@opentrac.org>
Date: Tue, 30 Sep 2003 14:40:56 -0700
X-Message-Number: 55
http://www.indystar.com/print/articles/6/078419-4506-031.html
----------------------------------------------------------------------
Subject: Re:THD7AG Problems
From: Robert W Burton <kd4ydc@juno.com>
Date: Tue, 30 Sep 2003 17:30:19 -0400
X-Message-Number: 56
I tried a hard reset...no luck...I think.
When trying to use the PC port, it will "Beep" but then says,
"Communications Failure".
Any ideas?
73,
Robert
----------------------------------------------------------------------
Subject: Re: Digipeater Duplicate Checking is broke
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 30 Sep 2003 17:52:28 -0400 (EDT)
X-Message-Number: 57
On Tue, 30 Sep 2003, Scott Miller wrote:
>>1) there will always be some collisions.
>>2) There will always be some success from DIGI A just about everywhere
>>3) There will always be some success from DIGI B just about everywhere
>
>I guess I'm not following how this is supposed to work. You've got two
>digis equidistant from a fixed station. Both digis have zero DWAIT. A
>mobile somewhere between them is picked up by both digis, and digipeated at
>the same time, give or take a 200 msec in TXD difference. The fixed station
>has a pretty constant multipath situation. How does it ever see ANYTHING
>from EITHER digipeater?
Many things involved:
1) The mobile is only going to get digipeated by BOTH if he is in the
middle
2) Any home station approximately in the middle will probably hear the
mobile DIRECT (they are in the same area)
3) Both digis should have D-Wait set to zero so if they both hear it they
BOTH transmit at the same time. This will somettimes NOT decode in the
area of the mobile (though they will see full signal strength), but see
#2. See also the discussion that throws in 6 to 20 dB of variability and
then usually anyone in that area will hear just one of the other digi at
any instant more than 10 dB stronger than the other and so will get a good
decode by the FM capture effect.
4) DIGI A will not hear DIGI B and B will not hear digi A, because with
Dwait set to 0, they both are supposed to key up at the same time.
This cancels any DUPE that would propagate further.
4) digis in ALL other directions from A will hear A's and propagate it.
5) digis in all other directios from B will hear B's and propagate it.
Thats how it works...
Bob
----------------------------------------------------------------------
Subject: RE: Random backoff
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 30 Sep 2003 18:00:11 -0400 (EDT)
X-Message-Number: 58
On Tue, 30 Sep 2003, Jeff Thomas - KD4EVB wrote:
>">Each digi does a random 'back off' before retransmission of a packet."
>
>We've got most of that in SLOTTIME and PERSIST parms now. The problem
Hold on. SLOT TIME and PERSIST only work in a connnected envrionment with
retries. (IE, regular packet) APRS is a UI system that has no retries,
thus no PERSIST. Yes we can assign SLOTS based on GPS timing, but NONE of
the mobiles can currently do that. Yes, a great idea, but it would need
new hardware...
That is a separate issue from just fixing what we have now that is broke
now. But a good project for the future...
Bob
----------------------------------------------------------------------
Subject: Re: Random backoff
From: "Jeff Thomas - KD4EVB" <kd4evb@hotmail.com>
Date: Tue, 30 Sep 2003 18:00:12 -0400
X-Message-Number: 59
At least one or two groups of "brave" sysops are about to (or are in the
midst) of experimenting with such a setup, they are also adding in a Linux
igate and some smart routing between the two freqs to keep unwanted "DX" out
while maintaining local traffic. I'm looking for the messages (in the pile,
hopefully I didn't delete them as I try to manage a few hundred messages on
my hotmail account) or I'd post some of it if the author approves as most of
the best stuff has been in the direct emails between digi sysops lately.
Maybe if these folks are reading this, they can refoward their previous
direct messages to me. Lot of folks talk about dual freqs, but few laid out
the details of the concept like these guys did.
When I get things tidied up and sorted out, I'll post the better ideas out
to the website where it'll be much easier to reference and digest compared
to the list traffic. Gotta strip out the email addresses and so forth
before posting them on the web to keep the spammers at bay and I imagine
some folks don't want to be named/located as of yet while they try their
experiments. Hopefully they will make the results known along with the raw
traffic logs. Then, just then, we might actually start to accomplish
something on this problem versus everyone having an opinion they demand is
right but no real world tests/traffic logs to back it up.
While a lot of folks (including myself I guess) are battling over what is
actually at fault while ingnoring the root of the problem in all cases, some
folks out there are experimenting towards a better way, grin.
73 de Jeff, KD4EVB
www.qsl.net/kd4evb
----------------------------------------------------------------------
Subject: RE: Random backoff
From: "Scott Miller" <scott@opentrac.org>
Date: Tue, 30 Sep 2003 15:14:50 -0700
X-Message-Number: 60
Smarter digis (and back channels) solves a LOT of problems. It's just going
to take a lot of new hardware to do it right. I think the first step in
that direction is replacing proprietary, closed-source systems like
KPC-3/3+'s with industrial PCs running DIGI_NED or something similar.
Here's my low-tech proposal for increasing usable bandwidth for trackers...
add a second VHF frequency for TX-only trackers. Require that all trackers
on that frequency use a timeslotting algorithm that uses GPS time for
synchronization and assigns slots based on the tracker's callsign/ssid.
I'll work out the math later on what your usable channel load is, but it's
bound to be a lot higher than Aloha.
Don't have the digipeaters transmit on that frequency at all - what you do
with it at the digi depends on how much work you want to put into it. But
here's some options...
Phase 1 - Just digipeat the packets back out on 144.39. At least the digi
has better luck with collision avoidance because it can actually see most of
the local traffic.
Phase 2 - Burst it all out once every minute or two on 144.39, saving a
bunch of TXDs. This can be set up with pretty simple hardware.
Phase 3 - Burst it out on 144.39 but local only, and also drop it on a UHF
backbone. The backbone gets it to the nearest IGATE, and allows any digis
on the backbone to 'subscribe' to whatever traffic they want to pass to the
local area on VHF.
You can add more input channels as needed - your output channel's going to
hit a limit eventually, but it's a rather high one if you've only got a
couple of digis overlapping and they can coordinate timeslots with each
other. And running 2400 or 9600 baud here makes sense. Actually, how
about...
Phase 4 - Digis on 144.39 output at most maybe 10 seconds of traffic per
minute. Traffic is prioritized based on what's changed and how long it's
been since a station got a packet out. The full feed goes out only on 70cm
at 9600 baud.
You still get to run dirt-cheap trackers on radios designed for audio only,
and the usable capacity of the system scales to orders of magnitude better
than what we've got now. Hell, save yourself a few cents and eliminte the
carrier detect on your tracker - with no digipeater to listen for, the
chances that you're actually going to hear another tracker in your time slot
are very low.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: ***New*** TRACEn-N (LANn-N) Paradigm
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 30 Sep 2003 18:10:03 -0400 (EDT)
X-Message-Number: 61
On Tue, 30 Sep 2003, Scott Miller wrote:
>I keep looking at my Xastir map and trying to figure out how to apply this
>to the local area, but I'm just not getting it. I guess it's still the
>mobiles passing through that get me. How do they get to my IGATE when they
>don't know the local settings, and can't get there with WIDEn-N? Even
>within the 'LAN', there are plenty of areas that would take more than one
>hop to reach the IGATE, especially for a mobile.
Have you seen the MAP by James Jefferson on my FIX-144.39 web page? It
shows that a 1 or 2 hop path will get you to an IGAte almost ALL the time
in California. The path of RELAY,WIDE or WIDE,WIDE is a 2 hop path and
should work for anyone anywhere...
http://www.ew.usna.edu/~bruninga/aprs/fix14439.html
But guess what? In a lot of california, local hacks have disabled RELAY
and WIDE. THus the only thing that works is WIDE2-2. BUT users think,
duh, if 2-2 is good, then 3-3 must be better! And since 5-5 should get
me to all of california, then Ill just use that instead.
Thus users expectations and understanding of APRS is quite flawed indeed.
And until we CHANGE the WIDEn-N flood everything mentailty, we are stuck..
de WB4APR, Bob
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
