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. <br>
<br>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.<br>
<br>I'm all with you on the lack of qrm on an alt input though.<br><br>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.<br clear="all">
Wes
<div>---</div>
<div>"Language shapes the way we think, and determines what we can think about." -- B. L. Whorf</div><br>
<br><br><div class="gmail_quote">On Sat, Feb 26, 2011 at 21:29, Wayne Sanderson <span dir="ltr"><<a href="mailto:whsander@gmail.com">whsander@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">>>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.<br>
<br>
>>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.<br>
<br>
>>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.<br>
<br>
</div>I absolutely agree. It is the only simple way to clear up the majority<br>
of collisions and initial position transmit failures. Plus, a<br>
dedicated input freq will allow reception at the digi of mobile<br>
packets from much farther afield- 144.39 is almost impossible to<br>
successfully beacon on around here (central NJ) with a 5 watt HT<br>
unless you are right under a digi, and even then the frequent<br>
collisions smash your signal down. An input like the 60 khz repeater<br>
offsets elsewhere in the band would cure this.<br>
<div class="im"><br>
>>All of this, of course, is lost if the alternate channel is also used for digipeater OUTPUTS.<br>
<br>
</div>You may be right in the long term, but I can speak from experience on<br>
this. My Wife is from Olympia WA. When we fly there for vacations and<br>
to see her family and friends, along goes my D7, which runs red hot<br>
from all the APRS I work when I am there. I have never had so much fun<br>
with my D7 as I have had in the Puget Sound area running 9600 on the<br>
NWAPRS network. I always got good reception, almost no collisions, and<br>
my position packets nearly always made it up to the digi. I personally<br>
think that the combination of the heavy traffic getting out 8x as fast<br>
at 9600 and leaving more dead air time in which to transmit, coupled<br>
with the decreased range and modulation power on the 440mhz band<br>
(which kept the local digi in range of the next without 3-5 others<br>
adding QRM to the environment) allowed the nice high digis there to<br>
gather and pass the heavy traffic, if not seamlessly then certainly<br>
with less effort and strain on the bandwidth.<br>
<div class="im"><br>
>>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.<br>
<br>
</div>Some separation is certainly the way to go for the long term. For my<br>
little experiment featuring off the shelf equipment, I may have to run<br>
a conventional one channel setup for now. In the long run, I don't<br>
know how or whether a D700 or 710 can be set up to be a stand alonI<br>
thi digi using this scheme without a computer and/or a second radio on<br>
the site. Maybe a firmware patch for the D710 might make this function<br>
available?<br>
<div class="im"><br>
>>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.<br>
<br>
>>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.<br>
<br>
>>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.<br>
<br>
</div>>>Bob, WB4APR<br>
<br>
As I said, 9600 worked just fine for me in Lacey WA (Olympia) on the<br>
NWAPRS network whenever I have been there. I think any DB loss would<br>
still measure up favorably to the greater amount of dead air in<br>
between the packets that are 8x shorter due to the increased speed. A<br>
quiet voice from across an empty room may be better than a loud voice<br>
in a crowded noisy room.<br>
<br>
Besides, I'm itching to use the increased speed capabilities built<br>
into my radios. I also think that the reason you do not find more<br>
people out there on the road here in NJ running voice alert and<br>
messaging is because the traffic level and overburden of fixed site<br>
beacons and dumb trackers who never message or monitor the channel but<br>
contribute to the congestion here squeeze out those of us who would be<br>
more active if we could just be heard. A 9600 alternate network would<br>
attract users who want to use the participatory features of the APRS<br>
mobile radios and HTs such as messaging and voice alert and tactical<br>
updates, while the tracker crowd would stay where they are because<br>
they need spend no more money or time to continue as they are. A<br>
faster less congested channel would also allow more services and<br>
content to be passed to the mobile users, such as amber alerts and Law<br>
Enforcement warnings- Things you can't get from weather radio.<br>
<div class="im"><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
---- Original message ----<br>
>Date: Sat, 26 Feb 2011 09:00:18 -0800<br>
</div><div class="im">>From: aprssig-bounces at <a href="http://tapr.org" target="_blank">tapr.org</a> (on behalf of Bill V WA7NWP <wa7nwp at <a href="http://gmail.com" target="_blank">gmail.com</a>>)<br>
>Subject: Re: [aprssig] 9600 APRS net experiment in Central NJ<br>
</div><div><div></div><div class="h5">>To: TAPR APRS Mailing List <aprssig at <a href="http://tapr.org" target="_blank">tapr.org</a>><br>
><br>
>Some thoughts from a long time alternate-channel 9600 baud user...<br>
><br>
>Number 1 and most important - YES! An alternate channel is the way to<br>
>go. It makes an incredible difference. It''s trivial to set up as<br>
>the only requirement is an IGate on the new frequency. Add a couple<br>
>digipeaters and a back up IGate and you have a really useful LAN.<br>
><br>
>> Here in the Pacific NW we are experimenting with 9600 baud on both 440.80<br>
>> and also on 144.35. I am using 144.35 at 9600 baud and in my area it works<br>
>> better for my trackers than the standard 144.39 at 1200 baud.<br>
><br>
>The "trick" of running 9k6 on a channel near 144.39 is ingenious - for<br>
>locations where transmitters are restricted and controlled. There is<br>
>still an unknown quantity of lost packets due to desense and<br>
>overlapped transmissions.. This isn't an issue with an alternate<br>
>channel on UHF. Herb's success even with the desense issues shows<br>
>how well the alternate channel concept works.<br>
><br>
>For this alternate channel APRS - I'd argue against going to 9600<br>
>baud... IF your goal is simply a personal LAN and you have the<br>
>radios - that's great. If you want to open it up to others and take<br>
>some of the load from a busy 144.39 - then go with 1200 baud.. Go<br>
>with 1200 because a) at 9600 none of the proliferation of trackers<br>
>will be be able to leave 144.39 and use the new channel. b) 1200 is<br>
>fast enough to fill the display on a D7?0 anyway. The higher speed<br>
>isn't needed.<br>
><br>
><br>
>> So this is a fairly simple way to set up a duel 9600 baud and 1200 baud<br>
>> digi. The only thing is you have to sacrifice a D700 or D710 radio. Not<br>
>> sure if you could use a D7A(G) or D72A since the external TNC in the above<br>
>> set up is connected through the 6 pin data port on the radio.<br>
>><br>
>> We have a number of similar mountain top digipeaters set up like this and<br>
>> are even doing some fancy computer stuff with a mountain top internet feeds<br>
>> to a home computer and are blending to two systems so that what one hears it<br>
>> is also transmitted out on RF on the other side. On our 440.800 network, we<br>
>> also do similar blending between it and the 144.39 system.<br>
><br>
>I'd say the jury is still out on the value of 'blending'. The big<br>
>problem with alternate channels is that the mobiles on one channel<br>
>don't see the mobiles on the other. Blending (digipeating) the<br>
>packets between channels was an attempted solution. For now we're<br>
>probably generating a marginally unhealthy amount of traffic on the<br>
>main channel from the alternate channels. Smarter digipeating may be<br>
>the answer but that software technology is currently not available.<br>
><br>
>> We can send RF APRS messages between all three system.<br>
><br>
>Note the messaging comes from the IGates - not cross band digipeaters.<br>
><br>
>> Pretty slick stuff... No, I am not<br>
>> the one who came up with these ideas but once I saw it in operation, I was<br>
>> willing to try it and liked it.....<br>
><br>
>Herb's too modest. :)<br>
<br>
</div></div><div><div></div><div class="h5">_______________________________________________<br>
aprssig mailing list<br>
<a href="mailto:aprssig@tapr.org">aprssig@tapr.org</a><br>
<a href="https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig" target="_blank">https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig</a><br>
</div></div></blockquote></div><br>