[aprssig] New n-N success in North Carolina
jdw at eng.uah.edu
Sat Feb 12 09:02:32 CST 2005
On Feb 11, 2005, at 11:13 PM, A.J. Farmer ((AJ3U)) wrote:
> Something like this idea of a kiss mode controller on a PIC chip might
> what is needed to push us over these hurdles. By trying to "fit" to
> current KPC3 firmware, it sometimes seems like the square peg in the
> hole. Is the root of this problem really lack of flexibility of the
The root of the problem is twofold: one is the simplicity of the
current hardware. The biggest is configuration being in the wrong
place in the APRS network. Correct operation of the entire network
depends on every cient being properly configured, and the definition of
"properly configured" changes both with geographical location and with
the "fix .39" plan de-jour.
If you really want to fix 144.39 and not just patch it, make routers
out of digipeaters and get all but the most basic configuration _out_
of the hands of the clients. For software based digis (digi_ned, etc)
this shouldn't be too much trouble. For TNC based digis the
microcontroller on a serial port is the solution. I agree that such a
device would be pretty cheap and easy to attach to existing TNCs. It
would also allow one to use a $50 TNC-X instead of a $190 KPC3+. One
might even be able to shoehorn the code onto the PIC and do it
_entirely_ with a TNC-X.
I think the basic problem right now isn't hardware as much as it is
mindset. Everyone is thinking in terms of source-routed paths and N-N
modifications to same. What we _need_ is a fundamental shift in
thinking away from source routed dat link layer solutions and toward a
real layer 3 network solution.
An APRS client should specify a requested hop count. The
infrastructure should handle that request as local conditions allow.
Existing clients (like Earl's PROM that can't change) could be handled
at layer 3 with some backwards compatibility code, but the new default
path for a layer 3 network would be just a hopcount - a single digit
(how's that for shortening the length of the packet?).
In either case the _router_ would determine how many hops the packet
if requested hop_count > max_allowed_hops
hop_count = max_allowed_hops
if hop_count > 0
So, if someone lives in an area where a 5 hop path is OK, (layer 2
"RELAY,WIDE4-4" or layer 3 hopcount "5") then the packet goes 5 hops.
If this station is, say, a mobile who drives through a big city while
traveling, the routers in the high density areas simply decrease the
hopcount remaining in the packet to the number of hops supported by the
local network, so that the traveler's packet goes 2 or 3 hops in higher
What will all this take? A small but fundamental shift in thinking (up
one layer in the OSI reference model), a little planning, and that
microcontroller that's been mentioned.
More information about the aprssig