Category: GPS

Guided?

Here’s something interesting. Andrew Krepinevich is quoted by the AOL News (!) blog criticising various aspects of US strategy, which is what he does. But this quote popped out of the background for me:

“The American military is losing some critical sources of advantage that it’s enjoyed over the last twenty years. One is the near monopoly we’ve had in precision guided weaponry,” he said. Not only are China and Iran investing in precision, he said, but even the terrorists who struck the US consulate in Benghazi may have used precision-guided mortar rounds…

May they really? If so, I think that’s the first confirmed use of guided indirect fire weapons against a US or “western” target, certainly by a nonstate actor, and a moment of some historic significance. Also, it’s Libya, which is currently leaking weapons in all directions. So if someone either has a supply of these rounds, or else an operation producing them, I wouldn’t be at all surprised if they appear elsewhere soon.

That would include Syria and also Palestine, which makes it time to unfreeze this post out of the carbonite. Bill Clinton had a damn good point there.

GPS receivers available in commerce are restricted, via the CoCom export control machinery, to functioning below 60,000 feet altitude and at less than 1,000 knots ground speed. This is precisely intended to stop people building their own ballistic missile guidance systems, and greatly annoys amateur high altitude balloonists.

In practice, as JGC points out, some manufacturers implement this as an AND and some as an OR, but overall it functions as a restriction on the range of such a device. 1,000 knots is 514m/s. Assuming a 45 degree launch, that would give a maximum altitude of 22,000 feet, well within the restriction, and a range of 27km/16.7 miles with a time of flight of 74 seconds. For example, one of the Fajr-5s the Iranians claim they supplied to Hamas, or taught Hamas how to make would be out of court on both counts. Of course, it’s more likely that guidance would operate after the rocket burned out.

Commenting on ARML 2.0

You may remember my brief involvement with AR standardisation (the annotated whiteboards are here). As a result I’m on the mailing list for various things, and the Open Geospatial RFC for the ARML 2.0 spec just dropped. Being on a plane, I got around to reading it. I have comments.

Back in Barca, in order to “simplicate and add lightness”, I wanted to make the point that fieldnaming and typing more important than anglebracket jihad (there was a row about HTML or JSON style), to make sure relative coordinates were a possibility, as I thought they would be really important for industrial applications and I’d just been bitching at Dirk from Layar about this. I’m very pleased to see that relative location made it into the spec.

I also think it’s important to have simultaneous, intermixed display – this fits with the (usually) urban environment these things are used in, and map overlays are a powerful pattern. This brings problems, though.

The ARML spec

I was a strong advocate for markup, but I’m really not sure about this. It’s a bit of a mess of HTML and object oriented concepts. I challenge anyone to try explaining a “trackable” to an intelligent programmer, and recommend you don’t try explaining it to your dad.

Reading through, I jotted various points.

What should the internal context of the browser, equivalent to DOM, be like?

Are we representing the AR content internally as several independent objects (like browser tabs) containing placemarks, or are we representing all the placemarks currently loaded in a common context, or are we keeping them in a store and then lazyloading them into the display?

is the current composed scene several “pages” overlaid, or one metaclass of objects from multiple sources?

“Composed scene” is the AR term-of-art for the subset of all the currently loaded content that’s visible in the current view. This led me to the next point:

HTML thinks of everything as a document

We definitely don’t look at documents, or Web pages, like this. You don’t have multiple tabs overlaid on each other, with elements selectively hidden. HTML is a fundamentally textual medium, AR things just…aren’t. This raises an interesting point.

should different AR things be able to see each other?

OK, what if I wanted to show some object, depending on the presence of another object? Or if I wanted to track an AR object and use that as a reference to place another? I can’t think of any reason why I shouldn’t be able to do that within my own page/application/whatever one of these is called. It might be cool to be able to do things based on the content of other pages, but I can see why having a same-domain policy would be valuable (you don’t want RandomApp smearing dogshit all over FindYourHSBC).

Should objects change state because some sort of conditional was passed to the browser when they were created, or because scripts tell them?

At the moment, you can have an “enabled=” property on an ARML object that determines if it is shown or not. You can also have a script show or hide objects, or even create them ex novo, based on its program logic. I think we ought to decide how much logic should be in the supposedly structural ARML and the browser, and how much in scripting.

What about audio, and, and…

The spec sort-of deals with the possibility that you might want to show things based on sound, or on conditions that aren’t locations in general. But I don’t think it provides a convincing starting point for this.

