[aprssig] 9600 APRS net experiment in Central NJ
Wes Johnston, AI4PX
wes at ai4px.com
Sat Feb 26 22:57:48 EST 2011
What ever happened to simply using the 144.99 alt input at 1200 baud? This
way the trackers can still use it. Not too many of our current generation
of trackers do 9600. In practical terms I just can't see the advantage of
9600 with the lengths of packets we use. We take a 35ms of data (1200) and
150ms of txdelay, and if we use 9600, we get an 8ms of data with ... you
guessed it 150ms of txdelay.
The only place I see for 9600 in aprs is in a mic encoder application where
we've already got the rig on the air and simply squirt the packet... plus it
requires no muting for the voice users because it sounds like soft static.
I still haven't figured out how to get 9600 into the mic jack though.
I'm all with you on the lack of qrm on an alt input though.
Up with Jason in Virginia we did do an experiment where we caught 9k6 data
off a voice repeater's rx and cross connected the kiss tnc to a 1200 baud
kiss TNC. I could see doing this the other way around... taking the 1200
baud channel (plus extra 100 miles raduis) from the internet feed and
sending it at 9k6... but it would / should need to stay keyed up lots of the
time to solve the txdelay problem.
"Language shapes the way we think, and determines what we can think about."
-- B. L. Whorf
On Sat, Feb 26, 2011 at 21:29, Wayne Sanderson <whsander at gmail.com> wrote:
> >>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
> >>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
> >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
> >> and also on 144.35. I am using 144.35 at 9600 baud and in my area it
> >> 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.
> >> sure if you could use a D7A(G) or D72A since the external TNC in the
> >> 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
> >> are even doing some fancy computer stuff with a mountain top internet
> >> 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
> >> willing to try it and liked it.....
> >Herb's too modest. :)
> aprssig mailing list
> aprssig at tapr.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the aprssig