<div>This is a smart digipeater system. I hate to say it but it's been hashed out here for years. </div>
<div> </div>
<div>1) I may want my packets to take a specific route from city A to city B. So the solution to this is to limit the range on omni-pathed packets but allow the packets with specific callsign related paths. Fair enough.</div>
<div> </div>
<div>2) It would be impossible for a digi to weed out all dx packets... not all packets contain coordinates. Messaging, Telemetry and WX are types of positionless packets. For example, positionless weather alternates sending a packet with position info and another with wx info. This could be solved by caching a callsign's position though. Caching a position would mean that there would be no use of the network for particular station until he gave his position. The other solution to this is to mandate that all packets contain a position. This adds overhead to a rather bandwidth limited channel.</div>
<div> </div>
<div>3) Imagine that a digiowner decides that he is only going to digipeat things from the east side of a town. The digi on the west side fails and now my packets don't get in because I've crossed some imaginary line and am on the wrong side of it. There needs to be a method that the digipeater would realize that it's neighboring digi is not available and broaden it's range automatically. Come to think of it, imagine Scott Miller's T2 tracker/digi. If he programmed it to look for the callsign of the neighboring digipeater and stay in mode 1 (limited digipeating in this example) as long as it heard the other digipeater every 10 minutes. If the other digi wasn't heard from in 10 minutes (or 20??) it would switch to mode 2 (a much more permissive digipeater mode in this example). It would also be very neat if we could use PL tones to identify the neighboring digipeaters too. In that case, external hardware (such as a timer) would provide a logic signal to switch between modes.</div>
<div><br clear="all">Wes<br><br><br><br></div>
<div class="gmail_quote">On Sat, Sep 19, 2009 at 21:44, Jeff Dugas <span dir="ltr"><<a href="mailto:radarbuzz@delphiforums.com">radarbuzz@delphiforums.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div bgcolor="#ffffff">
<div><font size="2" face="Verdana">It seems to me ...</font></div>
<div><font size="2" face="Verdana"></font> </div>
<div><font size="2" face="Verdana">I've been "playing" with APRS for the last 5-6 years now, and I have some thoughts that I wonder if anyone in the APRS community has considered. </font><font size="2" face="Verdana">After 26+ years experience in the Air Force, working survillenace radar and advanced digital tracking systems, I've thought about some potential new concepts for the future of APRS. If someone somewhere has already thought of this, then please forgive my searching skills.</font></div>
<div><font size="2" face="Verdana"></font> </div>
<div><font size="2" face="Verdana">I propose conceptually that the next generation of APRS digipeater systems ought to include a level of intelligence that takes into consideration exactly where, geographically, the packet originated from, in real time. For instance, an advanced future digipeater could posses a modest internal processing power and memory to be aware of the surrounding geographic environment, and have its local area "mapped" in memory in a simple way whereby, in relation to its own geographic location, it "knows" the location of the transmitting station (from the packet), and also geographically knows the local digipeater network (other digipeaters). Then, theoretically, it would not be difficult to define spatial rules that would determine whether or not a packet is to be digipeated.</font></div>
<div><font size="2" face="Verdana"></font> </div>
<div><font size="2" face="Verdana">This 2-D spatial awareness (and maybe 3-D, for APRS packets from airborne objects?) would allow you to digitally define a geographic circle (or sphere), so to speak, around the digipeater, and precisely define the the radius of the cell in range. This may allow us to make the system more cellular, decreasing network congestion, collisions, and increase overall usability. Heck, rather than a circle, it could be any shape as required by the local environment. You could even designate separate multiple areas, to account for known blind spots that exist in a neighboring digipeater's coverage area. And if these smart digipeaters of tomorrow were linked together on another channel (using the Internet, or another RF link) they could talk with one another and make joint decisions in real time regarding who is going to digipeat what for the best benefit of the local RF community.</font></div>
<div><font size="2" face="Verdana"></font> </div>
<div><font size="2" face="Verdana">With this kind of processing, more of these next-generation digipeaters could be placed on towers, mountain tops, or at other long-distance line-of-sight locations. Although they could hear "everything", they would not digipeate everything like today, but rather use geographic processing/rules to determine what is appropriate to digipeat.</font></div>
<div><font size="2" face="Verdana"></font> </div>
<div><font size="2" face="Verdana">Something like this would complement, not replace, other APRS techniques in practice. And it would not be a cure all. But in could be another powerful tool for our tool box.</font></div>
<div><font size="2" face="Verdana"></font> </div>
<div><font size="2" face="Verdana">Submitted for your consideration.</font></div>
<div><font size="2" face="Verdana"></font> </div>
<div><font size="2" face="Verdana"></font> </div>
<div><font size="2" face="Verdana">Jeff</font></div>
<div><font size="2" face="Verdana">N5TEV</font></div></div><br>_______________________________________________<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>
<br></blockquote></div><br>