<div class="gmail_quote">FYI from the NWAPRS mail list. Digipeaters mentioned below are in the Seattle/Puget Sound area. Dave K7GPS<br><br>


  

<div bgcolor="#ffffff" text="#000000">
All,<br>
<br>
BALDI/VBALDI has had some interesting improvements in the last month or
so.  Scott N7FSP and
I added an additional piece of hardware to his APRS station up on the
hill before the snow
and we now have added IGate functionality for both 144.39/1200 and
144.35/9600.<br>
<br>
The hardware is a Lantronix UDS2100, a commercial-grade dual-port
serial-to-ethernet converter.  It's a small
box about the size of 2 packs of cigarettes.  The device is physically
connected to the serial port of the OT2 TNC on the .39 side and the
serial port on
the D700 TNC for the .35 side.   The Ethernet side of the device is
connected to the Internet through a router at the site.  At my QTH I
have a server that runs the WW7CH IGate/WX station
and is also running a piece of relatively new Linux-based digi/igate
software called <a href="http://wiki.ham.fi/Aprx.en" target="_blank">aprx</a>.  aprx
connects to the APRS-IS, and also connects to the remote TNCs on the
hill via internet tcp stream and operates them in KISS mode (KISS
over IP, or KoIP!).  Prior to running aprx I tried running UI-View and
connecting to the TNC via serial port emulation software, tried
APRSISCE, and aprsd as well.  All three worked, but aprx had the most
functionality for what I wanted it to do and was designed for this kind
of application, including the ability to do all of this with 1 instance
of software running with no memory leakage.  And it's open source!<br>
<br>
The advantage to using a serial-ethernet converter over having a PC at
the site is because the site
is not easily accessible almost 6 months out of the year and the
Lantronix
device is a firmware-based appliance specifically designed for this
type of application that is far less likely to fail than a PC.  The ISP
that provides the network connectivity at Baldi responds VERY fast to
outages there year-round because that is lost revenue to them when it
goes down.  So it's comforting to know there's good reliability there.<br>
<br>
I have been experimenting with this setup for over a month
now (including experimentation with cross-freq messaging and
digipeating) and neither Scott or I have received any complaints about
its
operation.  In fact it has resulted in quite a few more packets being
heard direct making
it into the APRS-IS and increasing the chances of messages/acks being
heard in the field.  Since it can hear many packets first before they
are first digi'd, it results in less packets being lost due to RF
collisions,
which is frequent on .39.  No, it doesn't solve the congestion issue,
but it does help to allow for the packets that would have otherwise
been lost to get into the system.<br>
<br>
One feature of aprx is the ability to send telemetry to the APRS-IS to
show erlang and RF packet count statistics:<br>
BALDI (1200 side) - <a href="http://aprs.fi/telemetry/a/BALDI" target="_blank">http://aprs.fi/telemetry/a/BALDI</a><br>
VBALDI (9600 side) - <a href="http://aprs.fi/telemetry/a/VBALDI" target="_blank">http://aprs.fi/telemetry/a/VBALDI</a><br>
<br>
The amount of packets sent/rcvd to/from the APRS-IS is shown on Tom
KD7LXL's server statistics page (connected as BALDIMTN):<br>
<a href="http://northwest.aprs2.net:14501/" target="_blank">http://northwest.aprs2.net:14501/</a><br>
<br>
This station and setup does not replace any existing
igates/digipeaters nor make any others obsolete - that's not the
intent.  Like any other station, it is always subject to outages due to
internet connectivity loss, power loss at either end, etc. and will
occasionally miss packets here and there due to collisions, etc.  The
intent is to enhance APRS coverage/capabilities
in the area by taking advantage of having internet access on the
mountaintop and Scott, me, and others are noticing that it is working
successfully. <br>
<br>
Casey WW7CH<br>
<br>
</div>

</div><br>