OpenBCM V1.13 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
ZL3AI  > APRDIG   11.09.03 11:02l 256 Lines 9073 Bytes #999 (0) @ WW
BID : 1886-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 08, 1/7
Path: DB0FHN<DB0RGB<DB0MRW<OK0PKL<OK0PPL<DB0RES<ON0AR<VK6HGR<ZL2BAU<ZL3VML
Sent: 030910/1334Z @:ZL3VML.#80.NZL.OC #:8087 [Chch-NZ] FBB7.00i $:1886-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To  : APRDIG@WW

TAPR APRS Special Interest Group Digest for Monday, September 08, 2003.

1. APRS Point?
2. Node Symbol on map.findu.com list has MIC in it - huh ?
3. Homeport
4. Re: Node Symbol on map.findu.com list has MIC in it - huh ?
5. RE: Homeport
6. RE: Homeport
7. RE: Homeport
8. RE: Homeport
9. RE: Homeport
10. RE: Homeport
11. Re: Homeport
12. Adding location "SMARTS" to APRS (HLR VLR)
13. RE: Homeport
14. RE: Homeport
15. RE: Homeport
16. Re: Homeport
17. RE: Homeport
18. Re: Homeport
19. Re: Homeport
20. Re: Homeport
21. Re: Homeport
22. Re: Adding location "SMARTS" to APRS (HLR VLR)
23. Re: Homeport
24. RE: Homeport
25. Re: Homeport
26. RE: Homeport in Montana
27. RE: Homeport
28. Re: Homeport
29. Re: Homeport
30. Re: Homeport
31. Re: Homeport
32. RE: Homeport
33. Re: Homeport
34. Re: Homeport
35. RE: Homeport
36. Re: Homeport
37. Re: Homeport
38. Re: Homeport
39. RE: Homeport
40. Re: Homeport
41. Re: Homeport
42. Re: Homeport
43. Re: Homeport
44. Re: Homeport
45. TinyTrak3-TripmateUSB interface
46. Dell Axim RandMcnally
47. Re: Homeport
48. Re: Homeport
49. RE: Adding location "SMARTS" to APRS (HLR VLR)
50. Re: Homeport
51. Re: Homeport

----------------------------------------------------------------------

Subject: APRS Point?
From: "Bob & Janet" <jbcraft@adelphia.net>
Date: Mon, 8 Sep 2003 02:01:06 -0400
X-Message-Number: 1

Hi Guys,

I just got a notice back from Yahoo that the user APRSPOINT does not exist.

Does anyone happen to know a better address than aprspoint@yahoo.com?

73 Bob K8YS

----------------------------------------------------------------------

Subject: Node Symbol on map.findu.com list has MIC in it - huh ?
From: "Maiko" <maiko@langelaar.net>
Date: Mon, 8 Sep 2003 8:50:39
X-Message-Number: 2

I'm using '/' (primary data set) and 'n' (Node) in my posit broadcasts, but
when I go to the map.findu.com site (and list stations near me) I see a
symbol with the letters MIC arranged in a vertical pattern.

That's a NODE ?

I havn't tried the BBS one yet '/' and 'B', hopefully it will show BBS ...

Any comments ?

73 Maiko Langelaar / VE4KLM

----------------------------------------------------------------------

Subject: Homeport
From: Bob Bruninga <bruninga@usna.edu>
Date: Mon, 8 Sep 2003 12:14:02 -0400 (EDT)
X-Message-Number: 3

The concept of APRS homeport.

This is a new fundamental concept for APRS that is probably re-stating the
obvious to most travelers, but it just gelled in my mind as one of those
concepts that should be a cornerstone of APRS operations and should thus
be given special recognition.  (Again, many of you probably already do
this routinely, and I appologize for my slow recognition of its
importance).

The significance of this concept is that it should help reduce channel
loading and long hops in general.

APRS Home Port:  Those APRS users who frequently travel to distant areas
significantly outside of their local area should define their "homeport".
Their "homeport" is the local IGate in the vicinity of their home or
friends who care.  Defining one's homeport means that the user asks for
his homeport IGate to list him on the special GATE-TO-RF list.  Details:

1) The IGate then will accept his distant travel packets as worthy of
forwarding back to RF in his homeport area.

2) At any  instant, such a user can only have one existing homeport
definition at a time.

3) The IGate is smart enough to NOT loop through any of his local travel
packets by knowing when he is operating locally.  My guess is that this is
best accomplished by POSITION.  The homeport algorithm is only activated
when a position report for that person comes in on the Internet and it is
a position report BEYOND X distance from the homeport.

