[aprssig] 9600 APRS net experiment in Central NJ

[Wayne Sanderson]

>>My only comment is to emphasize the most important aspect of any of these schemes and that is the presence of an ALTERNATE channel for INPUTS that does not have any DIGI OUTPUTS on it.  That improves the *reliability* of any given user by more than an ORDER OF MAGNITUDE.

>>The reason is simple.  Just monitor EVERY packet you see on -your- station.  You will notice that 95 to 98% of EVERY packet you hear is from a DIGI, NOT the direct input packet from a user.  When you transmit on 144.39 from your station, you have a very high collision potential with all this other traffic.

>>Now consider what happens if you transmit to the digi on an INPUT ONLY channel.  Now your packet is not competing with those 95% to 98% of packet QRM from other Digipeaters but only with the 2 to 5% of other uplink packets in the same local area who might collide with your input at that closest digi.  THis is a HUGE benefit.

I absolutely agree. It is the only simple way to clear up the majority
of collisions and initial position transmit failures. Plus, a
dedicated input freq will allow reception at the digi of mobile
packets from much farther afield- 144.39 is almost impossible to
successfully beacon on around here (central NJ) with a 5 watt HT
unless you are right under a digi, and even then the frequent
collisions smash your signal down. An input like the 60 khz repeater
offsets elsewhere in the band would cure this.

>>All of this, of course, is lost if the alternate channel is also used for digipeater OUTPUTS.

You may be right in the long term, but I can speak from experience on
this. My Wife is from Olympia WA. When we fly there for vacations and
to see her family and friends, along goes my D7, which runs red hot
from all the APRS I work when I am there. I have never had so much fun
with my D7 as I have had in the Puget Sound area running 9600 on the
NWAPRS network. I always got good reception, almost no collisions, and
my position packets nearly always made it up to the digi. I personally
think that the combination of the heavy traffic getting out 8x as fast
at 9600 and leaving more dead air time in which to transmit, coupled
with the decreased range and modulation power on the 440mhz band
(which kept the local digi in range of the next without 3-5 others
adding QRM to the environment) allowed the nice high digis there to
gather and pass the heavy traffic, if not seamlessly then certainly
with less effort and strain on the bandwidth.

>>My thoughts for 9600 baud would be to use TWO new channels, one for all the blended 9600 baud OUTPUTS from all 9600 digipeaters AND from everything on 144.39 brought over.  THen still separate the 9600 baud INPUT channel from this output channel by operating with separate TX and RX frequencies.

Some separation is certainly the way to go for the long term. For my
little experiment featuring off the shelf equipment, I may have to run
a conventional one channel setup for now. In the long run, I don't
know how or whether a D700 or 710 can be set up to be a stand alonI
thi digi using this scheme without a computer and/or a second radio on
the site. Maybe a firmware patch for the D710 might make this function
available?

>>SOme would argue that this wont work, because the mobile cannot also listen on the input channel before transmitting to avoid colliisions.  But a little bit of thinking will show that this is virtuallly meaningless.  TYpicallly one cannot hear any other UPLINK signals from any other mobile anyay!  So listening first does not really avoid any collisions either.  And since the uplink-only channel is now virtaually QRM free, there is very little to collide with.

>>Yes, there is some added small 3 to 5% chance of a collision with another uplink, but the improvement gained by elijminating the other 95% to 98% QRM  that would otherwise be on a combined in/out channel is so great as to make this concern vanishingly small.

>>The reason I would not use 9600 baud (if there is an alternative) is the measured 7 dB performance loss as measured on existing radios.

>>Bob, WB4APR

As I said, 9600 worked just fine for me in Lacey WA (Olympia) on the
NWAPRS network whenever I have been there. I think any DB loss would
still measure up favorably to the greater amount of dead air in
between the packets that are 8x shorter due to the increased speed. A
quiet voice from across an empty room may be better than a loud voice
in a crowded noisy room.

Besides, I'm itching to use the increased speed capabilities built
into my radios. I also think that the reason you do not find more
people out there on the road here in NJ running voice alert and
messaging is because the traffic level and overburden of fixed site
beacons and dumb trackers who never message or monitor the channel but
contribute to the congestion here squeeze out those of us who would be
more active if we could just be heard. A 9600 alternate network would
attract users who want to use the participatory features of the APRS
mobile radios and HTs such as messaging and voice alert and tactical
updates, while the tracker crowd would stay where they are because
they need spend no more money or time to continue as they are. A
faster less congested channel would also allow more services and
content to be passed to the mobile users, such as amber alerts and Law
Enforcement warnings- Things you can't get from weather radio.









---- Original message ----
>Date: Sat, 26 Feb 2011 09:00:18 -0800
>From: aprssig-bounces at tapr.org (on behalf of Bill V WA7NWP <wa7nwp at gmail.com>)
>Subject: Re: [aprssig] 9600 APRS net experiment in Central NJ
>To: TAPR APRS Mailing List <aprssig at tapr.org>
>
>Some thoughts from a long time alternate-channel 9600 baud user...
>
>Number 1 and most important - YES!  An alternate channel is the way to
>go.   It makes an incredible difference.   It''s trivial to set up as
>the only requirement is an IGate on the new frequency.  Add a couple
>digipeaters and a back up IGate and you have a really useful LAN.
>
>> Here in the Pacific NW we are experimenting with 9600 baud on both 440.80
>> and also on 144.35.  I am using 144.35 at 9600 baud and in my area it works
>> better for my trackers than the standard 144.39 at 1200 baud.
>
>The "trick" of running 9k6 on a channel near 144.39 is ingenious - for
>locations where transmitters are restricted and controlled.  There is
>still an unknown quantity of lost packets due to desense and
>overlapped transmissions..   This isn't an issue with an alternate
>channel on UHF.    Herb's success even with the desense issues shows
>how well the alternate channel concept works.
>
>For this alternate channel APRS - I'd argue against going to 9600
>baud...   IF your goal is simply a personal LAN and you have the
>radios - that's great.  If you want to open it up to others and take
>some of the load from a busy 144.39 - then go with 1200 baud..  Go
>with 1200 because a) at 9600 none of the proliferation of trackers
>will be be able to leave 144.39 and use the new channel.  b) 1200 is
>fast enough to fill the display on a D7?0 anyway.   The higher speed
>isn't needed.
>
>
>> So this is a fairly simple way to set up a duel 9600 baud and 1200 baud
>> digi.  The only thing is you have to sacrifice a D700 or D710 radio.  Not
>> sure if you could use a D7A(G) or D72A since the external TNC in the above
>> set up is connected through the 6 pin data port on the radio.
>>
>> We have a number of similar mountain top digipeaters set up like this and
>> are even doing some fancy computer stuff with a mountain top internet feeds
>> to a home computer and are blending to two systems so that what one hears it
>> is also transmitted out on RF on the other side.  On our 440.800 network, we
>> also do similar blending between it and the 144.39 system.
>
>I'd say the jury is still out on the value of 'blending'.   The big
>problem with alternate channels is that the mobiles on one channel
>don't see the mobiles on the other.   Blending (digipeating) the
>packets between channels was an attempted solution.  For now we're
>probably generating a marginally unhealthy amount of traffic on the
>main channel from the alternate channels.  Smarter digipeating may be
>the answer but that software technology is currently not available.
>
>> We can send RF APRS messages between all three system.
>
>Note the messaging comes from the IGates - not cross band digipeaters.
>
>> Pretty slick stuff...  No, I am not
>> the one who came up with these ideas but once I saw it in operation, I was
>> willing to try it and liked it.....
>
>Herb's too modest.   :)