N9 Development Blog

Playing around with NFC

So instead of continuing with the Pedometer, I started playing around with NFC.

NFC is part of the Connectivity API and actually pretty straight forward. But before I could start playing with the API I would need.. well, something else that actually supports NFC. I could have either went shopping for another mobile phone (not a cheap option), go for another NFC enabled device (Pokens seem like a good and cheap option) or use a NFC tag. In the end I ordered some tags at the Nokia NFC hub.

They arrived a couple of days later in a cute package that actually contained another NFC tag which pointed to the NFC Hub Facebook page.

While playing with the tags I found that the NFC Tag Writer (Source can be found here) was a great help as it (quick and dirty) integrates pretty much everything you would want to do with a tag.

The tags ordered from NFC Hub worked pretty much as expected: they contained a shorted link that takes you to the platform, which in turn redirects you to the URL you specified when ordering the tag (or afterwards in the web interface). The tags themselves were fixed and not writable anymore.

Interestingly the tag in the envelope was not fixed and I was able to write data to it. Thanks, Nokia!

It seems to me the connect / data transfer is kinda slow but so far NFC is a lot of fun to play with. It has a lot of potential - once there ar emore handsets supporting it. For now it’s a funny distraction :)

Pedometer, Step 1

As said I started out with gathering some raw data from the accelerometer and tried to make sense of it. I simply wrote a small app that was based on the accelerometer test and wrote all data to a text file.

I then took the text file and used Excel to plot some nice graphs.

The problems with writing a pedometer plain and simply are as follows:

• The phone can be anywhere while walking: in your hand, your pocket, your bag, pointing in any direction, so the movement could be in any given direction
• We don’t walk nearly as constant as we think, there are huge deviations between steps

The data pretty much reflected that. To solve the first problem I checked how much the phone actually moved.

    var dot = ( reading.x * reading.x ) +
    ( reading.y * reading.y ) + 
    ( reading.z * reading.z );

Then I took this number and compared it to the last data point. This could be positive or negative depending on the general movement direction of the phone (the actual direction doesn’t matter). Next I normalized the resulting value over time as the data points do not come in constant intervals.

    var dotDelta = 
      ( Globals.dot[ (Globals.dot.length - 1) ] - 
      Globals.dot[ (Globals.dot.length - 2) ] );
    
    var timeDelta = 
      ( Globals.timestamp[ (Globals.timestamp.length - 1) ] - 
      Globals.timestamp[ (Globals.timestamp.length - 2) ] );

    var dotOverTime = (dotDelta / timeDelta) * 100;

The result is a nice mapping of the actual movement as a wave period.

The blue line is the result of the calculations (dotOverTime). The red line shows when a step was recognized. As you can see it pretty much adds up.

What I did was check for the peak amplitudes and use them to set a flag. When the values oscillated between two peak points I added a step.

To get rid of some little quirks I only recognized a step if the wave period took longer than 250ms. Finally I only started counting steps if more than three steps are recognized in a short period of time.

So all in all this works pretty good. However there is the slight problem that the sensor data is not available when the display is off / the device is in locked mode. Even when asking as a daemon the sensors do not send signals. Strangely they also don’t report any state change when going in locked mode.

However there seems to be a way as the Pedometer app in the Nokia Store still works when the device is locked. So the question now is: how does it do that?

Next project set

I guess I’ll do a Pedometer as the next project. There already is one in the Nokia Store, but judging from the one comment it doesn’t work well.

Overall I hope it will be a fun project as building a pedometer that works (= counts) correctly is quite a challenge. My goal is to work a bit more with backend logic as enQRy was mostly frontend stuff.

I already found some basic information that should help me find the right algorithms. But first I’ll start with a simple application that writes raw accelerometer data to a log and walk around a bit to see if the collected data makes any sense.

enQRy is done

So, enQRy works and is stable. Also, as Nokia published MeeScan I don’t see any reason why I should continue working on it :)

As a result I decided I should just include enQRy into the Google Code project for this blog so that others can take a look at the code and learn or improve it. The download page also contains the .deb file for your convenience.

I also created a project page at n9-apps.com.

The remaining question would be: what’s my next project? Any ideas?

enQRy Beta

I discovered there was no QR code reader in the store available for the N9. So I started working on one to have a little goal while experimenting with MeeGo.

