At 11:03 AM 7/8/99 EDT, [EMAIL PROTECTED] wrote:
>
>
>On the contrary.... You do not need a computer to run a TCPIP router or APRS
>digi... It can all easily be done in a TNC-2 compatible TNC running TheNet
>X1JR4 firmware. APRS functions simply by use of the antiquated "dumb
>digipeat" mode... which if switched on in any Netrom or TheNet or BPQ node,
>etc, works just fine.
This isn't completely correct. The newest WIDEx-x digipeater capability
(used extensively here in the Northwest) requires more intellegence than
that programmed into a standard TNC-2 clone - or that I expect is in TheNet
- unless it has been added in the last 14 months or so.
WIDEx-x works in part by the relaying station decrementing the SSID of the
digipeater field before transmitting the packet - but not marking that
field as "digipeated". The next WIDEx-x dipeater sees that the packet is
still able to be digipeated, and handles as above. When the SSID is
counted down to zero, the last WIDEx-x digipeater handling it also sets the
"digipeated" flag bit.
Another part of the intellegence added by Kantronics (and perhaps others?)
is to keep a recent table of frames sent, and if the packet data that it
recently sent is heard on the air again, the TNC ignores it and won't
digipeat it again. So each WIDEx-x handles each broadcast data frame just
once.
A third part of the equation is performing callsign substitution. This is
done by replacing the first digipeated call field with the call of the
current digipeater. If there is no digipeater field ahead of the WIDEx-x,
then one is inserted. This has the beauty of performing legal ID of the
digipeater without needing ID beacons, etc. and allows those monitoring the
channel in real time to see what digipeaters can be heard, and which ones
handled the packet.
There are other additions (and more being discussed) to enhance the
facility of the APRS flooding concept while reducing channel loading.
These include (but are not limited to):
- GPS data frame translation to MIC-E (or similar) format - reduces length
of tracker postion packets to about 25% of original, for all digipeated
tracker packets
- TRACE mode, where each digipeater that handles a TRACE frame inserts its
call between the TRACE digipeat field and any that precede it. Used for
evaluating paths to/from an area or station.
- "Fill-Digi" concept - to provide coverage in an area where the main
network WIDEx-x digipeaters can not be easily received - such as with a
handy-talky in a building, etc. The Fill-digipeater will probably digipeat
all heard packets, but will mark all digipeat address fields as digipeated.
This is (to my knowledge) not yet implemented anywhere, but would be
easiest to develop, test, and tune with computer-based software instead of
TNC-based firmware. I'm sure that ultimately its most useful
implementation will be in a TNC, typically in the car of a handheld user.
However to 'get it right the first time' in firmware would be easier if the
concept is fully tested and documented before comitting code to firmware.
Also, for standalone PC applications, TAPR (and possibly others?) have
created a PCMCIA to IDE interface, and with proper PCMCIA-based flash ram
products, it's pretty easy to create a bootable Linux system with no
physical moving parts, except the power supply fan. With IP over AX.25,
it's possible to almost completely maintain the machine remotely - except
the hardware, of course!
73, Bob
-----------------------------------------------------------------------
Bob Donnell, KD7NM [EMAIL PROTECTED] [EMAIL PROTECTED]
Western Washington Amateur IP Address Coordinator (425) 775-3651
--------------------- http://wetnet.wa.com/~kd7nm ---------------------
