The Blog of Lee – Technical. Philosophical. Photographical. All-Sorts-ical.

Saving Disks Nobody Even Knew Were Lost

May 182026

Or, How I Built a Floppy Preservation Platform From Scratch

There’s a moment I keep coming back to. I’m holding a 5.25-inch floppy disk from 1985, slightly warped, its label faded to near-illegibility. The disk belonged to a now-defunct magazine that no longer exists, containing software written by programmers who may have no idea their work survived at all. In about thirty seconds, my Greaseweazle is going to read it at the flux level — capturing not just the data but the magnetic signature of the original write head, preserved with a fidelity that would have seemed like science fiction to the person who formatted it 41 years ago.

That moment is why I built this.

The Problem With “Just Copy the Files”

When most people think about digital preservation, they imagine it’s straightforward. Files are files. Copy them. Done.

It isn’t like that.

Floppy disks from the 1980s and early 90s were written by a dozen different DOS versions, on hardware with varying geometry, using formatting conventions that were often undocumented, non-standard, or deliberately obfuscated. The IBM PC disk format evolved rapidly between 1981 and 1993 – from 160KB single-sided disks with no BIOS Parameter Block at all, through the chaotic proliferation of 180KB, 320KB, 360KB, 720KB, and 1.2MB formats, to the eventual standardisation around 1.44MB. Every step of that evolution left behind disks that modern tools handle poorly, or increasingly, not at all. You can’t just plug a 5.25″ floppy disk drive into a modern computer either; the motherboards do not have the headers, there is no USB version of such drives, and most modern OS’s have no idea what to do with such devices.

An open-source project (@keirf/greaseweazle: Tools for accessing a floppy drive at the raw flux level · GitHub) gets round this problem with sufficient technical knowhow, but even with the right hardware, software, tenacity and preparation, recoveries can be slow and time-consuming.

My first serious problem was a 160KB disk – an IBM DOS 1.0 single-sided format from 1985. DOS 1.0 predates the BPB entirely. The boot sector BPB area doesn’t exist; it’s either zeroed or, in many cases, contains raw bootstrap code, because the formatter never needed to write geometry data there. DOS didn’t read it. The BIOS told DOS the geometry. That was enough.

Modern Linux does not have a BIOS. It reads the BPB, finds garbage, and refuses to mount.

I spent a week on this. The solution involved mtools with explicit geometry configuration, a content-addressed scan cache, and eventually a BPB-patching function that writes a correct 25-byte geometry block into a temporary copy of the image before mounting – leaving the original completely untouched.

The Stoned Virus Problem

Several of the cover disks I’ve been archiving are infected with boot sector viruses. Stoned is the most common – a 1987 New Zealand virus that spread primarily through floppy sharing, and that infected an absolutely enormous number of disks before it was widely understood. Finding it on a magazine cover disk isn’t surprising. Finding it on a disk that was then sent to thousands of subscribers and read on machines that went on to infect office networks is a small window into how the late 80s computing ecosystem actually worked.

The interesting preservation question is: what do you do with it?

My answer: keep the original, warts and all. Archive it faithfully. Document the infection. But also provide a clean variant for people who just want to use the software.

The tool now handles this automatically. ClamAV scans happen in two passes – first against the raw .img file (the only way to catch boot sector viruses, which live in the first 512 bytes and never appear as files on the mounted filesystem), then against the mounted filesystem itself. If the original is infected and a .clean.img exists, BPB patching is applied to the clean image, not the infected one. The variants system – original, clean, patched, recovered – means every state of a disk’s history is preserved and documented.

The infected original is still there, still mountable via NetDrive if you want to study it. It just comes with a red warning badge and a button you have to click to acknowledge the risks before you get the connect command.

Archaeology at the Boot Sector Level

The most technically interesting disk I’ve encountered so far had a boot sector that was simultaneously valid bootstrap code and appeared to corrupt the filesystem. The JMP SHORT 0x3E instruction at offset zero – a two-byte jump that skips over the entire BPB area – is a deliberate design. The publisher wanted a custom boot experience: insert the disk, power on, and instead of Non-system disk or disk error, you’d get something. A menu, a splash screen, a welcome message. There wasn’t space for that in the standard three-byte jump and eight-byte OEM label. So they used the BPB fields – offsets 11 through 61 – as overflow for executable code, and got 51 extra bytes.

