With an appropriate APRS QSY object to show the availability for the functionality.<br><br><div class="gmail_quote">On Mon, Jan 30, 2012 at 7:38 PM, Bob Bruninga <span dir="ltr"><<a href="mailto:bruninga@usna.edu">bruninga@usna.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Great!... With the proviso, that it should target 145.01 or other locally<br>
available packet channel and NOT 144.39.  Maybe 145.55 is an alternative if<br>
a DX cluster is already there somewhere...<br>
<br>
Bob, Wb4APR<br>
<div class="im HOEnZb"><br>
-----Original Message-----<br>
From: <a href="mailto:aprssig-bounces@tapr.org">aprssig-bounces@tapr.org</a> [mailto:<a href="mailto:aprssig-bounces@tapr.org">aprssig-bounces@tapr.org</a>] On Behalf<br>
Of Steve Dimse<br>
Sent: Monday, January 30, 2012 8:06 AM<br>
To: TAPR APRS Mailing List<br>
Subject: Re: [aprssig] RK3KKPK? (CONNECTED Igates?)<br>
<br>
<br>
</div><div class="HOEnZb"><div class="h5">On (the last few days), (various people) wrote (things like):<br>
<br>
> And, of course, two sets of routing tables, two sets of addresses, two<br>
> sets of address resolution/mapping protocols and so on.<br>
><br>
It is easy to fall into a tendency to over-engineer things. People sometimes<br>
talk about redoing the APRS IS for a variety of reasons, but if it were<br>
complex it never would have gained traction (just as their proposals to<br>
re-engineer never gain traction). I was actually guilty of this, I had a<br>
rather complex plan when the idea for the APRS IS formed, but I am eternally<br>
indebted to Keith WU2Z, who convinced me if the importance of simplicity if<br>
I wanted it to catch on.<br>
<br>
Here is a relatively simple way to do what Bob proposes, call the concept<br>
CGate, for Connected Gateway.<br>
<br>
The CGate listens on RF, when it hears the RF beacon of a local station it<br>
sends a packet to the internet backbone with the RF station's call and the<br>
CGate's IP number or DNS name. The packet could be either a new APRS packet<br>
type, a user-defined packet type, or even just a position report with a<br>
comment like "CGate via <a href="http://cgate.k4hg.net" target="_blank">cgate.k4hg.net</a>" or "CGate via 64.76.23.1"on a<br>
regular position packet. The internet backbone could be the APRS IS itself<br>
or a stand-alone net using javAPRSSrv and/or aprsd.<br>
<br>
The CGate listens on the internet and builds its own flat database of all<br>
the beacons and the CGate that heard them. Call this a routing table if you<br>
want, but this is quite simple and reasonably scaleable, even low-end<br>
computers could handle tables with half a million lines easily.<br>
<br>
To initiate a connect I would type into the tnc "C WB4APR VIA CGATE". A<br>
local CGate could hear the connection request, look in its table for WB4APR,<br>
if it finds an entry it connects to the CGate that heard WB4APR, and that<br>
CGate sends out a connect request that prints like "K4HG>WB4APR,CGATE*".<br>
>From this point the packets are sent end-to-end via the TCP connection<br>
between the CGates, the only translation needed to flag the CGATE digi as<br>
used (CGATE*). The TCP connection would probably use the KISS protocol as<br>
the data format for simplicity, this would require KISS TNCs on each end to<br>
be able to send out packets with the callsign of the person on the other end<br>
of the connection.<br>
<br>
A problem would be multiple CGates in range of a single RF originating<br>
station. In that case the operator would need to use the call of one of the<br>
CGates in place of the generic CGATE via. The other end is not a problem<br>
because the originator's CGate would only connect to a single CGate at the<br>
destination, though you may want to add in some sort of quality test in the<br>
routing table so the better of two CGates is the one in the table.<br>
<br>
Personally, I am not convinced this is worth the effort, I doubt it would<br>
attract many users, but if someone wanted to try this is the way I would<br>
recommend they do it. You only need write one piece of software (the CGate),<br>
the configuration is automatic, it uses existing infrastructure (at least<br>
during testing) and the RF users need know nothing about the internet<br>
network, it just looks like a digi.<br>
<br>
Steve K4HG<br>
<br>
<br>
<br>
<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>
<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>
</div></div></blockquote></div><br>