| |
ZL3AI > APRDIG 20.11.03 20:00l 167 Lines 6810 Bytes #999 (0) @ WW
BID : 2333-ZL3AI
Read: GUEST
Subj: TAPR Digest, Nov 13, 3/14
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<ON0AR<7M3TJZ<KP4IG<KD7HAH<GB7BHX<
GB7BHM<ZL2BAU<ZL3VML
Sent: 031120/1713Z @:ZL3VML.#80.NZL.OC #:13183 [Chch-NZ] FBB7.00i $:2333-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: MULTI-ICON proposal
From: Steve Dimse <k4hg@tapr.org>
Date: Wed, 12 Nov 2003 10:04:25 -0500
X-Message-Number: 14
On 11/12/03 at 3:05 PM Henk de Groot <henk.de.groot@hetnet.nl> sent:
>Hello Steve and others,
>
>At 11:38 11-11-03 -0500, Steve Dimse wrote:
>>I never said the disussion was not worthwhile, I'm proposing a better
>>alternative. Software to determine digi configuration would not be
>>difficult to
>>write, and would provide this information in a reliable fashion not
>>dependent on
>>self-reporting!
>
>This opens another can of worms. Basically this moves the decision how to
>present a station from the sender to the receiver.
Both methods depend on correct implementation of a protocol by programmers,
just as almost everything else does in APRS. Granted, it will be easier on
the programmers to implement decoding of an explicit protocol that to
implement snooping and probing. However the self-report method shifts the
difficult task over to thousands of users, much harder to assure quality in
that setting.
I also question an underlying assumption in your statement, that all
clients need to implement this. Does the typical user need to know whether
their local digi is WIDEn-n, NOID, TRACE, etc? Isn't it enough for them to
know that their packets are getting picked up by the local digi? Everyone
needs to know this last fact, even if they are power users with a complete
understanding of the network, to be sure their radio/antenna/TNC are
correctly functioning. Even if you presumed that every APRS user fully
understood all these classes of digis (a big leap), what do they gain by
knowing exactly how their local network is configured?
Absolutely this information is useful to network designers, maintainers,
and managers, but I do not believe it needs to built into every APRS
client. Again, whether any particular client implements this (or the
parsing of an every frame add-on for that matter) is a choice for each
author, as dictated by the needs of their users.
>In the end the repesentation on screen will be different from client to
>client, something which was highly undesired.
Undesired by Bob, but very much desired by me. I say choice is good, let the
market decide which features and innovations are best!
Steve K4HG
----------------------------------------------------------------------
Subject: D700 Remote Cable
From: Larry McDavid <lmcdavid@lmceng.com>
Date: Wed, 12 Nov 2003 07:51:10 -0800
X-Message-Number: 15
Has anyone experienced problems using standard unshielded modular cable
to remote locate the Kenwood D700 control head? I need to use about 20
feet of cable from the wagon trunk to an overhead forward location.
I note that the supplied cable, which is not long enough, is shielded.
--
Best wishes,
Larry McDavid W6FUB
Anaheim, CA (20 miles southeast of Los Angeles, near Disneyland)
----------------------------------------------------------------------
Subject: Re: D700 Remote Cable
From: K8DNE <wh.reynolds@verizon.net>
Date: Wed, 12 Nov 2003 12:40:22 -0600
X-Message-Number: 16
Hi y'all.
I have constructed many (approximately 10) control head cables and
extensions from R/S phone parts and associated crimpers. The D-700 control
head and the mike cables (cat5 cable and associated crimpers) seem to be
pretty impervious to anything but incorrect wiring (while crimping the
cable ends.
GoForIT!!
73.....bill
--
W. H. (Bill) Reynolds, K8DNE
A.R.R.L. Liaison F.C.C. Examiner
8821 Willowbrook Dr.
Rowlett, TX 75088-4614
Phone: 972-475-3854
E-Mail = <wh.reynolds@verizon.net>
Rowlett, TX RACES Radio Officer, Unit 801R
----------------------------------------------------------------------
Subject: Re: MULTI-ICON proposal
From: "Scott Miller" <scott@3xf.com>
Date: Wed, 12 Nov 2003 10:45:26 -0800
X-Message-Number: 17
>risk that this function will be abused is high. After giving it a second
>thought I would vote against it. OpenTrac could have the required layering
>for doing this the right way though.
And anyone with a clear idea of how to do it right should come join us on
the OpenTrac mailing list. There's a great temptation to do things in an
APRS-centric way - for example, a capabilities field with flags for IGATE,
WIDEn-N, EOC, SATGATE, and so on. That'd certainly be an efficient way to
encode things for today's network, but it's too ad hoc. Instead, what I'm
trying to do with OpenTrac is to define a more general vocabulary to
represent such things. Rather than IGATEs and SATGATEs, for example, each
network (144.39, APRS IS, Garmin Rino FRS, whatever) is assigned its own
identifier. The entity then defines its network capabilities in terms of
connections to those networks.
As for Ev's origination frequency proposal, the OpenTrac network heard-by
list should address that. In the current spec, each transmission is flagged
with the ID of the network it was first heard on, but that's turned out to
be redundant with the use of the heard-by list that records all networks
it's heard on. I don't think individual frequencies are necessary, because
you can't go and transmit on a random frequency without anything to listen
to you. If there's something out there listening, then it's listening on an
identified network.
Speaking of frequencies, the format still hasn't been finalized for the
radio capabilities element. The intent there is to provide clear
identification of repeaters, satellites, and other such resources. With a
properly equipped radio this would give you automatic programming - just
listen to a single frequency, and you automatically learn about all local
repeaters, their offsets, CTCSS settings, and so on. Or a satellite can
announce what transponders it has enabled. The biggest problem is defining
modes. Emission designators only get you halfway there, because you still
need to know protocols for digital modes. It'll probably wind up just being
an enumerated list of known modes. Again, if you're an expert in the field
and want to contribute, let me know.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Station attributes -was- RE: APRS Icon statistics
From: Bob Bruninga <bruninga@usna.edu>
Date: Wed, 12 Nov 2003 15:42:05 -0500 (EST)
X-Message-Number: 18
On Tue, 11 Nov 2003, Bill Herrmann wrote:
>Would the whole discussion make more sense (and possibly actually get
>somewhere) if the protocol to convey capability via RF got defined
>separately from the that look pretty... but are not actually usable under
stress... by the lowest commond denominator of operator.
BECAUSE WE DONT HAVE A STANDARD for operations (this means DISPLAY)...
de WB4APR, Bob
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