Ladies and Gentlemen: enQRy - a QR code reader for MeeGo.

I used the online decoder of ZXing so basically I’m just taking an image from the camera, push it to the webservice and read out the response. I could have used ZXing locally, but adapting the (incomplete) C++ libs to work with MeeGo was too much of a hassle for this little project. Especially as I wanted to focus on learning MeeGo.

There’s still some work to do, but so far enQRy works pretty well as a reader. I’m still not sure what to do with the app, though.

Harmattan-style Font

If you are also wondering why the default “Hello World” Harmattan project uses a different font as all the preinstalled apps, this will help you:

// Use for headlines
font.family: "Nokia Pure Text Light"

// Use for regular text
font.family: "Nokia Pure Text"

Harmattan Transitions

So if I got this right, in generic QML you’d have to build your own transition layout. At first I didn’t really understand why the meetmeego tutorial added the confirmation dialog right outside the bounds of the visible area, just to pop it in when needed. Instead I changed it so that only the visible propoerty changed. What I didn’t get is that this seems to be the normal way of doing transitions in generic QML.

However since I’m concentrating on MeeGo / Harmattan development, I was more curious what the Harmattan UI would have to offer. Turns out, the magic is all done by PageStack.

The PageStack is pretty much a normal stack in the sense that you can push and pop items to it. The items in this case are individual QML pages. If you push one on top of the stack, the page will become visible via the normal system transition. If you pop the top page, it disappears with the usual system transition and the page below on the stack is shown. Simple, eh?

See the official documentation and examples here.

So I had a quick go. As usual I started with the Meego / Harmattan “Hello World” project. This time I removed the Label element and changed the button so that it would push a new QML page on the stack.

    Button{
        anchors.centerIn: parent

        text: qsTr("Click here!")
        onClicked: { pageStack.push(Qt.resolvedUrl("hello.qml")) }
    }

Of course I now need a “hello.qml” so I added it (right click on the project -> add file and choose QML). The content itself was pretty simple.

import QtQuick 1.1
import com.nokia.meego 1.0

Page {
    tools: commonTools

    Label {
        id: label
        anchors.centerIn: parent
        text: qsTr("Hello world!")
        visible: true
    }

    Button{
        anchors {
            horizontalCenter: parent.horizontalCenter
            top: label.bottom
            topMargin: 10
        }
        text: qsTr("Go back!")
        onClicked: { pageStack.pop() }
    }
}

Note the pageStack.pop() which removes the page from the stack. It will transition out and the last page will be visible again.

And there you go. Transitions with Harmattan. Simpler than I thought.

The code is checked into the n9development project on Google Code and also added as download.

Camera

Next thing I wanted to try was the camera. It looked pretty easy on paper: just add the camera element and a button and that’s pretty much it.

Again, just start with a new MeeGo / Harmattan project. I threw out the Label and added a rectangle that should contain the camera image.

    Rectangle {
        id : rctCameraUI
        color: "black"
        visible: true
        width: 460
        height: 460
        x: 10
        y: 10
        rotation: 90

Note the rotation of the element. Even if the orientation of the application is locked to portrait, the camera seems to be still in landscape mode. I didn’t find anything about setting the camera into portrait mode, so I just rotated the rectangle that displays the image.

Next up I added the camera element to the rectangle. I don’t really want to do something if the camera takes a picture, so the onImageCaptured event is empty.

        Camera {
            id: camCameraElement
            x: 0
            y: 0
            width: parent.width
            height: parent.height
            focus: visible //to receive focus and capture key events
            captureResolution : "460x460"

            flashMode: Camera.FlashAuto
            whiteBalanceMode: Camera.WhiteBalanceAuto
            exposureCompensation: 0

            onImageCaptured : {
            }
        }
    }

The original button from the new project is converted into the capture button.

    Button{
        anchors {
            horizontalCenter: parent.horizontalCenter
            top: rctCameraUI.bottom
            topMargin: 10
        }
        text: qsTr("Capture Image!")
        onClicked: camCameraElement.captureImage()
    }

And that’s really it. Of course the QEMU does not support camera simulation, so you have to deploy it to your phone to make it work.

The code is checked into the n9development project on Google Code and also added as download.