| |
ZL3AI > APRDIG 30.10.03 21:42l 276 Lines 10476 Bytes #999 (0) @ WW
BID : 2236-ZL3AI
Read: GUEST
Subj: TAPR Digest, Oct 28, 1/4
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0NOS<DB0BI<DB0FBB<DB0GOS<DB0ACC<DB0ACH<
ON0DXC<WA7V<VK7AX<ZL2BAU<ZL3VML
Sent: 031030/1232Z @:ZL3VML.#80.NZL.OC #:11606 [Chch-NZ] FBB7.00i $:2236-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Tuesday, October 28, 2003.
1. Is there a list of Kenwood Constraints?
2. Re: 0 channel load APRS Steward (New concept)
3. Is there a list of [APRS Appliance] Constraints?
4. Re: 0 channel load APRS Steward (New concept)
5. Re: 0 channel load APRS Steward (New concept)
6. Idea needs feedback
7. Re: 0 channel load APRS Steward (New concept)
8. Re: 0 channel load APRS Steward (New concept)
9. Re: The point is NOT use of BLN, it's RF User Education
10. Re: 0 channel load APRS Steward (New concept)
11. Re: 0 channel load APRS Steward (New concept)
12. Re: 0 channel load APRS Steward (New concept)
13. Re: 0 channel load APRS Steward (New concept)
14. Re: APRS bulletins
15. Re: APRS bulletins
16. Re: 0 channel load APRS Steward (New concept)
17. Object security in APRS
18. Re: Idea needs feedback
19. Re: Idea needs feedback
20. FIRENET Question
21. Re: Object security in APRS
22. Re: Object security in APRS
23. Re: FIRENET Question
24. Re: Idea needs feedback
25. Re: FIRENET Question
26. KPC-3+ Digipeater Question
27. MODIS and APRS
28. Re: FIRENET Question
29. Re: San Diego firestorm
30. Re: The point is NOT use of BLN, it's RF User Education
31. Re: San Diego firestorm
32. Re: Object security in APRS
33. Re: FIRENET Question
34. Re: Object security in APRS
35. Re: Object security in APRS
36. Re: Object security in APRS
37. Re: FIRENET Question
----------------------------------------------------------------------
Subject: Is there a list of Kenwood Constraints?
From: Bill Herrmann <bherrman@spro.net>
Date: Mon, 27 Oct 2003 23:26:58 -0700
X-Message-Number: 1
Does anybody have a list of the limitations of the Kenwoods and how to work
around them? It would seem like it might be helpful to the rest of us who
chose not to buy them. (I looked, but just couldn't justify the extra price
to get less.)
Better yet - can one of the web sites emulate a Kenwood at a given
location? (In other words, input a lat,long, and range and get a simulation
of how a Kenwood at that location would behave on RF based on what's on the
internet feed for that area.) (Simulating a Kenwood on the full feed would
be useless, of course.)
Constraints I've seen mentioned today:
Status Text - 64 characters
Max Message Length with a posit - 37 characters (this appears to be an APRS
max that is about 17 more than the D7 can handle)
Max number of messages/bulletins - 10
Have I mangled some of those? Probably, but the point is that somebody who
is intimately familiar with both the D700 and the D7 needs to document the
dang things so the rest of us don't have to guess what they can/can't do.
Ideally that should be a table that includes a column for each of them plus
the applicable APRS standard.
Once we have 'em documented than maybe we can make decisions about how to
convey information on this tactical network so that it gets to everybody!
Bill
----------------------------------------------------------------------
Subject: Re: 0 channel load APRS Steward (New concept)
From: John <bigjohn45@cox.net>
Date: Tue, 28 Oct 2003 06:17:45 -0500
X-Message-Number: 2
I like Ev's suggestions and will no doubt implement them in some form. I
also agree with Dave that TXD is radio system specific but an operator who
knows how to set it is likely to be able to figure out what happened if his
setup dies after a change. It could provide a gentle nudge towards better
practice.
I will probably recommend SET TXD <300ms.
Another possibility is to use an object. Digi_Ned can send an object named
PATH with the information. This would not clog the Kenwoods. Or perhaps
PATHCENGA. Actually Digi_Ned has the ability to respond to queries from
users so ?PATH could return this information on demand as well as sending
an object on a routine schedule.
Ah the joys and possibilities of an intelligent digi rather than just a
smart one.
----------------------------------------------------------------------
Subject: Is there a list of [APRS Appliance] Constraints?
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Tue, 28 Oct 2003 06:32:43 -0500
X-Message-Number: 3
Bill Herrmann wrote:
>
>Does anybody have a list of the limitations of the Kenwoods and how to work
>around them?
No APRS appliance or software program does it "all" (either by protocol or
by personality).
The Kenwoods are simply the most visible due to the latest thread (and the
fact that they seem to be a very widespread appliance with some interesting
personality and protocol limitations). Even so, they implement enough good
stuff that they work fine for the needs of 90% of the mobile APRS users (a
number I'm pulling out of the air).
The underlying issue is that there is no published standard by which the
level of "APRs Compatibility" can be judged for a given APRS appliance or
software system. Authors implement what they want and call it "APRS".
I'm now dreaming of a system that can take the entire constellation of all
APRS systems and rank them by compatibility, then transmit that list once a
day as a BLN: as a public service to the RF-based APRS community who may be
thinking of upgrading some day. <grin>
<giggling>
Ev, W2EV
----------------------------------------------------------------------
Subject: Re: 0 channel load APRS Steward (New concept)
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Tue, 28 Oct 2003 06:41:04 -0500
X-Message-Number: 4
Tim Schall wrote:
>
>I might be missing something here. How is changing from a BLN to a status
>message going to lighten the load on the network? I'm in on the idea in a
>minute if someone can explain this one to me.
Hi Tim,
The goal of the proposal is to use RF to educate RF users as to the
acceptible non-specific UNPROTO to use in a given APRS LAN. When RF users
are properly educated, they will apply "good Amateur practice" and comply.
THAT will allow the APRS LAN to operate as efficiently as the physics of
1200 baud UI-AX.25 allows.
As for changing an APRSteward message format from BLN to status... this
simply addresses a Kenwood personality-fault (some people's opinion)
related to how it handles BLN's vs. how it handles status frames. Nothing
else.
Regards,
Ev, W2EV
----------------------------------------------------------------------
Subject: Re: 0 channel load APRS Steward (New concept)
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Tue, 28 Oct 2003 06:48:55 -0500
X-Message-Number: 5
John wrote:
>I will probably recommend TXD <300ms.
Maybe simply omit the recommendation, then? <300 leaves a lot of room for
allowing a significant amount of dead air in a LAN. Bob has already
mentioned that the satellites use 100ms...and do so quite effectively,
fwiw.
>Another possibility is to use an object.
Here's another very interesting idea! An object that -- when queried --
shares all of the UNPROTO info needed for a LAN.
This is a variation of an earlier post on the use of UI-View's "query
station" parameter, where several lines of text can be transmitted upon a
query from another station. All it would take is for an agreement as to
the icon that should be universally used for such a purpose and configure
it as presented.
Is there an opportunity for "Info Kiosk" here? I don't know enough about
that function to comment.
Ev, W2EV
----------------------------------------------------------------------
Subject: Idea needs feedback
From: "Bud Talbot" <kb9wvg@arrl.net>
Date: Tue, 28 Oct 2003 6:16:55
X-Message-Number: 6
Greetings-
I have this idea about a new(?) APRS field game/SAR practice. For lack of a
better term, I call it APRS Geodashing. The concept came to me when I heard
about Geodashing.
Anyway, a month or so ago I wrote it up and it has just been sitting there.
I think it would be a cool idea and a fun thing to particpate in.
Basically, it is an APRS based checkpoint hunting game. Please read about
it at:
http://home.houston.rr.com/kb9wvg/APRS_Geo.doc
I'd love to have some feedback or even develop an implementation.
73 de Bud
KB9WVG
home.houston.rr.com/kb9wvg
----------------------------------------------------------------------
Subject: Re: 0 channel load APRS Steward (New concept)
From: David VanHorn <dvanhorn@cedar.net>
Date: Tue, 28 Oct 2003 08:50:09 -0500
X-Message-Number: 7
>Here's another very interesting idea! An object that -- when queried -- shares
>all of the UNPROTO info needed for a LAN.
This I like!
A beacon once in a while telling new folks how to use it, would present
minimal load.
I suppose you /could/ even make it only show up when you see things that
you don't like in the neighborhood. No sense telling everyone what they
already know.
----------------------------------------------------------------------
Subject: Re: 0 channel load APRS Steward (New concept)
From: "Tim Cunningham" <tim_cunningham@mindspring.com>
Date: Tue, 28 Oct 2003 08:05:42 -0600
X-Message-Number: 8
>I like Ev's suggestions and will no doubt implement them in some form. I
>also agree with Dave that TXD is radio system specific but an operator who
>knows how to set it is likely to be able to figure out what happened if his
>setup dies after a change. It could provide a gentle nudge towards better
>practice.
>
>I will probably recommend SET TXD <300ms.
Be careful with TXD. This is not just a transmitter implementation. TXD
also allows compensation for the receiver on the other end to open its
squelch, if utilized, and to allow the radio/TNC to lock onto the incoming
signal. While setting TXD to the optimal setting that works with one
digipeater, you might find that as you move to another digipeater your
signal may not be decoded reliably. There is a variable on the receiving
end that must be considered if you want your transmitted signal to be
received reliably.
What we need is a minimum required specification for a digipeater decoding
system. Most can handle a 300ms delay in decoding a signal. As you venture
below this number, you start to push the limits. Also, keep in mind that a
digipeater has to allow for the worst case with its own TXD setting because
there is a diverse set of equipment on the other end that may employ
squelch operated radio's. In order for the system to be reliable a
digipeater must take this into account for compatibility with equipment on
the receiving end..
Tim - N8DEU
Huntsville, Alabama
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
