Wednesday, December 30, 2009
If you've got questions on how to use aprs.fi, or if you'd like to share tips or tricks, please join the group and send an email there. I'd also like to encourage experienced users to answer any questions posted by others, if you happen to know the answer. I'd greatly appreciate your support - any time I don't need to spend writing emails I can use for developing new features.
Several users have also requested that support for the Google Maps Traffic would be added. It's there now, along with a couple of other popular overlays behind the More button. The traffic data is collected using crowdsourcing methods (Google's view), so it's available on those roads where people use Google Maps to navigate (excluding iPhone users).
The heard and gated maps have also been fixed a bit, they no longer load all the other stations in the view. That was a stupid bug on my part. These views have also received some technical improvements and speedups. As a side-effect I erased the 48-hour history tables, so those views (and the "heard by" tables in the info pages) will be a bit empty for the next day or two. Sorry about that.
The info pages now show symbols together with the callsigns in the tables. Hmm, sorting by symbol doesn't seem to work, though.
There's also a new service status view.
Saturday, December 26, 2009
I've also changed the igate / digipeater receiver performance graph to use a logarithmic Y scale, so that distances with smaller amount of activity are more visible.
Sunday, December 20, 2009
OH2RCH close to downtown Helsinki, but there have been a few bad GPS fixes:
OH7AA fairly quiet on 144.800, peaks generated by stationary digipeaters:
OH6RDK is a digipeater without any activity within 20 km range (the receiver probably does work at that range, though):
VK2TV-4 has an HF receiver:
As usual, there are a few catches:
- The graphs tell more about the amount of activity within a given distance, than the receiver performance at that range. A receiver in the middle of a big city might hear well from a long distance, but there is simply so much traffic close to the receiver that the linear Y scale of the graph hides the position packets from the distant stations. Maybe I should switch to a logarithmic scale, or would that be too confusing?
- Stations transmitting invalid or fake coordinates will skew the stats. If the transmitting station claims to be 1000 km away (due to a bad GPS fix), my best guess can only be that the station actually is that far away.
- Items and objects are not shown here, since they are usually far away from the transmitter which transmitted the packets.
- AIS support is still in the works, I need to add a method to configure the coordinates of the receiver.
Monday, December 14, 2009
I strongly recommend all APRS authors to implement UTF-8 encoding in their APRS software for proper internationalization support! To get some UTF-8 testing packets, send an APRS message to the callsign UTF-8, and my testing responder will respond with four messages containing English text, Scandinavian and German special characters, and a few Japanese words.
In addition to UTF-8, I also added a magic recode feature (inspired by the irssi IRC client), which tries to guess the character set of the original packet based on the character distribution. It currently attempts to support ISO-8859-7, ISO-8859-15, CP437 and CP850. Because of the overlaps between these character sets, this feature can not be made to work perfectly - the task is impossible. It's guesswork. To get your characters to show correctly, please transmit them in UTF-8.
Inspired by weighted tag clouds, callsigns shown in the Other SSIDs list are now weighted according to the time of the last position update from that callsign. If the position was updated within 24 hours, the callsign becomes bigger than usual, and the other way around. For example: KJ4ERJ, WB4APR
The position history database table was migrated to a partitioned table. Or rather, the migration was started - new data is being inserted in a partitioned table, and old data is still in the unpartitioned one. This is a very technical change which does not make a lot of difference to most of you folks, but improves things a lot on the server side. I can now delete old history data in 1-day chunks very quickly with a minimal performance hit. Inserting new data requires less disk I/O and smaller memory buffers (thanks to the partitioned indexes).
I've also upgraded aprs.fi to use Ham::APRS::FAP version 1.13, upgraded the web server software, fixed some XHTML syntax, done some performance tweaks on the real-time map, and added support for APRS targets without a current known position (required for receiving telemetry from a station without a known position).
This upgrade was a big one, and required about an hour of downtime. Sorry for the trouble. I hope I didn't break anything this time.
Sunday, December 6, 2009
Before the reboot, the master server had an uptime of 681 days. Thanks go to the UPS and the diesel generator - there have been a few small power outages in Espoo during that time.
In the near future I'll be installing a new master server for aprs.fi, the hardware is already waiting for the OS installation in the basement.
I've also bought an 80 GB Intel X25-M SATA solid-state drive (SSD), a very quick flash-based hard disk-like device. The amount of disk I/O operations is starting to become an issue on aprs.fi, so I'm going to try moving the busiest database tables (which are also the smaller ones) on SSD. We'll see how that improves things! It might even allow me to implement some new features (which require additional I/O capacity).
Sunday, November 22, 2009
Another small bit of news is that I've disabled anonymous commenting on this blog due to comment spam - I'm getting tired of manually deleting all the spam. From now on, you'll need a Google account to comment, or an account on one of the supported OpenID-enabled services. Sorry for the trouble.
During the last couple weeks I've been working on making the service UTF-8 clean for proper universal text messaging. It almost works in my testing installation, but there are still some quirks I need to clean up.
I've also installed a new database replica server at another physical site in downtown Helsinki, so that I'm able to bring the service alive without significant data loss in case of a complete hosting site loss (fire, flooding, extended network outage). The main servers are located in Espoo, Finland.
Wednesday, November 18, 2009
Ham::APRS::FAP is the APRS packet parser used by aprs.fi. If you wish to decode APRS packets in Perl, this is what you need. It's pretty fast, it's stable, and it can report it's errors in a developer-friendly way. And it's free (as in free speech).
Version 1.13 contains the following small fixes:
- Allow anyone to update telemetry parameters, skip the source callsign check
- Allow a PHG of 0000 for deleting PHG
- Added new error code sym_inv_table for invalid symbol table char
- Added local time zone parsing to object timestamps
- Fixed comments parsing for last resort !-location packets
- Parse APRS message rejects (negative acknowledgments)
Tuesday, November 3, 2009
Sunday, November 1, 2009
I only added the temperature plugin yesterday (before the upgrade), but ... the CPU core temperatures did drop by 2°C. Now, does nginx reduce global warming?
Oh yeah, referenced digipeaters and igates are now shown when you look up a day in the history. There is little bug in there, though - it shows their current positions, instead of their positions on the selected day. But hey, they rarely move.
There were also some rather large changes under the hood, causing a longer outage than usually. I replaced the Apache web server software with nginx, which allows me to run with HTTP keep-alive again (without running out of memory), and should generally handle larger amounts of users without that much trouble. It also helps with resource management - I'm now running separate web server processes for each service instead of a single Apache process pool for a large number of virtual servers. Now, if one service gets a beating, the others won't be affected so easily. Upgrades and configuration errors in one service won't break others, either. The downside is that name-based vhosts are out of the question.
Today's photo was taken on 11th of August at the summer cottage in Maaninka. EXIF says 9:39:17 PM. It's freezing and very dark in Helsinki today, so I'd rather go back a few months.
PS. I'll be in Bordeaux, France for the next 2 weeks or so.
Wednesday, October 28, 2009
Monday, October 26, 2009
To try it out, surf to the beta site and enter a comma-separated list of callsigns (OH7LZB-9,OH2RDK,OH2RDS), or click 'start tracking' on multiple targets!
It's also running with a completely different web server software than before. We are still fixing bugs with the new setup, so the beta service might be unavailable at times. Please report any bugs as comments on this post, or send a private email to the address shown on the profile page.
- Hessu and the bug-eating cats
Thursday, October 15, 2009
RAUTAUOMA, OH2RDK, oh2rd*
The exact matches (rautauoma and oh2rdk) are preselected, and the wildcard matches are not.
Implementing this on the live map will be slightly more complicated, but unavoidable. :)
PS. Got my OT2 running with my Garmin Nüvi 350 today. Details will be posted later. It's very cool indeed.
Tuesday, October 13, 2009
Monday, October 12, 2009
An FM broadcast antenna, which was used as the 145 MHz repeater transmitter antenna (together with a circulator and dummy load to handle the SWR), was removed and replaced with a proper 2-element stacked dipole for 145 MHz. Also, a 432 MHz repeater antenna with 4 stacked dipoles for RX and 2 dipoles for TX was added. And an extra 145 MHz dipole on the side of the mast. The 145 MHz RX antennas on the top of the mast, which are shared by the 2M repeater and the APRS igate, were not touched at this time. The new single dipole could be used for a transmitting igate to support 2-way messaging. There's another igate handling that in the area already, though.
The work happened at 70 meters above ground level, right above the second guy wire attachment point. Here is Antti, OH2MNI, attaching the 145 MHz dipole pair to the mast:
And here you can see yours truly, holding the braking rope which keeps the 2M antenna far from the mast while the antenna is being pulled up, so that it doesn't break all those microwave link antennas on the way up. On my right side is one of the guy "wires" - there are 6 of these on three sides of the mast, a total of 18.
And here, on the left side of the mast, are the completed antennas. On the top right side of the mast is a fancy new wind turbine, which is generating 48V DC to help power the commercial network equipment on the site. Green energy, global warming, you know the story. It was installed this summer, and it's already broken - the bearings are making so much noise that the neighbors are more than slightly annoyed.Thanks go to: OH2LAK (the brains of the operation), OH2FDA, OH3GMZ, OH2MNI, OH2GLG, OH3GMZ and Markku V (the mast pro). More photos by OH2LAK and OH2MNI...
It should work better for jets (traveling close to 1000 km/h), although during the takeoff acceleration some points might be dropped. After some initial test flights we'll be fixing that. :)
It should also better handle the case where the initial transmission happens to be somewhere far off. It seems like there are a bunch of stations which always wake up in Tokyo and then start transmitting their correct position in the US or Europe. Probably the GPS manufacturer has decided to show it's office location instead of the standard 0/0 lat/lon, and either does not indicate the bad fix in the NMEA sentence, or the tracker ignores that bit of information and transmits the bad position. These should now jump to the correct position after just a couple of packets.
The algorithm also ignores positions which were sent more than 2 hours ago, so if you take an intercontinental flight and start transmitting your new position immediately, it should just work!
Feedback is more than welcome!
Thursday, October 8, 2009
There has been some confusion about these messages. There are three kinds of "status/comment" messages you can attach to your position. For example, SM4IVE-9 (info) is sending two of them.
The comment text is sent together with the position, in the end of the position packet. Here's an example packet with a comment text of www.sm4ive.com:
The status message is sent as a separate packet which starts with a '>' character:
The Mic-E status message is encoded in a mic-e packet using just a few bits, and can contain one of these 8 standard messages: Off duty, En route, In service, Returning, Committed, Special, Priority, Emergency. 7 custom messages (Custom 0 to Custom 6) are also defined. All Mic-E packets contain this status message, and it only consumes a couple of bits in the message, so this requires the least bandwidth from the APRS channel. On the other hand, it can only express the few predefined values.
I would recommend using only the comment text, since it is sent in a single packet together with the position. The status message is sent in a separate packet which increases congestion.
If a status message is required (for example, if the text really needs to be so long that it doesn't fit in the comment text), the status message should not be sent too often. Certainly not as often as the position packet.
In the following photo Armi frowns upon seeing a long, static status packet:
Tuesday, September 29, 2009
I've improved the static map view a bit. From now on, the map will always be centered on the current location of the tracking target. The 'fit as many points as possible' centering algorithm of Google left a moving target outside the map view way too often, especially in the higher zoom settings. I also reduced the amount of zoom selections to make it quicker to navigate on mobile devices, and made the zoom selector show the currently selected value.
The user account password storage was improved, too. It now uses the RFC 2898 PBKDF2 algorithm to better protect the passwords against an offline dictionary attack. The computationally intensive hash algorithm intentionally makes it slower to perform the cryptographic operations required to check whether the given password is correct for the user. In case someone manages to break in the aprs.fi servers and steal the password database, it'll take a very long time for him to try all the dictionary words against the password hashes. This is basically a safeguard to protect those users who are stupid enough to use the same password on aprs.fi and other services (like their email accounts).
Monday, August 31, 2009
The callsign / object name labels shown on the map now have colours which partially match "APRS symbol attribute" colours in Bob Bruninga's original APRS software:
- White: APRS stations which are capable of messaging
- Gray: APRS stations which are not capable of messaging
- Violet: Objects
- Purple: Items
aprs.fi now updates the case of the callsign / target name to match exactly what is transmitted, even though the service is still case insensitive. So, if you're transmitting an APRS object named 'Oh7lzb' now, and you switch to a normal APRS station (not object) with the callsign 'OH7LZB', the service will now show the updated upper-case 'OH7LZB'. Before now, it retained the old mixed-case name. Both will refer to the same station and tracking history on aprs.fi, as before.
The path adviser on the info page now warns you about funny path elements like WIDE1-3.
The bigger under-the-hood changes make the web UI marginally quicker, easily expandable, and enable more fine-grained per-feature access control and site configuration.
Wednesday, August 26, 2009
The new one only shows the days when new points have been inserted. For a fixed station like a digipeater it shows the initial date when the station was first heard by aprs.fi - the old one showed all of the days between the initial packet and the latest packet at the same position.
I also described the date selection menu in the FAQ. It turns out a lot of people don't know about it. Would some people like to try to write a beginner's manual?
The info page now shows the latest telemetry from the station instead of the number of telemetry packets stored. It's much more useful and much quicker to look up.
Most importantly - there is now a GIF animation in a couple of places! Honestly, I never thought I'd bother with such an useless thing which takes such an enormous amount of time to produce. But I accidentally figured out how Gimp does it, so I just had to try it once. Sorry!
In case you were wondering - a new kitten arrived on Saturday evening! The photo is maybe a bit off-topic, but it sure is cuter than the computers and radios.
Tuesday, August 18, 2009
I've just installed a new build of the software with a couple of features I've implemented yesterday evening and tonight.
I've regenerated the whole map symbol (icon) set from the Revision H APRS symbols provided by Stephen H. Smith, WA8LMF. The symbols shown by aprs.fi should now match those shown by findu.com, UI-View (with Stephen's symbol files) and other programs running with up-to-date symbols.
Thanks to Stephen for maintaining the symbol tables!
The downside is that the new symbols are a bit smaller than the old ones, and they suffer more from the artifacts caused by rotation (for course/heading display).
The upside is that I've also implemented symbol overlays! For example, OH2RDG now has the letter N overlaid on top of the solid green star, both on the map, in Google Earth, and in the info pages.
There's also a short FAQ page.
Sunday, August 16, 2009
The really odd thing is that the ship didn't go to the nearest Swedish port, but continued towards Africa as if nothing had happened. Very strange indeed. Either the hijackers were still on the ship, or the crew is taking part in the plot.
Latest news (Ransom demanded): BBC, CNN, YLE.
There have been a few questions about AIS positions of Arctic Sea shown on aprs.fi.
Q: Why is the track not shown for the moment of hijacking between Gotland and mainland Sweden?
A: There are no AIS receivers in the area which would directly send AIS reports to aprs.fi. These receivers are run by volunteers (thank you!), and each volunteer chooses where to submit AIS data. There is a receiver in the area, but it is submitting data to MarineTraffic only, and while MarineTraffic and aprs.fi exchange AIS data, aprs.fi is not getting the reports of all of those receivers. The Swedish maritime officials have an AIS receiver network of their own, and they've reported it ran circles and stopped for a while.
Q: Is the position shown for Saturday, 15th of August, valid?
A: Technically, it's possible, but I personally would find it very unlikely. It is easy to fake and it doesn't make any sense for the hijackers to publish their true position like this.
The position report was sent by an anonymous receiver station to MarineTraffic. It is quite easy to send fake data to MarineTraffic over the Internet, since they allow unauthenticated UDP packets containing NMEA strings to be sent to the service. aprs.fi does not allow unauthenticated UDP packets, all AIS submissions are tied to a specific receiving station using a password. Of course any one of those stations could feed us invalid positions, but at least we have some idea of the originator.
If the hijackers (or someone else) wanted to play tricks, they could also go to a shop selling marine radio equipment, buy an AIS transmitter, configure Arctic Sea's MMSI number (and other correct data) in it, give it an incorrect position by crafted NMEA strings (fake GPS receiver on the serial port of the AIS transmitter) and have it transmit the packets on the correct AIS frequency. If they've got the money and motivation to hijack ships with guns and speedboats, they've certainly got the guts to buy or steal AIS equipment. They could also grab the AIS transmitter from Arctic Sea, and take it to another position using a speedboat.
The French navy says there were 3 military vessels in the claimed position on the Bay of Biscay, heading for the Baltic sea, and they didn't see the hijacked ship. And they didn't see it on their radar, either.
The coast guard of Kap Verde claims to have seen the vessel about 800 km off the coast of Cape Verde, which is some 3600 km away from the Bay of Biscay.
In any case, this is starting to become a good plot for a movie.
Friday, July 31, 2009
The Mic-E status message is encoded in the packet using just a few bits, and can contain one of these 8 standard messages: Off duty, En route, In service, Returning, Committed, Special, Priority, Emergency. 7 custom messages (Custom 0 to Custom 6) are also defined.
The current message is shown on the info page of the sending station, and the info balloon of the current position on the real-time map. Old values of the message bits are currently not stored in the database.
Tuesday, July 21, 2009
I also installed new aprs.fi software on the servers. The new version adds support for the APRS equivalent of the email / newsgroups x-no-archive header, "!x!", which can be placed in the beginning of the comment text of a position packet. It prohibits aprs.fi (and findu) from archiving the position packet in the database. This is quite an old feature in findu, and has not really been documented anywhere (except the APRSSIG archives).
The !x! string is different from using NOGATE or RFONLY in the digipeater path. NOGATE/RFONLY prohibit gating the packet to the APRS-IS completely. !x! does not forbid igates from gating the packet on the Internet, it just requests that the packet is not stored in databases for a long time.
Please note that not all igates or databases support these features. Amateur radio transmissions are defined to be in the public domain (by FCC rules in the US, and by respective legislation in most other countries, and I suppose, by international regulations). Anyone can receive them, and retransmit, publish or store them as they wish.
As Steve Dimse put it on the APRSSIG: "if you do not want your data appearing on the internet the only guaranteed way is not to transmit it!"
I also added a search button to message and raw packets browsing views, and fixed a bug in clickable callsign links in digipeater paths. And did a rather massive source code tree reorganisation, making it a bit more tree-like.
Wednesday, July 8, 2009
The upgrade itself, and the necessary conversions, wouldn't have caused any outages, since I can tell my software to do queries on another database server while upgrading one (in fact, they will automatically fail over to another server if one is down). But, as usual, there was something I overlooked, and for a few minutes about 50% of the /info/ page requests failed and complained about problems with looking up nearby cities. I had to improve the stored procedures a bit to get them working on the new database engine version.
Please, drop a note in the blog comments, if you notice any other problems.
Tuesday, July 7, 2009
If you already have an account on aprs.fi for posting AIS data, and you don't have your login password (it's different from the AIS feeding password, and no, you didn't have one before since there was no such thing before today), try logging in with your email address and any bad password, and you'll get to the "forgot my password" path which lets you reset the password to a new one.
As usual, there are quite a few new strings to be translated. From now on, you'll have to sign up for an account and log in to access the translation tool. I hope you don't mind.
Sunday, July 5, 2009
One of the visible changes is a new authentication and authorization layer, which is based on a conventional email address + password model with a team-based authorization system. It'll enable some new features and services later (once I get around to implementing those) - in the first phase it just lets you sign up for submitting AIS data without manual work on my part.
There's no need to worry, as a normal user viewing data on aprs.fi, you won't need to sign up for an account. Logging in is completely optional, and I won't encourage or beg everyone and their cat to sign up. In fact, the "login with your nickname to see the map" model will go away - you'll end up directly on the map page when you arrive on the site, and the "most usual" site entrance path will be easier and quicker than before.
I will be adding an "introductory" entrance page for first-time visitors later, so that there's a chance to let them know what this site is all about. But it'll only be shown once for each visitor.
Saturday, May 16, 2009
A couple of components started hitting file descriptor limits, which had last been upgraded over a year ago. Too many simultaneous connections per process. This made the site perform very, very slowly. I quadrupled the limits, and the site started to perform quickly again, I hope that's enough for more than a year to come. Well, I have to admit that it would actually be a nice surprise if the site would be so popular that it wouldn't be enough...
I also fixed a bug in the "first heard" algorithm pointed out by Ian, VK1IAN. The digipeater alias GATE was not treated as a special digipeater alias (like WIDE, RELAY and TRACE are), and an igate which first heard a packet with a GATE in the digi path was not given credit for hearing it first.
Another fix that went in was a filter which takes out complete APRS packets which have somehow made their way to the comment field of another APRS packet. Apparently something is loosing CR LF sequences between packets (could be my code...), which causes packets to go into the comment of the previous one. Before I find the actual bug I've added a filter to strip these off.
Saturday, May 9, 2009
Bob Bruninga is expecting to have APRStt running there, too, so if you're visiting Hamvention, you might be able to place yourself on the map using just a DTMF-capable 2m transceiver.
I've also added a new parameter 'he_maptype' in the APRS map embedding interface which allows you to select satellite, physical or hybrid map views in addition to the normal street map.
Tuesday, April 14, 2009
This morning I added arbitrary date range lookups to the weather and telemetry pages. It allows you to look up a detailed graph between any two dates or times. It also has a little calendar widget for your convenience.
I've also done some XHTML validity fixes for better browser compatibility, switched to a smaller position marker on the static maps, and added some navigation links in the bottom of most pages. I also fixed the bug of date selection menu not appearing when clicking on 'start tracking' on the live map.
Also, the /info/ page of a weather station now shows a brief 'latest weather' report instead of the number of weather reports in database. It's probably much more interesting, and it's much quicker to load, too, since it's almost always cached in memory and doesn't require a potentially large disk read.
Wednesday, April 1, 2009
I've now manually downgraded to Google Maps API version 2.150 which seems to work better.
Sorry for the trouble, and thank you for your patience!
Tuesday, March 24, 2009
As announced before, I ran some database restructuring batch jobs during the weekend. The last one was actually started on Monday morning and the execution was completed early Tuesday morning. I hope the slowdowns were not too noticeable, I tried to make them run slowly enough to not interfere with normal use.
I'm currently looking at ways to clean up some unused data from the aprs.fi database. There's quite a lot of automatically or erroneously generated targets stored in the database, most of which are not really looked at by anyone. They just inflate my tables and make the prefix browsing view very cluttered. The performance impact caused by the extra targets isn't really noticeable, but it's just not very nice to have them there.
If you're keeping an eye on the statistics, you might have noticed that today I deleted about 60000 targets. Those were all APRS objects, which had only a single point stored (non-moving), which were last announced over a week ago, and which were announced for less than 12 hours. Almost all of them were automatically generated earthquake and severe weather warning objects, which don't really need to be here any more.
There's also an awful lot of regular APRS targets which have a corrupted source callsign. Most usually one or two characters have been lost from the beginning of the callsign. For example: 1VAJ (J41VAJ), 3GXT-2 (W3GXT-2) and 3TVX-9 (VE3TVX-9). You can find these by looking at the prefix browsing view, picking a strange prefix starting with a number, and looking up the correct original call in the "nearby stations" list of the info page. I wonder how the callsigns get mangled like this, and how could I remove these from the database without accidentally removing some valid data.
Friday, March 20, 2009
Sunday, March 1, 2009
There are spots of APRS coverage in (at least) St. Petersburg, Moscow and Novgorod.
Sunday, February 22, 2009
On Saturday I also made some significant changes in the backend code, which should make it scale out a bit better. I added some more in-memory caching which should speed things up so that the addition of things like APRS packet paths will not cause a significant performance hit.
Sunday, February 15, 2009
I've also added support for failing over to secondary APRS-IS servers automatically, so now I don't have to do anything manually if my own APRS-IS server fails (or is taken down for maintenance). This should prevent today's outage from happening again.
As a result, aprs.fi didn't collect APRS data between 11:35:43 UTC and 14:21:13 UTC. Sorry about that, I'll try to be more careful next time.
The memory upgrade itself went fine. The server should perform quite well for a while now.
Saturday, February 14, 2009
The upgrade should speed up the second frontend a bit (not that it would really have been slow before), and make it do the job for another year or so. It's been a gig or two on the swap before, but there hasn't been significant swap I/O happening normally, so it hasn't really been a problem. This is just a proactive upgrade to keep it performing as well as before, with the increased usage.
Monday, February 9, 2009
Thursday, February 5, 2009
Monday, February 2, 2009
It currently shows the path of a single packet, when you point an APRS station or a track point with the mouse cursor. In the screen shot on the right I had the mouse cursor pointing to the oldest waypoint of OH7FDN, and that position packet was relayed by the digipeater OH7RAA, and forwarded to the APRS-IS by the igate OH7AA.
There are a couple of limitations in this implementation:
- It currently only shows the first digipeater found in the path, and the igate.
- The digipeater and the igate must be visible on the map (or just outside the visible map area) - you might have to zoom out to make them visible.
- The digipeater and the igate must be visible on the map - if you're tracking a single station (you've just searched for a callsign), you'll have to click on "stop tracking".
- It currently only works in the real-time view - it doesn't work if you select a day in the past (because it only shows a single station in that mode).
Features like this always come with a performance penalty. To provide the additional eye candy I'll have to pass on more data to the web browser. It will consume a bit more memory, and make the web browser slow down some more. I certainly hope it's worth it.
If you simply stop transmitting the PHG data, it will still be present in the aprs.fi database. There are a bunch of digipeaters using multiple different comment texts in a round-robin fashion, and some of them only transmit the PHG extension once per three position packets. So, if I'd delete the PHG data from the database whenever the PHG extension is missing, those digis would only be shown with a PHG circle 1/3rd of the time.
Friday, January 30, 2009
The map is somewhat configurable, supports several different map types, zooming, different measurement units and coordinate formats. It runs on the same quick and scalable backend servers with aprs.fi.
There are some issues with the combination of Google Static Maps and Facebook, so it might stop working once it becomes a bit more popular. We'll see later.
I'm sure a lot of you will shake your heads in disbelief, and quietly comment something about the uselessness of this feature, but let's face it, Facebook is a big thing, and I just wanted to try it out, see what's going on in there, and figure out how things can be integrated with it.
aprs.fi also has a facebook page now. I don't know what it's good for, but at least you can mark yourself as a fan of the site to show your support. And maybe exchange some related photos, links and videos there, or use the discussion board. I'm sure it has a better discussion board feature than this blog's comments.