• Category Archives Software
  • Cardio Grapher Beta

    As hinted at in my previous post, I’ve been working on an Android application in my spare time for the last month or so.

    As a result of me no longer being a student I can no longer go cycling so easily during the middle of the day when there is daylight and the roads are quieter. When winter has passed so I don’t end up cycling back in the dark (multiply the distance by the number of working days the journey would be in the dark for and take into account the fact it would be at rush hour and on busy roads and that’s quite a lot of risk to accumulate) I’ll get around this by cycling to and from work (I did a few times before winter set in). But for now I’ve bought a turbo trainer for my bike and have it set it up in my flat.

    Now, necessity is the mother of invention and as with many of the things I’ve built this was the case here; when cycling out on roads I’ve used Google My Tracks a lot (and even added a small feature at one point), but when inside it becomes a lot less useful – obviously all distance and speed data (derived from the GPS) become meaningless. Now, I could setup a standard magnet based cycle computer on the rear wheel, but even then the data are not so meaningful – knowing that you’re doing e.g. 20 mph when stationary doesn’t really give you any idea how you’d be doing out on roads. So heart rate really does become the metric of real interest.

    Of course there are numerous applications out there already that will connect to the Zephyr HxM (the Bluetooth heart rate monitoring strap I bought) – for example, My Tracks itself has support for a wide range of sensors – but the majority of them share the problem that displaying heart rate is only one the things they do and as such little emphasis is placed on doing things with that metric other than graphing it and giving the current value.

    Enter Cardio Grapher: While it doesn’t yet do that much more than the existing solutions, my intention with it (as you may guess from the name) is for it to solely work with heart rate data. As such, I intend over time to explore a number of ideas for metrics that can be used to gauge the quality of a workout and to track progress.

    Today I’ve released version 1.0, which I consider to be beta quality. The features:

    • Live graphs of your heart rate over the last 1, 10 and 120 minutes.
    • User specific heart rate training zones, helping you get the most you can from your training (based on formulae from http://www.machinehead-software.co.uk/bike/heart_rate/heart_rate_calculator.html).
    • Audio alerts when entering and exiting training zones.
    • Can be set to keep the phone’s screen on when in use.
    • Can be set to automatically switch the phone’s Bluetooth adapter off and on again when connecting to the HxM times out (this is a work around for a bug in the Bluetooth implementation on some phones).
    • Reports the remaining battery charge level of the HxM.

    View it on the Android market here: https://market.android.com/details?id=net.cardiographer

    Screenshots:

    Connecting Autoscaling Training zones Details About EULA Preferences Menu

  • Source Lines Of Code with Munin and SLOCCount

    Pretty much exactly a year ago I wrote a plugin for Munin that scrapes the current temperature in Cambridge as recorded by the University Computer Laboratory.

    The plugin is unlikely to be of much use to anyone else if used exactly as is, given that it only provides information for Cambridge. Posting the code here serves two purposes:

    1. It serves as a backup of the plugin for my own reference – full blown version control for snippets like this is overkill.
    2. Mutating something that already works to make it do what you want is often easier than writing something from scratch, so it may be of use to other Munin plugin developers just getting started.

    It doesn’t take any configuration, and has no comments – the code should be self explanatory:

    #!/bin/sh
    
    case $1 in
    config)
    cat <<'EOM'
    graph_title Cambridge Weather
    graph_args --base 1000 -l 0
    graph_vlabel Celsius
    graph_category sensors
    temperature.label Computer Laboratory
    EOM
    exit 0;;
    esac
    
    echo -n "temperature.value "
    wget http://www.cl.cam.ac.uk/research/dtg/weather/current-obs.txt \
    -O - 2> /dev/null | awk '/Temperature/ {print $2}'
    

    Installing this plugin is as simple as writing the above source to

    /usr/share/munin/plugins/weather

    and making a symbolic link to it in

    /etc/munin/plugins

    - not forgetting to restart munin-node having done so.

    The graphs can be viewed at penguin.piggott.me.uk.

    The temperature over the course of the last year, at the time of writing, follows:

    If you do happen to look around at the rest of the graphs at the above link, you’ll notice that all the others are currently looking very bare, and that the weather graph is missing a chunk of the last week. There are two reasons for this:

    1. I’ve recently migrated away from a fixed-price-per-month VDS (it was slightly overpowered in terms of CPU and underproviding in terms of disk capacity) to an Amazon EC2 micro instance, which is more flexible in terms of cost (but also seems to be fairly erratic in terms of performance, to the point that I’m having second thoughts). It wouldn’t have been very meaningful to migrate the server-specific statistics of one server over to another.
    2. In the process of developing my SLOCCount plugin, I managed to make a bit of a mess of the freshly installed Munin configuration on the new EC2 instance, and had to revert to a backup of the RRD file that I’d copied over from the previous VDS.

    Anyway, one year on and I’m just starting up a small side project for fun outside of work (which I will hopefully be making a post about soon), and as I don’t have a dissertation to write alongside it – which served well as a planning tool – I’m putting a bit of initial time in to setting up some tools like Trac for the project. As well as that, I thought it would be neat to have a graph of the number of lines of code over time as the project develops (this would have been interesting for my dissertation, but alas, I was – quite appropriately – focused only on the bits that really mattered; graphing lines of code is just a bit of fun).

    So, before allowing myself to do any more development on the project itself, I hacked up a quick and dirty Munin plugin that shows lines of code by language as stacked graphs:

    #!/bin/sh
    
    case $1 in
    config)
    printf "graph_title $PROJECT_NAME\n"
    printf "graph_args --base 1000 -l 0\n"
    printf "graph_vlabel Lines of code\n"
    printf "graph_category projects\n"
    sloccount $PROJECT_PATH 2>/dev/null | awk \
    'BEGIN{FS="[:]?[ ]*[(]?[%)]?"}; \
    /Totals grouped by language/ {resultLine=NR}; \
    /Total Physical Source Lines of Code/ {resultLine=0}; \
    resultLine>0 && NF==5 {print $1 "_lines.label " $1; \
    if(NR==resultLine+1) print $1 "_lines.draw AREA"; \
    else print $1 "_lines.draw STACK"}'
    exit 0;;
    esac
    
    sloccount $PROJECT_PATH 2>/dev/null | awk \
    'BEGIN{FS="[:]?[ ]*[(]?[%)]?"}; \
    /Totals grouped by language/ {resultLine=NR}; \
    /Total Physical Source Lines of Code/ {resultLine=0}; \
    resultLine>0 && NF==5 {print $1 "_lines.value " $2}'
    

    Because you may wish to run multiple instances of the plugin – e.g. if you have several distinct projects that you want code analysis running on – I suggest you write the above code to

    /usr/share/munin/plugins/sloccount

    and then make symbolic links of the form

    /etc/munin/plugins/sloccount_cardiographer

    The plugin does require configuration: the single entry I currently have in

    /etc/munin/plugin-conf.d/munin-node

    is:

    [sloccount_cardiographer]
    env.PROJECT_NAME Cardio Grapher
    env.PROJECT_PATH /home/dhpiggott/Workspace/CardioGrapher
    user dhpiggott
    

    With this configuration, the config output at the time of writing is:

    $ sudo munin-run sloccount_cardiographer config
    graph_title Cardio Grapher
    graph_args --base 1000 -l 0
    graph_vlabel Lines of code
    graph_category projects
    java_lines.label java
    java_lines.draw AREA
    xml_lines.label xml
    xml_lines.draw STACK
    

    and the value output is:

    java_lines.value 887
    xml_lines.value 37
    

    PROJECT_NAME and PROJECT_PATH do what they say on the tin. The user is a bit more interesting; sloccount tries to cache the results of its analysis to

    ~/.slocdata

    and fails if it can’t write this data. The directory it uses is configurable with

    --datadir

    but the point here is that Munin plugins by default run as the munin user and thus cannot write this slocdata. To make it work, configure the plugin to run as any user that will allow slocdata to be written to its home directory.

    Of course, the user will also need permission to read PROJECT_PATH and you will need to have SLOCCount installed.

    At the time of writing this post, the resulting graphs are pretty bare – as they would be. Here’s a snapshot anyway:

    References

    In creating this plugin I found the following resources useful. I won’t repeat the content to be found in them, except to say that if you’re struggling to grok awk, the key concept that everything else will follow from is the idea of patterns and actions (though I don’t claim to have grokked it!).


  • Inferring Transportation Mode using Smartphone Sensor Data

    Now that The End (of The Beginning) is complete, one of the various things that it is appropriate to do is to post a bit about my dissertation, which I had fleetingly mentioned in previous cycling posts.

    You can download a copy here: Inferring Transportation Mode using Smartphone Sensor Data (220)

    The inspiration and motivation behind the project was from the UROP I did last year summer. I had envisioned my Energy Meter application accounting for peoples’ day to day energy usage in three ways:

    1. Scanning QR codes that point to modified Atom feeds that contain cumulative energy consumption figures for regularly used “facilities”, for example, home and workplace HVAC systems. See the video below for a full description of this; I successfully prototyped it in the UROP.
    2. Scanning barcodes from consumable items (e.g. a ream of paper), using the barcode to look up the consumable in question in a crowd sourced database mapping consumable items to their embodied energy.
    3. Using GPS and accelerometer data on the smartphone to infer when the user is travelling, and what sort of vehicle (if any) they are using. This data, along with a record of their mileage for the trip (measured using the GPS) could then be used to calculate an estimate of the energy used and hence the carbon dioxide released as a result of the activity.

    As with so many projects, these goals turned out (as I had suspected) to be too much for one summer, and I settled for making a good go of the QR code system.

    Still keen to develop the system at the end of the summer, I decided to continue my work and develop the third metering approach. The dissertation investigates the use of sensors not tried  by other research (orientation, light level, magnetic field strength and GPS satellite data) as well as the more tried and tested accelerometer data and GPS location data. Within this scope, various features (ways of analysing the raw sensor data) for classification are compared.

    Part of doing this required that I construct a representative data-set for classifier training and evaluation purposes, which first of all meant creating Route Tracer [1] [2], an Android application which records accelerometer, GPS location, GPS satellite light level, magnetic field strength and orientation data, along with the (user supplied) transportation mode label to the SD card. I used this to collect (with the aid of volunteers) 3000+km (100 hours/200 journeys) of data spanning eight cities in four countries.

    Saying much more here would just mean repeating what I have said in the introduction and conclusion of the dissertation itself, so I’ll wrap up with two concluding paragraphs:

    “The accuracy of the best resulting classifier (recall of 97.8%) is very promising and it would really be good to develop a standalone Android application for personal transportation energy metering. Better yet would be to automate the personal transportation energy metering component of the Energy Meter application I created as part of my Undergraduate Research Opportunities Program (UROP).”

    “In addition to testing approaches from existing literature, I have been able to confirm my original hypotheses that magnetic field strength and GPS satellite information are useful data sources. Finally, I found that orientation sensor information is a strong data source.”

    The mark I received was 81.2/100, resulting in it being one of eight dissertations to be highly commended! Better yet is the fact that the organisers of the UROP projects have set somebody working this year to develop an Android application that uses the findings of my dissertation to further the energy metering work that started all of this.

    This is the presentation I gave at the end of my UROP last summer, explaining Energy Meter:

    You can also download the slides: Personal Energy Meter UROP Presentation Slides (94) (Note: the email address on the cover slide has now expired, and most of the URLs seen in the examples are no longer around).


  • How to make PulseAudio work with Nvidia HDMI audio outputs under Fedora and Ubuntu

    Posted on by Dave Comment

    Normally the sound setup for my machine consists of a pair of Wharfedale speakers and a Temple Audio Bantam XC2 amplifier. Due to the fact I’ll be returning home later this morning for my final Easter vacation, pretty much everything I have is packed up in boxes right now; the machine and screen remain on the desk, however. Driven by the desire to listen to music while I finished packing, I decided to get output over HDMI working (having had problems with it in Fedora [14] and Ubuntu [10.10] in the past). I have an iiyama monitor which has speakers built in and is connected to a GTX 470 graphics card by HDMI.

    The problem was that although the PulseAudio Volume Control applet (pavucontrol) showed the output (as “G100 High Definition Audio Controller (HDMI)”), when I redirected output streams to the device I simply heard no sound. As I didn’t have this problem under Windows I knew it was a software issue.

    After some more experimentation using aplay I figured out that the problem was due to PulseAudio outputting to the wrong HDMI subdevice. This I did by running aplay -l:

    [dhpiggott@panther ~]$ aplay -l
    **** List of PLAYBACK Hardware Devices ****
    card 0: Intel [HDA Intel], device 0: ALC889 Analog [ALC889 Analog]
    Subdevices: 0/1
    Subdevice #0: subdevice #0
    card 0: Intel [HDA Intel], device 1: ALC889 Digital [ALC889 Digital]
    Subdevices: 1/1
    Subdevice #0: subdevice #0
    card 1: NVidia [HDA NVidia], device 3: NVIDIA HDMI [NVIDIA HDMI]
    Subdevices: 1/1
    Subdevice #0: subdevice #0
    card 1: NVidia [HDA NVidia], device 7: NVIDIA HDMI [NVIDIA HDMI]
    Subdevices: 0/1
    Subdevice #0: subdevice #0
    card 1: NVidia [HDA NVidia], device 8: NVIDIA HDMI [NVIDIA HDMI]
    Subdevices: 1/1
    Subdevice #0: subdevice #0
    card 1: NVidia [HDA NVidia], device 9: NVIDIA HDMI [NVIDIA HDMI]
    Subdevices: 1/1
    Subdevice #0: subdevice #0
    

    I then tested out each subdevice to determine which actually produced sound:

    aplay -D hw:1,3 testsound.wav
    aplay -D hw:1,7 testsound.wav
    aplay -D hw:1,8 testsound.wav
    aplay -D hw:1,9 testsound.wav
    

    I found that 7, 8 and 9 would produce sound while 3 did not. Assuming the problem was that PulseAudio was using 3, I set about changing that:

    1. Open /etc/pulse/default.pa
    2. Find the line “load-module module-udev-detect” and comment it out with a #
    3. Paste in at the end of the file entries that will manually load the necessary modules for your hardware. In my case:
    load-module module-alsa-sink device=hw:1,7
    load-module module-alsa-sink device=hw:0,0 (necessary so I can also use the Wharfedale speakers, since it will no longer be autoloaded).

    Having done this a simple killall pulseaudio was enough to make things work; I could resume Spotify playback and then redirect it successfully to the iiyama speakers using pavucontrol. One problem that came about was that the volume hotkeys on my keyboard stopped having any effect on actual audio volume as they weren’t being mapped to the right sink. Before I got a chance to look into it more I’d had to reboot the machine to move some cables, and this turned out to be enough. Perhaps even just logging out and back in again would have been sufficient.

    Hopefully this guide will help a few people; I came across plenty of posts by people having the same problem when I Googled it but no solutions.

    Notes:
    1. The system I did this on is running Fedora 14. As such I haven’t actually tested the solution on Ubuntu 10.10, but I know that the same problem exists from when this machine ran Ubuntu.
    2. It may be necessary to unmute the HDMI output channels using alsamixer (press F6 when in alsamixer to change device, press m to toggle mute/unmute status).


  • A small contribution to My Tracks

    Following on from SO37-38, O4, I’ve gone and reimplemented the import from GPX functionality (which just exposes existing import functionality to the user) to My Tracks that I hacked into it for Return to Cambridge and yet more cycling (I needed it again because today’s nightly build of CyanogenMod 7 for the HTC Hero seems to have made GPS fixes very intermittent). It turns out that there was actually an issue posted requesting such functionality back in May last year, and so I decided I may as well do a proper job this time and get it merged into My Tracks rather than just hacking something together and deleting it once I’d used it. I’ve set up my own clone of My Tracks, pushed the change to it and posted a review request. Hopefully it will get merged in soon and make its way into a Market release!



  • dinamic_sidebar 4 none

©2012 piggott.me.uk Entries (RSS) and Comments (RSS)  Raindrops Theme