Probably best not lazyload data

It often suggests that content ought to be pulled over the network as late as possible. But I think this is wrong. We’ve got lots of RAM! We’ve got fast radio air interfaces! But our radio networks like interactions that crank up to linerate, and are then finished. Mobile networks are stressed more by signalling than by traffic, and that’s driven by setup/teardown. Chatty is the enemy. Further, the other big constraint in mobility is battery, and that’s driven by how long the radio is active.

If you must be chatty, hold open a data connection. Don’t do endless setup/teardowns.
Positive suggestions

Rather than hiding stuff, creating various kinds of basic registration objects, etc, what about this simple point? Registration is a conditional statement. IF we are within LoD range of point(x,y,z) THEN show this. Therefore, all the ARML anchors are conditionals. It doesn’t matter if it’s a WGS84, a range/bearing/elevation, a noise, a camera recognition, a QR, a smell…or importantly a combination of these.

We might want to work with other objects in the app. We might want to work with objects from other apps in the current scene. We are very likely to want to show content on the basis of program logic, though, and of course, even a simple placemark is shown because a conditional statement is evaluated and an event fired. So all an anchor should be is a named conditional. Rather than “trackables” and such, we have anchors which bind an object to an event, covering all kinds of location, audio, etc.

No, this isn’t terribly webby, but then most advanced Web apps aren’t either. Google Maps isn’t much like rfceditor.org. But the wonderfulness of the www comes from links, view source, REST, openness. There’s no reason we can’t have those! but we don’t need to have hellish app syntax either.

And I think the big meta-question here is “is it an app or a page?”

RQ-170 upshot, part 2: the bubble

Is there a drone bubble? It’s not clear whether this is more like the .com bubble, when a lot of useful stuff was built but a couple of years too early, or more like the housing bubble, when a lot of stuff was built in the wrong places to the wrong standards at the wrong prices and will probably never be worth much. It’s the nature of a bubble, of course, that it’s precisely at the top of the bubble that the commitment to it is greatest.

One of the things the RQ-170 incident tells us about is some of the operational limitations of the drones. Typically, they are piloted in the cruise from locations that may be a long way off, using satellite communication links, but when they land, they do so under local control via line-of-sight radio link from their base. This allows us to set some bounds on how much of a problem link latency really is, which will take us circling back to John Robb’s South Korean gamers.

Gamers are famous for being obsessed with ping-times – the measurement of round-trip latency on the Internet – because it’s really, really annoying to see the other guy on your screen, go to zap’em, and get zapped yourself because it took longer for your zap to cross the Internet than theirs. Typically you can expect 40 or so milliseconds nationally, 60-80 inter-continentally…or several hundred if a satellite or an old-school cellular operator with a hierarchical network architecture is involved. A sat hop is always clearly identifiable in traceroute output because latency goes to several hundred ms, and there’s a great RIPE NCC paper on using the variations in latency over a year to identify the satellite’s geosynchronous (rather than geostationary) orbit as the slant-range changes.

On the other hand, roundtrip latency across an airfield circuit a couple of miles wide will be negligible. So we can conclude that tolerable latency for manoeuvring, as opposed to cruising, is very little. Now, check out this post on David Cenciotti’s blog from January 2010. Some of the Israeli air force’s F-15s have received a new communications radio suite specifically for controlling UAVs.

You might now be able to guess why even drone pilots are going through basic flight training. Also, this post of Cenciotti’s describes the causes of six recent hull losses, all of which are classic airmanship accidents – the sort of thing pilot training is designed to teach you to avoid.

That said, why did all those drones get built? The original, 1980s UAV concepts were usually about the fact that there was no pilot and therefore the craft could be treated as expendable, usually in order to gain intelligence on the (presumably) Soviet enemy’s air defences by acting as a ferret aircraft, forcing them to switch on the radars so the drone could identify them. But that’s not what they’ve been doing all these years.

The main reason for using them has been that they are lightweight and have long endurance. This is obviously important from an intelligence gathering perspective, whether you’re thinking of over-watching road convoys or of assassinating suspected terrorists (and there are strong arguments against that, as Joshua Foust points out). In fact, long endurance and good sensors are so important that there are even so-called manned drones – diesel-engined, piloted light aircraft stuffed with sensors, with the special feature that they fly with intelligence specialists aboard and provide a much faster turn-around of information for the army.

