KLM In-flight media runs linux

Just a mention of a fact that may be well know, KLM’s in-flight media computers run linux, yay.  I saw one rebooting on somebody sitting in the next row, unfortunately it took some 5 minutes to (network-)boot showing the booting messages in framebuffer to the poor person.  The machines also get a little hot.  Apparently others have managed to record all of the boot process where you can see they run sshd and what not.  It would be a cool project to try to get console access with the keyboard on the back of the handset, the computer could then become more useful.

In other news USA is overrated.  Grassrootmapping.org’s wiki mentions 95 gallon trashbags that are good as helium-filled or hot air balloons, which I haven’t found in Europe in this size.  Turns out they’re also hardly available in the US.  (I happened to meet some GrassrootsMappers who came to the WhereCamp San Francisco last weekend over from New York, and we have flown a kite, a mylar helium balloon, we have tried shooting cameras into air with a big slingshot and even wondered about aerial photography with water rockets.  Kudos to the designer of the WhereCamp “Null Island” t-shirt)

The frozen pizzas are also not as good as I thought.  I have an old IRC friend from Florida who, for some reason, really likes the frozen pizzas like DiGiorno.  He’s worked as a chef in a pizzeria (in fact four different pizzerias) so it sounds like he knows what he says.  Having found all of the frozen pizza brands in Europe to be invariably tasteless and not showing any resemblance to actual pizza as I know it, I thought it was an american thing and set out on this research project to try various US frozen pizzas.  And they may be slightly better but, after a series of experiments, I haven’t found the difference to be so significant.  (..in case you’re in Europe and just have been wondering the same thing).

I’m happy to report though that 4G data connectivity is nice and, a result of my US trip, you can now use it from under linux with either of the USB modems offered by Verizon.

Temperature graphs from EXIF header

In case it’s interesting to anyone I generated simple graphs showing temperature change when sending a camera up in the air using the tags in the images.

These two are from a camera attached to my kite on different winter days.  You can see how the temperature decreases about 1C every 100m of altitude and the camera then gets warmer again while lowering the kite back to the ground (up to about -4C), nothing surprising in there.

(I was curious what the minimum was the camera would operate in since Li-ion and Li-poly batteries are known to perform poorly in sub-zero temperatures, most of the time giving less than 3V.  My Canon was showing “change batteries” all the time but then showed 65% again when warmed at home.)  Well, here’s a gnuplot graph from a near-space balloon flight, unfortunately with much fewer data points, where you can see that a Canon G11 still works in under -20C.

I extracted these temperatures from the headers of the images taken by the seven Google Android branded high-altitude balloons at Greg Klein’s hibal.org page, launched in November reaching over 100000ft. There are only 15 pictures on that page and they possibly come from different balloons as the seven balloons were launched over a period of 2 hours.  The page also mentions that the balloons had battery powered USB power supplies so that the cameras wouldn’t stop working in the cold of near-space, but that seems to be only for the GoPro ones and the phones, not the Canon G11 (the Canon models I’ve seen can’t even be powered fromUSB).  It’s curious how the graph doesn’t drop below -20C, possibly this is the sensor’s limitation and the temperature actually got much lower.

Update: I did the same with a few pictures from the Hollands Hoge Hogte project‘s near-space balloon launch of last August, which also featured a CHDK equipped camera.  Here the camera was in an insulated styrofoam box and it was the middle of summer so the payload was well protected from the cold.  It reached just below 100000 feet with minium temperature of 8C inside the box.  The graph is again suffering from only partial data, the few data points on the far right are from pictures taken by the camera as the box was floating in one of the Dutch bays just before recovery by a boat.

For some background, most programmable chips these days have a sensor of own temperature, an average cell phone probably has a number of them even if the phone doesn’t use or expose the measurement results in any way.  My old Palm PDA for example had an unused temperature sensor in the touchscreen controller that could be read when Linux was hacked onto the device.  The Canon cameras also measure their temperature and save the result in the images with 1 centigrade accuracy, at least when the CHDK open-source firmware is installed on them, (which seems very popular in many do-it-yourself projects like aerial photography and weather balloon launches).

FCOIII looking sad

This is my FPV camera after a 200m dive from the kite when the rig failed yesterday.
It fell on the roof of a Ferrari car-service (seen below from a photo camera which made it safely to the ground) and it kept recording/transmitting for another 30 minutes despite the twisted head joint and being covered in snow.

By the way I have selected some of the occasional interesting aerial shots taken by the camera as it’s making the vertical imagery or from a paraglider or airplane window or on other occasions, and collected in a picasa album here, though I now have a two months backlog of winter kite pics.

