Category Archives: Mobile

Hardware projects of the week

As an avid backer of quite a few interesting kickstarter projects, I have early access to a number of new technologies. Two projects in particular are Bluetooth LE based, which we believe will be a multi million dollar industry in the next couple of years, and one dealing with wearable computing, which is set to explode.

The first project that we would like to talk about is Spark (http://spark.io), which is a programmable networked core that can be made to report data from numerous sensors via HTTP. With the dev kit, we get a number of useful sensors out the box, as well as a high voltage relay to control appliances in your home via REST method calls. What this means, in a simple project, would be that you can turn on your coffee machine from your phone on the way home from work, and have a fresh pot brewed as you walk in the door. There are obviously numerous other applications, which we will be exploring in the coming weeks. Spark cores can also make use of an Arduino shield shield, which will allow you to add on any Arduino compatible shield to expand capabilities.

Next up, is the MetaWear dev board from MbientLabs. See https://www.mbientlab.com/ for more information. MetaWear is a tiny dev board that can be used to power wearable computing devices, and which reports back to your phone via Bluetooth LE. It can be used to quickly create fitness bands, or any other wearable device. It is also relatively inexpensive and has API’s for Android and iOS already, as well as a few sample apps. Metawear can make use of any I2C compliant add on so the applications are almost limitless!

The third product that we would like to bring your attention to is the PowerUp3.0 device. https://www.kickstarter.com/projects/393053146/powerup-30-smartphone-controlled-paper-airplane
This device is sold as a toy, and enables you to use a Bluetooth LE receiver with your phone to create a remote controlled paper aeroplane. The interesting portion of this device is that we can see many interesting applications with it, both as a toy and not!

Another Bluetooth device that we are currently working on, with the Raspberry Pi as a back end, will allow us to transmit data of all sorts via a cheap commodity Bluetooth transmitter. This is very similar in nature to an Apple iBeacon and we are imagining a world where these things are attached to billboards at busy traffic intersections. The user will be able t receive updates on entertainment schedules, interact with Sports games or download advertising clips with special offers while they wait in traffic. Utilizing a Wifi breakout, we can then also create networks of users and information at your fingertips!

Maven for Android

This is a quick howto on setting up and using Maven for your Android projects. Maven Android integration is not yet excellent, but is coming along nicely, and if you are familiar with Maven projects, will make managing your dependencies a lot easier!

I will be working with Ubuntu, but your set up will be similar. Just adapt paths etc for your setup as you need.

Ubuntu ships with Maven2, but we need Maven-3.0.5 at least in order to work with Android. I prefer to install maven manually because you don’t need to stress about pinning and other such nonsense from a binary distro. I also usually install stuff in /opt/ so that is where we will be working from.

The first thing that you need to do, is to grab the maven distribution file. I used 3.2.1, but anything later than 3.0.5 should work OK.

wget http://apache.saix.net/maven/maven-3/3.2.1/binaries/apache-maven-3.2.1-bin.tar.gz

Extract the archive and copy it to /opt/

sudo cp apache-maven-3.2.1 /opt/

Great! First steps completed! You are doing well so far!
I am assuming that you have a semi-recent JDK installed, in our case we need JDK 6+. Check for your JDK version with

java -version

If all comes back OK, we are ready to proceed.

Get the path to your JDK now with

locate bin/java | grep jdk

and make a note of it. Mine is at

/opt/java7/jdk1.7.0_45

Edit your bashrc file (located at /etc/bash.bashrc on Ubuntu) and add the following parameters (modify according to your paths) to the end of the file:

export ANDROID_HOME=/opt/android-sdk-linux
export M3_HOME=/opt/apache-maven-3.2.1
export M3=$M3_HOME/bin
export PATH=$M3:$PATH
export JAVA_HOME=/opt/java7/jdk1.7.0_45
export PATH=$JAVA_HOME/bin:$PATH:/opt/java7/jdk1.7.0_45

Load up your new basrc file with

source /etc/bash.bashrc

and check that everything is OK.
You should now be able to test your brand new Maven3 installation with

mvn -version

If that seems OK, you are ready to install the Android m2e connector in Eclipse. Please note that this works best in Eclipse Juno or later (I use Kepler).

Open up Eclipse, and choose to install software from the Eclipse Marketplace. This is found in Help -> Eclipse Marketplace. Do a search for “android m2e” and install the Android configurator for M2E 0.4.3 connector. It will go ahead and resolve some dependencies for you and install.

You should now be able to generate a new Android project in Eclipse with New Project -> Maven -> new Maven project and in the archetype selection, look only in the Android catalogue or filter on “de.akquinet.android.archetypes” and choose the android quickstart project.

If this fails, you can also generate a new project on the command line and simply import it to Eclipse.

mvn archetype:generate \
  -DarchetypeArtifactId=android-quickstart \
  -DarchetypeGroupId=de.akquinet.android.archetypes \
  -DarchetypeVersion=1.0.11 \
  -DgroupId=com.your.company \
  -DartifactId=myshinyapp

Once all of that is complete, dev carries on as usual. Remember that now dependencies are in your POM.xml document, so check that out first and ensure that you have some basics in there:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>com.your.company</groupId>
	<artifactId>myshinyapp</artifactId>
	<version>1.0-SNAPSHOT</version>
	<packaging>apk</packaging>
	<name>myshinyapp</name>

	<properties>
		<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
		<platform.version></platform.version>
		<android.plugin.version>3.6.0</android.plugin.version>
	</properties>

	<dependencies>
		<dependency>
			<groupId>com.google.android</groupId>
			<artifactId>android</artifactId>
			<version>4.1.1.4</version>
			<scope>provided</scope>
		</dependency>

		<dependency>
			<groupId>com.actionbarsherlock</groupId>
			<artifactId>actionbarsherlock</artifactId>
			<version>4.4.0</version>
		</dependency>

		<!-- Androlog is a logging and reporting library for Android -->
		<dependency>
			<groupId>de.akquinet.android.androlog</groupId>
			<artifactId>androlog</artifactId>
			<version>1.0.5</version>
		</dependency>

		<dependency>
			<groupId>junit</groupId>
			<artifactId>junit</artifactId>
			<version>4.10</version>
			<scope>provided</scope>
		</dependency>

		<dependency>
			<groupId>joda-time</groupId>
			<artifactId>joda-time</artifactId>
			<version>2.3</version>
		</dependency>

	</dependencies>
	<build>
		<finalName>${project.artifactId}</finalName>
		<pluginManagement>
			<plugins>
				<plugin>
					<groupId>com.jayway.maven.plugins.android.generation2</groupId>
					<artifactId>android-maven-plugin</artifactId>
					<version>${android.plugin.version}</version>
					<extensions>true</extensions>
				</plugin>
			</plugins>
		</pluginManagement>
		<plugins>
			<plugin>
				<groupId>com.jayway.maven.plugins.android.generation2</groupId>
				<artifactId>android-maven-plugin</artifactId>
				<configuration>
					<sdk>
						<platform>17</platform>
					</sdk>
				</configuration>
			</plugin>
		</plugins>
	</build>
</project>

As you can see, I have included some other stuff, like ActionBarSherlock and JodaTime in case, as they are generally really useful, and it may save you some time just copying the dependency information!

Have fun!

Using QEMU to emulate ARM devices

This post will show you how to set up a QEMU virtual device to play with your ARM code on an x86_64 host. It is quite simple, and you should be able to simply copy and paste into a terminal and get going relatively quickly.

As an example, we will be installing a debian build (wheezy) into your VM.

First off, we need to install the QEMU packages. I use Ubuntu/Mint, so this post will be somewhat biased towards that.

Let’s start off getting the packages we need:

sudo apt-get install qemu-kvm
sudo apt-get install qemu-system-arm
sudo apt-get install qemu-utils

Now we can check that everything is installed OK and ready to go with:

qemu -version

Make a directory to work with and then grab some files off your local debian mirror. Remember, we need the ARM based distro.

mkdir ~/arm-emul
cd ~/arm-emul
wget ftp://ftp.debian.org/debian/dists/wheezy/main/installer-armel/current/images/versatile/netboot/initrd.gz
wget ftp://ftp.debian.org/debian/dists/wheezy/main/installer-armel/current/images/versatile/netboot/vmlinuz-3.2.0-4-versatile

Remember now that depending on your board/device, you may want to check if it supports ARM EL or ARM HF. As you can probably guess from the above filenames, we are working with ARM EL. There are a number of differences between the way (and efficiency) of the two device types, but if you don’t know, then you are probably using an ARM EL device. Also, it is worth checking with your manufacturer if you haven’t built your device yourself, as ARM HF is a way better buy!

Let’s create a virtual HDD now to host the code/OS:

qemu-img create -f raw hda.img 8G

I like to create a drive as big as my devices flash ROM. In this case, it is 8GB. Yours may vary.

Now, lets get the system up and running:

qemu-system-arm -m 256 -M versatilepb -kernel ~/arm-emul/vmlinuz-3.2.0-4-versatile -initrd ~/arm-emul/initrd.gz -hda ~/arm-emul/hda.img -append “root=/dev/ram”

Should get you started with the Debian installer. Do the installation and then close your VM.

Once complete, mount your filesystem, and then copy the relevant files around. You need to do this step as debian will not be able to install the bootloader, so you kind of have to do it manually.

mkdir mount

sudo losetup /dev/loop0 hda.img
sudo kpartx -a /dev/loop0
sudo mount /dev/mapper/loop0p1 mount

cp ~/arm-emul/mount/boot/initrd.img-3.2.0-4-versatile ~/arm-emul/
sudo umount ~/arm-emul/mount

Now you can start up your brand new debian ARM VM with:

qemu-system-arm -M versatilepb -kernel ~/arm-emul/vmlinuz-3.2.0-4-versatile -initrd ~/arm-emul/initrd.img-3.2.0-4-versatile -hda ~/arm-emul/hda.img -append "root=/dev/sda1"

Great! Now off to make your custom OS and flash it to your board! Good luck!

ht_chromecast_nt_130724_16x9_992

Google Chromecast in a South African context

I had my Google Chromecast delivered from a local supplier last night, and thought that I would write a quick post on my experiences so far.

Seeing as though I have already had a large number of requests as to where I got it, I will answer that question first. I bought it from Takealot.com on the following URL http://www.takealot.com/tv-audio-video/google-chromecast-hdmi-streaming-media-player,29924636

Right, so the first thing that you need to do is plug the chromecast into a free HDMI port on your TV. Great. Easy enough. The box comes with an external power adapter as well as a USB adapter to power the device, but the external power plug is a US plug. Oops. Useless. USB power it is then! I would have liked to use the external power, simply for the fact that the TV does not have to be on for me to queue up online videos to the device, but alas, unless you are willing to screw around with clumsy power adapters and transformers, forget about it. The USB cable plugged into one of the TV USB slots and powered up the device without issue.

You are presented with a beautiful wallpaper and a device name, with the instruction to go and finish setup by connecting to your new Chromecast with an Android device or a laptop.

I tried to complete setup immediately with my Samsung Galaxy S4, having to download the Chromecast app from the Play store beforehand, which failed. I then tried to set up using my laptop computer, and was told by Google that I was using an unsupported OS (Linux), but I could try anyway. That failed too. Hum…

I then had a bit of an idea, and checked that uPnP was enabled on my (admittedly very old) wifi router, and enabled that. It would have been nice if that little caveat was covered in the intro screen, but it wasn’t. I use MAC address filtering to limit wifi access at home to specific devices, and one thing that I really did appreciate is that the Chromecast device displayed its MAC address on the setup page by default.

The setup, once started, becomes somewhat fiddly. My S4 has decided that a wifi connection is unworthy if it cannot reach the internet, and this was a big problem in completing the setup. I resorted to my laptop again, and managed to get through the steps after having to (confusingly) change wifi networks mid way to properly configure the device.

The device will not connect properly to anything but a 2.4GHz wifi network, so keep that in mind too.

I did have to do each of the steps a couple of times in order for the device to recognise my network and install itself properly, but once that was done, it was pretty plain sailing thereafter.

I immediately was able to stream a YouTube video to the TV in full HD without a glitch. The coolest part was that in the Chrome browser, I installed the Chromecast extension and was able to share not only a specific browser tab to the TV, but also my entire screen. There was some noticeable lag (about 500ms) when playing Kerbal Space Program via the network, but for a very graphics intensive app, and on a not-so-great wifi router, it was rather impressive (and still completely playable).

The apps that Google use to sell you the Chromecast (Netflix, Hulu etc.) are great, but not available in South Africa. Sure, I know that you can get a Netflix account (illegally) by spoofing a DNS service to make it look like you are in the US or UK, but the Chromecast has a trick up its sleeve. Google DNS services are hard coded into the device, so, even with a service like that, you would still need some trickery to get it right.

On the other hand, however, DStv BoxOffice works beautifully via a Chrome browser window, and you are able to enjoy the entire Online catalogue at R30 a movie, even if you are not a subscriber! To me, that is well worth the purchase price, as you are not entitled to pay a subscription, and you can rent when you want to. It is way cheaper for a family to grab a BoxOffice movie in this manner than it is to go to the cinema!

Overall, I think that the device is well worth getting (if you don’t already have an XBMC device or similar), although the price could come down a little in my opinion. There is a LOT of potential here, and I do think that we are only seeing the beginnings of something here for TV viewing.

The ultimate best awesome crazy cool killer feature of this device, though completely undocumented, is for people that do a lot of presentations. If you are a regular speaker, you will know that fiddling with projectors and screens on your laptop can quickly become a nightmare. I would suggest getting one of these things to pop into your laptop bag, and carry around with you. When you need to give a talk, simply plug it in and cast your presentation, saving a lot of time and stress!

I don’t normally do reviews like this, so I don’t really know how to end it off, but, yeah, get one of these things, they are OK tending towards good. In the future, depending on the climate, they may be awesome.

 

CORS in Python Bottle Framework

I was hacking up a quick mobile web app and needed to do an AJAX (jQuery based) POST and PUT to a simple Python Bottle REST server. Turn out that the AJAX POST was sending HTTP OPTIONS before the POST and the server was rejecting it with a 405. This, I find out, was due to a Cross Origin scripting issue and needed a solution.

Easiest way that I could come up with to fix the CORS (Cross Origin Resource Sharing) problem, was to write a simple bottle.py decorator that would enable me to do cross origin posts easily.

Firstly, the JQuery AJAX looked something like this on the client side:

$.ajax({
                            url: "http://host:port/save",
                            type: "POST",
                            data: JSON.stringify( { "mydata" : "Some stuff" } ),
                            contentType: "application/json",
                            success: function(data){
                                $("#result").html('got datal: ' + data);
                            },
                            error:function(error){
                                $("#result").html('There was an error while submitting: ' + error.message);
                            }
                    });

and the Python code looks like this:

# the decorator
def enable_cors(fn):
    def _enable_cors(*args, **kwargs):
        # set CORS headers
        response.headers['Access-Control-Allow-Origin'] = '*'
        response.headers['Access-Control-Allow-Methods'] = 'GET, POST, PUT, OPTIONS'
        response.headers['Access-Control-Allow-Headers'] = 'Origin, Accept, Content-Type, X-Requested-With, X-CSRF-Token'

        if bottle.request.method != 'OPTIONS':
            # actual request; reply with the actual response
            return fn(*args, **kwargs)

    return _enable_cors

You can then add the decorator to whatever of your @route methods that you need to enable CORS for with the simple @enable_cors annotation

@route('/save/', method=['OPTIONS', 'POST'])
@enable_cors
def save():
    # Rest of your code here...

Note that in the method I have set a list of the allowed methods, which include HTTP OPTIONS…

That is it! Javascript folks will tell you to rather do a $.post query, but I do prefer this method (I am more of a server side type of dude…)

There are, other ways to achieve this, but in my opinion, this is simplest and most elegant.

VoIP only phones

Reposted from old site – original date: Friday 13 January 2012

Not sure if this has been done or not, but this may be a pretty cool idea to steal.

Imagine an ultra cheap mobile device, in a phone handset form factor, that only does data based VoIP. Would be very cheap as you don’t really need to put much into it feature or component wise and could very well replace devices like walky talkies and things like that in rural areas (farms etc) and many other places.

Is it cheap enough to manufacture something like that? Would people rather have the features of an entry level phone?

Using mobile phones and data mashups for sustainable agriculture

Reposted from old site – original date: Friday 21 January 2011

I wrote an article about this a few years back, but would like to just put down some thoughts here too. @andyhadfield asked on twitter about ideas for sustainable development in rural areas in Africa using mobile/web/tech and reminded me of a set of ideas that I had.

1. Use mobile data to get remote sensing reports to subsistence farmers. Remote sensing data coupled with some simple GIS systems could easily be used to help subsistence farmers make the best use of their lands. With accurate data on things like chlorophyll flourescence, farmers can be informed of where to fertilise, irrigate etc without wastage. Chlorophyll flourescence can be used to quickly determine the overall health of a plant, and preventative measures can be quickly taken to rectify any problems. Data can be made available quite easily through simple text messages or in a more realtime scenario by XMPP push to the devices or kiosk internet stations.

2. Agriculture eLearning – eLearning systems (like the Chisimba eLearning system) can be used to provide basic HOWTO’s and techniques shared between farmers and experts from around the world. This is especially important for non-farmers like school feeding schemes, that could benefit from learning on their mobile phone how to grow vegetables for their communities etc.

3. eCommerce – I have posted quite a few examples of mobile based eCommerce, and again, it applies. You could quite easily use a phone based system to create marketplaces for goods like fruit and vegetables, as well as crafts and curios made locally. Payment can be made by mobile payment solutions or by a bartering system where goods are assigned virtual currency values for fairness.

4. Use local communities to build infrastructure – This was a result of another suggestion by @dazMSmith, but the mobile phone companies and others could contract locals to build cell towers and other infrastructure to boost local economies. Once connectivity is in place, more can happen (see above)

5. Deploy wireless networks with backhauls – using very cheap hardware, it is easy enough to deploy wireless zones over large areas of agricultural land. The advantage is that most will be line of sight, which makes for cheap and easy to build/maintain networks. IP phones, eLearning and eCommerce would follow quickly.

There you go. 5 simple ideas that could make a huge impact. All mobile, all do-able with minimal resources and effort. So what is stopping you?

The MXit API

Reposted from old site – original date: Friday 29 October 2010

So today I attended the launch of the MXit API. I was pretty excited about this one from the hype surrounding it mainly because there was a lot of talk of MXit finally “opening up” and creating an open API for anyone to use. Turns out that this is not really the case at all.

Firstly, as the launch event started, the audience was asked not to tweet anything without running it by the MXit folks first (you know in case they have to deal with more bad press), at which point I should have left, but didn’t.

The “API” as it turns out, is really an SDK. A Microsoft .Net C# SDK at that. There is no API (well not counting the standard XMPP “API” which we have been using for years anyway) at all, but a Windows DLL that contains an interface to the MXit currency functions (they call it Moola) and some basic messaging options. They have also introduced a simple markup language that allows some simple graphical elements to be cached client side for performance. The markup would be really useful IMO, but that seems to be secondary to MXit themselves.

Essentially the DLL is only useful to Microsoft Visual Studio coders as it uses the Net.TCP function to do the bidirectional API calls. That basically means that you cannot even hack this thing onto Mono and still use a Free Software stack to run your apps. There is a WCF service that runs on top of the API to handle the requests to handle the HTTP requests from client apps.

This could all have been achieved in a much easier way by sticking to pure old XMPP plus a basic API to handle some non-standard XMPP stanzas for the transactions etc. I do not know why they approached it in this way at all.

Basically the MXit API is Yet Another Walled Garden (YAWG) that I do not need to think about again.

For those that are interested in doing something with the “API” the approach would be:

1. They are very interested in games, so make a simple text based multiplayer game.
2. Get in real early. I suspect that the apps will quickly become saturated and lose novelty fast, so start coding immediately if you think that you may want to make money from this thing
3. Be aware that your revenue stream is based on MXit Moola, which means a Premium Rated SMS service via MXit. That means that for every Rand you charge your clients, you will get 50c

One vector that I can think of for one person to make an absolute fortune from this would be to buy the infrastructure and software and create an Open API around it for 3rd party devs to use. You will essentially become the middle middleman and create value for everyone in the world that does NOT want to fiddle with Windows DLL’s and such. You could then charge a small transaction fee on that service.

Overall, I was underwhelmed, but lunch was good, so thanks to MXit for that! We also got a goody bag(let) full of stickers and a cap, so I am sure my kids will have fun with those.

How to blog to your WordPress or Chisimba powered blog by mobile phone

Reposted from old site – original date: Saturday 9 October 2010

Most modern blogging software uses a standard for sharing posts called the MetaWebLog API. WordPress and Chisimba (www.chisimba.com) both use this standard to allow communications between blogs, both with posting of new content as well as editing and managing your posts with some pretty neat desktop utilities.

So far, however, this API hasn’t really been available as a mobile endpoint, which is why I decided to do something about that!

In South Africa mobile XMPP is pretty ubiquitious in the form of the really popular MXit application. MXit uses pretty standard XMPP stanzas to communicate with other XMPP services (like Google’s GTalk) which is compatible with the system.

In order to blog via your mobile phone, you will need an Instant Messaging (IM) client (like MXit) or simply use your desktop or web client that you would normally use for instant messaging. Steps are as follows:

1. Open up your client and add [email protected] as a contact

2. Register your blog by typing in register:yoururl.tld endpoint username password as a message. e.g. register:myblog.com /xmlrpc.php admin mypass. Remember that the username and password should be the details that you would normally use to log in to your blogging software to post a new article. For WordPress blogs the endpoint will be /xmlrpc.php and for Chisimba blogs, it will be /index.php?module=api

3. Once registered, you will get a message saying that you are now registered and are able to blog. Whenever the urge overcomes you, simply open up your mobile IM client and type a post. Posts are split into title and post content, so format it as title#content. e.g. This is my title#Some content that I would like to share with my readers…

That is it! Mobile blogging in 3 easy steps!
Thanks to @exmi and @dkeats on twitter for their help in testing!

Augmented reality, location based apps and what next?

Reposted from old site – original date: Thursday 16 September 2010

We are currently seeing a whole load of location based applications, especially in the mobile space, coming through, which is pretty cool. Many even include some aspects of Augmented Reality (AR) like compass applications coupled with some pretty decent linked data (like Wikipedia information about a building etc). All of this is great, for now, because the novelty will wear off real soon, so, we must start thinking about the next generation of these types of applications now.

What I would like to attempt (in my spare time of course, I have a day job), is to couple realtime sensor data from scientific sensors like water flow meters, water quality meters, thermometers, anemometers and other such sensors to augment phone built in sensors like accellerometers and GPS data to create realtime scientific apps that can be used in the field for research, and a little more than letting your friends know where you currently are.

Another avenue that I would like to explore, is to create marketing opportunities in hyperlocal areas with “Sale Mobs” or something. Borrowing from the Flash Mob concept, have retail outlets gather basic notifications about how many potential customers are in the area and have a sale that only lasts like 20 minutes or something. Could be fun and a pretty novel way of approaching it, although privacy issues may be encountered.

Another good way of looking at things may be to start working with activity streams that are generated by users. This means that as users move around and check in with coordinates, they will do something at each location. By analysing what people do while at a place at a time could also be used for engagements.

The best thing about using activity streams with users is that users can easily update information in real time. This makes for some cool stuff!

Some other applications could also include using thermometers and barometers (which the device manufacturers would have to agree to building in to the devices themselves) to gauge and monitor weather activity in a sort of real time mobile sensor grid. Extremely useful information indeed!

Disclaimer: I am a marine scientist by training, so I do have a slight bias towards scientific applications, but you get the idea right?