On real hardware, this worked perfectly. DOS never reads the BPB during normal file access. The BIOS knows the geometry. The disk just works.

It also functioned as copy protection. Duplicate a disk and your duplication tool reads the BPB to determine geometry. It gets: 147 bytes per sector, 240 sectors per cluster, 55,438 sectors per FAT. Whatever it produces next is not a working copy.

The bytes that should contain geometry – 0x93, 0x00, 0xF0, 0x1E, 0x50... – are MOV instructions and jump offsets. When I decoded them I found a fragment of the IBM 3.3 bootstrap string interspersed with 8086 opcodes. The formatter had been creative.

The Tool

What started as a PHP script that mounted disk images and printed a directory listing has become something considerably more substantial. The current version:

Recursively discovers .img files and groups them by base slug, automatically detecting variant types (.clean, .patched, .recovered, .cracked, and several others)
Detects filesystem type from the raw boot sector bytes – FAT12/16/32, early DOS formats, CP/M, NTFS, ext2/3/4 – without mounting
Extracts disk geometry from image size, using a lookup table covering every standard floppy format from 160KB (1981) to 2.88MB (1991)
Mounts via Linux loopback, falling back to mtools with explicit geometry, falling back to BPB patching on a temp copy, with a content-based sanity check at each stage to catch silent failures
Runs ClamAV in two passes, including raw image scanning for boot sector infections
Extracts readable text files – documentation, README files, source code in BASIC, C, Pascal, Assembly – and publishes them as individually-crawlable HTML pages, so a search engine can index a 1987 copyright notice or an author’s name embedded in a REM statement
Generates per-disk HTML reports in a retro green-screen CRT aesthetic, with directory trees, full SHA-256 file manifests, archivist’s notes, photo galleries, and a live mTCP NetDrive connect command
Publishes a cross-archive file search, a sitemap.xml, a robots.txt, and a static all-disks.html specifically for search engine crawling
Caches everything by image SHA-256, so unchanged disks cost nothing on subsequent runs

The Point

The software on these disks isn’t historically significant the way a Gutenberg Bible is significant. Most of it is small utilities, games, productivity tools, and programming experiments – written by hobbyists and professionals who were, in many cases, making things for the love of it.

That’s precisely why it matters.

The commercial software of the 1980s is relatively well-preserved. Companies had catalogues, revenues, lawyers, and reasons to maintain archives. The cover disk software – the stuff that came shrink-wrapped to a magazine, distributed to tens of thousands of subscribers and then largely forgotten – has no institutional custodian. Nobody owns the rights in any meaningful active sense. The authors have often lost their own copies.

But some of them are still out there. And some of them have children, and grandchildren, who might one day search the internet for their name and find a piece of code they wrote in 1987, preserved in a running state, mountable on a DOS machine via a TCP/IP protocol that didn’t exist when the disk was formatted.

That’s not a small thing.

