Recently Written

• Kiosk Browser Grows Up, Goes Pro
• Android App: Simple Kiosk Browser
• Widget, it’s got a widget…
• LinkUSB(i) and 1-Wire setup
• I am an IAMS cat
• LG TV Serial Control
• Tivo Return to UK Via Virgin Media
• Another Android Security Update
• Pictures from Computex 2009
• Pull That Squidgy iPhone application
• Extra Cupcake, Still No Latitude
• G1 Assault on battery
• Everywhere you go, always take the weather with you
• Pachube dials without the heartache
• Dynamic Dials Disclosed
• Gratifying Graphic Gizmos
• Current Cost Capers
• One Wireduino made easy
• WordPress tweetbacking
• What the UK VAT Reduction really means

Categories

• 1-Wire
• android
• arduino
• computex
• freerunner
• hardware
• image builds
• iphone
• kiosk
• learning
• linux
• neo 1973
• openmoko
• opensource
• personal
• software
• VoIP

Archives

• November 2011
• July 2011
• May 2011
• January 2011
• October 2010
• November 2009
• July 2009
• June 2009
• May 2009
• April 2009
• March 2009
• February 2009
• January 2009
• December 2008
• November 2008
• October 2008
• September 2008
• August 2008
• July 2008
• June 2008
• April 2008
• March 2008
• February 2008
• January 2008
• December 2007
• November 2007
• October 2007
• September 2007

Admin

• Log in

Search

Remember when I mentioned my tracking application for the TomTom Go? Well last night I found a little bit of spare time so I could port it to the Neo 1973. I say ‘port’, it wasn’t so much a port as a ripping out of the TomTom specific stuff and adding a little GTK interface. It’s not massively impressive to look at but it is actually my first GTK application. There is quite a bit of hard coded stuff in there at the moment but I do intend to move this to a config file. Currently, if the distance between the previous and current positions is below a certain threshold, a packet is not transmitted at all and position checks only occur at 15 second intervals. The data that is sent out is encrypted with a very simple algorithm, but I’m more interested in low cpu usage and speed at this point. I’m also going to be fairly honest about the state of the code at the moment, it’s not a pretty sight at all. I need to put together something on the server side to decode the packets, I know I have it somewhere, it’s just a matter of locating it.

I did wonder if the application should have an interface at all or if it should just run in the background, ‘secretly’ so that if someone stole your Neo you might actually be able to trace it.

The one thing that this did show me, however, is that you can’t actually run gllin for a particularly long time. I think it’s a minor fix but it does tend to fill up the free space on the Neo with its log data. I guess just disabling this might help, though I haven’t actually bothered to poke around with that just yet.

The other news is that to build this application I used the new toolchain and I have to say it makes life a whole lot easier. As a result I will also be building the toolchain at regular intervals and providing downloads via my buildhost. Sorry, but I can only build 32 bit versions at this time.

Tagged with: neo 1973 • openmoko • opensource • software • tracking
January 23, 2008 14:53

I’ll admit it, I’m a Volvo driver. I don’t care who knows it, I love my S80. Recently I decided that I could really do with a decent stash of music for my long trips that I’m making every couple of weeks between the UK and Netherlands. For the longest time I’d been struggling with getting CD’s out of their cases for the single cd, or fighting with the CD Changer jumping at the slightest bump. I finally caved in and purchased an IMIV unit so I could connect an iPod and control it from the stock Volvo head unit. So far it’s working really well, although I seem to have the knack of putting it into firmware upgrade mode. I’m going to email the developers to see if it’s possible to disable the headunit trigger of an update. I’m pretty sure I’m never going to upgrade while in motion which means I’ll have access to the physical unit to switch to update mode. The interesting thing about the IMIV is that you can get it to pretend to be various different devices, mine presents itself to the car as a Mini-disc changer and TV input. This means that I can still have the CD Changer working just by using the IMIV pass through port.

Itunes sucks as it is, but since I don’t use Macs or Windows it means I can’t use that for my music. It’s a bit of a blessing in reality. There are a number of applications for Linux which allow you to manage your iPod, in the end I went with the simple to use, opensource gnupod Perl scripts. The best part of these scripts is the ability to use regex for generating the playlists, something that’s very important with the IMIV.

