[aprssig] New n-N success in North Carolina

[Jason Winningham]

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 
> be
> what is needed to push us over these hurdles.  By trying to "fit" to 
> the
> current KPC3 firmware, it sometimes seems like the square peg in the 
> round
> hole.  Is the root of this problem really lack of flexibility of the 
> current
> hardware?

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 
was allowed.

if requested hop_count > max_allowed_hops
	hop_count = max_allowed_hops
hop_count--
if hop_count > 0
	transmit packet

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 
density areas.

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.

-Jason
kg4wsv