Their limitations – restricted manoeuvre, limited speed and payload, and high dependence on communications infrastructure – haven’t really been important because they have been operating in places and against enemies who don’t have an air force or ground-based air defences and don’t have an electronic warfare capability either. Where the enemy have had man-portable SAMs available, as sometimes in Iraq, they have chosen to save them for transport aircraft and the chance of killing Americans, which makes sense if anti-aircraft weapons are scarce (and surely, the fact of their scarcity has to be one of the major unreported news stories of the decade).

But then, the war in Iraq is meant to be over even if the drones are still landing in Kurdistan, and the US may be on its way to a “pre-1990″ military posture in the Gulf. This week’s strategic fashion is “Air-Sea Battle” and the Pacific, and nobody expects anything but the most hostile possible environment in the air and in the electromagnetic spectrum. And the RQ-170 incident is surely a straw in the wind. Also, the Bush wars were fought in an environment of huge airfields in the desert, and the ASB planners expect that the capacity of US bases in Japan and Guam and the decks of aircraft carriers will be their key logistical constraint. (The Russians aren’t betting everything on them either.)

I think, therefore, it’s fair to suggest that a lot of big drones are going to end up in the AMARC stockpile. After the Americans’ last major counter-insurgency, of course, that’s what happened. The low-tech ones are likely to keep proliferating, though, whether as part of the Royal Engineers’ route clearance system or annoying the hell out of Japanese whalers or even playing with lego.

The RQ-170 hack and the drone bubble

The fact that a majority of this year’s graduates from USAF basic pilot training are assigned to drone squadrons has got quite a bit of play in the blogosphere. Here, via Jamie Kenny, John Robb (who may still be burying money for fear of Obama or may not) argues that the reason they still do an initial flight training course is so that the pilot-heavy USAF hierarchy can maintain its hold on the institution. He instead wants to recruit South Korean gamers, in his usual faintly trendy dad way. Jamie adds the snark and suggests setting up a call centre in Salford.

On the other hand, before Christmas, the Iranians caught an RQ-170 intelligence/reconnaissance drone. Although the RQ-170 is reportedly meant to be at least partly stealthy, numerous reports suggest that the CIA was using it among other things to get live video of suspected nuclear sites. This seems to be a very common use case for drones, which usually have a long endurance in the air and can be risked remaining over the target for hours on end, if the surveillance doesn’t have to be covert.

Obviously, live video means that a radio transmitter has to be active 100% of the time. It’s also been reported that one of the RQ-170’s main sensors is a synthetic-aperture radar. Just as obviously, using radar involves transmitting lots of radio energy.

It is possible to make a radio transmitter less obvious, for example by saving up information and sending it in infrequent bursts, and by making the transmissions as directional as possible, which also requires less power and reduces the zone in which it is possible to detect the transmission. However, the nature of the message governs its form. Live video can’t be burst-transmitted because it wouldn’t be live. Similarly, real-time control signalling for the drone itself has to be instant, although engineering telemetry and the like could be saved and sent later, or only sent on request. And the need to keep a directional antenna pointing precisely at the satellite sets limits on the drone’s manoeuvring. None of this really works for a mapping radar, though, which by definition needs to sweep a radio beam across its field of view.

Even if it was difficult to acquire it on radar, then, it would have been very possible to detect and track the RQ-170 passively, by listening to its radio emissions. And it would have been much easier to get a radar detection with the advantage of knowing where to look.

There has been a lot of speculation about how they then attacked it. The most likely scenario suggests that they jammed the command link, forcing the drone to follow a pre-programmed routine for what to do if the link is lost. It might, for example, be required to circle a given location and wait for instructions, or even to set a course for somewhere near home, hold, and wait for the ground station to acquire them in line-of-sight mode.

Either way, it would use GPS to find its way, and it seems likely that the Iranians broadcast a fake GPS signal for it. Clive “Scary Commenter” Robinson explains how to go about spoofing GPS in some detail in Bruce Schneier’s comments, and points out that the hardware involved is cheap and available.

Although the military version would require you to break the encryption in order to prepare your own GPS signal, it’s possible that the Iranians either jammed it and forced the drone to fall back on the civilian GPS signal, and spoofed that, or else picked up the real signal at the location they wanted to spoof and re-broadcast it somewhere else, an attack known as “meaconing” during the second world war when the RAF Y-Service did it to German radio navigation. We would now call it a replay attack with a fairly small time window. (In fact, it’s still called meaconing.) Because GPS is based on timing, there would be a limit to how far off course they could put it this way without either producing impossible data or messages that failed the crypto validation, but this is a question of degree.

