[aprssig] 9600 APRS net experiment in Central NJ

Bob Bruninga bruninga at usna.edu
Sat Feb 26 17:55:49 EST 2011


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.

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

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 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




Bob, WB4APR


---- 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.   :)
>
>> Herb, KB7UVC
>> NW APRS Group, West Sound Coordinator
>> Our WEB Site:  http://www.nwaprs.info
>
>73
>Bill - WA7NWP
>
>_______________________________________________
>aprssig mailing list
>aprssig at tapr.org
>https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig




More information about the aprssig mailing list