| |
ZL3AI > APRDIG 19.11.03 20:02l 258 Lines 9255 Bytes #999 (0) @ WW
BID : 2325-ZL3AI
Read: GUEST
Subj: TAPR Digest, Nov 11, 5/6
Path: DB0FHN<DB0THA<DB0ERF<DB0FBB<DB0GOS<ON0AR<ON0AR<7M3TJZ<SP7MGD<VK3TE<
ZL2TZE<ZL3VML
Sent: 031119/1729Z @:ZL3VML.#80.NZL.OC #:13138 [Chch-NZ] FBB7.00i $:2325-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: APRS' Protocol Holes [was: APRS Icon statistics]
From: Steve Dimse <k4hg@tapr.org>
Date: Tue, 11 Nov 2003 18:05:05 -0500
X-Message-Number: 27
On 11/11/03 at 5:32 PM Ev Tupis (W2EV) <w2ev@arrl.net> sent:
>By embedding additional network functions into the frame, clients can quickly
>parse for that info and display it in accord with the client's need.
Again, the fact that someone is a digi can be usually be determined from
listening to the rf network, there is not need to use an unreliable
self-reported digi field!
In an emergency, when someone needs to add WIDE capability to the EOC, they
will change the alias (otherwise it won't work), but they are a lot less
likely to correctly change the PHG beacon (or whatever self-reported digi
status you want to propose) to reflect its new status!
Steve K4HG
----------------------------------------------------------------------
Subject: Adding Frequency of TX to the Protocol [was:APRS' Protocol Holes]
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Tue, 11 Nov 2003 18:14:27 -0500
X-Message-Number: 28
>You will certain know it came from some HF gate (because the GATE callsign in
>the path has been used).
Not if the station is a multi-personality station (HF Gate and VHF Digi).
All I'll know is that it came through that station. Was it a band opening
on 2m? (it could be). Did it come through on 30m? 20m? There's too much
to think about if time is of the essence.
Simply embed the frequency and know what you're dealing with.
>>This is such a simple addition to the /PHGabcdefg/ protocol, it's hardly worth
>>debating. The advantages of including such information far outweigh the
>>continued lack of having it.
>>
>I could not disagree more. The danger in adding something like this is subtle,
>but real. Once a means exists to tabulate something, no matter how inexact it
>is, people will do so, and start basing decisions on it. Bad data is MUCH more
>dangerous than no data.
Don't provide a tool because it may be misused? You can't be saying that,
can you? What am I missing?
Ev, W2EV
----------------------------------------------------------------------
Subject: Other ways to embed the info? [was:APRS' Protocol Holes]
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Tue, 11 Nov 2003 18:18:53 -0500
X-Message-Number: 29
Steve Dimse wrote:
>Please, don't forget, that no matter what, this is not compatible with many
APRS>stations out there. PHG cannot appear in compressed position reports
including
>Mic-E, position+weather format (@.....lat/lon_spd/crs....) and many other APRS
>packet formats. You are proposing something which could never give the desired
>result!
Then let's not "throw the baby out with the washwater". If this mechanism
(PHGxxxxx/) isn't the best one, let's find one that is more universally
applicable. The need to embed frequency of TX and network personality is
real.
What would you suggest?
Ev, W2EV
----------------------------------------------------------------------
Subject: Re: MULTI-ICON proposal
From: Steve Dimse <k4hg@tapr.org>
Date: Tue, 11 Nov 2003 18:46:58 -0500
X-Message-Number: 30
On 11/11/03 at 5:40 PM Ev Tupis (W2EV) <w2ev@arrl.net> sent:
>The 'better alternative' works only if there is a way to determine a
personality
>from a stations' transmission. I've already pointed out at least one example
>where such is not the case.
If you are talking about the person that sends a distress signal on an HF
frequency other than 30 meters, exactly how likely do you consider this???
>APRS needs a way to allow savvy operators to manually embed information into
>their transmissions.
APRS has it, it is called the status packet, or you can define a new
"user-definable" packet if you want.
>There's a reason that manual transmission vehicles exist.
No, they exist because they are cheaper to make and better at transferring
power to the wheels ;-)
Steve K4HG
----------------------------------------------------------------------
Subject: UI-View setup
From: "Jim Ebner" <jimebner@charter.net>
Date: Tue, 11 Nov 2003 18:46:18 -0500
X-Message-Number: 31
I have just switched over to UI-View32. I have an older AEA Pakratt 232 and
the command lines are different than what is in the program.. Would someone
please send me the command lines for it? I have lost them.
Thank you,
Jim Ebner N8JE
----------------------------------------------------------------------
Subject: RE: APRS Icon statistics
From: "Eric Christensen" <kf4otn@earthlink.net>
Date: Tue, 11 Nov 2003 18:59:42 -0500
X-Message-Number: 32
Now, I really like this idea from Ev...
<<<Ev Wrote...>>>
In fact, this is where I applaud Roger and UI-View. At a glance, I know
who the IGates are. He tests the traffic coming from a given station
and then places a blue-box around those exhibiting IGate
characteristics.
The same could be done for any flavor of N-N digipeater, HFGate, etc I
suppose.
Looking forward ...
A simple client-side pull-down menu like this would be interesting to
persue: Display Only...
And a check-box selection screen with the following...
[] Relay Digipeaters
[] WideN-N Digipeaters
[] TraceN-N Digipeaters
[] IGates
[] HF Gates
[] SatGates
[] WX Stations
[] Mobile
Display symbols could continue to be expressions of personal choice --
though users would be encouraged to always display star-digis whenever
any digi function is present (since that forms the foundation of RF-side
operation).
Ev, W2EV
----------------------------------------------------------------------
Subject: Re: Adding Frequency of TX to the Protocol [was:APRS' Protocol Holes]
From: Steve Dimse <k4hg@tapr.org>
Date: Tue, 11 Nov 2003 19:25:07 -0500
X-Message-Number: 33
On 11/11/03 at 6:14 PM Ev Tupis (W2EV) <w2ev@arrl.net> sent:
>>You will certain know it came from some HF gate (because the GATE callsign in
>>the path has been used).
>
>Not if the station is a multi-personality station (HF Gate and VHF Digi). All
>I'll know is that it came through that station. Was it a band opening on 2m?
>(it could be). Did it come through on 30m? 20m? There's too much to think
>about if time is of the essence.
Maybe I'm missing something...
K4HG>APRS,GATE,WIDE*:....This comes via HF
K4HG>APRS,GATE*,WIDE*:....This comes via HF
K4HG>APRS,WIDE*,GATE,WIDE:....This comes via VHF
K4HG>APRS,WIDE,GATE,GATE,WIDE*:....This originates on VHF, goes through two HF
GATEs, then ends up back on VHF.
All HF Gateways respond to the alias GATE, so by looking at the path you can
tell where it originated.
>>I could not disagree more. The danger in adding something like this is
subtle,
>>but real. Once a means exists to tabulate something, no matter how inexact it
>>is, people will do so, and start basing decisions on it. Bad data is MUCH
more
>>dangerous than no data.
>
>Don't provide a tool because it may be misused? You can't be saying that, can
>you? What am I missing?
Yes, I do believe it is irresponsible to provide a tool that can cause
harm, unless there is a clear benefit. The danger of hammers being misused
on people's heads is tolerated because the tool has a very useful purpose.
If it did not have any useful purpose, then it should not be available.
(No, please, no gun control arguments here!).
You are proposing something that will take time for every programmer to
implement, which can only give the desired information to some of the
users, and which I'm arguing gives no significant benefit.
Furthermore, it is something that almost any client now could support by
simply placing frequency info in the status packet (which I'm betting most
infrastructure appliances, if not nost users, on non-standard frequencies
already do). My guess is 99% of the APRS activity is on standard
frequencies easily determined by analysing the packet. Given that it is
such a small subset of the packets, it makes much more sense to use
user-defined packets...
Steve K4HG
----------------------------------------------------------------------
Subject: Re: Other ways to embed the info? [was:APRS' Protocol Holes]
From: Steve Dimse <k4hg@tapr.org>
Date: Tue, 11 Nov 2003 19:29:32 -0500
X-Message-Number: 34
On 11/11/03 at 6:18 PM Ev Tupis (W2EV) <w2ev@arrl.net> sent:
>>Please, don't forget, that no matter what, this is not compatible with many
>APRS
>>stations out there. PHG cannot appear in compressed position reports
including
>>Mic-E, position+weather format (@.....lat/lon_spd/crs....) and many other
APRS
>>packet formats. You are proposing something which could never give the
desired
>>result!
>
>Then let's not "throw the baby out with the washwater". If this mechanism
>(PHGxxxxx/) isn't the best one, let's find one that is more universally
>applicable. The need to embed frequency of TX and network personality is real.
>
>What would you suggest?
Since this is such a low volume thing (do you have any data that the
percentage of otherwise unidentifiable stations even as high as 1%?) I'd
say create a user-defined packet for frequency, anyone that wants to send
it can use that format. That is the whole point of the user-defined format.
Steve K4HG
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
