| |
ZL3AI > APRDIG 17.07.03 17:04l 242 Lines 9370 Bytes #999 (0) @ WW
BID : 1621-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jul 14, 2/4
Path: DB0FHN<DB0RGB<OE5XBL<OE3XSR<OK0PCC<OM0PBC<HA5OB<HA3PG<JE7YGF<JA4QNJ<
7M3TJZ<IK6PYS<ON0BEL<ZL2BAU<ZL3VML
Sent: 030716/1330Z @:ZL3VML.#80.NZL.OC #:4480 [Chch-NZ] FBB7.00i $:1621-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: packet repeater?
From: John Becker <w0jab@big-river.net>
Date: Mon, 14 Jul 2003 11:56:00 -0500
X-Message-Number: 9
> I want a packet REPEATER , say 144.39/147.40 split
Ain't that just a bit close to the 147.39 / 147.99 repeater pair ? ?
We have one here in the St. louis area......
----------------------------------------------------------------------
Subject: Re: [ Wes Johnston ] Re: packet repeater?
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Mon, 14 Jul 2003 13:19:44 -0500
X-Message-Number: 10
>So what I'm proposing here is a dual mode access digipeater... which
>will allow mobile users a fair shot at seizing a channel.
Currently, you have a 'fair shot' given the CSMA technologies in use. The
more frequencies you add, the more opportunities you'll provide for
interference free transmission by hidden transmitters. This is why I want
to design a VHF/UHF SSB radio that uses PSK for modulation and provides a
narrower channel spacing than FM, but wider than conventional SSB. If you
can get 20+ channels on PSK31 at a slow baud rate, you should be able to
get a reasonable number, perhaps 5, at a higher baud rate. And, if we move
to using opentrac there, with known packet lengths, a station wishing to
use a channel could negociate for a segment and a time, to improve the
changes that it could actually use that slot. We all have GPS data for
APRS mobile use, so timing could be pretty precise...
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: Re: [ Wes Johnston ] Re: packet repeater?
From: "Sadowski, Allan" <allan.sadowski@ncshp.org>
Date: Mon, 14 Jul 2003 14:32:34 -0400
X-Message-Number: 11
Gosh... this is starting to sound like an interesting version of DAMA !!!
especially if different bandwidths were negotiated... hmmm a control
channel to send requests to... then a downlink channel to acknowledge and
assign the request... then a channel and time slot to actually use...
yep... sounds like DAMA (as used on FLTSATCOM?) .... hey... and we do it
all in a single voice bandwidth channel ... that's new and interesting !!!
I like the sounds of this... now to kill the doppler problem to use it
on Satellites as well as terrestial links....
ALOHA
AH6LS
----------------------------------------------------------------------
Subject: Re: [ Wes Johnston ] Re: packet repeater?
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Mon, 14 Jul 2003 13:43:29 -0500
X-Message-Number: 12
Since there would be software involved on both ends, you could make it as
smart about bandwidth use as you wanted... You could have 2 low baud channel
for requests in, and responses out, and then allocate the remaining bandwidth
based on requests. It would be something like USB bandwidth allocation I
suppose...
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: Re: [ Wes Johnston ] Re: packet repeater?
From: wes@johnston.net
Date: Mon, 14 Jul 2003 15:14:58 -0400 (EDT)
X-Message-Number: 13
What I'm wondering is will the AFC on PSK31 auto track the doppler shifts
on the new PCsat when it's up? I think it will...
Greg, you have hit on a gold mine... dynamically allocated baud rates and
frequencies within a 3khz audio signal. Now I just wish SSB equipment was
as cheap as FM.
I've actually been reading lots lately about cell phones. They do things
on the downlink channel such as instuct the cell phone to increase or
decrease it's power every 1.25mS (CDMA). Power should be a software
programmable thing in your proposed system too... to keep one station from
swamping the receiver.
You know, APRS works because it is ad-hoc. Of course that's the achillese
heel. It's also uncoordinated, has no guaranteed thruput and no way to
know if you are in the network or not. I think the time is right for
intelligent radios/TNCs which can try to "connect" to some central node,
and upon failure of that, fall back to what we run today. Yes, ACKs on
each packet will slow things down, but only if they are done on the same
frequency. At the onset of aprs, UI-Frames were compared to connected
frames. And assuming the connection had to be made each time, that was
indeed very, very lossy - couple that with having to TX and ACK a packet
with each station. However if a station were to connect to a WIDE node
once upon entering it's coverage area and remain connected until it left
the area, that would be the equivalent of calling someone's house and
having them set the phone down so you could hear the goings on in the room.
No need to call and let the phone ring each time you have something to say.
If we were to combine (I know I'm completely off the subject of your PSK31
method - sorry, I'm on a rant) the virtual connection and timing
coordination of DAMA with the UIrouting of APRS, we'd have a winner. In
other words, you enter an area let the local wide node know you are there.
If you don't get an answer back from the wide node, operate normal UI mode.
If you DO get an answer back from the local wide node, then you are
considered to be "connected" and hold off all transmissions until polled by
the wide. If you go more than 3 minutes w/o hearing from a the controlling
WIDE, then you fall back to normal UI mode. When you are polled and do
finally get to transmit your position, it is not transmitted directly to
the wide, rather it is transmitted as an APRS RELAY, WIDE path. (The
assumption is that you may be able to hear the wide, but it can't hear you.
In this case, the WIDE node doesn't really serve as a DAMA master, but
rather a time slot coordinator. Polling times would be longer than dama's
.5 second... more like 3 or 4 seconds / station to give time for all the UI
frames to bounce around.
Wes
ham callsign: kd4rdb
find me: http://wesvan.zapto.org
----------------------------------------------------------------------
Subject: Balloon over WV heading East!
From: Bob Bruninga <bruninga@usna.edu>
Date: Mon, 14 Jul 2003 18:30:46 -0400 (EDT)
X-Message-Number: 14
Eastcoasters:
The Balloon launhced in the michigan did not burst and is heading east.
It is now (1830 EDT) over WV/Ohio line and headed S.East. Bob.
---------- Forwarded message ----------
Date: Mon, 14 Jul 2003 14:55:00 -0700
From: brunson1 <brunson1@gte.net>
To: "Bruninga, Bob" <bruninga@usna.edu>
Subject: Looks like we have a floater
Bob- I see the balloon launched up in Michigan is floating your way ~
52,000'. It shows as KC8UCH-11. I suspect it was suppose to burst, but
didn't reach that altitude. Have been watching via the internet for most
of the day. Have fun tracking it as it comes by. ;-)
73
Craig
N7TSZ
----------------------------------------------------------------------
Subject: Re: Please...authors...please [was: hidden transmitter problems]
From: "hasan schiers" <schiers@netins.net>
Date: Mon, 14 Jul 2003 08:49:45 -0500
X-Message-Number: 15
UI-Traffic add-on for UI-View already does this and graphs the results. It
even breaks out the graphic display by number of "hops" so you can compare
"efficiency" vs hops.
I would also agree that coverge circles are only useful if you manually
"tweak" them to reflect actual coverage. In Iowa, at least, if you enter
"real data", the coverage doesn't even remotely resemble "actual
performance".
The Probe concept is much more useful than the thoughful imaginings of
coverage circles.
....hasan, N0AN
----------------------------------------------------------------------
Subject: Re: Balloon over WV heading East!
From: James Jefferson <jj@aprsworld.net>
Date: Mon, 14 Jul 2003 17:42:16 -0500
X-Message-Number: 16
Here's a nice plot of what the balloon is doing:
http://db.aprsworld.net/datamart/track.php?call=KC8UCH-11&hours=72
-Jim
----------------------------------------------------------------------
Subject: Re: Balloon over WV heading East!
From: "Scott Miller" <scott@opentrac.org>
Date: Mon, 14 Jul 2003 15:50:50 -0700
X-Message-Number: 17
Been watching this one all day. Are the chase vehicle(s) equipped with
trackers, and if so, does anyone have the callsigns? It'd be interesting to
watch the chase.
Scott
----------------------------------------------------------------------
Subject: RE: Balloon over WV heading East!
From: "KENT HUFFORD" <khufford@comcast.net>
Date: Mon, 14 Jul 2003 18:51:38 -0400
X-Message-Number: 18
This is kinda cool.
It is 1850 EDT and it is at 51,440 feet over I77 in OHIO.
Kent
KQ4KK
----------------------------------------------------------------------
Subject: Re: hidden transmitter problems - PHGR query
From: Bill Vodall - WA7NWP <wa7nwp@jnos.org>
Date: Mon, 14 Jul 2003 16:11:06 -0700 (PDT)
X-Message-Number: 19
On Fri, 11 Jul 2003, Bob Bruninga wrote:
>Adding a RATE on the end of PHG and calling it PHGr then not only tells
>something about the power, height and gain of your APRS station but also
>how often it is transmitting.
The "R/rate" field only applies to the packets actually containing
the "PHGR" entry? That way we don't have to worry about all the
unscheduled packets such as Wx, Telemetry, etc being generated?
Bill
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
