| |
ZL3AI > APRDIG 04.05.03 19:42l 231 Lines 9849 Bytes #999 (0) @ WW
BID : 1244-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 28, 2/3
Path: DB0FHN<DB0ZWI<DB0CHZ<DB0ERF<DB0FBB<DB0IUZ<DB0GOS<DB0EEO<PI8DAZ<PI8WFL<
ON0AR<ZL2BAU<ZL3VML
Sent: 030501/1634Z @:ZL3VML.#80.NZL.OC #:64896 [Chch-NZ] FBB7.00i $:1244-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: findu Down???
From: "Christensen, Eric Harlan" <CHRISTENSENE@MAIL.ECU.EDU>
Date: Mon, 28 Apr 2003 13:12:22 -0400
X-Message-Number: 5
Is findu down? I cannot get any response.
73s,
Eric KF4OTN
----------------------------------------------------------------------
Subject: Re: findu Down???
From: "Steve Dimse" <k4hg@tapr.org>
Date: Mon, 28 Apr 2003 17:19:49 +0000
X-Message-Number: 6
On Mon, 28 Apr 2003 13:12:22 -0400, Christensen, Eric Harlan wrote
>Is findu down? I cannot get any response.
Working fine here.
Steve K4HG
----------------------------------------------------------------------
Subject: RE: findu Down???
From: "Christensen, Eric Harlan" <CHRISTENSENE@MAIL.ECU.EDU>
Date: Mon, 28 Apr 2003 13:21:58 -0400
X-Message-Number: 7
Okay... Must be local.
----------------------------------------------------------------------
Subject: Re: AX.25 & TCP/IP [was: Another thing I'd like to see...]
From: wes@johnston.net
Date: Mon, 28 Apr 2003 14:55:39 -0400 (EDT)
X-Message-Number: 8
Well, this would work, except for one thing... who decides who gets which part
of the SSB bandwidth? You end up with the same problem all over again - many
stations would choose, say, an easy round number like RF Freq+1khz or +2khz,
and we'd all be bunched together again. I've even seen this with dumb trackers
which use GPS time slots.... everyone picks 0 seconds and 30 seconds after the
minute to TX and they all end up bunched together again anyway. DAMA is a good
solution to solve hidden transmitters, but I don't know of any trackers which
support it.
I suggested a few weeks ago that we have multiple receivers at each digipeater
and one transmitter. then any stations wishing to TX would randomly pick a
frequency from the list that the digipeater was listening to, and if two
transmitted at the same time, it would be unlikely that two would have chosen
the same frequency at the same time. The digipeater of course would collect
all packets and dole them back out onto 144.39 as time permitted.
Wes
----------------------------------------------------------------------
Subject: Re: [ wes@johnston.net ] Re: AX.25 & TCP/IP [was: Another thing I'd
like to see...]
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Mon, 28 Apr 2003 14:06:15 -0500
X-Message-Number: 9
>Well, this would work, except for one thing... who decides who gets which part
>of the SSB bandwidth? You end up with the same problem all over again - many
>stations would choose, say, an easy round number like RF Freq+1khz or +2khz,
>and we'd all be bunched together again. I've even seen this with dumb
trackers
>which use GPS time slots.... everyone picks 0 seconds and 30 seconds after the
>minute to TX and they all end up bunched together again anyway. DAMA is a
good
>solution to solve hidden transmitters, but I don't know of any trackers which
>support it.
Which is why I suggested that statistics be kept and a slot chosen that was
least used....
>I suggested a few weeks ago that we have multiple receivers at each digipeater
>and one transmitter. then any stations wishing to TX would randomly pick a
>frequency from the list that the digipeater was listening to, and if two
>transmitted at the same time, it would be unlikely that two would have chosen
>the same frequency at the same time. The digipeater of course would collect
>all packets and dole them back out onto 144.39 as time permitted.
How is this different than PSK-31 slots with everyone randomly picking a slot?
Seems like the same problem...
Right now, TXD is killing useful bandwidth, along with the ineffective 1200
baud over 12+Khz of bandwidth using FM modulation. Getting rid of the FM
carrier would eliminate some of the TXD related time delays, because others
could transmit in other segments simultaneously.
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: Re: AX.25 & TCP/IP [was: Another thing I'd like to see...]
From: "Wes Johnston" <wes@johnston.net>
Date: Mon, 28 Apr 2003 15:53:09 -0400
X-Message-Number: 10
>How is this different than PSK-31 slots with everyone randomly picking a slot?
>Seems like the same problem...
It is the same problem , you are right. We need a way to randomize the
slots for dumb (ie blind) trackers. SSB channels would be preferable to
wasted FM bandwidth and wasted energy in the carrier.
>Right now, TXD is killing useful bandwidth, along with the ineffective 1200
>baud over 12+Khz of bandwidth using FM modulation. Getting rid of the FM
>carrier would eliminate some of the TXD related time delays, because others
>could transmit in other segments simultaneously.
Absolutely it is.... but I when I suggest 9k6, people scream about needing 8
times the power for same S/N ratio. It would be cool if we used CDMA too.
Everyone would get their own "code", and tx using spread spectrum.
Can you tell me something.... seriously... is there any PSK31 type program
which can instantly "jump" to a place where there's a carrier? I think
digipan scans, and might miss a short packet.
I'm not sure what the solution is...we are working towards the same goal....
But this I can guarantee... Hams are notoriously cheapskates. APRS took off
only because so many TNCs were gathering dust from the failure of packet BBS
days. We (collectively) will have to decide either to A)continue
incremental upgrades, or B) make an entirely new system in which everyone
will have to purchase a newly defined least common denominator of equipment
to play - and build a new network which solves all of the problems we have
evolved into today. Unfortunatly, I know which I'd prefer, and I know that
the other will happen. <grin> Viva Opentrac! (shameless plug)
Wes
----------------------------------------------------------------------
Subject: Re: AX.25 & TCP/IP [was: Another thing I'd like to see...]
From: Miller Scott Contr 30SCS/FTI <Scott.Miller@vandenberg.af.mil>
Date: Mon, 28 Apr 2003 19:57:02 -0000
X-Message-Number: 11
I was thinking about this the other day. I don't know about PSK31, but if
you can devise a modulation scheme that works like spread spectrum to give
you a low bitrate on a shared channel with a known collision rate for a
given number of stations, you can use forward error correction to make sure
that you (almost) always get a packet through as long as the channel loading
is below a certain threshold. APRS doesn't really need a lot of bandwidth,
it just needs to overcome the limitations of FM capture and slow TXDs.
Of course, the obvious problem with using SSB is cost. How many of us have
SSB capable 2M rigs? I paid $50 for the Alinco I'm using for a tracker.
Where are you going to find SSB hardware that cheap?
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Filtering of Internet feed?
From: radio_q@juno.com
Date: Mon, 28 Apr 2003 08:26:47 -0600
X-Message-Number: 12
>At 09:23 PM 4/27/2003, you wrote:
>A local op. was asking me if there is any way to filter down the
>amount of stations received on the internet feed of APRS at the local
>(machine) level?
>
>Was looking for just stations within approx. 100 mile radius of his
>station instead of a worldwide dump of stations?
>
>I was also wondering about this for use at our soon to be active
>EOC/Igate station. Not wanting to hog so much band width from the donated
>cable modem connection.
Although APRS+, and perhaps others, have easy range filters to apply to the
received data as well as a way to only allow your selected stations to be
received via the internet connection, I don't think there is any way to
reduce the bandwidth required on the incoming link, in your case the cable
modem connection. The data has to be processed and then each report
calculated to determine its range from YOUR location which you manually
input. The server doesn't know where you are and thus all data is
forwarded to any connection. Your processor will do any filtering etc to
determine which to keep and which to discard. That is not something done
on the server.
However there are various servers which offer only regional coverage
and that would reduce the incoming bandwidth somewhat. I'm sure
others could tell you what you need to do to select those.
Finally, I have cable here and the additional load from having the
live internet feed seems to make no difference on the things I do
with the rest of my internet connection. Although a nice gesture
and an item to be concerned with if you had a slower connection
you were sharing, I don't think the APRS load will affect any
of the other users.
Jim
----------------------------------------------------------------------
Subject: Re: Filtering of Internet feed?
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Mon, 28 Apr 2003 15:59:06 -0500
X-Message-Number: 13
>Although APRS+, and perhaps others, have easy range filters to apply to the
>received data as well as a way to only allow your selected stations to be
>received via the internet connection, I don't think there is any way to
>reduce the bandwidth required on the incoming link, in your case the
>cable modem connection.
I think it was stated that the java Aprsd implementation has this facility.
Essentially, we need a publish/subscribe server architecture with a well
documented protocol/API so that you could say that you only want positio
information, or weather information or status etc, and from which stations,
distances, times etc... Not a small can of worms to open, but it is a great
benefit to have this level of control...
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
