Why I don’t use GPS logging on my smart phone

This post is an adaptation of an email I was sending to someone who wrote to me to ask about doing what I do. I directed him to this previous post (What GPS to use) and started off clarifying a couple of things:

eTrex (on its own with no further letter) used to be a product that Garmin did. They now produce something called an eTrex H with a high-sensitivity chip. It’s their most basic model. They’ve been selling eTrexs for years. It works well but as I mention in that earlier post, it needs a proprietary cable. Here’s a link to a homebrew version in the blog if that’s up your street.

I don’t own an iPhone and probably never will, not agreeing with how they go about business. I do have an Android phone courtesy of the MRL that Soph and I are using for our mood reporting but because I have a GPS on me anyway from way before smart phones were around, I have little or no experience in this area. If anyone reading this has some experience using GPS applications with smart phones, I’d love to hear them.

Something that is important to me and that I would certainly bear in mind if I was to look at smart phone GPS logging apps is how it lets you keep your data if at all. I’d avoid anything that had some funky web application or internal viewer that was the only way to look at your tracks. Look for export of tracks in gpx format. It’s the most useful and translatable way of saving gps data (if a little verbose). There are plenty of good open source applications that handle gpx.

As to my comments about battery life and robustness. There’s nothing more disappointing than coming back from a hike and discovering that your iPhone ran out of battery a quarter of the way through. By robustness I mean an app that will not freeze or crash. The great thing about having a piece of technology that does only one thing is that it generally does not freeze or crash, especially if it is as basic as the Garmin eTrex.

On a technical level, I am a little dubious about smart-phone GPS logging apps because I increasingly care about how they arrive at position, what data they keep and what they throw away. Heaven knows this is already an issue in an eTrex, but a smart phone app developer can make many decisions that can have a large effect on your tracks. Snapping your track to a ‘known’ road could be one very undesirable intervention. Making overly crude assumptions about the speed you are moving is another that can adversely effect the shape of what you know you did. I know they do it to help iron out some difficulties in providing an accurate position but it is often not documented or made transparent. I would like minimum interference on this and clean up anything afterwards if necessary. (This is where Mathieu’s gps cleaning software will come in)

On the other hand, there is the adage-turned-iPhone-app that the best camera is the one you have with you. What I mean to say is that it might be good to have an app on your iPhone ready to go so that when you find that you’ve forgotten to pack your GPS, it can be a backup.

Posted in Diary, GPS | Tagged , , | 3 Comments

HP DraftPro EXL (7576A) Pen Plotter working

It’s been a long time waiting for me down the studio, but the other day, I managed to crack getting the plotter we bought on eBay for 40 Euros working.

At the moment, it’s under WindowsXP and through AutoCAD, which seemed to have the requisite drivers / translators. I tried installing the HPGL/2 driver and then realised that this plotter only understands HPGL, bless it.

I have had partial success under Linux using the python Chiplotle modules but I need to get my head round the margins / offset before I feel confident about publishing my findings here.

It’s so thrilling and beautiful to watch, though, reminds me of the first washing machine my family got and us all watching the first load it did like it was the most entertaining film we’d seen. I’m sure it will wear off, but I find it so thrilling to watch as it moves the paper and pen to make the marks. There’s something so embodied about the way it draws, it’s hard not to anthropomorphise it in some way.

Here’s the vid:

Posted in Diary, Linux, Python | Tagged , , , , , , , | Leave a comment

How to Georeference K5 Raster Maps from the Berlin Senat in QGis