In other news last week groupon.com had an offer for sight-seeing flights over Warsaw in a two-seater ultra-light airplane for just about EUR20. I bought three coupons :)  They let you decide the route and altitude and buy additional kilometres for 50cent/km and I hope that will let me complete most of the free (as in freedom) orthoimagery map for my city, till now made with the kite or rc helicopter.

MediaLab Chrzelice and KAP

Three weeks ago I took part in the MediaLab Chrzelice aka. Culture 2.0 Camp, and didn’t have time to mention it here yet.  I wrote about it in some more detail at the OSM diaries here & here, but let me just say that it was lots of fun, and I’m also really satisfied with how the OpenStreetMapping part of the workshop turned out.  I was never really good at convincing people to do things, but at the workshop I had introduced the project to people who had never heard of OSM and they were immediately very eager to actually go out and start collecting data and then putting it onto the map as quickly as possible (specially since the village where this was held was a very blank spot), which was very satisfying to see.  The GPSes hadn’t arrived, and we didn’t manage to produce good aerial imagery, but trying to launch the balloon and then flying the kite was fun anyway (possibly educative? when something fails is it more educative or less educative?). Two people who had come from Warsaw like me signed up for re-trying the balloon launch some time in the coming weeks, using some new ideas we had. Also one of the concurrent workshops was the Arduido workshop led by Daniel Soltis of Tinker.it! London and I got an arduino kit as a gift. I had some ideas of things I’d like to do with an arduino board, the only problem is I’m truly clueless about low-level electronics (I’m definitely a software person), I can’t even solder properly, so whatever I do with it, I’ll need help making any use of it.

My friend and me had some more attempts at Kite Aerial Photography here in Warsaw after I was back and actually are starting to get some nice pictures although I still need to build a better rig for the camera and get more line (currently have 600 metres and that let us lift the camera to 450-500 metres above the ground).  The current rig was the “plastic bottle”-type (aka. pendulum type) just without the bottle, using just string and duct tape, and attached just about 3m below the kite.  The advantage is that you get pictures taken in all directions.  With a picavet-type rig they will be looking straight down but the swinging is greatly reduced, specially if the rig is attached some 20 metres below, and so you can get much better ground resolution even on not-as-sunny days, because the exposition times can be longer and ISO lower.  So possibly I’ll be attaching multiple cameras instead of one to cover more directions, or building/ordering one of the fancy RC rigs (but more likely just attaching three or four cameras if I can get them from somewhere).  I figured out how to do “interval photography” with a WebOS phone like the Palm Pre (without installing any App Store apps like the Time Lapse Maker for EUR1.99) and I’ll post my app here later — turns out making webOS apps is really simple, even if you’ve never made any you can make a time-lapse app in about 1h without using any SDK or documentation, when on a bus trip for example.

Also my early impression with the latest Canon cameras is that they are terribly bad and there can seriously be no other reason to buy one other than CHDK suport (although the really new ones are not supported anymore because the firmware blobs encryption has changed — particularly what the CHDK developers call the dancing bits sequence).  If you’re looking for a nice pocket camera with high ccd resolution, get a Casio for example (seems to be just starting in the pocket camera market), although not usable for KAP.  I was never very up-to-date with things like hardware specs and prices and benchmarks but now that I had to decide on a camera, I’m taking the opportunity to sound like I have a clue :)

For the next couple of weeks I will be super busy with a university project (I even took a week of vacations at work) and will resume my world dominationkite flying plans afterwards.  I’m also seriously considering RC drones, some of the cheaper ready-to-fly models are slightly cheaper than the bigger kites.  The problem with the kites is that to make a good photo-map suitable for mapping, covering the area size of Warsaw, I’d need to fly it in about 80 places in the city and while it’s fun, it’s also tiring, possibly risky (if you haven’t registered with air traffic control a week ahead) and very weather-dependent.  With drones these are all things yet to figure out as people are just starting to experiment as far as I see on the web.

BAP test flight 1

Our first attempt at Balloon Aerial Photography (or BAP) statistics:

one Canon CHDKed camera dead after landing in the water, a good amount of CO2 released into atmosphere. (The camera may still live when it dries.. the SD card works)

To be continued.

DRMed TV stream

For some time I’m living with a friend who now uses Linux on her computer, but mostly because she likes the idea of Linux, and also because the Ubuntu install breaks less often than the Windows Vista preinstalled on that computer, works faster etc., but not because she likes coding or digging in the intestines to customise things or make rare things work.  As a result every some time I’m asked to make this and that work. This week’s request was to enable her to watch a TV programme she likes, one that is aired on the TVN24 channel.  Since I don’t watch TV, she bought a three-day online subscription to TVN24 after she googled an Ubuntu forums post where someone had success watching TV on Ubuntu.  So it turns out the channel indeed can be watched online if you have a Microsoft DRM-enabled player.  Also it turns out that mplayer does support Microsoft DRM decoding using code borrowed from the FreeMe2 opensource DRM decoder.

