Monday, April 12, 2010

Receiver range estimations, colour gradients and AIS receiver list updates

Here's a little summary of changes done during the past weekend and week.

I've changed the colour scale of activity maps to a logarithmic one. This makes the receiving and gating activity maps much more readable:

http://aprs.fi/heard/OH2RCH, http://aprs.fi/gated/OH2RCH, and http://aprs.fi/heard/hkiais - be sure to zoom well out to get the full picture!

The estimated receiving range is now shown for igates and digipeaters. For example, the info page for oh2rch says:

Normal receiver range estimate: 80 km (Updated: 2010-04-12 19:36:27 UTC)

This means that OH2RCH doesn't usually hear packets transmitted much farther than 80 km away. It does hear something from 80-90 km away, and maybe very rarely from much farther away. These statistics have 10 km resolution for up to 200 km, 100 km resolution until 2000 km and 500 km resolution from there on. A monthly receiver performance graph can be seen on the graphs page, with a dotted vertical line marking the estimated normal receiving range. The longest distances are usually caused by bad GPS fixes or corrupted packets. The range is only calculated when the receiver has directly heard at least 3000 packets during the month, so that the estimate is somewhat accurate. This is a new algorithm which will require some fine tuning after some experience is gained.

Last heard a station directly: 2010-04-12 19:36:27 UTC (31s ago)

This indicates that the receiver of the igate is currently working - it has added it's callsign to the path of some APRS packets recently. Please note that because of APRS-IS duplicate filtering only some packets received by the given igate will update this timer.

Owners of AIS receivers can now update their receiver location strings and also configure a home page URL in their user account's AIS settings. These will be used in a new automatically updating page which will replace the old AIS sites list.

On the testing front, I've add system-level tests for the API and the KML interfaces, so that their basic operation is tested every time before building the software installation package.

No comments: