| |
ZL3AI > APRDIG 04.05.03 19:04l 275 Lines 11304 Bytes #999 (0) @ WW
BID : 1231-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 26, 1/5
Path: DB0FHN<DB0ZWI<DB0CHZ<DB0ERF<DB0FBB<DB0GOS<ON0AR<ON0AR<IW8PGT<VK3TE<
ZL2BAU<ZL3VML
Sent: 030429/1355Z @:ZL3VML.#80.NZL.OC #:64801 [Chch-NZ] FBB7.00i $:1231-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Saturday, April 26, 2003.
1. PCSAT Question
2. Re: KPC 3+ and Motorola Maxtrac Quesion
3. Re: Lesson needs to be learned in VA
4. RE: Ver.2: Another thing I'd like to see...
5. RE: Ver.2: Another thing I'd like to see...
6. Re: Running Multiple COM ports from a one port Laptop
7. Recommendations; Was: Just trying to understand.
8. NSTAR tracking assistance needed
9. RE: Recommendations; Was: Just trying to understand.
10. Re: Ver.2: Another thing I'd like to see...
11. Re: Alinco DR-135TP
12. Re: Recommendations; Was: Just trying to understand.
13. Re: Recommendations
14. Re: Recommendations
15. Alinco DR-135TP and Digi_Ned
16. Re: Recommendations
17. Re: Recommendations
18. Re: Recommendations
19. Re: Recommendations
20. Pharos GPS question
21. Weather Watches Not Showing Up On APRS
22. Re: Recommendations
23. Re: Weather Watches Not Showing Up On APRS
24. Re: Recommendations
25. Relaying traffic between two AGWPE ports
26. Re: Just trying to understand.
27. RE: Recommendations; Was: Just trying to understand.
28. Re: Recommendations
29. Re: Recommendations
30. Re: Weather Watches Not Showing Up On APRS
31. Re: Recommendations
32. Fw: NSTAR 03-A successfully recovered
33. Re: Recommendations
34. wide?
35. Re: wide?
36. Re: Recommendations
37. Re: wide?
----------------------------------------------------------------------
Subject: PCSAT Question
From: "Dakota Summerhawk" <dakotas@dotorg.org>
Date: Fri, 25 Apr 2003 22:44:32 -0600
X-Message-Number: 1
What is the best degree for hitting PCSAT? I have a new program that I am
playiong with and it wants to know what degree to set it for. I was thinking
about 10 or 15 because I live at an aelvation of 6100 Ft and have mountains
on one sie to the west. Can someone give me a hint?
Thanks
Dakota
----------------------------------------------------------------------
Subject: Re: KPC 3+ and Motorola Maxtrac Quesion
From: Skip Allison <skipk9sa@ameritech.net>
Date: Fri, 25 Apr 2003 23:53:21 -0500
X-Message-Number: 2
If you are getting Rx audio from the headset pin on the mic connector,
you may have to change the load resistor on the Rx audio line in the
TNC. It will load the headset line down too much. The headset output
impedence is about 1K. I think the load resistor is around 100 ohms. I
changed it to 4.7K.
Skip
K9SA
----------------------------------------------------------------------
Subject: Re: Lesson needs to be learned in VA
From: Roger Grady <k9opo@comteck.com>
Date: Sat, 26 Apr 2003 00:47:04 -0500
X-Message-Number: 3
At 10:54 PM 4/25/03 -0400, Michael Amos wrote:
>Could you please explain the situation as to why this is bad for "beginners"
>in APRS and digipeaters and don't quite understand the problem here...
The "bad" being referred to is the use of a path of RELAY,WIDE7-7 by a
digipeater.
RELAY is intended for use by mobiles/portables only. Since they are moving
around, it's difficult for them to know what particular digi they are in
range of at any given time. Most APRS stations will respond to the alias of
RELAY and digipeat the packet into the local network. When a fixed station
uses RELAY it is likely to be heard by other fixed stations, each of which
will digipeat the packet. This generates a lot of unnecessary traffic. When
a digipeater uses RELAY it's even worse because presumably it has a higher
profile than a home station, is heard by more stations, and thus even more
unnecessary digipeats will be generated. A fixed station should learn its
local network and use a specific digi as its first hop rather than RELAY.
WIDE7-7 is probably an excessively long path. There may be specific
circumstances where it's OK but usually 3 or 4 hops is plenty. More than
that mostly generates a lot of extra packets as it bounces around the digi
network.
73,
Roger Grady K9OPO
----------------------------------------------------------------------
Subject: RE: Ver.2: Another thing I'd like to see...
From: "Darryl Smith" <Darryl@radio-active.net.au>
Date: Sat, 26 Apr 2003 18:01:51 +1000
X-Message-Number: 4
"Ev Tupis (W2EV)" <w2ev@arrl.net> Commented on
>BobDonnell@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
---------
Darryl Smith, VK2TDS POBox 169 Ingleburn NSW 2565 Australia
Mobile Number 0412 929 634 [+61 4 12 929 634 International]
Darryl@radio-active.net.au | www.radio-active.net.au
----------------------------------------------------------------------
Subject: RE: Ver.2: Another thing I'd like to see...
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Sat, 26 Apr 2003 08:31:13 -0400
X-Message-Number: 5
>>I wonder why APRS hasn't exploited the advantages of connected mode
>>more. Hmmm.
>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.
Hi Darryl,
First, a huge thanks to taking the time to lay out the issues. My question
was based in true inquiry and not tongue-in-cheek.
It appears to me as if the "problems" of connected mode are rooted in the
way the hobby has implemented it, rather than the mode itself. The
question then becomes, "Is there a different implementation that would
showcase its advantages and minimize its disadvantages?".
Of course, the momentum of needing to maintain compatibility with existing
technology will kill any actual development of such a system, so this is
simply an academic discussion.
Wouldn't it be interesting to explore the application of "connected mode
store-and-forward" logic into APRS keyboard messaging? The advantage is
guaranteed delivery and the increased channel utilization is evident only
in the collision domain of the two stations involved in the relay.
Of course, Bob's idea of a high speed backbone RF link changes things
again, as it would affort other ways of getting to the same
destination...but the realistic chances of that happening are even smaller
than a client author adding the function that is described in the earlier
paragraph.
Anyway... in an academic way, I still wonder if there is room for strictly
controlled "connected mode" communication even on an "unconnected channel",
as long as it is implemented in a friendly way.
Regards,
Ev, W2EV
----------------------------------------------------------------------
[commercial content deleted]
----------------------------------------------------------------------
Subject: Recommendations; Was: Just trying to understand.
From: Rich Osman <Rich@osman.com>
Date: Sat, 26 Apr 2003 07:58:43 -0500
X-Message-Number: 7
Ya know guys, it seems like there really needs to be a uniform set of
recommendations. I know this is hard to acheive in the delightful
anarchy that is the ham community, but we really need it. I'm not
suggesting that we manage the anarchy, just provide a little light for
those willing to look for it. There's a lot of emotional response to
settings out there, but I believe that most hams are willling to 'play
nice' even if their opinion of nice varies a lot.
I've seen opinion web pages, which a lot of people around here cite that
that recommend frequent beacon messages (not IDs, beacons) that include
TRACE paths and WIDE3-3 (or 5-5) paths. Why is it important for a digi
to beacon (beacon, not ID) at all, much less this frequently and with a
TRACE path on all the time? I know it's nice to see your call out
there, but removing the ego, how is it used? Does the value merit the
channel load? I've had people tell me that mobiles need this data.
They do? Really? Don't mobiles know they are being digi'd by seeing
the packets? I can't remember ever seeing a mobile using a fixed path
that wasn't associated with an event.
I beleive that we need a mobile set of recommendations too. I see local
mobiles in the DFW Metroplex running WIDE7-7 every minute, not many, but
there *are* a lot of 5-5s.
Finally, think any recommndation document should provide the reasoning
behind the recommendation. This is rare in any of the web based
recommendations I've seen.
How could we generate a living document that provides consensus driven
recommendations for settings? Polling data is often largely emotion,
and I'd sure like to see fact based recommnedations.
Could we divide things by terrain, population density, and expected
coverage? I realize that the guys in Carthage, Tennesee don't have the
same problems as Scttsbluff, Nebraska, or Denver, or here. But we ought
to be able to provide a couple sets of guidelines that local guys could
point to with minimum modification.
--
mailto:Rich@Osman.com http://www.rich.osman.com
Rich Osman; POB 93167; Southlake, TX 76092 (Near DFW Airport) ARS: N1OZ
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
