[aprssig] ideas for a simple digi

[Chris Kantarjiev]

The T238+ hardware is getting closer to being ready, and I've
been thinking that it would be really nice if such weather stations
could also be digipeaters.

The hardware is fairly nice, but limited in RAM - only 512 bytes total.
There's already a packet buffer for the WX operations. Will tells
me there's lots of room for code. So I've been thinking about how
you could build a stripped down "end-node" digi that makes it possible
to extend the APRS network, and the ability to reach APRS-IS,
without too much bad behaviour.

My basic premise is that the device shouldn't try to do full WIDEn-n,
or make any attempt at delayed RELAY, because there just isn't
enough memory. But it can do something a little clever about
WIDEn-n calls, along the lines of UIDIGI's local pre-emptive digipeat. I
see 3 scenarios. Assume that KG6VYD is the digi, and KD8KZ sends the packet.

1. If KD8KZ sends, and KG6VYD hears

KD8KZ>APRS,RELAY,WIDE2-2

then KG6VYD should send

KD8KZ>APRS,KG6VYD*,WIDE2-2

Straightforward RELAY with callsign sub.

2. If KD8KZ sends, and KG6VYD hears

KD8KZ>APRS,WIDE2-1

then KG6VYD should send

KD8KZ>APRS,KG6VYD*,WIDE2

Straightforward WIDEn-n with callsign sub, but no holding, delaying
or checking for "already heard".

2a. If KD8KZ sends, and KG6VYD eventually hears

KD8KZ>APRS,W6WB*,WIDE2-2

then KG6VYD should send

KD8KZ>APRS,W6WB,KG6VYD*,WIDE2-1

Again, straightforward WIDEn-n with callsign sub.

3. If KD8KZ sends, and KG6YVD eventually hears

KD8KZ>APRS,W6WB*,WIDE2-1

then KG6VYD should/could send

KD8KZ>APRS,W6WB,KG6VYD*

This is the "local preempt"-inspired feature; the idea is that KG6VYD
shouldn't repeat an already digipeated frame such that it will be
digipeated further, but digipeat it such that local users (as in
a remote valley) can hear it.

(This should be optional, I think, since there may be situations where
a small chain of weather stations is set up along a highway on the
way to/from an IGATE, and those machines *do* want to continue!)

That's it. No rules, no list of buffered packets, no complicated options.
I guess that it wouldn't be hard to add a "max path" parameter that
causes packets with more than P hops decremented from a WIDEn-n path
to be dropped.

Comments? Is this functionality sufficient? Harmful? Worthless? 

73 de chris KG6VYD