Thursday, July 26, 2012
bit bucket due to a broken configuration on one of the servers. These included sign-up email confirmation and password recovery emails. Sorry about that!
The configuration is now fixed, and I've manually triggered a retransmit of the signup emails for the users who've signed up during the time but haven't yet clicked on the confirmation link.
Sunday, July 8, 2012
From the what-else-keeps-me-busy & off-topic department: It was a bit windy in Finland after christmas. So, this is what I found waiting at our summer cottage:
I didn't want to be an engineer. I wanted to be... a lumberjack!
I'm a lumberjack, and I'm okay, I sleep all night and I work all day.
I cut down trees, I eat my lunch, I go to the lavatory.
On Wednesdays I go shoppin'
and have buttered scones for tea.
Luckily it didn't fall the other way, across the road and over the power line.
I couldn't help it - the lumberjack song played on repeat in my ears most of the day.
Next task: manually converting the wood to smaller bits and pieces to make them fit in the stove.
Wednesday, July 4, 2012
|One of aprs.fi's servers getting new disks|
aprs.fi's second server migration reached completion today. It's now running on two blade servers, each having two quad-core Xeon processors with 12MB cache each, for a total of 8 CPU cores at 3 GHz and 32G of RAM per server. That's a total of 16 CPU cores and 64G of RAM for aprs.fi alone! The memory really helps, as I can now fit more and more stuff in memory and avoid slow hard disk seeks. We found the blade server in a dumpster, so it's not the latest and greatest in the market, but certainly useful for a few more years.
I also upgraded the aprs.fi server software with a few visible changes and several important features which are not directly visible to the end users.
The most visible change is that Dead Reckoning was enabled for all stations which have moved recently. If the station has moved within the past 30 minutes, a blue line will be displayed, indicating where the station would be right now, assuming it has continued on the same course and speed.
For stations which transmit quite often in relation to their speed, or do not turn quickly (ships, airplanes and high-altitude balloons, for example), the DR'ed position will be surprisingly accurate. For cars driving a very curved road (in the city) it will be less accurate, but the DR line still provides an indication on the relative age, speed and usefulness of the displayed position. Your internal non-artificial algorithm can easily figure that the car probably turned along the road, even if the blue line ends in a forest.
The blue line becomes gradually more translucent during the first 10 minutes after the reception of the position report. If it's almost completely translucent, the position is more than 10 minutes old and both the DR'ed position and the displayed old position are pretty outdated. This information can be very useful, too.
It can take a small while until everyone gets used to the DR lines. After having them for a couple months on my development server I can assure you that they really improve the usefulness of the real-time map view!
Ham::APRS::DeviceID module was upgraded to version 1.05, adding detection for a number of new APRS devices: TrackPoint, BPQ32, ircDDB Gateway, DIXPRS, dsDIGI, dsTracker, DireWolf, MiniGate, YAAC, and MotoTRBO. New version of the module will appear on the CPAN soon.
Fixed calendar date selection in the data export tool.
Implemented a nice user and team management web UI (for administrator use only). Especially useful when running the software in a closed "intranet" mode.
Gave a face lift for the service management command line tools.
Web server software was upgraded (as usual).
I've also implemented TETRA LIP position packet decoding and support for Google Maps Enterprise licensing. More on that later!