| |
ZL3AI > APRDIG 20.11.03 19:58l 258 Lines 10008 Bytes #999 (0) @ WW
BID : 2332-ZL3AI
Read: GUEST
Subj: TAPR Digest, Nov 13, 2/14
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<ON0AR<ZL3VML
Sent: 031120/1713Z @:ZL3VML.#80.NZL.OC #:13182 [Chch-NZ] FBB7.00i $:2332-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Sniffing for WideN-N's? [was: APRS Icon statistics]
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Wed, 12 Nov 2003 07:33:56 -0500
X-Message-Number: 6
This seems to have been lost along the way...
"Gregg G. Wonderly" wrote:
>>The same could be done for any flavor of N-N digipeater, HFGate, etc I suppose
>
>A Widen-N digi doesn't have any packet present identifying artifacts does it?
In the absence of an embedded tag (and no known artifacts to judge it's
personality) how would one go about identifiying a WIDEn-N, NOID digi with
your proposal of simple personality observing, Steve?
Ev, W2EV
----------------------------------------------------------------------
Subject: Re: Sniffing for WideN-N's? [was: APRS Icon statistics]
From: Steve Dimse <k4hg@tapr.org>
Date: Wed, 12 Nov 2003 08:02:52 -0500
X-Message-Number: 7
On 11/12/03 at 7:33 AM Ev Tupis (W2EV) <w2ev@arrl.net> sent:
>>A Widen-N digi doesn't have any packet present identifying artifacts does it?
>
>In the absence of an embedded tag (and no known artifacts to judge it's
>personality) how would one go about identifiying a WIDEn-N, NOID digi with your
>proposal of simple personality observing, Steve?
You should read more carefully, included in the my discussion was the use
of probe packets with different paths, sent in the wee hours when there
would be the lightest load on the system. Using these, it would be possible
to determine the network configuration.
Still, even without probes, you can deduce a lot. for example, the presence
of noid (not familiar enough with digi to know if this demands widen-n or
not. Furthermore, should a client only be hearing a single dig directly, it
would often be possible to determine what aliases a digi responds to
passively.
The cases where it is not possible to determine the network configs hardly
seems like adequate justification to add data to every frame as you have
proposed.
Steve K4HG
----------------------------------------------------------------------
Subject: Re: Adding Frequency of TX to the Protocol [was:APRS'Protocol Holes]
From: Steve Dimse <k4hg@tapr.org>
Date: Wed, 12 Nov 2003 08:05:48 -0500
X-Message-Number: 8
On 11/12/03 at 7:29 AM Ev Tupis (W2EV) <w2ev@arrl.net> sent:
>There is *no* APRS programmer that has invoked all APRS protocols (Bob's
APRSdos
>included). Authors will implement what they wish to implement.
>
>On the other hand, I know of *no* APRS programmer who has implemented new
>protocols outside of the bounds of the APRS spec. The goal is to get it into
>the spec first, then let 'market forces' dictate it's implementation.
Then all you need to do is announce a user-defined paket format, and let
people code it if they desire. This is exactly the situation for which I
fought to include this format in the spec.
Define it however you want, and if it proces to be useful THAT is when it
gets added to the spec.
Steve K4HG
----------------------------------------------------------------------
Subject: Re: Deduced *and* Declared Personality [was: APRS' Protocol Holes]
From: Steve Dimse <k4hg@tapr.org>
Date: Wed, 12 Nov 2003 08:13:48 -0500
X-Message-Number: 9
On 11/12/03 at 6:57 AM Ev Tupis (W2EV) <w2ev@arrl.net> sent:
>There are potential flaws in each approach. Why not embrace both approaches?
>Establish an on-air protocol that will allow the embedding of the information
in
>each TX frame (where it can be embedded) and also define the personality of
each
>possible APRS network appliance to use on the client-side where such embedded
>information is not available?
You are completely free to do create a protocol with the user defined
format. I will continue argue strongly against anything that adds a
significant amount to the channel load though, especially when you propose
to add it to every frame, that is a huge amount of additional channel load,
even if I were to accept your position on its benefit.
Steve K4HG
----------------------------------------------------------------------
Subject: RE: APRS Icon statistics
From: Steve Dimse <k4hg@tapr.org>
Date: Wed, 12 Nov 2003 08:19:03 -0500
X-Message-Number: 10
On 11/11/03 at 11:06 PM Gregg G. Wonderly <gregg@skymaster.cytetech.com> sent:
>>It should! The "N" overlay character in its position report should _only_
>>designate a full featured WIDEn-N digi with "NOID."
>>http://web.usna.navy.mil/~bruninga/aprs/digi-overlays.html
>
>Right, but the argument was that we shouldn't count on the content of the
>packet being correctly configured, and software should be able to snoop around
>to determine the capabilities of the station.
Not just snoop, but also to probe in those cases where it was needed.
Steve K4HG
----------------------------------------------------------------------
Subject: Re: MULTI-ICON proposal
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Wed, 12 Nov 2003 15:05:17 +0100
X-Message-Number: 11
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. At first glance this
looks okay, but now all clients need to have the same method to determine
how to present the stations by observing its capabilities. Even if they all
use the same algorithm, they will come up with different representations
since not all stations get the same information. Some are connected to the
Internet feed, some to RF and some to both besides positional differences
in reception and the ammount of history they have of the station depending
on how long they have been on.
In the end the repesentation on screen will be different from client to
client, something which was highly undesired.
I do not have a solution, but my feeling is that this solution will only
add to the confusion.
If an EOC is a digi in normal times and an EOC during an emergency, the
digi-icon can be swapped for an EOC icon during that emergency. I guess
people are present at the EOC and the main purpose will be changed to EOC -
so a change would be in-line with Bobs vision. Maybe this can even be made
automatic by adding a door switch to the cabinet containing the emergeny
protocols, as soon as the cabinet is opened the symbol is changed and the
EOC is in service...
This means that if a client is switched to only see EOC's the station will
not show up until it starts its EOC duty. It will disapear after the EOC
duty is finished and the stations runs as normal digipeater again. At least
all clients will see the change and know if the station is on duty or not.
I do the same with my TH-D7. If it is at home is shows a W or a house. When
I take it with me in the car I change the icon to "car" etc. It changes
identity when the purpose changes.
You can keep history, that way you will know that an EOC was previously a
digipeater and details of the EOC could reveil that. Clients that switched
on later will not have that information however.
I think multi-icons/symbols only have a purpose if there is some kind of
layering, a primary symbol with additional secondary symbols to show the
other, at that time less important, uses. I'm worried however, I think the
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.
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Re: MULTI-ICON proposal
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Wed, 12 Nov 2003 15:17:43 +0100
X-Message-Number: 12
At 18:46 11-11-03 -0500, Steve Dimse wrote:
>>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 ;-)
And to be able to sell cars is Europe, the majority of cars in Europe have
manual gears. No idea why, maybe Europeans are control-freaks? Same for
cruse controls etc. Its starting to change, but it will be a long time
before everybody is "converted".
It only problem with a manual gear is driving with a mike in your hand
(cell-phones are not allowed anymore to be used while driving, unless its
hands-free, so that's not a problem).
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Re: tm-d700A / Peet Ultimeter question
From: David L Norris <kg9ae@webaugur.com>
Date: 12 Nov 2003 09:41:10 -0500
X-Message-Number: 13
On Tue, 2003-11-11 at 21:58, Anthony Guillory wrote:
>display on the D700, it must be in one of the weather formats specified in
>the APRS protocol, which is an ASCII text packet as opposed to the
>hexadecimal format transmitted by the Peet Bros unit.
Actually, APRS spec lists several Peet Bros formats under "raw weather
reports" on page 72 of the PDF. But, Peet's formats don't match up well
with the more generic "positionless weather reporting" format on the
next page.
>I'd be interested in knowing of any simple code (inexpensive and preferably
>complete) that can be used in between the Peet Bros and a TNC (basic stamp
>approach, etc)
In case you're interested, I've written some code in C to parse all of
the Peet Bros data formats. It does nothing with that data but provide
a struct filled with the raw sensor readings. This same code is used in
XASTIR and APRS World. So, (I hope) it's fairly well tested.
My C code and some PERL scripts can be found here:
http://webaugur.com/wares/ultimeter.html#parser
--
David Norris, ARS: KG9AE
http://www.webaugur.com/dave/kg9ae/
ICQ - 412039
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