4) This homeport concept should be AUTOMATIC and requrire no maintenance
by the IGate operators (they have enough to do already!)...  THus we must
define a means for the traveler to send a packet over the air to identify
his homeport on the fly.  This packet must contain both the name of the
homeport AND the radius X from that home port when it becomes active...

I propose a message, addressed TO the homeport IGate that contains these
fields:  CALL, Distance of activation, Start Date, End Date.  Something
like:

   Message: To: MYGATE-14:  Set Homeport, 130 mi, now, to forever.

If the homeport IGate gets this message, the sender gets an ACK and also
then a "Your Homeport is: MYGATE-14".  Or it could say, "Sorry, This
homeport is full.  It can accept no more packets at this time."
Whatever...

HERE IS THE ADVANTAGE OF FORMALIZING THIS CONCEPT:

1) It should remove the incentive for 200-500 mile travelers to try to use
WIDE7-7 to get back home

2) It adds NOTHING to the network.  If the travler is local, his packets
are local.  If he is away, his packets still only affect HIS neighborhood.
APRS is a local thing.  By keeping the burden of packets local, then any
overuse or problems can be resolved locally too...

3) It should encourage the intended use of the IGate system for distant
conectivity and help support that infrastructure.  It might also encourage
people to help support their homeport IGate and owner too!

We have everything we need.  Many of you already do this.  But we must
make it standard operating procedure (get people to reduce their path
length... APRS is LOCAL!) and take the maintenance burden off the IGate
owners...

Bob, WB4APR

----------------------------------------------------------------------

Subject: Re: Node Symbol on map.findu.com list has MIC in it - huh ?
From: WA8LMF2@aol.com
Date: Mon, 8 Sep 2003 12:31:02 EDT
X-Message-Number: 4

In a message dated 9/8/2003 6:56:40 AM Pacific Daylight Time, 
maiko@langelaar.net writes:

>Isee a symbol with the letters MIC arranged
> in a vertical pattern.
>  
> That's a NODE ?
>  
> I havn't tried the BBS one yet '/' and 'B', hopefully
> it will show BBS ...

The symbol set used by findu, APRSworld and APRSplus is hopelessly out of 
date.

For example, the symbol that is supposed to be "SSTV" produces a
thundercloud instead.   The code that is supposed to produce "Boyscouts"
instead produces a backwards "L".

I have been editing the actual icons for APRSplus to get the symbols and 
their positions to agree with the current definitions in the APRS standards 
document.  I am going to post the revised set in layouts for both APRSplus
and UIview in the next week or so.

I can make my local programs display the correct symbols but it will take
the site operators of findu and APRSplus to install the correct symbols on
their servers before the problem is completely fixed.

Stephen H. Smith                   wa8lmf (at)  aol.com 
Home Page:                                         http://wa8lmf.com
Ham Radio/Mobile SSTV page:     http://members.aol.com/wa8lmf/ham
APRS Stuff                                              
http://members.aol.com/wa8lmf/aprs

----------------------------------------------------------------------

Subject: RE: Homeport
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Mon, 8 Sep 2003 11:37:27 -0500
X-Message-Number: 5

The idea, overall, is good.  Just a note about #3.  IGates already have
in their algorithm "don't gate to RF" packets from stations heard on RF
within the last X minutes (X is usually settable by the sysop).  That is
a much better method than leaving it up to the traveler to try and
figure out how big an area an IGate covers (especially with band
openings).

One thing that the IGate software would need to do is monitor all
messages to see if someone changes their homeport under your proposal.
Maybe, instead having to know what IGate to send a message to, the IGate
software could contain a "local area" definition and then watch for a
message to, say, IGATE with the text being the lat/lon  with the text being the lat/lon of where the
>traveler calls "home".  This would tend to ensure that only one (or two)
>IGate(s) would be acting as the homeport (yes, there would be overlaps,
>but they should be minimal).

This is a good idea.  In fact, better...  but as you note... there are
some downsides...

Advantage:  Lack of unique dependency...
Disadvantage:
1) overlaps, (and added QRM, not less, as we were striving for)
2) anonymous IGate.  I was trying to encourage a more recognizable
relationship between the user and the IGate.
3) Igates come and go.  The user might want to just nail the most reliable
one down and depend on it...

Weighing all the above, I lean towards explicitly declaring the target....
but no reason why we shouldn't have the LAT/LONG as an option.  but lazy
people might use it because they are too lazy to look up their local IGate
and then we have in fact, created a NEW QRM source...

hummhh...  which then puts me back to not wanting the LAT/LONG option.

Oh, we would have a Query, so that if a traveler was unsure if he is
properly registered his HOME port, he can send out Homeport? and ANY
igate that think's it is, will respond....

Bob

----------------------------------------------------------------------



Read previous mail | Read next mail


 05.11.2026 01:35:51lGo back Go up