| |
ZL3AI > APRDIG 25.05.03 10:10l 252 Lines 9751 Bytes #999 (0) @ WW
BID : 1380-ZL3AI
Read: GUEST
Subj: TAPR Digest, May 22, 6/7
Path: DB0FHN<DB0RGB<DB0MRW<DB0SON<DB0SIF<DB0EA<DB0RES<ON0AR<ZL2BAU<ZL3VML
Sent: 030524/1348Z @:ZL3VML.#80.NZL.OC #:863 [Chch-NZ] FBB7.00i $:1380-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: RE: APRS-NET COncept! -- Radio Mirror
From: Bill Vodall - WA7NWP <wa7nwp@jnos.org>
Date: Thu, 22 May 2003 14:17:01 -0700 (PDT)
X-Message-Number: 46
On 22 May 2003, Rich Garcia wrote:
>Was there not a QST article a year or so back on this topic ? I am
>thinking that maybe W2FS wrote it but I may very well be wrong on the
>author.
What was the Ham Web or is currently called Radio Mirror project?
Here's John's original info on Radio Mirror at TAPR:
http://www.tapr.org/~wa0ptv/
Here's some notes on my work in progress:
http://www.jnos.org/cgi-bin/moin.cgi/RadioMirror
73,
Bill - WA7NWP
----------------------------------------------------------------------
Subject: RE: APRS-NET COncept!
From: Bob Bruninga <bruninga@usna.edu>
Date: Thu, 22 May 2003 17:17:26 -0400 (EDT)
X-Message-Number: 47
On 22 May 2003, Rich Garcia wrote:
>Was there not a QST article a year or so back on this topic ? I am
>thinking that maybe W2FS wrote it but I may very well be wrong on the
>author.
Yes see my original post. My last paragraph said this was just a rehash
of his HAMNET idea of many DCC's ago. In fact, I think his paper appeared
in 1992 at the SAME DCC where I introduced APRS...?
Bob
----------------------------------------------------------------------
Subject: Re: "Gap Filler" digipeaters
From: Bob Bruninga <bruninga@usna.edu>
Date: Thu, 22 May 2003 17:22:02 -0400 (EDT)
X-Message-Number: 48
On Thu, 22 May 2003, Joseph C. Bender wrote:
>Say I've got a 5-10 watt transmitter with an antenna setup that can "hear"
>most stations within a 20 mile radius. Say I can reliably (> 90% of
>attempts) hit a WIDE that might be able to hear most of what I can hear,
>but low-powered mobiles or portables may not be able to get out in my
>immediate area. Add on top of that other fairly close RELAY capable
>stations that may or may not operate all the time, while my station would.
PERFECT application for a RELAY digi as you propose.
>Now, as it's a station slightly on the low-powered side, should I go
>ahead and accept and digi RELAY packets outward, to get them to the WIDE?
If you have any doubt about possibly being "overkill" because of other
RELAY's in the area, then being a LOWER power is again, a perfect
solution. If the other RELAY hears it, it will CAPTURE the digi and your
weaker signal will not cause any problem. If the other RELAY misses it,
and you hear it, then your lower power station still has a chance of
helping out the packet....
If you will be permanent, do it. (of course every situation is different
and your milage will vary)...
Bob
----------------------------------------------------------------------
Subject: Re: Ultra simple MIC-e repeater
From: Bob Bruninga <bruninga@usna.edu>
Date: Thu, 22 May 2003 17:24:01 -0400 (EDT)
X-Message-Number: 49
On Thu, 22 May 2003, David VanHorn wrote:
>At 04:32 PM 5/22/2003 -0400, Wes Johnston wrote:
>
>>Good eye Dave, but this won't be a problem... since both TNCs hear the
>>same audio souce, and they decode 2 different signals which are mutually
>>exclusive, both TNCs will never talk at the same time. There will not
>>ever be a collision on the serial port in this setup.
>
>I wouldn't be so sure. There's delays between the audio and the output,
>and I wouldn't bet on them being the same in both cases. I also
>wouldn't bet on either detecting the other's carrier.
Its a Voice repeater and we are talking about a MIC-E packet on the end
of a voice transmission. Can't possibly be two Mic-E VOICE users ending a
voice transmission within a 3rd of a second of each other...
Bob
----------------------------------------------------------------------
Subject: Re: Ultra simple MIC-e repeater
From: David VanHorn <dvanhorn@cedar.net>
Date: Thu, 22 May 2003 16:25:04 -0500
X-Message-Number: 50
>I do it all the time as long as you dont have simultaneous data.
There's the rub..
>In this
>case, there can be only one Packet at a time heard on the Voice repeater.
>So both a 1200 and 9600 baud packets cannot possibly occcur at the same
>time.
>de WB4APR@amsat.org, Bob
Not ever? Long packet on one side, short on the other, variable delays
internal to the TNCs in processing..?
----------------------------------------------------------------------
Subject: Re: Ultra simple MIC-e repeater
From: Bob Bruninga <bruninga@usna.edu>
Date: Thu, 22 May 2003 17:25:13 -0400 (EDT)
X-Message-Number: 51
Or install a KPC-9612 which listens for both 1200 and 9600 and can
digipeat BOTH on 1200 and it does callsign substitution so it self-ID's
every packet. (so gets rid of that terrible CWID idea). Only problem of
course is that they cost $xxx. But you only need one.
----------------------------------------------------------------------
Subject: Bogus Tropical Depression
From: dale huguley <kg5qd@wxsvr.net>
Date: Thu, 22 May 2003 22:09:24 +0000
X-Message-Number: 52
Hi All-
Anyone have a clue why vk2xjg-2 is plotting a non-existant tropical
depression at 9.7N 104.2W ? It has a name of "TD_____" with future
positions having names like TD2 +12. There is no tropical depression #
2. The "present" matches the position on the 20th at 0600z for TD #1
which became Tropical storm Andres.
Bogus.
73 de kg5qd Dale
----------------------------------------------------------------------
Subject: Re: Ultra simple MIC-e repeater
From: Wes Johnston <wes@johnston.net>
Date: 22 May 2003 18:45:30 -0400
X-Message-Number: 53
OK, so we jack the baud rates up to 57k on the serial ports. This
insures that the time a packet spends transversing the serial link is as
short as possible. Not foolproof, but it would prevent my 128byte long
1200 packet from being clobbered on the serial link by your 9600 32byte
long packet which came in right behind me. I've just done some
calculations... assuming packet lengths from 32 bytes minimum to 128
bytes max.
1200 9600 57k
32 bytes 266ms 30ms 5ms
128 bytes 1066ms 133ms 22ms
Let's assume the worst case... I've just transmitted a 128byte packet at
1200 bauds. While it does take just over 1 second on the air, it only
takes 22ms on the serial port at 57k baud. You come along behind me
with a short 9600baud packet which takes 30ms on the air. By the time
you have finished sending your 9600 baud packet and the TNC has run it's
checksum test and begun to sent it out the serial port, a little more
than 30ms has gone by. Since my packet ran thru the serial link in
22ms, we have a lull on the serial link of 8ms before your packet could
possibly begin to run. Given the bounds of normal mic-e packets, I just
don't see how the two TNCs could talk at the same time. If you
extended the packet lengths beyond 128 bytes, then you have a) connected
mode, b)tcp/ip, c)an aprs message... all of which are acked, and will be
sent again if there is a problem. The real potential for problems here
is the short 9600 baud packet... but I never heard of a mic-e packet
which was less than 32 bytes.
Another simple method would be to build a timer which would inhibit
serial port on the opposite TNC for x nubmer of seconds if the CD light
came on.
While I don't expect to see a packet much longer than 35 or 40 bytes, it
could happen.
And I also don't expect to see a packet more than once every 3 to 5
seconds... these are mic-e's tagged onto voice transmissions - and it
takes me a few seconds to "ummm" and "ahhh" on the air. It could
happen...
Admittedly the idea solution would be to run something like digined at
the repeater site - which I stated in the original email. But when I
suggested running a PC at a digi site a few weeks ago (under the subject
of frequency diversity reception), it was pointed out to me that a PC
wasn't the way to go at a remote site.
Dave, nothing is fool proof. But what I've proposed will get 99.9% of
packets thru. I think the bigger possibility for interference using
this is going to be "tailgaters" on the voice side stomping on my packet
transmission which is muted.
However, if users are really worried about collisions on the serial
port, then they only hook up one TNC to receive and one to transmit.
The logical thing here would be to forfeit the 9600 and just run this
all on one TNC, but you loose the ability to copy those nice quiet 9k6
packets that no one on voice notices.
Of course Bob had the suggestion for using a 9612 which would also
work.. and in the long run is probably the best solution. I just happen
to have an old 9600 tnc laying around and a handful of kpc3's.
My goodness this got long and convoluted... this is supposed to be a
thread about how to make a *simple* mic-e compatible repeater....
Wes
----------------------------------------------------------------------
Subject: RE: APRS-NET COncept!
From: John Hansen <hansen@fredonia.edu>
Date: Thu, 22 May 2003 18:58:53 -0400
X-Message-Number: 54
The pacsat protocol has way more information in it than you need. The
amount of overhead is really more than you would want to use. When that
protocol was written, the authors had no way of knowing that the average
user was going to get his files via broadcast, so they built in support
fields for both broadcast and connected mode. For example, there is a
field in the header for the number times that a particular file has been
downloaded. If it were rewritten today, I'm sure it would be a lot leaner.
John W2FS
At 04:19 PM 5/22/03 -0400, Wes Johnston wrote:
>Doesn't AMSAT already have a protocol (WISP?) which harvests data from
>other users passively and requests fills as needed? DOn't wanna
>reinvent the wheel..
>Wes
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
