[aprssig] -IS to RF Igating reloaded (Was: APRS on Android)

[Stephen H. Smith]

On 1/25/2011 11:37 PM, Max Harper wrote:
> and it looks like the functions of the igate are pretty
> simple. Now what if these functions where moved to the
> servers. Using a Kiss tnc, a small microprocessor and a
> serial to Ethernet converter (terminal server) the
> microprocessor would establish the connection to the
> server and identify the station with a call-sign and
> location and any other options.
>
> A PC running 24/7 that consumes 100 watts costs about
> $10 a month and most PCs draw more than that. I would
> gladly pay $10 dollars a month to the server operator
> to not have to worry with keeping a PC running for an Igate.
> Yes there would be the initial costs of the microprocessor
> and terminal server, but it would be allot cheaper than
> maintaining a PC and I don't think it would increase
> the load on the servers very much.
> P.S. I have been using a terminal server for over a year
> now to drive a remote display for my weather station. It
> handles dropped connections very well. As long as it
> has power it makes the connection, logs on, sends the
> filer command and waits for incoming data from my
> weather station. If it gets disconnected, after a couple of
> minutes it reconnects on it own.
>
>

100 watts or more 24/7?     I have a full APRS software/digipeater/igate 
installation on an Acer ZG5 netbook.   This is an actual PC running Windows XP 
that has a 1024x600 pixel display, WiFi & Ethernet, and 3 USB ports.  It 
consumes 10 watts and costs about $230.  With a  soft TNC (AGWpe or MixW) 
running on the ZG5's sound system, this device goes from RX/TX audio to 
Ethernet in one box.   Combined with a TH-D7 hand-held, it makes an 
instantly-deployable portable igate/digi that weighs under 4 pounds total!

My DC-powered "ham super server" described here:

<http://wa8lmf.net/EPIAserver>

is based on a VIA Computer micro-ITX motherboard and draws only 15 watts to do 
similar functions.



Servers already perform most of the other functions you describe with the port 
14580 filter options.

The issue would still remain of deciding whether or not to reverse-gate an 
Internet-based mobile as it moves from the coverage of one receiver/terminal 
server to another.    How is the centralized server/mullti-igate supposed to 
know what the coverage of a given receiver/terminal  server is?    Are you 
going to have the APRS server run a terrain-based RF-coverage plot on every 
posit sent by an itinerant Internet mobile in order to decide which terminal 
server (if any) should reverse-gate his beacon?