• Topping TP32 Class T amplifier & DAC

    Posted on by Dave Comment

    Back in January 2009 just after having acquired a pair of Wharfedale Diamond 9.1 speakers (plus floor stands) I purchased a Temple Audio Bantam XC class T amplifier (prior to using that I used a Technics SU-Z11 that was handed down to me – to this day it remains a very good amplifier, just not ideal for desktop use due to its bulk).

    For over three years the Bantam XC has served me very well, delivering brilliant sound for its price and size, and all with high efficiency (by way of explanation I refer you to http://en.wikipedia.org/wiki/Class_T_amplifier).

    I replaced it today with a Topping TP32. Below are some unboxing pictures, followed by a few comparison shots alongside the Bantam XC:

    So why have I replaced it with a Topping TP32?

    Well, the sound quality of the Bantam XC certainly wasn’t the issue. In fact I specifically sought a replacement based on the same Tripath TA2024 Class T driver IC so I could have some confidence that I wouldn’t be downgrading. In terms of sound the Topping TP32 shouldn’t be significantly different (and doesn’t seem to be).

    No, the reason for the change is more one of practicality. The simplest explanation is to list what the TP32 has/does that the XC didn’t:

    • IR remote control.
    • Auto fade-in on power on.
    • Built in Texas Instruments PCM2702 based USB DAC (again ideal because around the same time that I purchased the Bantam XC I built myself an Alien DAC which, yes, you guessed it, is based on the PCM2702 – so again I had an idea of what I would be getting in terms of sound quality) – as well as a theoretical sound quality improvement, the practical gain is that I can plug it into my USB hub thus reducing the number of cables I must connect/disconnect when switching between ‘desktop’ and laptop mode.
    • Auto power on/off based on USB host status (i.e. unplug it from your laptop and the amplifier switches off, plug it in and the amplifier switches on).
    • Digital volume control – aside from making the remote control and auto fade-in feasible (analog would be possible with a motor driven potentiometer, just not very practical), this is ideal because it won’t:
      • Wear out over time (as is really starting to show with the Technics SU-Z11 I referred to earlier)
      • Be unbalanced down at low volumes as the Bantam XC was (the right was louder than the left at very low levels)
    • Independent speaker/headphone output control – the XC lacked this; with headphones plugged in the speakers were off and I have a pair of headphones (Audio Technica ATH-ES7s with custom cable) that I use primarily for stationary listening that I’d have liked to be able to just leave plugged in all the time and use a separate switch – with the TP32 I can leave the headphones plugged in and switch independently between speakers only, headphones only, and both.
    • Dual inputs – as well as the integrated PCM2702 based USB DAC that I mentioned, the TP32 has an RCA input (as the XC had); the gain here being that if I want to listen to music from my phone (which has no fan, unlike my laptop, thus increasing SNR!) I don’t have to first unplug the cable from my laptop since that drives it over USB.

    The items above add up to a significant improvement in overall practicality. If I’d had to pay much money for the change I probably wouldn’t have (especially as I’m having to be careful with money right now due to recent events which I may or may not blog about in a later post when the dust has settled). Fortunately I won’t be paying much for this upgrade at all, because i) the Topping TP32 cost me £85 new on eBay and ii) completed eBay listings suggest that my Bantam XC should fetch at least £60 – if it does, £25 feels worth paying for the improvement I’ve got here.

    You may have noticed that throughout this whole post I’ve not really used the any terms like ‘warmth’, ‘sharp’, ‘soundstage’, ‘depth’, ‘muddy’ or similar others. Two reasons for this:

    1. I don’t consider myself to meet the definition of audiophile that seems to be implied by reviews that use such terms. I like listening to music and appreciate quality kit, but I rarely find value in qualitative reviews.
    2. It only arrived today, and if audiophile lore is true then I need to wait a few days for it to burn in.


  • All Change

    Posted on by Dave Comment

    I’ve had a busy last few weeks. About a month ago I flew out to Israel for a long weekend and as a result have gone 180 degrees on my previous post (in which I declared that I was turning down the opportunity to go and work for a startup developing some neat smartphone technologies).

    In just nine days from now I’m going to have finished tearing up my roots (first graduate job and flat) in Cambridge and will be regrowing them in Tel Aviv. There will be challenges and it’ll be hard work, but the work should be rewarding, it will be an adventure, and I will learn so much. It essentially all comes down to the fact that I’ll never be in a better position to take risks like this and if I don’t now I’d always wonder “What if?”. I expect the next time I post on here it will be from Tel Aviv – I have had and continue to have so much to do and so little time to do it in.

    While out for the long weekend we went mountain biking near Bet Shemesh:


    View Bet Shemesh in a larger map

    Before all the above this had been a draft blog post titled “Out Of Beta”, with the following content:

    Both Cardio Grapher and my spring cycling endeavours, that is.

    Cycling: North Cambridgeshire 18 at an average moving speed of 16.44 miles per hour. Figure of Eight 19 (same route, more descriptive name) at an average moving speed of 16.73 miles per hour.

    Cardio Grapher: I fixed the last known bug in the version one beta series, dropped the beta tag and released the two changes to the market on Tuesday 28th (February). I’ll now be focusing all the time that I do put into Cardio Grapher (which probably won’t be much given the above) on version two. I already have plenty of ideas for features so it’s just a matter of time. I’ve also received numerous emails thanking me for Cardio Grapher and requesting new features which is nice.

    Here is the Google Doc with all the stats: http://spreadsheets.google.com/ccc? key=0At0EKwdiLZmYdFg4Mk9fdHltdWlGeWpQTHMzM3RjU3c&hl=en_GB

    After the above I found time one wonderful Saturday to do another 29 mile figure of eight on the Cambridgeshire roads, at a slower still average moving speed of 16.39 miles per hour (though I will say I really wasn’t trying this time).


  • A Slow Start to the Year, and a Day of Firsts

    15.71 miles per hour to be exact.

    Today is a good day.

    Today is a day of reflection and decision making.

    Today is the start of summer. In my world there are only two seasons, summer and winter – the former is the set of days when there are sufficient daylight hours for cycling (as a student I was able to schedule work around cycling, but not so much now I work), and the latter is the set where there are insufficent daylight hours.

    Today is the first time since September that my road bike has actually been on the road – due to the above I set it up in my flat on a turbo trainer when winter arrived.

    Today I cycled 32.61 miles, going through Madingley, Dry Drayton, Oakington, Longstanton, Swavesey, Over, Willingham, Rampton, Cottenham, Landbeach, Waterbeach, Clayhithe, Horningsea and Fen Ditton before arriving back in Chesterton:


    View North Cambridgeshire 17 in a larger map

    Today I cycled more road miles in ~2 hours than I did in the last half a year. And it’s perhaps not then surprising that I did it at a miserable 15.71 miles per hour. I have my work cut out! That said, when I got to Cottenham (about 20 miles in) my average was at just under 17 miles per hour which doesn’t sound anywhere near as bad, so part of the decrease is due to a loss of muscle endurance and part due to a loss of muscle performance – also not really surprising.

    Today I used my Zephyr HxM Bluetooth heart rate monitor with Cardio Grapher on the road for the first time, until now having only used them on the turbo trainer.

    Today I realised that Cardio Grapher really needs to have an orientation preference (landscape/portrait/auto): the handlebar mount that my phone sits in on the bike holds it pretty much parallel to the road meaning that even the slightest of turns makes the phone switch to portrait mode (I have the mount setup with it in landscape), while even the slightest of inclines makes it switch to landscape. Unfortunately the Android orientation detection algorithm (sensibly) incorporates histeresis, meaning that to get it to switch to the right mode would have required removing the phone from the mount. As a result I’ll be putting said functionality into the the next release of Cardo Grapher that I put out.

    Today Cardio Grapher helped me realise that thanks to the small amount of cardio training I managed to do during winter my cardiovascular fitness is not (currently) limiting me – my legs definitely are.

    Today is day two of ten days of holiday from work, and the first of which that has been relaxing.

    Today all the above made me realise I made the right decision recently. Back in December I was contacted by the MD of an Israel based team of self-described “investor-inventor-entrepreneurs” regarding some products they are developing, one of which relates closely to the work that I did for my dissertation, Inferring Transportation Mode using Smartphone Sensor Data. A few emails, an NDA and a couple of Skype calls later and I was interested enough that we arranged (me having first sought the approval of my primary employer) for me to work as a consultant on one of the products in my spare time. At the time my thought process was essentially “hey this is cool stuff, the kind of thing that I can imagine developing just for fun, and here’s the opportunity to get paid for doing it – what have I got to lose?”. So I did. But after just a few weeks I realised that my work life balance was all wrong, coming back from work in the evenings only to sit down at the computer and think “Oh, I’m being paid to work on <X> in my spare time, I should do some of that.” This took time away from things like turbo training. The realisation that I’d thrown the “Winter miles for summer smiles” ethic to the wind and not done any turbo training since starting then made me realise that what I was doing was not sustainable. I was spending too much time working and as a result neglecting many other things. So I had to pack in the part-time consulting. When I did, I was asked what it would take for me to move out to Israel and work on it full-time. This was pleasantly surprising to hear, but it didn’t take very long for me to realise that as I like doing what I do and being where I am, I would have had to give up a lot only to gain a lot of uncertainty (in both quality of life and financially – with potential for both loss and gain).

    Tying in nicely with the above the following article is a good read: http://youarenotsosmart.com/2011/12/14/the-overjustification-effect/. Indeed, many of the articles on that site are good reads.

    Here is the Google Doc with all the stats:
    http://spreadsheets.google.com/ccc?
    key=0At0EKwdiLZmYdFg4Mk9fdHltdWlGeWpQTHMzM3RjU3c&hl=en_GB


  • 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
    NextGen ScrollGallery thumbnailNextGen ScrollGallery thumbnailNextGen ScrollGallery thumbnailNextGen ScrollGallery thumbnailNextGen ScrollGallery thumbnailNextGen ScrollGallery thumbnailNextGen ScrollGallery thumbnailNextGen ScrollGallery thumbnail

  • 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!).



  • dinamic_sidebar 4 none

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