Igate's are the interface between RF and the internet. If configured properly, they allow APRS packets to be pushed to central servers and accordingly made available to various services. Igates can be any number of WinAPRS, MacAPRS, UIview, or aprsd for Linux type setups. Igates need to have a TNC, appropriate software, a computer capable of running the software, and a fulltime internet connection of some sort. Nashvilleaprs.net defines an Igate as any system that is capable of putting RF APRS traffic onto the internet on a full time basis. The Igate need only to hear at least one digi in order to be truly effective, however it's possible to run an Igate that in fact does not hear any digi's.

Nashvilleaprs.net was formed with several goals in mind.

• The goal of Nashvilleaprs.net's setup is to provide multiple Igates with the potential for overlapping coverage in a given area. By providing redundant coverage, those people that utilize internet based APRS services are assured that information from a given area makes it to the central servers and services.

• We realize that where there is often a lot of internet bandwidth, there may not be a suitable location for a full Igate setup. And likewise, those that do have some bandwidth with a fulltime connection, in addition to having the ability to run a full Igate, are often on a pipe that is truly not ideal in relation to the volume of traffic on the national APRS network (ie, Teir 1 or Teir 2 servers). As a result, Nashvilleaprs.net suggests that the minimum upstream needed to run an Igate in the Nashvilleaprs.net system is a single channel ISDN (64k) type connection. Thus, cablemodems, DSL, and T-1 type connections generally provide more than enough bandwidth to feed upstream servers in the Nashvilleaprs.net system.

• In order to keep from decimating those connections that can support Igate arrangements and to assist in keeping to a minimum the number of connections to the national aprs feeds, all Igates in the Nashville / Mid TN area are suggested to connect to the "regional" Nashvilleaprs.net servers. Those "regional" servers are known as first.nashvilleaprs.net, second.nashvilleaprs.net, and third.nashvilleaprs.net.

  Note: currently second.nashvilleaprs.net, and third.nashvilleaprs.net are off line. We are looking for suitable locations with large bandwidth availability to host these servers.

• The goal of the regional servers (ie, first, second, and third.nashvilleaprs.net) is for the servers to be centrally located on geographically and topicalogially disperate locations and networks. Those servers, while each residing on networks with unique upstream providers, all reside on full T-1 or better networks. In addition, servers reside in different locations to ensure that power or other types of damage or destruction do not knock all systems offline at once.

• Servers tie into the Teir 1 or Teir 2 servers network and provide data collected from the Nashville region in one centralized and controlled connection. However, only one Nashvilleaprs.net server is connected to the Teir 1 or Teir 2 server network at one time. Those nashvilleaprs.net servers that are not talking to Teir 1 or Teir 2 servers are talking to each other and to the one nashvilleaprs.net server that does talk to Teir 1 or Teir 2 servers.

• Igates should be configured to talk to one of the servers, however, if possible they should be setup to roll over accordingly whenever the server they are talking to fails (ie, HUB in aprsd). For those people using aprsd under linux, and in particular the RIMiGate software, we suggest turning on the priority hub feature. Aprsd will connect to first.nashvilleaprs.net and roll over to second.nashvilleaprs.net if "first" fails. However, as a result of the priority hub feature, aprsd will attempt to connect back up to "first" after a set amount of time. Should "second" be offline then aprsd will roll over to "third", and will eventually attempt to connect back to "second", and then back to "first". It is the goal to put first.nashvilleaprs.net onto the biggest/fastest internet connection available and allow second and third to reside on connections that are well situated and have relatively reasonable speed (again, T-1 or better).

• As a result of these individual Igates feeding into the regional servers, it's possible to connect to the regional servers and get more or less a Nashville / Mid-TN feed. We suggest connecting to port 1313 of any of the servers, but first.nashvilleaprs.net is the preferred connection point for that regional feed.

• We do not require coordination to connect to the Nashvilleaprs.net servers. However, if you would like to run an Igate that ties into Nashvilleaprs.net we do ask that you contact Sean, Terry, or Bruce ahead of time. The main thing is to make sure that your password is generated properly. Those Igates that connect without a proper password in effect have their Igate packets dropped on the ground.

• We've run this system for over a year now and it appears to work quite well. While there is still work to be done, Nashvilleaprs.net feels like it has accomplished the initial goals it set.

Here's some additional information to bear in mind when running an Igate in the Nashville / Mid-TN area.

If you are running a fixed station you should not have WIDE1-1 in your unproto path. And a WIDE2-2 should be more than enough for local tactical communications that APRS was designed for. WIDE2-1 should be enough to make it to an Igate and get into the APRS-IS system.

For those that may not be reading the APRS list from TAPR there are a few new requests. Folks running dedicated Igates should use the gateway symbol with the "I" overlay. To do this you would have the character I substituted for the / character between the latitude and longitude. This gives you the I overlay. The gateway symbol "&" is placed after the longitude where WIDE digis have a "#". For example here is how it looks on my Igate:

        NetBeacon 10 !3603.00NI08716.60W& aprsd Linux APRS Server
or
        TncBeacon 10 !3603.00NI08716.60W& aprsd Linux APRS Server
or
        btext !3603.00NI08716.60W& aprsd Linux APRS Server

Also, anyone using Sean's RIMigate software needs to make a change in their INIT.TNC file and put a ! character in front of the latitude.

While, people are free to do as they wish, I would like to suggest that if you are running an Igate then it should only have an alias of WIDE1-1.

There is a need for Fill-in Digi stations. Most fixed home stations in the area can hit one or more of the NT4UX-x or W1ARN-1 digis directly. If so it probably doesn't need to be a WIde Area Digi but would be very helpful to mobiles as a Fill-in Digi.

Suggested configuration information for an Igate in the Nashville / Mid-TN region:

ALIAS	WIDE1-1
UNPROTO WIDE2-1

Note, per suggestions above, the Igate at most should be WIDE2-1 or WIDE2-2. However, given that the igate is connected to the internet it stands to reason that it does not need to be digi'd in order to show up on the the various APRS applications. Thus, if the Igate station can hear and talk to a Wide Area Digi, then a WIDE2-1 should get it to that digi, be heard and then beaconed (and picked up by other stations such as Igate's or Kenwood D700 or D7 setups).

Mic-E conversion on Igates:

In short, please don't do it. It came to our attention from Tim Cunningham, N8DEU. In this email he explains why Igate stations should not decode Mic-E packets and push them onto the APRS-IS system. Users of MacAPRS, WinAPRS, aprsd and other applicable programs should make sure that they have disabled the decoding of Mic-E packets if they are using those programs for the purposes of running an Igate. Mic-E packets will still get passed to the Teir 1 or Teir 2 servers (APRS-IS system) and will be decoded on an application by application basis. Such applications may be findu, or WinAPRS, Xastir, and MacAPRS connected to nashvilleaprs.net or Teir 1 or Teir 2 servers for the purposes of receiving an internet feed for positional data. The problem lies in the rounding formulas used by the various programs. Where some round down, others round up in their conversion of MicE packets. As a result, duplicate packets are not tossed and thruput for everyone is decreased.