It’s been suggested that Russian hackers have a valid exploit of the RSA cipher, although the credibility of this suggestion is unknown.

The last link is from Charlie Stross, who basically outlined a conceptual GPS-spoofing attack in my old Enetation comments back in 2006, as a way of subverting Alistair Darling’s national road-pricing scheme.

Anyway, whether they cracked the RSA key or forced a roll-back to the cleartext GPS signal or replayed the real GPS signal from somewhere else, I think we can all agree it was a pretty neat trick. But what is the upshot? In the next post, I’m going to have a go at that…

i haz bin in yr AR standardz, facilitatin yr interop. kthx!

So I had the opportunity to take part in an Augmented Reality standardisation meeting on the fringe of this year’s 3GSM Mobile World Congress. First of all, it was the year the heavens opened (someone on twitter said it was as if the show had turned into Glastonbury) and I got drenched and my shoes went bad, and my cab didn’t take me to the Telefonica R&D building in Via Augusta but instead to the main switching centre, this amazingly domineering building…

2011-02-17 13.07.09 Telcos – they live in places like this, they know where your dog goes to school, but can they tell you if it’s really your bank on the line?

So I got soaked again, and eventually arrived, and spent the first session listening to my shoes rotting. I acted as scribe for the session on AR browser implementations, markup language vs. JSON, native application vs. browser plugin and the like. I hope I contributed something of value. I have a Flickr set of the annotated flip charts here; I’ve been asked to help prepare the final report. Which just goes to show the enduring truth that if you want to influence something, wait until the very end and sum up with a balanced account. Supposedly this used to be the way to pass the Diplomatic Service exams – buy a pipe, puff on it occasionally during the team exercise, then “sum up with a balanced account”. But you’re not allowed to smoke these days.

2011-02-17 19.16.26

optimise your social isolation more efficiently

OK, back from eComm in Amsterdam; here’s something interesting. Besides all the stuff I was meant to be following for work, we had a presentation from a group of the sort of media-arts types who get a lot of coverage on Bruce Sterling’s blog; in fact the whole gig was faintly Beyond the Beyond-esque when it wasn’t Charlie Stross-esque. Notably, two projects struck me as emblematic of a certain kind of thinking.

The first one was the Isophone, which is a mashup of a flotation tank and a telephone. The idea is that you sink into yummy sensory deprivation while talking to someone else in the same condition; it looks like this.

the isophone, with user

Maybe it’s just me, but having to take phone calls under a state of total sensory deprivation is not my idea of fun. I couldn’t help imagining some sort of nightmarish prison call centre, a whole pool full of them.

Then there was Mutsugoto. Let the official description speak for itself.

Mutsugoto is meant to be installed in the bedrooms of two distant partners. You lay on your bed and wear a special touch-activated ring visible to a camera mounted above. A computer vision system tracks the movement of the ring and projects virtual pen strokes on your body. At the same time these pen strokes are transmitted to and projected on the body of your remote partner. If you follow your partner’s movements and your strokes cross, the lines will react with each other and reflect your synchrony. Special bed linens, silk curtains and other aspects of the physical context have been designed to enhance the mood of this romantic communication environment.

But what are the civilian applications? As they say.

Go on, this is basically a sex toy, isn't it?

Well, I think we can probably guess. Anyway, I found both of them depressing; it also struck me that too many of these projects are all about sucking information out of the virtual space and representing it on a piece of hardware in private space. Basically, a gadget that reads out Twitter feeds, that you’re meant to think is your friend. Further, once you get rid of the microphone, pointing device, keyboard, webcam, etc, you’re basically watching TV on your own. It’s read-only communication into the private realm.

The suit faction in this field, oddly, works the other way round – the M2M (Machine to Machine) community in telecoms, the big IT types, they’re all more interested in getting data from the real world and representing it in virtual space. Basically, it’s all SCADA applications – monitoring the current status of CO2 pipeline valve number 58634. Flowrate, direction, valve setting and temperature, please, and when did you last have your grease changed?

What seems to be missing from this as an artistic project is sending stuff into the public space. A lot of data gets captured from the public space into the private space; CCTV is one version, promoting your demo on Flickr and taking photos of the cops is another. Nothing much seems to be sent back, though; can’t we have truth-screamer robots that run about yelling out under-reported news? Of course, if you or I were to encounter one we’d probably dropkick it into a handy canal. Splosh; “Hey there! CitizenMediaBot is sinking!”