I was lucky enough to get a present from the wonderfully generous Teri Rueb when she was in Berlin making an mscape project (those were the days) at the Akademie der Künste. Even though it’s out-of-date, I still like the funky old-fashioned state raster of Berlin with every apartment block numbered. Here’s the unhelpful page from the Berlin state: http://www.stadtentwicklung.berlin.de/service/veroeffentlichungen/de/karten/digital/extra/k5rd.shtml as an explanation why this explanation is necessary.

  1. I have halved the dimensions of the tiffs included on the CD and saved as gifs, but the process should be the same for the full size tiffs. Make sure you have the ‘uebersicht-K5′ image to refer to. This is your data source for georeferencing.
  2. Make sure you have the georeferencer plugin installed and enabled. Info here: http://gis-lab.info/qa/qgis-georef-new-eng.html
  3. Start a new project in QGis with ‘DHDN / Soldner Berlin – EPSG:3068′ as the Coordinate Reference system (CRS). You’ll find it in ‘Projected Coordinate Systems/Cassini’ or just search for the name
  4. Start the plugin (Plugins/Georeferencer) and click File/Open Raster (ctl+O)
  5. Browse to the image file from the Senat. This loads it into the big window in the georeferencer
  6. Zoom and pan to the top right-hand corner of the image and click Add Point
  7. Click as near as you can to the top-right hand corner (you can adjust later). A dialogue box comes up for you to enter the coordinates in.
  8. Find your image on the uebersicht image and read off the x coordinate of the left edge of the image e.g. 413B is x=24000. Repeat for top edge e.g. 413B:y=19600. Click OK
  9. The bottom pane now has the details of this point and this is where you can adjust. As this is the top left hand corner, the srcX and srcY values should be 0. If they aren’t, you can adjust them by clicking in the cell and typing them in. Use ‘Enter’ on the keyboard, not ‘Tab’ to make sure your changes stay (don’t know why and might change)
  10. Go to the bottom right hand corner and repeat the process. For 413B the values are x:27200, y:17200. Again, you might have to adjust the srcX and srcY values to whole numbers to make sure the point is really at the bottom right hand corner.
  11. You have enough information to include one more point. I choose the bottom left hand corner. Using a mixture of the coordinates already entered, you should be able to enter this without too much fuss.
  12. If you click the green triangle now (Start Georeferencing), a transformation settings dialogue box might come up. Leave Linear transformation and resampling on, no compression. Now comes the unintuitive bit: I want to leave my gif where it is and only create a world map but if you click world map, it asks for an output file name and the box is greyed out. The way around this is to first pretend you will produce a new image file by unselecting ‘Create World File’, enter the name of the file you already have loaded (pretend it is going to be a tiff), say ok to the file browser and then select ‘Create World File’. The georeferencer will then not complain about not knowing what to call the world file.
  13. Congratulations. You’ve done all that work but there’s still no raster file in QGis? Actually you’ve done something quite powerful and created a world file for that image no matter what Qgis you’re in. You should never have to georeference that raster again, unless you want to transform the image to another coordinate system (which is really what the georeferencer is all about). All you have to do is click Add Raster Layer, navigate to the IMAGE file you referenced (a .gif in my case) and say ok. Qgis will find the associated .wld file and pop it in.
  14. One last thing. Qgis might import new layers with something other than the project CRS, in which case, you have to double click on the layer you just added or right click/Properties and make sure, under the ‘General’ tab, that ‘EPSG:3068 – DHDN / Soldner Berlin’ is in the Coordinate reference system box.
  15. That’s it. Not very straightforward, but at least once you’ve done it for one project and you save the .wld file alongside the image file, you shouldn’t ever have to do it again.

Posted in Linux | Tagged , , , | Leave a comment

Hooray for Distributed Version Control. Boo for Dropbox

I’ve been having problems with Dropbox lately, not updating all files. I still haven’t got to the bottom of that but last night I worked on a Python script down our studio and wanted to polish it up at home but hey presto! It wasn’t there in the Dropbox – just the old version I’d renamed. Now it could be a problem with using Mercurial and Dropbox like I did (details follow) but I think that this morning I’ve solved it, thanks to this post.

What I used to do: Python scripts in the Dropbox under version control with Mercurial.
Now: I have my scripts locally and push/pull to a Mercurial repository only in the Dropbox. This means that there are no actual scripts in the Dropbox, just the magic .hg files from which you can clone everything.

The happy ending was that after creating an independent clone of my python scripts from the Dropbox folder (using the hg clone --pull option), my script from last night was all there, just as it should be.
Lesson learned.

Posted in Code, Diary, Linux, Software | Tagged , | Leave a comment

Digital Dowsing 0.1

It’s been around enough in my mind (actually since the Suffolk Psychogeophysics Summit [SPS]) to finally talk about it here. A mash-up of the esoteric and the technological – my nascent Digital Dowsing project.

My dowsing weapons of choice are two pieces of brass rod, bent at right-angles, held loosely in the hands. With me, they cross each other when I’m over something. I’m not so concerned with what it is that triggers them and I’m not so interested in the esoteric theories of how they work but it does seem to me that they are indicators of some subconscious impulse that most people have to fine-grained location. I also have experienced casual evidence of ‘agreement’ between people. This happened at the SPS when Ryan took them and seemed to find similar ‘findings’ as me. This happened again during Martin’s workshop in Tiergarten where an adult and his 6-year-old daughter had a go with the rods and seemed to find places that agreed with my findings.

What I want to do is build a(n Arduino?) datalogger that, in conjunction with an accurate, industry standard GPS (more of this in a future post), would log the movement of the rods and geolocate them on a map, enabling the results to be compared either between users or allow one user to build up a dowsing landscape over a certain area.

Perhaps unsurprisingly, I am not the first. Don’t put ‘Digital Dowsing’ into Google, that way lies madness. Here are some projects I found interesting

  • Here is someone who has given it a go on archaeological sites in England. Seems to be using the rod technique but frustratingly little technical detail.
  • This project from ISEA2008 in Singapore also seems very interesting. Uses the split stick method and an accelerometer. Elegant. But guys – is that datalogger really ‘small’? How accurate is that fob-style GPS around your neck?

My DD0.1 is to use the brass rods and try to digitise their movement with rotary encoder found in an old mouse. This seems better to me than the potentiometer method of rotary encoding which would put too much stiffness in the swing of the rods.

In my initial searches for hacking the mouse itself, I came across this excellent site as well as a page on the Arduino Playground site itself about interfacing a PS/2 mouse with an arduino.

Here’s a nicely annotated photo mostly for my own reference and hopefully anyone else out there who might need it:

Logitech Mouse Annotated

What the wires are on a Logitech Trackball PS/2 Mouse

Posted in Diary, GPS, Linux, Walking | Tagged , , | 3 Comments