That is, only if you have the DRM key, particularly the SID which is a 30 or so digit number and which seems to be unique to the TV channel or a group of songs or a movie if you buy it through one of the online services.  It’s as simple as passing -demux lavf -lavfdopts cryptokey=<The-SID>.  Apparently the SID doesn’t change very often so it would probably enable you to watch the TV beyond the subscription period, but that wasn’t my goal, I just need an open-source player. The activation or deactivation of the subscriptions are handled using some non-cryptographic methods (IOW security through obscurity only).  That means that the SID is well hidden in Windows when Windows Media Player downloads the DRM keys, and it seems the method of hiding it is different in each new version.  Windows Media Player also checks that you’re using the latest DRM version every time you download a new DRM license.  I’m not sure if the method of requesting and downloading the licenses also changes, I’d guess it changes less often or is completely standardised.  Unfortunately all software that I was able to find to extract the SID is based on reading the Windows key storage structures, registry etc. from disk (which change), rather than interpreting the network communications between the client and the server.  It seems the central place for all this software is the undrm.info website which has been pretty stagnant since 2008, so none of these programs work with the latest Windows Media Player anymore.

We restored the Windows Vista partition to a bootable state and launched the closed-source player there, but I have a tcpdump of all the communication that was happening between the client and the license server up to when it started playing.  The protocol (as of 2008) has been beautifully documented by Beale Screamer and it seems the dump contains all of the elements mentioned there.  I’d love to implement the algorithms from that documentation to try to calculate the SID, if I had a week of vacations on a desert island or was retired :)  But if anyone else has time to play with it and wants that achieve undying fame (or an undying subscription to the various TV channels), I’ll happily give you the TCP log, a sample encrypted fragment of the wmv stream, or give links to other places that use Ms DRM, and links to existing code and documentation.

Exporting javascript objects

gateway.py, the script that is part of my little ofono web-based client which I mentioned before, now lets its clients export their own objects as D-bus objects.  While not very practical, a full D-bus service can be written in javascript that way.  I added this capability mainly because ofono will now start using agent interfaces as part of its D-bus interface and other daemons, like connman and bluez, already have agents, so you need to be able to export an object to make a UI.

All other types of http requests remain as listed here.  The new (GET) requests are:

• /path/to/object/export/<n>/ObjectName[;Interface.MethodOrSignalName,<in_signature>[,<out_signature>][;…]] – This looks complex but it just creates a D-bus object with the given name (arbitrary string, used just internally), and a given list of members on given interfaces. Members list is ;-delimited, each member is a signal or a method depending on whether it has an out signature.  New calls with their parameters are sent to the client in replies to the “idle” request using the same syntax as for signals from remote objects.  In turn signals from exported objects are emitted using the same syntax as method calls on remote objects.
• /path/to/object/Interface.MethodName/return/[<value>[,…]] – Return a (possibly empty) tuple of values to a pending call sent in an “idle” request earlier.
• /path/to/object/Interface.MethodName/error/<string> – Return an exception / error constant to a pending call sent in an “idle” request earlier.

Certified

I took one more of those silly, but sometimes recognised, language exams, because my university let me do it for free due to some programme.  This one was in Turkish, and now I’m certified.  But because the exam was for the “A2” level, I think it’s fair to say I’m a certified Turkish non-speaker.  A2 really really means you can’t speak the language. (So what’s the point?)

I also have these certificates in Spanish and English  (both corresponding to level C2 according to wikipedia chart) that say that I can actually speak, and even teach the basics of these languages (but don’t worry.. I have not the slightest idea about teaching), and I guess these could be useful — but have never been useful so far.

Mostly done with Szczecin

In the last two months I spent quite a lot of time working on a data import into OpenStreetMap that has been a little different from most of the imports happening in the project.  I’m quite happy with the result but I’m also really happy to be done with in.

Most of Poland administrative institutions today are behind in the aspect of sharing information with others for common good, and information re-use (and in many other aspects).  This includes geospatial data and clinging on to it and always assuming there might be something secret in it, such as… I don’t know, really.  Obviously at some level there can be information protected by the privacy laws intermixed with geospatial data (parcel owners etc.), the other common case of spatial data that cannot be shared is the locations of protected species.  But most of the time none of this is concerned.

Then there are laws in place that mandate those institutions to take money for disclosing particular types of information, and only under rather restrictive licensing conditions (nothing that remotely resembles CC-By-SA).  But according to some people in the know, there are other laws in Poland that make most of this information classify as public information.  Theoretically those former laws take precedence over the public information related ones, but last I heard there’s some other legal complication, way above my level of understanding law (unfortunately), that in effect means there’s a conflict/inconsistency in that system.  What this means is that the institutions can assume either interpretation and they should be safe under the law.  But they will always assume the “closed” interpretation.