The archive is live at dl.x86.world [or https://dl.x86.world] come and have a rummage…

MySQL Query to Use MaxMind GeoLite IP Database

Programming 1 Response »

Feb 162015

MaxMind offer a fantastic resource to geolocate IP addresses. Unfortunately the PHP API supplied is overkill for most (simple) uses. Instead, we can do it mostly within PHP/MySQL.

Create Schema:

DROP TABLE IF EXISTS `blocks`;
CREATE TABLE  `blocks` (
  `startIPNum` int(10) unsigned NOT NULL,
  `endIPNum` int(10) unsigned NOT NULL,
  `locID` int(10) unsigned NOT NULL,
  PRIMARY KEY  (`startIPNum`,`endIPNum`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 PACK_KEYS=1 DELAY_KEY_WRITE=1;

DROP TABLE IF EXISTS `location`;
CREATE TABLE  `location` (
  `locID` int(10) unsigned NOT NULL,
  `country` char(2) default NULL,
  `region` char(2) default NULL,
  `city` varchar(45) default NULL,
  `postalCode` char(7) default NULL,
  `latitude` double default NULL,
  `longitude` double default NULL,
  `dmaCode` char(3) default NULL,
  `areaCode` char(3) default NULL,
  PRIMARY KEY  (`locID`),
  KEY `Index_Country` (`country`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 ROW_FORMAT=FIXED;

Read in the MaxMind data:

load data infile 'GeoLiteCity-Blocks.csv' 
into table `blocks` 
fields terminated by ',' optionally enclosed by '"' 
lines terminated by '\n' 
ignore 2 lines;

load data infile 'GeoLiteCity-Location.csv' 
into table `location` 
fields terminated by ',' optionally enclosed by '"' 
lines terminated by '\n' 
ignore 2 lines;

And then we can use raw SQL to query against it – extremely quickly (0.0001 sec) by using the following query:

SELECT * 
FROM   `location` 
WHERE  locid = 
       ( 
                  SELECT     locid 
                  FROM       `blocks` 
                  INNER JOIN 
                             ( 
                                    SELECT Max(startipnum) AS start 
                                    FROM   `blocks` 
                                    WHERE  startipnum <= inet_aton('1.2.3.4')) 
                           AS 
                             s ON 
                             ( 
                               startipnum = s.start 
                             ) 
                             WHERE endipnum >= inet_aton('1.2.3.4'));

You can similarly use this almost exact query within PHP using the following function (assuming PDO….):

function IPdata($ip) {
	global $dbh;
	if(!isset($dbh)) die("No database connection available.");
	if(filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_IPV4 | FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE)) {
		$cip = ip2long($ip);
		if($cip) {
  			try {
				$stmt = $dbh->prepare("SELECT * FROM `ip_geolocation` WHERE locID = (SELECT locID FROM `ip_blocks` INNER JOIN (SELECT MAX(startIPNum) AS start FROM `ip_blocks` WHERE startIPNum <= :IPADDR1) AS s ON (startIPNum = s.start) WHERE endIPNum >= :IPADDR2)");
				$stmt->bindParam(':IPADDR1', $cip);
				$stmt->bindParam(':IPADDR2', $cip);
				$stmt->execute();
			} catch (PDOException $ex) {
				die("IPdata() SQL ERROR: " . $ex->getMessage());
				return false;
			}

			if($stmt->rowCount() == 1) {
				$row = $stmt->fetch();
				return $row;
			} else  {
				die("IPdata() ERROR: NO DATA RETURNED FOR {$ip}");
				return false;
			}

		} else {
			die("IPdata() ERROR: ip2long RETURNED FALSE FOR {$ip}:{$cip}");
			return false;
		}
	} else {
		die("IPdata() ERROR: IP address does not validate ({$ip}:{$cip})");
		return false;
	}
}

CubieUPS – A UPS For the CubieTruck/Cubieboard3 Backup Battery

Programming 2 Responses »

Dec 182014

I recently got hold of a CubieTruck / Cubieboard 3 (think Raspberry Pi but on steroids) and ordered the LiPo backup battery to go with it (available from New IT in the UK, if you were wondering). Aside from just how fabulous the Cubieboard is (running Ubuntu 14.04 LTS no less), it also has a built-in battery backup for when the power goes out. This can, without a SATA HDD/SSD attached, power the Cubieboard for many hours. Even with a SATA attachment, it’ll ride out most power blips, burps, minor outages and power-plug moves.

But there is no built-in intelligence to it. It runs until the battery dies, and then your system dies with it. That’s pretty much the same as not having a backup battery at all in an extended outage and you aren’t around to notice. It just delays your file system corruption rather than prevents it.

So I wrote CubieUPS one evening. It’s a simple pair of scripts, run via cron (for extra points, run the same PHP script in your .profile as well and it’ll show you the current power status without you having to even do anything at all). It logs everything, and when things are looking a little dicey, it’ll shutdown your system cleanly.

It’s quite straight forward. You can view the source code, installation instructions and download the tarball here.

Using Temper1F USB Temperature Probe on Raspberry Pi

General 11 Responses »

Oct 122014

Article updated 28/10/2014 thanks to Pete Chapman releasing even better software. Read on!

One of the long-term goals is to pop one of my Raspberry Pi’s up in the loft. From there I plan to move my ADSB aircraft monitoring from the ‘Mancave’ into the highest point of the house; as I live up way up a hill, hopefully this will significantly improve my reception.

I also wanted to pop a temperature sensor on the mains water pipe feeding the cold water storage tank. My loft is very well insulated from the house (good for us), but also quite exposed. In a very cold winter this could result in the ambient temperature up there dropping to or below freezing. Frozen pipes, cracked tanks … not funny.

I ordered the above item from Amazon (search for PCSensor Temper1F). There are many types it seems but this is the one I’m writing about today. From what I can gather, they all function mostly the same and the instructions below should work regardless of which one you get. For the price (~£10-15) they are reportedly very accurate.

Throw away the driver CD

Firstly throw away the driver CD that comes with it. Yes it has linux software on it, but it’s buggy. Particularly for my purposes as when the temperature drops below 0C it overflows and reports 248C. Not that helpful when you wish to report on too cold rather than too hot.

Plug it in

Remove the USB stick from the packaging and plug in the temperature probe to the rear. Then use a USB extension lead to plug it in to your Pi (not mandatory, but when I use the Raspberry Pi I dislike touching the actual device and extension leads make it much easier to not disturb the device too much). If it’s the same model as mine you should get a little red LED light up.

$ dmesg | tail

[  623.621245] usb 1-1.2: new low-speed USB device number 7 using dwc_otg
[  623.735966] usb 1-1.2: New USB device found, idVendor=0c45, idProduct=7401
[  623.736004] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  623.736020] usb 1-1.2: Product: TEMPer1F_V1.3
[  623.736034] usb 1-1.2: Manufacturer: RDing
[  623.757428] input: RDing TEMPer1F_V1.3 as /devices/platform/bcm2708_usb/usb1/1-1/1-1.2/1-1.2:1.0/input/input2
[  623.760094] hid-generic 0003:0C45:7401.0004: input,hidraw1: USB HID v1.10 Keyboard [RDing TEMPer1F_V1.3] on usb-bcm2708_usb-1.2/input0
[  623.777723] hid-generic 0003:0C45:7401.0005: hiddev0,hidraw2: USB HID v1.10 Device [RDing TEMPer1F_V1.3] on usb-bcm2708_usb-1.2/input1

$ lsusb

Bus 001 Device 007: ID 0c45:7401 Microdia

Driver Installation

As I said above the existing software that comes with it is broken. ~~Peter Vojtek has released a fixed version of the original code on GitHub (local mirror).~~ Pete Chapman has released an even-more fixed version of the original software, as a fork of Peter Vojtek’s code on GitHub (local mirror). While Vojtek fixed the negative temperature issue, the sub-integer (decimal) temperature values were not accurate. Pete Chapman’s code fixes that little issue as well and makes the probe even more accurate. Thanks Pete!

Go grab it, and follow me. The instructions are a bit sparse with the code but it’s not at all difficult.

$ apt-get install build-essential libusb-dev
$ unzip master.zip (or whatever the driver zip file is)
$ cd usb-thermometer-master
$ make
$ sudo make rules-install
Unplug and Re-Plug the Thermometer
$ ./pcsensor

If all went according to plan and you haven’t had any errors or you’ve resolved them on the way, you should get back:

2014/10/12 13:03:35 Temperature 69.95F 21.08C

You can then use awk, or any shell script or scripting language of your choice (python example) to extract that data and make use of it. Copy the executable to /usr/local/bin when you are happy it works. Anyone on the system can execute it, it requires no special pemissions thanks to the 666 udev rules.

Have fun!

When you’ve got a decent amount of temperature data (the sources differ, but I put them in a uniform format in a MySQL database), you can have some fun with the data as well as more serious alerting ideas like above.

Click the graph to go play with the live version. 🙂

Lee

Monitoring ADS-B with dump1090 and Generating an Alert on a Squawk (7700, etc) in PHP

Programming 11 Responses »

Apr 222014

A friend of mine recently said he’d like to have something to ‘plug in’ to dump1090 running locally (see my previous post for my setup on this) to alert to emergencies in the air that are nearby. As I was getting in to it I realised what a neat idea it actually was. There are many different “interesting” squawk codes, and unless you’re glued to your Virtual Radar all day long, you’re not going to notice. Not to mention if a plane is going to fall out the sky it’d be handy to know to take cover …

So. SquawkWatch was born!

It’s a lightweight PHP script (uses approximately 1% of CPU time allocated to my ‘playground’ virtual server, and it has next to no CPU allocated to it) and sifts through all the messages coming in from dump1090, looking for a set of squawk codes defined within. When it finds one, it sits on it and waits for a complete data picture, and then emails the alert to you.

Requirements:

PHP 5.3
MySQL
dump1090 (reachable by the PHP host)

Download the source code here.

Download the G-INFO database here (late March 2014).

Example (non-debug mode) output here (stdout).

Any questions pop them in the comments and I’ll help where I can.

Lee

ADS-B (dump1090) with MySQL Support on the Raspberry Pi using a DVB-T (R820T) USB Stick

Programming 15 Responses »

Mar 252014

The Raspberry Pi is an amazing piece of kit. There’s little it cannot do with sufficient tweaking. I have a passing interest in planes, and love FlightRadar24 (iPad app and website).

FlightRadar24 screenshot

I started to wonder how they got this data. A quick rummage around their website reveals they mostly rely on a world wide network of volunteers to collect and then feed them data. You need ‘line of sight’ to an aircraft to be able to query the information, and no one entity can afford to do this globally. So, a network of volunteers run ‘feeder radar stations’ (ok, it isn’t really ‘radar’ but, more the Next Generation version of).

Hardware I Use

I use a ‘stock’ Raspberry Pi model B, connected via ethernet to my home network ordered via RS Components (fwiw, they’re slow as heck… order one from somewhere else…!). My Pi is strapped up under my desk out of the way. It has a 4 port (unpowered) USB hub connected to it (the black blob underneath) but otherwise it is entirely unremarkable. I’m even still using the original RS Components 4Gb SD card.

Excuse my camera charger lurking underneath it all – it’s entirely unrelated!

My Raspberry Pi, mounted under my desk

Hardware wise, to receive the ADS-B broadcasts from planes overhead, I use a DVB-T (R820T) Stick with an external aerial attached to it. I ordered mine from 1090mhz.com (based in Germany) and it arrived in the UK about 4 days later in perfect condition, and even had an adaptor and external aerial included in the package – thanks guys! This is the ‘best’ stick to use – apparently – as it is based on the R820T chipset.

Software I Use

I use a modified version of dump1090, originally installed using instructions from David Taylor’s SatSignal.eu website. dump1090 is fantastic. Using the sdr-rtl drivers (also documented on David’s site) to re-tune my DVT-B Stick from digital TV to the 1090MHz used by ADS-B, allows it to receive the ‘next gen’ radar data right from the planes in the sky themselves.

dump1090 then takes this feed and decodes the data into something human rather than machine readable. Using the –interactive mode, you can see the output as the planes fly by.

dump1090 –interactive

Perhaps even more exciting than that though, is the –net option, which enables not only all the data sockets so that FlightRadar24’s software can pull the information out of dump1090 (setup instructions here), but also enables a built-in web server so you can run and view your own miniature version of FR24:

Screenshot of my own ‘dump1090’ FlightRadar24-style output (–net option)

MySQL Support

You may remember I said I use a modified version of dump1090. That is because as well as everything above, I also wanted to store a local copy of all the data I receive in a MySQL database so I can do my own manipulations and calculations. While there is a MySQL’d branch of dump1090 on github, it is dozens of commits behind the main branch and missing out on a lot of the hard work Malcolm Robb has put in to his master branch and fork of antirez’ original work.

So, rather than forego either mysql, or using the latest version of dump1090, I hacked them together and re-introduced mysql support into the latest version of dump1090.

To keep updates to future versions easy, there are very minimal changes to all other source code/header files of the official dump1090 branch. 95% of mysql support code is contained within mysql.h and mysql.c with pretty much the only main branch changes being the inclusion of mysql headers and a new struct in dump1090.h, the –mysql switch handler in dump1090.c, and a call to modesFeedMySQL() in mode_s.c (that could even be moved to mysql.h I suppose to separate it even more .. but I just put it with all the other structs for consistency).

This should make it relatively simple for me/you to upgrade each time a new version comes out.

MySQL authentication credentials are now in mysql.h rather than buried deep in the codebase. If it’s something lots of people show an interest in, the database credentials could even be supplied on the command line for even greater simplicity and portability. We’ll see…

If you’d like the latest version (1.08.1003.14) of dump1090 with mysql support, you can get it here.

Happy flying!

Distributed, Daemonized, Parallel PHP

Google Latitude, Programming No Responses »

Jul 302011

Ever since I was 13 I’ve been programming in PHP. It’s one of those “you can do anything with it” languages that I just love working with. I have recently launched a (pre-beta) service that automatically checks you into Facebook Places (and more will follow, such as Foursquare) based on where your phone reports you to be totally automatically, courtesy of Google Latitude. It was awesome fun to write and is now live for folks to play with (you can find out more at beta.CheckMeIn.at).

The Problem

Now if it was just for me, it would have been trivial to write. Grab my Latitude position, compare it against a handful of places I frequent, and if any of them match, check me in on Facebook. Checking and comparing my location every 60 seconds would be really easy.

But what if I’m doing that for hundreds or even thousands of people? A script that runs each user in turn would run for hours just doing one sweep of the user database, querying Google Latitude, doing the distance calculation math based on latitude and longitudes, and then punching any matches to Facebook. Cron that script to run every 60 seconds and the server would fall over from RAM exhaustion in about 10 minutes, and only the first 50 or 100 people in the user database would ever be processed.

The Solution

There are 3 background processes (excluding the maintenance bots) that ‘power’ CheckMeIn.at. They are all written to work out of a central ‘work queue’ table, where the parent process gets a list of work to do and inserts work units into the work queue table. It then counts up how much work there is to do, and divides that by the number of work units each child process will be allowed to handle at a time. If there are more work units than permitted children, it spawns off the first batch, lets them run, and then spawns more as they exit off with their completed workloads.

The beauty of it is it dynamically grows itself. With 10 users it’ll happily spawn 1 process and run through them all in a second. With 100 users it’ll spawn 2 processes and do likewise. With 2,000 users it’ll spawn 10, and so on and so forth. If we have 1 million users it’ll spawn it’s maximum (say 50), then wait and spawn extras when there is room. All without any interaction on my part.

The Google Latitude Collector (GLC) manages the collection of user locations every 60 seconds. It’s “self-aware” in the sense that it manages its own workload, keeps track of the queries allowed by Google, and generally throttles itself to Do No Evil, while keeping the service responsive.

The User Location Processor (ULP) follows the same principles of the work queue, and compares locations collected by the GLC against a list of Places the user has configured via the web interface. It computes matches, near misses (to help with the setup), honours the delay periods, and so on and so on. If all criteria are met, it passes work units on to…

The Facebook Check-in Injector (FCI). The FCI handles a shedload of sanity checks, prevents double-checkins, examines Facebook for a users last check-in to make sure we’re not doing something they’ve already done themselves, and lots more. If it all works out, then we check them in and the whole thing goes round again.

Sounds complex, but from firing off a Google Latitude Collector, to checking a user in (assuming we’ve adhered to delay periods here), the are checked in to Facebook about 4 seconds later.

The Moral

Plan for growth in your application from the very beginning. This project would have been a b*tch to modify later on. But by knowing it’d grow, and implementing self-awareness and control into the app, it can handle infinite growth. If the current server that does all the processing becomes overloaded, it’s trivial to add another to halve its workload, and all without having to modify a single line of code.

The key however is to have a powerful database server to run it all off. In an hour it can easily generate a million database queries as users interact with the site, and the daemons go about their own business. Without a database server capable of keeping up, things start to seriously slow down.

Code Hacking with Google Latitude

Google Latitude, Mobile Phones No Responses »

Apr 212011

Those of you who have known me for any period of time will probably have been aware that you could find my current location on my personal website (which is now this blog). This was originally just the Google Latitude ‘badge’, which was quite a simple map representation of my current location with a guestimated range bubble around me. This is still displayed on every page in the right hand column. It only however, identified the town at best in textual format, and offered no historical view ability, or alternative display methods when I was somewhere I go regularly.

Since the 19th February 2011, I have been storing my Latitude location as updated automatically by my mobile phone that goes with me everywhere. This has been updated every 60 seconds into a MySQL database, along with a reverse-geocode lookup from the Google Maps API of the best possible postal address from latitude/longitude, an accuracy estimate (can be spot on with GPS, within 50 metres with wifi and city centre 3G coverage, and upwards of 2km in the countryside), and a timestamp. A couple of authorised PHP shell scripts do all the raw collection and storage operations. This then allows me create my own map of my location that I can play with, as well as offer minimaps of my ‘last 5 positions’ and anything else that might take my fancy.

For example on my location page now, I calculate the time I have been somewhere and also check my current location against a database of places I frequent on a regular basis and stay at for quite a while when I get to them. There are 9 entries in it. A short sample are my house, my girlfriend’s house, a couple of Starbucks that I go to regularly, and where I work. If it calculates I am within a permitted range of any place in that database table (each entry has a specific permitted range) and I’ve been there for more than a few minutes, it’ll “check me in” to that place and display precisely where I am. Once I begin moving again, it’ll check me out and begin the usual ‘roaming’ display once more.

If I ever get asked “To eliminate you from our murder enquiry, where were you at 5.33pm on the 2nd April 2011?” I can honestly say IKEA, Lakeside Retail Park, W Thurrock Way, Thurrock RM16 6, UK!

Some may question the logic of doing this – surely it’s invasion into my personal life? That may be so, but given any of my friends could ring me and say “Where are you?”, what’s the difference?

Getting around Three’s (3UK) ‘Porn’ Block

Mobile Phones 18 Responses »

Mar 072011

Anyone who has a cellular / mobile contract with Three / 3 / 3UK will have likely stumbled across their ‘porn’ block at some stage. Good goal in theory, except it doesn’t just block porn. I’ve had some really random websites blocked because of it. There is a workaround that you can use (depending on your handset I’ll leave you to figure out the specifics), but the jist is quite simple:

Create a new APN and call it ‘3 Routed’ or something. The name is irrelevant.

APN: 3internet
Proxy: <not set>
Port: <not set>
Username: <not set>
Password: <not set>
Server: <not set>
MMSC: http://mms.um.three.co.uk:10021/mmsc
MMS Proxy: mms.three.co.uk
MMS port: 8799
MMS Protocol: WAP 2.0
MCC: 234
MNC: 20
Authentication Type: <not set>
APN Type: *

Save this, and activate it as your active APN. This will temporarily disconnect your data connection and renegotiate a new one. It will give you handset a public routed IP address (minor security issue), break sending and receiving of multimedia messages (MMS). But, it will give you unrestricted, unfiltered internet access. When you’ve finished, simply switch back to your other original APN to restore normality for everything else.

Simple!

Photography in Brighton

Photography No Responses »

Mar 012011

Since moving to Brighton at the end of last year, I’ve been taking photos of my new City. Brighton and Hove is one of the more photogenic cities that I’ve visited; the buildings, people and features are incredibly diverse and open to so much interpretation that can be well-captured in photography.

I post maybe 0.1% of the photos I take to Facebook. 50% ends up in my Picasa Galleries, and the other 50% are either just interesting to me, or are not quite good enough to publish. Either way, that other 50% sits on my computer alone. The absolute best of the best and of potential public interest get posted on my photoblog Sussex in Focus. I’ve set up a page on this blog that lists all the different places you can find my ‘work’.

Click any for a full-size image..