But it would at least be fun, and more fun than gazing at a waldo that turns puce when #drivel is trending again. I suspect there’s scope for this with things like Layar, who were also presenting. Then, we’re deep into the Strossosphere; “what do we want? Brains!” indeed.

Blogging Rugby League: while you’re playing it

Manly-Warringah RLFC’s successful trip to the UK in the last few weeks, which saw them beat Leeds for the World Club Challenge, was assisted by an interesting piece of technology. All the players have been wearing networked GPS data loggers during the games, so Statto gets a live feed of data on precisely where they move, how fast, and what they’re doing. And just how hard they go in; there’s a three axis accelerometer in there too. It’s the work of their conditioner Dean Robinson.

Aussie clubs have been very good with statistics for years; in the 1990s, the Brits were still very impressed with themselves for counting tackles while the Aussies were looking at how you could measure the energy battle and coach to tire the other side out. But this impresses even me.

Weirdly, in a sense their team is blogging all the time it’s playing. Discussion ensues, over here. They used to say that you can smoke while playing a game but not while playing a sport, but then, the legendary French fullback Puig-Aubert used to bum fags off the fans and he was in the French World Cup winning side of 1951. It’s probably true that you can blog while playing a game, etc, but as you can see, technological change is even getting rid of that distinction.

In a surveillance society, you can be a star blogger without even noticing.

FixMyS60

I’ve put my mobile version of FixMyStreet for Symbian S60 devices up on SourceForge at fixmys60.sourceforge.net. You can check out the source code from SourceForge’s subversion repository by doing “svn co https://fixmys60.svn.sourceforge.net/svnroot/fixmys60 fixmys60″ or whatever your client likes.

The current version requires GPS to work and sends the reports to Matthew Somerville’s test FMS server rather than the production one, for reasons that ought to be obvious. It’s written in Python and is released under the Eclipse licence because I think the Nokia Python modules are. To do: get the thing signed and packaged as a SISX file so we can actually test it out. Further, I need to extend it to cope with no-GPS situations, probably using something like geonames to convert addresses/postcodes to OS references, those to get map tiles from TilMa, and then having the user correct them in an embedded browser.

Nokia Software Distribution FAIL

OK, so I was feeling sufficiently foolish to try and install the all-new version of Python for Symbian S60 phones. Not least because of rumours that things like the Location API (i.e. “all the interesting or useful stuff”) have been liberated from the finger-waggy signing process…

Unfortunately, Nokia has shipped it without completing the same finger-waggy signing process it imposes on everyone else, so it fails on install with “Certificate error – contact the application supplier”. Nokia FAIL. So I have to explicitly disable the fancy security system in order to install software supplied by the system’s manufacturer. Not just that, but software which is open-source, so I can read the damn thing myself. Why can’t they get it right already? GAH.

So, turn off the certificate check, and it installs. Great. Time for a quick hello world from the interactive interpreter. But no…”Python runtime missing!” We’ve just installed the sodding thing.

So no, until someone gets a grip I won’t be the one to do the S60 version of FixMyStreet:-)

Organise, and a very wet 2600

So I took my stupid damn idea off to the stupid ideas club. When we got there, guess who? Spyblog was waiting at the rendezvous with some Dutchmen and an Argentine documentarist and half the No2ID members not currently in hospital. And after we made our way through Jock McZanu’s EU Maddie monsoon (GOOD HERE ISN’T IT???) to the pub, who shows up but Rat; carrying a total of 30GB of mass storage on his person in an array of USB drives, a fob GPS, and God knows what in his piercings.

Anyway, we talked over the thing, and many other things besides; what should happen if secret police become members? wouldn’t it be easier to do an open-source clone of a BMC helpdesk ticketing app? (why? why? I thought my brain would concrete) how would you sterilise an airport fingerprint reader in less than 10 seconds? So I promised to revise the proposals, and well, here they are.

Or would be, but nobody likes a 2,000 word blog post. So instead it’s here on Google Documents, which probably means something badological. Read. Mark. Learn. Inwardly digest. Comment. Here at first, but if you want to take part just tell me and I’ll give you write privileges. If anyone cares very much I’ll get it set up on Sourceforge and set about preparing a list of functions and tables. I still think Django is the way to go, in which case the mapping of the org model into Python classes into db tables should be as straightforward as these things ever are.