The IMIV will only work with MELBUS (Mitsubishi Electronics Bus) based Volvo systems, newer Volvos (XC90, new model S40/V50/C70 and S80) use MOST which is apparently fiber optic based.

Tagged with: hardware • linux • opensource • software
January 19, 2008 20:47

I’d been planning to get myself, or at least persuade my wife get me, a tux droid which looks like an interesting piece of hardware to play with. The tux droid has is a wireless penguin which, for a change, only works with Linux. I’m pretty sure you could use cygwin or something if you were a Windows user, but I’m not so I don’t honestly care and obviously I haven’t actually tried it.

Sadly they appear to have just added 20 euro (an increase of nearly 25.5%) to the price for no apparent reason. I suspect they are just trying to cash in on Christmas – A pretty poor show if you ask me. So no Tux for me.

Tagged with: hardware • opensource
December 11, 2007 13:44

Lorn Potter from Trolltech dropped a note into the Openmoko community list to let everyone know that Qtopia can now use the fully GPL’d Cruxus media engine in their Qtopia builds. This is another step forward and away from Helix, which was basically holding Qtopia back in terms of a GPL phone stack. Now all I have to do is get it working properly, once it is I’ll be adding it to my builds. Stay tuned.

Tagged with: image builds • opensource • qtopia
November 30, 2007 10:52

Some time ago I wrote what I called the “Ramius” edition of my tracker application for the TomTom Go. The limitations of the Go SDK caused more than its fair share of grief and I shelved the project, hoping to revive it later. Now I’m thinking that it’s time to bring it back to life.

At the moment I’m selling my house in The Netherlands and moving back to the UK. Until the house sells I flit between the UK and Holland every couple of weeks. I’ve taken to using the Chunnel for this because it means I can drive through the night rather than have to bend to the ferry or flight schedules. The trouble is, my wife gets worried that I’m going to crash and burn. She does this every time I do the trip, in either direction. She wont go to bed until she knows that I’ve at least got to the Tunnel.

I brought the original code out of my archive and started looking at it, removing anything that was TomTom specific. I’m pretty sure that I’ll have a workable solution fairly soon, I may butcher the openmoko-agpsui2 application a bit too, just to add a face to the tracker application code. Obviously, it will need a network connection of some sort so I’ll be looking at starting and stopping a gprs connection, or using wifi when the GTA02 arrives.

On the topic of gprs and network connections, I was mulling over some points in my mind about this. Nobody wants their Neo to pull an iPhone, and give us all large bills because of roaming, so there needs to be some mechanism where the user can deny or allow access to things like gprs connections. These could be based on dates, times, even locations with the built in gps. The problem is not that it is difficult to do, the problem is that we need to be able to force applications to use an API to open gprs and wifi conections, and possibly even access the gps. There’s a whole kettle of fish here. Openmoko is opensource, not the Google kind of ‘opensouce’, the real kind. That in itself poses a few questions and perhaps some not so nice answers.

If we want to force people to use an API, then we have to make sure that they can only use the API and not bypass it. If they can bypass it, it’s useless because the malicious ‘l33t h4x0r’ is going to abuse your connection. The problem is, since we are opensource, the same abuser can simply replace the API. Sure you still have to install the application, but just think about it. Right now how many places do you update your Neo from with ipkg? If any one of those gets compromised or the owner deliberately alters packages, the first you’ll know of it is when you bill hits the mat with a thud rather than the usual ‘ftht’.

We can think about signed images or signed packages etc but that is not really going to help, this is opensource. As an application developer I’m going to want to publish applications, I don’t really want to have to get them certified or signed by someone else just so other people can use them. If you alert the user that an application or package is not signed, you know that they’ll just click ‘ok install it anyway’ and ignore it.

I think I’m going to have to ponder this one a little longer.

_{»crosslinked«}

Tagged with: api • google • gprs • neo 1973 • openmoko • opensource • tracking
November 21, 2007 14:49