APRS™ Automatic Position Reporting System. Last updated Jan 14, 2013. WInAPRS 2.9.0 zip This includes the basic maps with Washington DC tiger map MacAPRS390.zip. Softball Pitchers Ring Finger. Mar 05, 2012 APRS Software – Two great finds! The mapping feature uses Open. If you have any other suggestions for APRS/Packet software please. 41 useful links about APRS software for ham radio collected in Software/APRS at The DXZone. APRS™ is a multifaceted system for use with packet radio by Hams, it allows the monitoring of real time geographical information such as the position of vehicles.

The aprs.fi software consists of four main components: • A data collector process, which connects to the APRS-IS and stores position data in the database • A maintenance process, which deletes old data and does other maintenance tasks • A web user interface, which generates web pages for the users of the site • A real-time map engine The data collector and maintenance processes run on the primary aprs.fi server. The web user interface runs on multiple frontend web servers, and the real-time map engine runs mostly inside the web browsers of the users. Although the software is very stable and resilient to problems in the operating environment, all components are run under a supervisor process which takes care of restarting them in case of an exception or a crash. Localisation, content and presentation. The web user interface is based on a lightweight template engine.

With the exception of unlocalised static information pages (like this one), the layout of the pages has been separated from the content, and the English strings have been moved to a database, so that they can be translated to other languages using a web-based translation tool. Most importantly, the content and layout has been mostly separated from the application code, so that the look and feel can be customised without modifying the software. There are separate layout templates for mobile devices, and it would be straightforward to implement a new look for a new class of devices.

Scalability and availability. Aprs.fi was initially implemented as a service which only ran on a single server, but as the popularity of the site has increased, it has been improved so that it can be run distributed on a number of servers. Distributing the system on multiple computers improves the availability and the performance of the service. Aprs.fi currently runs on three servers. Form No. 16a In Excel Format. Two act as a load-balanced pair of web frontend servers, and the third one is a data backup system. One of the frontend servers acts as a primary data collector, connects to the, receives data, and stores it in the database.

Updated data is immediately replicated to the other servers by the database backend. When an user surfs to the web site, the request is served by one of the frontend servers. When the user clicks a link to get the next page, it might come from another frontend server.

There are a couple of shortcomings in the current setup: The system is currently only configured with automatic failover for the web service. If the primary server fails, position data collection will be down, until the secondary server is manually promoted to act as the primary server. Also, because all of the servers currently store a copy of all data, adding more servers will not improve the system's data storage capacity - it only improves it's availability and the performance of the web service. Adding support for more position transmitters, or increasing the storage time or detail of position data, requires adding disks to all of the servers. Some work has been done to support partitioning the service so that a subset of the servers would handle a subset of tracking devices, but it cannot be utilised or completed until at least 3 physical servers are used.

Taking consistent backups of a large and active database without stopping it for the duration of the backup is fairly tricky, and while it can be done, it does have a performance impact. So, aprs.fi has a dedicated backup snapshot server, which doesn't serve any users directly - it is only used to take backups of the live database. The database service on the backup server is first stopped, a filesystem snapshot is taken, and the database is started again. After it's been started, it will catch up with the primary server, sequentially replicating all updates which have been received during the backup. The compressed backup snapshot is then made from the consistent filesystem snapshot.