Order Tray | Contact Us | Home | SIG Lists

[aprssig] aprssig Digest, Vol 53, Issue 25

Tony Komljanec tkomljan at yahoo.co.uk
Fri Nov 28 03:27:58 UTC 2008


My opinion... Until APRS progresses beyond simple ALOHA, it will not be reliable and without *RELIABILITY* it is a "flash in the pan".  I'm all for slotted, Self Organized (like AIS) or other channel access control methods.   In the mean time.....  

What is knocking my enthusiasm out of me are the folks who put 6 fixed WX stations in an area each transmitting once per minute on 144.390, combined with long paths with "Ed at home" every few minutes. Overpowered digi's don't help either as when they transmit, every other igate and digi for 50 miles goes deaf.   QRM is very high with FIXED-FIXED traffic while the MOBILE-FIXED gets squashed.  Reliability for mobile message delivery is poor.  

My area is covered by a couple well placed iGates (and many, many digi's) so even a path of LOCAL or Wide1-1 will get into APRS-IS when the channel is quiet enough.   What can I do within my control (new iGates and digi's) to improve APRS in my area without feeling that all is for naught?  

Can a bi-directional iGate that is NOT a digi help move traffic to or from the internet if that is what people want for their mobiles, WX stations and telemetry.  

When is a digi simply adding to the QRM?  

In my W1 area I hear a lot of traffic that is targeted for APRS-IS being rebroadcasting through high digi's 2 or more hops.  My own underlay (fill-in) iGate contributes message delivery to APRS-IS perhaps 10% of the time (packets which would have otherwise been lost) of what it hears.  The other 90% of the time other wide area (high) iGates successfully hear and move the traffic to APRS-IS before my iGate does (my iGate delivery becomes duplicate an is tossed by IS).  If I turn on my iGate's digipeater functions (W1-1), I'm effectively adding redundant packets to the frequency 90% of the time to the detriment of the channel loading.  In the area, W1 is successful when not being killed by fixed station QRM.  For this reason I've tried turning the digi function off.  

We already have "path correction" to downsize the number of hops.  Perhaps an intelligent iGate or digi could ignore packets passing from user selected iGates or wide coverage digi's assuming that the packed is already successfully in APRS_IS?  A fill-in digi with "polite" channel access dumps packets that are repeated by a wide-area digi?  Since position is usually sent by APRS mobiles, the smart digi or iGate could remain fully engaged with close in mobiles (example: # filter m/15)?  This sort of autonomous decision making could reduce the "polution".  Alas, I'm not a programmer, just a very capable RF guy.  

What can I do within my control to improve APRS in my area without feeling that the effort to improve reliability is futile?  

Tony K
VE3TK

------------------------------
Date: Wed, 26 Nov 2008 21:38:23 -0500 (EST)
From: "Bob Bruninga " <bruninga at usna.edu>

The dumb-tracker-to-internet .... was just a flash in the pan.

We have got to overcome this mentality and get back to APRS as a RECEIVE and local RF distribution system where we PUSH information of immediate value to the MOBILE operator.  Then it becomes something that he remains interested in and wants more.

NOthing wrong with alternate inputs (either 144.99 or UHF) to give locals un-congested INPUT priority, but the output should always be on 144.39 from the high digi (which can hear everything so that it avoides collisios).  In fact such local alternate inputs are receommended, but NOT just to go to an IGate, but to go to RF on 144.39 which is where the intended USER (receiver) is.

Bob, WB4APR



      __________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr! 

http://www.flickr.com/gift/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.tapr.org/pipermail/aprssig/attachments/20081128/39f8e220/attachment.htm 


More information about the aprssig mailing list