| |
ZL3AI > APRDIG 18.04.03 10:05l 268 Lines 10624 Bytes #999 (0) @ WW
BID : 1172-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 15, 3/4
Path: DB0FHN<DB0RGB<OK0PPL<RZ6HXA<SP7MGD<VK7AX<ZL2BAU<ZL3VML
Sent: 030417/1042Z @:ZL3VML.#80.NZL.OC #:64064 [Chch-NZ] FBB7.00i $:1172-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: reducing hidden transmitter problems
From: "Wes Johnston" <wes@johnston.net>
Date: Tue, 15 Apr 2003 18:38:09 -0400
X-Message-Number: 15
Looks like the last 1/2 of your article is missing....
Your idea has merit, and has worked well in germany. There they have a
dedicated radio for each digipeater link. It is not uncommon for them to
have digipeaters with 6 or 7 radios and one userport. I really tried to do
this here in SC about 8 or 9 years ago with connected mode packet. I put up
a digipeater with three radios to link three towns and could not get ANYONE
to agree on frequencies (and no one wanted to be saddled with a 220mhz radio
either). Believe it or not, that incident was the final straw for me in
connected mode and TCP/IP on the air. The lack of willingness for the local
SYSOPs to work together for a solution to an overloaded channel showed me
all too well, that you can't depend on coordinating with others. I'm not
running your idea down at all (hope you know that), it's just a bad taste
for me from coordination. Anyway, the other thing your idea has going for
it is that you can progress beyond 1200baud on the back bones and leave the
legacy equipment on 144.39. Your idea will force people to upgrade if they
want to keep seeing things on their screen (a good thing).
My idea has price on it's side (sound cards and police scanners), but is not
very adaptable to the future. I thought it would be neat though, to use a
receiver on the downlink of PCsat and mic-e's on local repeaters. Someone
wrote me to say that sound card modems were not reliable, but I say in a
densely populated urban area where HTS is a problem, you will not have
unattended digi's.
Wes
----------------------------------------------------------------------
Subject: Re: Cool APRS idea
From: Bill Vodall <wa7nwp@jnos.org>
Date: Tue, 15 Apr 2003 15:44:21 -0700
X-Message-Number: 16
At 06:36 AM 4/16/03 +1000, Andrew Rich wrote:
>I don't know if this has been done before ?
>findu.com has by x months of data right, and in there there must be an
>occurance of a digipeater that was used to hop across a hill.
>Why don't we use findu.com to create coverage maps for digipeaters ?
I do that for the major digi's in the Pacific Northwest. Go to
http://www.jnos.org/cgi-bin/moin.cgi?NwaprsJavAPRS
and scroll down to the section on:
"Display traffic heard by the regions major wide area node"
There you can either pull up a JavAprs display for the past days
traffic heard by a digi or look at the raw data file.
Stored data files are "mined" daily at 2345Z for the packets heard by the
digipeater in the past 24 hours. This works thanks to the magic of
running NOID digipeaters and storing all packets heard locally on RF with
no duplicate filtering.
To make the display a bit more meaningful, I filter the PHG entries from
all entries except for the specific digi. Thus you can easily see the
coverage circle of a digi compared to the actual stations it's hearing.
73,
Bill - WA7NWP
----------------------------------------------------------------------
Subject: Re: HF APRS Suggestion
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Tue, 15 Apr 2003 19:02:19 -0400
X-Message-Number: 17
>>What with the proliferation of digipeating and RF Bridging on 20 meters,
>>it is often difficult to know on what band a particular transmission
>>originated.
>>
>>Here is a 100% APRS-compatible solution.
>>Place a 2-byte "band designation" in your Destination Field. Doing this
>>will allow users to automatically "filter" what is displayed (as an
>>ALTNET), by band of interest. Don't want to filter? Turn "ALTNET" off.
>>Easy, huh?
>
>Problem is, that ALTNET is exclusive.
It isn't exclusive, actually. UI-View, for instance, requires that ALTNET
functions be turned "on", otherwise, ALTNET processing is off. Therefore it
passes everything. APRSdos can do the same thing (turn off ALTNET).
The beauty of this particular solution is that it provides
band-of-origination information without wasting 2-bytes of airtime (a very
imortant consideration on non-AX.25 "APRS" frequencies such as 28.131 MHz).
Never the less, if one MUST use 2-bytes ahead of the band designation, then
those two bytes should convey useful information, and not be "just fillers".
So...
Use "ID" if...
... a station is NOT able to RX (it a TX only station such as a
beacon [we call 'em PROBEs in BEACONet, by the way]) or will
ignore any attempt to be interrogated (ie ?APRS?), such as
stand-alone TNC-based digipeaters.
Use "CQ" if...
... a station IS capable of RX operation and will respond to
remote interrogation.
According to the spec, these will do the same thing.
So...folks...these are all valid for a station on 20-meters, depending on what
YOU intend to have happen (after all, it is up to the launcher of the frame to
determine how the frame is handled on RF...by APRS convention):
W2EV>HK,.....
W2EV>CQHK,.....
W2EV>IDHK,.....
What say, Mr. B? Does this carry the "Father of APRS Seal of Approval"? :)
Ev, W2EV
----------------------------------------------------------------------
Subject: Re: Opening up the proverbial can o' worms
From: "Chris Rose" <kb8uih@arrl.net>
Date: Tue, 15 Apr 2003 19:40:25 -0400
X-Message-Number: 18
We will use packet on vhf locally to transmit names and conditions of
casualties. Names of fatalities will not be transmitted over normal voice
channels. Our Red Cross uses hams and non hams alike. Our EC/RO is
involved with the Red Cross here with DATs.
73,
Chris
KB8UIH
----------------------------------------------------------------------
Subject: Re: HF APRS Suggestion
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 15 Apr 2003 19:42:56 -0400 (EDT)
X-Message-Number: 19
On Tue, 15 Apr 2003, Ev Tupis (W2EV) wrote:
>>>What with the proliferation of digipeating and RF Bridging on 20
>>>meters, it is often difficult to know on what band a particular
>>>transmission originated.
>>>
>>>Place a 2-byte "band designation" in your Destination Field. Doing
>>>this will allow users to... "filter" what is displayed (as an
>>>ALTNET), by band... Don't want to filter? Turn "ALTNET" off.
>>
>>Problem is, that ALTNET is exclusive.
>
>It isn't exclusive, actually. UI-View, for instance, requires that ALTNET
>functions be turned "on", otherwise, ALTNET processing is off. Therefore it
>passes everything. APRSdos can do the same thing (turn off ALTNET).
But it is supposed to be exclusive. THus if you want to propose
something that is guaranteed to work with all software, you need to
propose things that are as they are "supposed to be".
>Never the less, if one MUST use 2-bytes ahead of the band designation,
>then those two bytes should convey useful information, and not be "just
>fillers". So...
>
>Use "ID" if...
> ... a station is NOT able to RX (it a TX only station such as a
> beacon [we call 'em PROBEs in BEACONet, by the way]) or will
> ignore any attempt to be interrogated (ie ?APRS?), such as
> stand-alone TNC-based digipeaters.
>
>Use "CQ" if...
> ... a station IS capable of RX operation and will respond to
> remote interrogation.
>
>According to the spec, these will do the same thing.
>
>So...folks...these are all valid for a station on 20-meters, depending on what
>YOU intend to have happen (after all, it is up to the launcher of the frame to
>determine how the frame is handled on RF...by APRS convention):
>
>W2EV>HK,.....
>W2EV>CQHK,.....
>W2EV>IDHK,.....
>
>What say, Mr. B? Does this carry the "Father of APRS Seal of Approval"? :)
Yes, but still, I would avoid the first one since you cannot guarantee
that APRS compliant software will receive it. In that case I would use
"APHK"... And secondly, Kenwoods goofed and did not wildcard all after
"CQ" and some software (I think) does special processing on "ID" packets
(Ie, they throw them away or put them on a special ID page). Im not sure
any of this is in the spec. But ID "should" be OK. Im just noting that
TNC ID packets were considered a waste of AIR time and many authors do
their own thing with them...
Good luck. Yes it is a good idea to use identifiers like this.
Bob
----------------------------------------------------------------------
Subject: Re: HF APRS Suggestion
From: <BobDonnell@arkalmus.com>
Date: Tue, 15 Apr 2003 16:48:55 -0700
X-Message-Number: 20
Hi Ev, and all
Ev: You've got a misconception about the "two bytes of air time
wasted". Those bytes are part of the packet destination field, which is
fixed at 7 bytes. The unused bytes are sent as spaces - but they are
sent. So there's zero penalty for using Bob's scheme, other than the
characters displayed on the screen of the receiving station. You might
want to study the underlying packet protocol, to better understand how
it works.
73, Bob, KD7NM
----------------------------------------------------------------------
Subject: Re: HF APRS Suggestion
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Tue, 15 Apr 2003 19:57:02 -0400
X-Message-Number: 21
>Ev: You've got a misconception about the "two bytes of air time
>wasted". Those bytes are part of the packet destination field, which is
>fixed at 7 bytes. The unused bytes are sent as spaces - but they are
>sent. So there's zero penalty for using Bob's scheme, other than the
>characters displayed on the screen of the receiving station. You might
>want to study the underlying packet protocol, to better understand how
>it works.
Hi Bob,
Though it was easy to miss in the original post, I was careful to say...
>>The beauty of this particular solution is that it provides
>>band-of-origination information without wasting 2-bytes of
>>airtime (a very imortant consideration on non-AX.25 "APRS"
>>frequencies such as 28.131 MHz). ^^^^^^^^^
^^^^^^^^^
On 28.131, participants use PSK31, rather than AX.25. They do not pack
anything there. Whereas, in the AX.25 world, "W2EV>HK" is actually
14-bytes long, in the PSK31 world, it is actually only 7-bytes long. Adding
another 2-bytes (especially if they carry no useful information) is not
insignificant at these transmission speeds.
Even so, the use of CQ and ID meet Bob's APRS spec while conveying somewhat
(arguably) useful information.
With the proliferation of modes other than AX.25, there is actually much to
be gained by assuring the shortest possible TX length.
Kind regards,
Ev, W2EV
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
