| |
ZL3AI > APRDIG 18.04.03 10:04l 254 Lines 10198 Bytes #999 (0) @ WW
BID : 1171-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 15, 2/4
Path: DB0FHN<DB0RGB<OK0PPL<RZ6HXA<SP7MGD<VK7AX<ZL2BAU<ZL3VML
Sent: 030417/1033Z @:ZL3VML.#80.NZL.OC #:64063 [Chch-NZ] FBB7.00i $:1171-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: aprs events calendar
From: Phil Reed <preed@dnaco.net>
Date: Tue, 15 Apr 2003 12:27:16 -0400
X-Message-Number: 7
How about http://makeashorterlink.com/?K3D423834 ??
---
...phil / w8sca
"For a list of all the ways technology has failed
to improve the quality of life, press 3."
----------------------------------------------------------------------
Subject: 802.11 APs
From: Miller Scott Contr 30SCS/FTI <Scott.Miller@vandenberg.af.mil>
Date: Tue, 15 Apr 2003 16:35:29 -0000
X-Message-Number: 8
I'm trying to identify exactly what information you might want to advertise
about an 802.11 access point. Here's what I've got so far:
Standard - 802.11b/g/a
SSID - 32 character Server Set ID
Channel - 14 for b and g, 12 for a
Status - Open / Closed / WEP (or would we assume they're all open for ham
purposes?)
Range - estimate in meters
Anything I'm missing?
Scott
N1VG
----------------------------------------------------------------------
Subject: reducing hidden transmitter problems
From: wes@johnston.net
Date: Tue, 15 Apr 2003 13:46:58 -0400 (EDT)
X-Message-Number: 9
I know this has been brought up before, but here's an idea that will
statistically reduce collisions from mobile stations (the worst offenders
in terms of HTS). What if we had digipeaters which listened on several
frequencies, but only talked on 144.39? You run a chance with a mobile
tracker keying up at the same time as another tracker. But how much would
that chance be reduced by if you and the other tracker could randomly pick
5 frequencies. Now you are talking about a 5 (or more - I never took stat's
in school) reduction in the chance of a collision. And think about all the
distant stations your local digipeater is hearing that you can't in you
mobile and are clobbering?
The idea is to use multiple receivers at the digipeater site. With the
advent of sound card modems, and sound cards costing $10 each, two sound
cards can provide 4 TNCs. Hook up your APRS radio on 144.39 to a real TNC
via serial port. Hook up a receiver to sound card 1's left channel. Hook
up another receiver (perhaps your local voice repeater) to the right
channel of sound card 1 to provide MIC-e services. Sound card two will be
hooked to two other receivers, on, let's say 145.09 and 145.71 (frequency
doesn't matter at this point). Now you have a PC with 5 receivers and 5
TNCs and one transmitter.
For the sake of this example, let's pick some frequencies.
At the digipeater site you will need:
1) a transceiver on 144.39 simplex
2) a receiver on 145.825
3) a receiver on 145.09
4) a receiver on 145.71
5) a receiver on 444.150 (my local repeater)
A mobile user would wire the PTT and MIC UP buttons on his radio together
when hooking up an external TNC. This would cause the radio to change
memory slots each time it transmitted. Let's say that you have 10 memory
slots in your radio. You program slots 1 to 10 with odd splits... that is
145.825tx/144.39rx, 145.09tx/144.39rx, 145.71rx,144.39rx . If you see
where I'm going with this, you're doing well....
A mobile user would program the first 10 (or more) memories in his radio
with the above frequencies in ODD SPLITS.
memory 1) 144.39 simplex
memory 2) 145.825 / 144.39
memory 3) 145.09 / 144.39
memory 4) 145.71 / 144.39
memory 5) 144.39 / 144.39
memory 6) 145.825 / 144.39
memory 7) 145.09 / 144.39
memory 8) 145.71 / 144.39
memory 9) 144.39 / 144.39
memory 10) 144.825 / 144.39
Now, if everyone programmed their radios with the channels listed in the
chart above in the same order, we'd have just as many collisions. To solve
this, I borrowed a page from spread spectrum. Now while many users will
choose the simple channel sequence listed above, I might choose to
alternate or reverse the order. And you could choose your own sequence as
well. Shuffle the order of the channels around so they are not the same as
the other users in your area.
The really slick part about this is that it is compatible with our existing
digpeaters. 100mhz pentuims are really cheap these days, so adding a pc to
your digipeater shouldn't be hard or expensive. The only thing left is to
select a list of channels. I imagine in most areas there are lots of empty
frequencies in the packet subbands. You could put a reciever on each
frequency from 144.91 to 145.09 if you wanted. These frequencies do not
have to be nationally coordinated b/c only the locals need to know them.
Travellers in your area would still use 144.39 simplex. All the local
mobiles would try not to ever include 144.39 in their TX list. If this was
adhered to, the only stations transmitting on 144.39 would be
out-of-towners, fixed stations, and digipeaters. A digipeater with a spare
LT buffer could transmit an aprs message with the list of alternate input
frequencies.
Please note that 144.39 can still only hold so much "stuff". This is not a
way to increase capacity by allowing more data to get funneled into 144.39.
This is a way to encourage "alligator" stations to reduce their TX rate b/c
they indeed have a better chance of getting heard by a digi and not
clobbered.
Thoughts?
Wes
----------------------------------------------------------------------
Subject: Re:reducing hidden transmitter problems
From: n8uev@juno.com
Date: Tue, 15 Apr 2003 19:42:48 GMT
X-Message-Number: 10
Hello list readers:
After reading Wes's message about hidden transmitter problems I had an
idea. I was wondering if it would be possible to solve this problem by
using recycled land mobile trunking radios??
Leroy Heck
N8UEV
----------------------------------------------------------------------
Subject: Cool APRS idea
From: Andrew Rich <andrew.rich@telstra.com>
Date: Wed, 16 Apr 2003 06:36:25 +1000
X-Message-Number: 11
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 mean we have all these full time drive surveys going on. Called APRS
Anybody wanna have a go ?
eg plot on a map, all stations heard vi vk4gme-3 (or local digi)
The telco i drive for does maps all the time - drive surveys.
Andrew VK4TEC
----------------------------------------------------------------------
Subject: Re: Cool APRS idea
From: "James Jefferson" <jj@aprsworld.net>
Date: Tue, 15 Apr 2003 15:47:04 -0500 (CDT)
X-Message-Number: 12
Andrew, I've done maps like this. The problem becomes how to display the
data in a meaningful way and get rid of anamolies.
What ends up happening on APRS (and probably not so much with cell phones)
is that the propogation opens up and a digi will start digipeating packets
from hundreds of miles away. For example, the N0QK-1 digi is about 30 feet
above surrounding terain in Minnesota (middle of USA). It has digipeated
packets from as far away as Texas and New York.
Now, if somebody could come up with an algorithm for making the data and
maps readable, I'd be all ears.
-Jim KB0THN
----------------------------------------------------------------------
Subject: Re: Cool APRS idea
From: wes@johnston.net
Date: Tue, 15 Apr 2003 16:51:04 -0400 (EDT)
X-Message-Number: 13
I haven't done this with regard to a specific digipeater, but I have done it
for general coverage in my area. I just pulled up a bread crumb trail of my
local area with my car to see my drive time route. Suprisingly, there are no
dead spots... if I don't get into a digi it's because of hidden transmitter
problems - hence the posting I just made a couple of hours ago <grin>.
Wes
ham callsign: kd4rdb
find me: http://wesvan.zapto.org
----------------------------------------------------------------------
Subject: Re: reducing hidden transmitter problems
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 15 Apr 2003 18:04:33 -0400 (EDT)
X-Message-Number: 14
This is kind of backwards from the way I have proposed it.
On Tue, 15 Apr 2003 wes@johnston.net wrote:
>I know this has been brought up before, but here's an idea that will
>statistically reduce collisions from mobile stations (the worst offenders in
>terms of HTS). What if we had digipeaters which listened on several
>frequencies, but only talked on 144.39? You run a chance with a mobile tracker
>keying up at the same time as another tracker. But how much would that chance
>be reduced by if you and the other tracker could randomly pick 5 frequencies.
>Now you are talking about a 5 (or more - I never took stat's in school)
>reduction in the chance of a collision. And think about all the distant
>stations your local digipeater is hearing that you can't in you mobile and are
>clobbering?
Your idea is 144.39 is an output channel. Mine is 144.39 as the input
channel so that it is backwards compatible to any mobile that wanders
in...
>The idea is to use multiple receivers at the digipeater site. With the advent
>of sound card modems, and sound cards costing $10 each, two sound cards can
>provide 4 TNCs. Hook up your APRS radio on 144.39 to a real TNC via serial
>port. Hook up a receiver to sound card 1's left channel. Hook up another
>receiver (perhaps your local voice repeater) to the right channel of sound card
>1to provide MIC-e services. Sound card two will be hooked to two other
>receivers, on, let's say 145.09 and 145.71 (frequency doesn't matter at this
>point). Now you have a PC with 5 receivers and 5 TNCs and one transmitter.
Similar to my backbone concept but the 5 receivers are listening to the
UHF outputs of the other surrounding DIGIS and backbones and one receiver
still listens on 144.39 for all locals. Also, my plan is cross band so
that the throughput at all nodes is more than double what it is normally.
Your idea is worth considering, but I dont have time to think it all out
right now. But it is the inverse of what I was proposing. My plan is
linked on my FIX 144.39 page about half way down...
http://web.usna.navy.mil/~bruninga/aprs/fix14439.html
Bob
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