So looking at all the other places and “battles” that people in OpenStreetMap have with their local administrations, it seems that this is a common trace in Europe, with a slowly progressing change in the direction of openness.  But perhaps if you drew a little map of how “open” the institutions in different places are based on the number of data releases that happened, the area covered by Poland would mostly range between black and dark grey.  So it was a lucky strike that the city of Szczecin was happy to let us use all the information available through their GIS website, including for automatic processing.

Their website has bitmap layers with some pretty high quality data, and no vector data available directly.  This meant that it could be manually copied or some complex and rather hacky vectorisation could be attempted (obviously talking only about the data layers that were lacking in OpenStreetMap, not just everything — if you’ve done any OSMing, you know that some types of data are unlikely to be crowdsourced).  French mappers are trying to manually copy the national cadastre bitmap layer made available by their administration, but it seems like a very tedious work, which is unlikely to be finished soon.  So I tried to automate as much as possible of the vectorisation and I think in a big part it was a success.  Still quite a lot of manual work was left to be done.  Not a very interesting job, but not one that you can let some monkeys do for you either, because everything that could be automated has already been automated.  So I’m really happy that it’s mostly done now (import status page firefox only, and takes a while to load).  More details in Polish available in this post, but check out the mapsurfer screenshots and the tree density heat-map there.  Maybe I’ll have a lightning talk about it at the upcoming State Of the Map 2010.

We’ve contacted some other municipalities trying hard not to scare them with the modern terms like share-alike etc., and as expected they are reluctant, but there seem to be two more candidates right now, and the import process is better streamlined now, and it really could be quite straight forward if it was not for some little annoying properties of the way the Szczecin data was shared.

For the moment I have a long backlog of information surveyed in my own neighbourhood to put on the map.

Javascript to D-bus, can you hear me

(I guess I better post something here because it’s been a while.)  So over the last two weekends I made a simple oFono client in javascript, meaning that it’s browser-based or “web-based”.  To do that I needed a way to talk to D-bus over HTTP.  I’ll try to set up a demo instance of the client later but now I’ll just mention the HTTP to D-bus gateway.  Even though the whole thing is a hack, maybe the gateway will be useful to someone.  It’s also possible that there are already fifteen similar programs there, I’ve not really checked.

The idea is rather simple, it’s a 10 kilobyte python script called gateway.py and you can run it in some directory and it will run a primitive web server on a given port using python’s built-in http library, and will serve the files from the current directory and its subdirectories.  It also understands a couple of fake requests that enable web applications to talk to D-bus.  It connects to the system bus and relays messages to and from D-bus services using the following three types of (GET) requests:

• /path/to/object/Interface.Method(parameters) – This makes a regular D-bus call to a given method on a given interface of an object.  It’s synchronous and the HTTP response will contain the D-bus response written as JSON.  The D-bus types correspond very neatly to JSON types so the response is easy to use in javascript on the web.
• /path/to/object/Interface.Signal/subscribe/<n> – This subscribes the application to a given D-bus signal.  The applications identify themselves with a number (<n>), this can be any integer but it should be (reasonably) unique, for example it can be a random number generated when the application loads.
• /idle/<n> – This just waits for any signal that application <n> is interested in, to arrive.  The signal arguments are then sent to the client as JSON again, in the HTTP response.  This way the browser keeps a socket open to the server and signals are sent over it.

Here are some example calls to make it clearer, along with their return values:

• $ wget 'http://localhost:8000/modem01/VoiceCallManager.Dial("5555")' -O -
  '/modem01/voicecall01'

• $ wget 'http://localhost:8000/modem01/voicecall01/VoiceCall.GetProperties()' -O -
  { 'State': 'active', 'StartTime': '2010-06-01T02:16:34+0200', 'LineIdentification': '5555' }

• $ wget 'http://localhost:8000/modem01/Modem.PropertyChanged/subscribe/500' -O -
  null

It’s easy enough to make a little javascript class in your code to hide the http stuff away so you can make plain js calls and get the return values and have handlers called for the signals.  Also, obviously ajax doesn’t just sit waiting for a http response so your application doesn’t become synchronous in any way.

You’ll notice that the interface names are shortened to just the last part of the name.  Since the part before the dot is usually same as the service name, you can skip it and it’ll be added automatically.  So you can write either /org.ofono.ModemManager or just /ModemManager

To check out the repository do,

git clone http://openstreetmap.pl/balrog/webfono.git

It’s python 3 and uses the D-bus and glib bindings, so getting these dependencies installed may be a little challenge at this point.