| |
ZL3AI > APRDIG 04.02.04 13:40l 247 Lines 9354 Bytes #999 (0) @ WW
BID : 2774-ZL3AI
Read: GUEST
Subj: TAPR Digest, Feb 02, 1/4
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<DB0EEO<DB0GOS<ON0AR<ON0AR<7M3TJZ<
EA5AKC<EA5DVS<ED1ZAC<ZL2TZE<ZL3VML
Sent: 040204/1120Z @:ZL3VML.#80.NZL.OC #:18322 [Chch-NZ] FBB7.00i $:2774-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Monday, February 02, 2004.
1. Re: Stupid Question - SORRY
2. Re: Stupid Question - SORRY
3. RE: Mailing Lists for Annoucements of sattelite passes- Suggestions needed
4. Re: TH-D7A question
5. Re: TRACE question...
6. Re: Stupid Question - SORRY
7. Re: Xastir and Toporama Maps
8. Re: Xastir and Toporama Maps
9. Re: TRACE question...
10. Re: TRACE question...
11. GPS Signal re-radiation
12. Re: TRACE question...
13. Re: TRACE question...
14. Re: GPS Signal re-radiation
15. Re: Xastir and Toporama Maps
16. Re: GPS Signal re-radiation
17. Private Voice Alert.
18. Re: GPS Signal re-radiation
19. Re: GPS Signal re-radiation
20. Re: GPS Signal re-radiation
21. Re: digi_ned.ini
22. PocketAPRS icons
23. Re: GPS Signal re-radiation
24. Xastir 1.3.0 Release
25. APRS client for Zaurus?
26. PCsat logs 2678 users
27. Re: APRS client for Zaurus?
28. ALINCO DJ-S41 COR Squelch Mods
29. Re: digi_ned.ini
30. KPC-9612
----------------------------------------------------------------------
Subject: Re: Stupid Question - SORRY
From: "Dick C. Reichenbach" <dreichen@columbus.rr.com>
Date: Mon, 02 Feb 2004 00:08:36 -0500
X-Message-Number: 1
I wouldn't beat yourself up over it. It's not a bad idea. IF the D7
serial port works Similarly to to the D700, then a program similar to
Link700 could control it remotely via RS232. That screen could be
computer output to your in-car video screen.
It would work, but the caveat being that you would need a computer, and
if you had a computer available to you, then there are about a dozen or
more other different options you could also do. Like XASTIR, UIView,
Win/MacAPRS, etc, etc, etc.
Like I said, its not a bad idea. For someone who doesn't need mapping
capabilities or anything complicated, it would generate a Simple to
read, large, text based display, that would just tell you only what you
need to know.
I don't know if it is in development anymore, but the simple application
SmartPalm (http://smartpalm.sourceforge.net/) might help you, but I
don't know if it supports the D7. It must not be in development, the
last binary is dated March 2001.
Curt, you might add SmartPalm to your Client Capabilities chart.
Dick Reichenbach
KC8OBZ
Jacob Tennant wrote:
>The D7A question/idea I sent out earlier was pretty stupid but I was tired
>and didn't think it thru first.
>
>SORRY
>
>Jacob Tennant-K8JWT
----------------------------------------------------------------------
Subject: Re: Stupid Question - SORRY
From: "Dick C. Reichenbach" <dreichen@columbus.rr.com>
Date: Mon, 02 Feb 2004 00:22:58 -0500
X-Message-Number: 2
Dick C. Reichenbach wrote:
>I wouldn't beat yourself up over it. It's not a bad idea. IF the D7
>serial port works Similarly to to the D700, then a program similar to
>Link700 could control it remotely via RS232. That screen could be
>computer output to your in-car video screen.
Sorry, I meant this program -
http://www.btinternet.com/~g6odt/d700.html, not Link700. I got
confused for a moment or two.
Dick R
----------------------------------------------------------------------
Subject: RE: Mailing Lists for Annoucements of sattelite passes- Suggestions
needed
From: "Steve Brockway" <ssbrockw@swbell.net>
Date: Mon, 2 Feb 2004 05:52:43 -0600
X-Message-Number: 3
Mark,
NASA does the same thing at:
http://science.nasa.gov/RealTime/JPass/PassGenerator/
This will generate rise time and duration visible, max elevation, and
cardinal direction of rise and set for up to 10 satellites as often as 3
times a week. It will provide this for any satellite in the database
that they have posted and for any location by either zip code or city or
lat/long if I remember correct.
Granted, this was set up for visually tracking satellites, originally,
but it works very well for planning and working LEO satellites with omni
antennas. This is not accurate enough for tracking with an OSCAR array.
Here is an example for AO-40
>> AO-40 approx. vis. mag. 10
Date Dur. Lit Dur. Max.
mm/dd Rise Set mm:ss mm:ss Elev.
---------------------------------------------------
*2/02 08:20:50pm WSW W 374:4 374:4 26 WSW
2/03 03:00:29pm SSW W 720:0 720:0 56 S
2/04 01:44:15pm E WSW 720:0 720:0 58 S
73,
Steve
KA5YFC
----------------------------------------------------------------------
Subject: Re: TH-D7A question
From: Bob Bruninga <bruninga@usna.edu>
Date: Mon, 2 Feb 2004 08:37:32 -0500 (EST)
X-Message-Number: 4
On Sun, 1 Feb 2004, Jacob Tennant wrote:
>I am looking at a TH-D7A for mobile use but was wondering if there was any
>way to display the radios screen on a external device?
This is not what you were after, but whenver I give demos and talks, I
carry one of those chip-cameras and a little bracket that holds it over
the D7. Then I plug the camera into the ubiquitous PC projector that is
usually there so that everyone in the room can see the display.
Everyone who doesnt have one is amazed at what this rig can do...
You could take this to extreme and combine one of the $50 cameras and the
$50 flat panel moitors they sell now and have a heads-up display...
bob
----------------------------------------------------------------------
Subject: Re: TRACE question...
From: Bob Bruninga <bruninga@usna.edu>
Date: Mon, 2 Feb 2004 12:18:53 -0500 (EST)
X-Message-Number: 5
Under the new n-N Paradigm of thinking in terms of LANn-N's, LINKn-N's and
firewalls on WIDEn-N, one area in the USA is disabling WIDEn-N flooding
and changing their digi's over to using WIDEn-N TRACING. I was asked to
comment on this move... So I decided to comment to the group too:
All of these concepts have been smmarized on my web page below:
http://www.ew.usna.edu/~bruninga/aprs/fix14439.html
It boils down to realizing that WIDEn-N was a good idea back in 1994 when
I first proposed it, becasue we had so few users, we wanted a simple way
to FLOOD the network. but since APRS has bloomed, we can no longer
tolerate everyone flooding the network with as many as 100+ copies of
every packet (7-7 can do that)...
So here are the driving facts:
1) 144.39 is overloaded, we must shorten paths where possible
2) We must learn that APRS is for local use and LOCAL is defined
by 1200 baud channel capacity and for APRS this works out to
be about 50 to 100 users. THis is true whether you are in Wyoming
or Los Angeles.
3) Hence your path must be only long enought to hit your area of 50 to
100 users and no more.
4) This is usually 2 hops or so
5) AND We DO want all paths to arrive with their 1st digipeater intact so
that we can manage the network by knowing where packets enter the
network.
6) This suggests transmitting with WIDE,WIDEn-N so that the
first digi would ID itself. But with some DIGI owners insisting on
setting their digis to ID on top of path data, this obliterates
and makes useless any path data in packets.
7) A packet originated as WIDE,WIDEn-N will also generate some dupes if
there is more than one initial digi that hears it.
THUS, one possible answer to the two problems of #6 and #7, is to stop
uising WIDEn-N FLOODING and change it to WIDEn-N TRACING.
* The path always arrives intact
* Most people should be using 2 or so hops anyway, so the packet arrives
with only a TWO hop digi field, so the automatic TRACE adds nothing
to a 2 hop path. (it would have been a minimum of 2 hops before too)
* It does add some overhead to longer hop paths, but those should be less
often used these days and when you do have packets coming in from that
distance, then they must be important and if they are important, then
you want to know how they got there anyway..
* If they are not important, you see the path, and you can figure out
where you might want to go configure either a LANn-N or LINKn-N or
WIDEn-N firewall to fix it.
So read the web page above and see if there aren't some ideas such as
LINKn-N and LANn-N that could be useful in your area... THe idea of
stopping the UIFLOOD of WIDEn-N that some areas are trying to
do, I think is a move in the right direction.
But yes, your initial concern of added PATH overhead that results from
WIDEn-n TRACING is a reasonable reaction, but in light of SHORTER paths,
DIGIS that wont obliterate path data, Identificaion of network
point-of-entry, Improved troubleshooting and you may see that it is in
fact better for the network.
WIDE,WIDEn-N pkt arrives w 2 digis EVERYWHERE (dozens of copies)
TRACEn-N pkt arrvies w 1 digi locally, 2 digis in the area and 3
digis only if TRACE3-3 or larger is used. But the
AVERAGE is about 2. SO it is no worse than the
existing use of WIDE,WIDE2-2.
So all the SYSOPS in your area are doing is chaning the TRACEn-N parameter
to respond on WIDEn-N packets so that they dont have to re-educate
thousands of users... but they can fix the network overnight...
(As long as MOST people start using shorter paths most of the time).
We do want people to be able to use LONG paths when they need to, but we
want to direct those hops where they should go, instead of flooding
everywhere.
Bob, WB4APR
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
