Sonos UPnP Development - Let's play some music!

So far we have seen how to discover media devices, how to monitor what is being played on them, and how to pause a media device.

I present here a way to play something on a Sonos Zoneplayer (or, for that matter, any other media renderer).

The code here is based on the code in my post Sonos UPnP Development - Controlling Playback which has been modified so that, instead of pausing the Zoneplayers, it now tries to play a file on one of them.

Firstly, an important point to consider here is that, unlike UPnPClient5 which searched for, and addressed all of the zoneplayers, this version needs to target a specific zoneplayer. We, therefore need a way to specify this.

We also need to specify a file to play. Browsing your Sonos library, looking for a specific file, selecting it, and playing it is a subject in it's own right and, hopefully, I'll get around to covering it eventually. I intend to keep this simple so I'm going to play a URI from the Internet which points to an MP3 file. So our program needs a way for use to specify this file.

The code below include these enhancements:


Rather than hardcode this information, I have made them parameters so you call the program thus:
./UPnPClient7 <zoneplayer> <uri>

The code to get these parameters is mostly at lines 128 to 135. These are held in variables declared at lines 18 and 20 along with another variable, rendererFound, which is used as a flag for error reporting.

As before in UPnPClient5 we discover all of the media render devices and create a list of them. The callback function device_proxy_available_cb is used for this as before.

However, in this case we do a test for the media renderer name. This is at lines 98 to 103. Not we are only matching on the first few characters, so we don't have to provide the full name of the ZP. If we are not careful, we could match multiple ZPs, and in this case the program will play the file on all of them. Note this is NOT the same as linking the zones.

When a match is made, we call a new utility function play_stream which is defined at lines 38 to 86. This takes two parameters: a pointer to the renderer, and the URI.

The instruction to set the AVTransport to use this URI is at lines 68 to 72. This is a call to the AVTransport service "SetAVTransportURI", which does exactly as it says on the tin. This requires a few parameters:

• InstanceID - Always 0
• CurrentURI - Our URI
• CurrentURIMetadata - This describes the URI in more detail

The CurrentURIMetadata parameter is a string containing an encoded DIDL-Lite description of the file. I have hacked this into a couple of strings "metadata1" and "metadata2" and used strcat at lines 59 to 61 to create the final metadata string which contains our URL. This is a nasty, hacky way of doing this, but it works and it also exposes the raw data so you can see what it is.

We then set this as the CurrentURI for our AVTransport. If this is successful, we then instruct the renderer to play (lines 74 to 77).

Job done!

If I call this as follows:

./UPnPClient7 Office http://www.archive.org/download/jj2008-06-14.mk4/jj2008-06-14d1t03_64kb.mp3

I will have Jack Johnson start to play in my office.

Note that this is actually not added to the Sonos queue. It is played directly. Adding stuff to the Sonos Queue is something which involves some Sonos-specific capability. At the moment I'm concentrating on standard UPnP capability. I hope to cover the Sonos queue in a future article.

Sonos UPnP Development - Getting more information from the renderer

This next version is an evolution of the version in my previous post Sonos UPnP Development - Accessing the AV Transport service.  It has been extended to display some basic metadata for any tracks that are found.

The main changes from the previous version (UPnPClient4) are:

1.  A new callback function on_didl_object_available (lines 31-44) which prints out metadata for a track object including the full URL of the album art.
2. New code in the existing on_last_change callback which creates a parser for the XML track object (lines 86-96)
3. A change to the service subscription to indicate we want to get the "CurrentTrackMetaData" information (line 69).
4. I have also added the ability to specify the timeout on the command line (lines 155-158 & line 194). For brevity I haven't done any serious condition/error checking here.

If you run this program with no parameter it will default to run forever. You will need to force close it with CTRL-C. If you specify a parameter in seconds, it will run for that many seconds before exiting.

The way this works is similar to UPnPClient4, on which it is based. However, within the last_changed callback handler (which, as you recall, is called whenever the AVTransport service changes state) we request and process the track metadata.

The track metadata is contained in an XML document which looks like this:

If you uncomment the "g_print" on line 88 it will print out this XML document for you to see (it prints on a single line - I have formatted the above sample to make it easier to read).

Looking through this document you can see it contains quite a lot of information about the currently playing track. This is contained in an XML schema known as "DIDL-LIte" which is a cut-down version of DIDL. In UPnP AV this is used for a lot of things including content directories.

Luckily in our case the gupnp toolkit provides us with some nice capabilities to make it easy to parse this and extract information from it. The way this works is you needs to create a parser (line 58). When the parser is run it scans the DIDL document and signals every time it gets a new sub-object. In our case, the sub-object is a DIDL Item containing the track metadata. We need to create a callback function to handle this (which we have called on_didl_object_available and connect this to the parse before we execute it (line 84). We then run the parser and let it do it's thing.

In the parser callback handler on_didl_object_available (lines 30 -38) we receive the metadata object from the parser as a GUPnPDIDLLiteObject object. We can then use the gupnp convenience functions to extract specific data from this.

If you run this, you should get something similar to:

If you play tracks whilst the program is running, or if the track changes, the new details will print out.

Of particular note is the "Album Art:" information. The metadata returns a partial URL of the Album Art. This URL is relative to the Device URL. To get the full url we have to append the device URL to it (http://<ZP_IP_ADDRESS>:1400). This version of the code does this for us so that the URL output (highlighted above) can be cut and paste into the address bar of a web brower in order to view the album art.  If you are listening to Internet radio you should get the station logo for the station, if there is one.

The change in this updated version is achieved by pushing a pointer to the renderer object into the on_didl_object_available callback so that the callback code can reference it (the change here is made at line 89). Then in on_didl_object_available we dereference the renderer object and use it to look up the base URL (line 39) and then construct a new URL using the device base URL and the album art partial URL (line 40).

Clearly this basic capability could be extended to a number of uses, such as:

• Keep a GUI client up to date with current playing information
• Create a logging service to monitor what tracks had been played
• Create a "most played" or "recently played" playlist from the log
• Create a screensaver or media centre display based on what a specified zone was playing
• Look up artist information, artwork, or lyrics on the Internet and display them
• Push Album Art of currentply playing track to a UPnP TV or picture frame

As well as many more applications of this.

Sonos UPnP Development - Controlling Playback

In previous posts I have introduced the important concepts of UPnP Services, and that they offer Events and Actions. We have seen how it is possible to subscribe to an Event in order to be notified of when something interesting happens.

Now we are going to look at how we can use Actions to actually control something. This is a very simplistic example, but should illustrate the basic concepts.

The following code, when run, will do a "Pause All" of the renderer devices it finds on your network. This code is based mostly on the version from my previous post UPnP Discovery with Sonos, event driven:


The main changes to this version are that that we no longer print anything out. The device_info method which was used to print out device details in v3 has been replaced by a new function pause_device which pauses the device instead (lines 20-35). The key function call is on lines 32-34. This requires a little explanation.

The call takes multiple parameters including the service being addressed (in our case, the AVTransport service which we have previously obtained a reference to, the action requested, which "Pause", a flag to pass back en error and then a bunch of parameters. The parameters depending on the action being triggered, and this is within the device description document. In the case of AVTransport it's also within the UPnP specifications at upnp.org.

The following image shows how this looks when using a development tool such as Device Spy. The left column shows the Actions supported by AVTransport. I have selected "Pause" and the right column shows me the parameter this Action requires. It needs a single parameter called "InstanceID" of type "ui4".

Using Device Spy developer tool to examine the AVTransport interface

So in our call on line 32 (and according the the GUPnP documentation for "gupnp_service_proxy_send_action") we need to specify this parameter a as a "tuple" comprising the parameter name, the parameter type and the parameter value. In this case we want the first (and only) AVTransport control. The count starts at 0. We finish wth a "NULL" to indicate there are no more parameters.

This call is a simple one with no return parameters. If we had return parameters to deal with we would need to handle this differently.

Also, the function returns an error if the action failed. In our case it will fail if the "Pause" cannot be carried out. One reason for this would be that the devices is already paused. In this case we don't care about this so we ignore it. A more complete version might keep track of the transport state of the player, and only send a "Pause" action to those which were not already paused.

When run, this program does not give any output. It simply pauses every discovered player on the network. Clearly this could be used to connect to a home automation system, such that when the phone rang or the doorbell was pressed, all of the zones were paused.

Sonos UPnP Development - Accessing the AV Transport service

This is an iteration of the code I produced in my post UPnP Discovery with Sonos - Event Driven. Now we have discovered the devices on the network, we should try to do something useful with them. In this post I show how to pull some interesting information from them.

More specifically, I am going to reference the AVTransport service which is part of the MediaRender specification. This introduces some other another important concepts in UPnP: Services, Events and Actions.

Services

Functionality in UPnP devices is primarily exposed via services. Services are advertised on the network and can be discovered. The advertisement for the service includes the technical document which explains its capabilities. This document may be viewed using UPnP Device Spy, or in the case of standards based services like AV the specifications are also published at upnp.org.

Services expose two types of capability: actions and events.

Actions

If you want to perform some function on the device, you call an appropriate action. For a media player device, for example, one action might be to start playing the current track. We will look at actions in a later article.

Events

When a device does something that the rest of the world might want to know about, it can trigger an event. The events that a device may trigger are part of it's device specification document which can be viewed using a UPnP Development toolkit like Device Spy, or in the case of AVTRansport by looking at the UPnP AV specifications at upnp.org.

Anything else on the network that is interested can register it's interest in knowing about that event by subscribing to it. It may also unsubscribe if it is no longer interested. If it is subscribed to an event, it will receive an event every time the target device does the thing which causes the event.

For instance, n the case of a MediaRenderer object there is a service called AVTransport which represents the status and capability of the renderer transport.

In this article we are going to look at this and used the event called "last_changed" which is triggered whenever the Transport state changes.

The code below is based on the version in my last article with some modifications:

The first thing to notice is I have removed a bunch of code:

device_info as been removed and the code to print the hashtable out in main_loop_timeout has also gone. This code was really only there in the previous version so that you could see what was going on.

I have also removed the "Device added:" and "Device removed:" print statements from device_proxy_available_cb and device_proxy_unavailable_cb so none of the console messages that were in the last version are there any more.

The major additions here are as follows:

Firstly we have added a new callback function on_last_change (lines 30 to 75). This function is passed the UDN of the device as well as some data. The data is an XML document describing the transport state.

A couple of things are important here. Firstly we used the UDN (Unique Device Name) of the device as the key when we stored it in the GHashTable. This means we can use the UDN to quickly find the renderer object.

Secondly, the XML doucment needs to be parsed to pull useful information from it. Luckily GUPnP provide a set of libraries (gupnp-av) to help with this.

So, this function parses the "TransportState" information from the XML user data, looks up the renderer from our GHashTable using the UDN, and prints out the device and state information.

We then need to subscribe to the AVTransport service. We do this in the device_proxy_available_cb. Whenever this is called it represents a new renderer device being found. We do the following:

1. look up the AVTransport service (line 92)
2. register our interest in the "LastChange" event, and point this at our on_last_change callback function (line 97-101)
3. and turn on the subscription (line 102)

From then on, any time the renderer transport state changes, it will fire a "LastChanged" event at us which will run our little function.

A few other, minor changes are needed to support this:

• I have #included the gupnp-av headers (line 8)
• I have created a parser object and initialised it (lines 16 and 135)
• I have also moved the timeout value to a #define called "RUN_TIME" (lines 12 and 162) so it is easier to change and set it to 10 seconds

If you run this you should get something like this:

If you clear the queue you will get:


As you can see this starts to offer some interesting possibilities. You could build a GUI around this which not only listed all of the zones, but also listed whether they were currently playing or paused, all in real time.

You could also use this (with the appropriate hardware and drivers) to send on/off messages to an amplifier on a specific zone via Infrared (lirc) or a 12V trigger (parallel port?)

UPnP Discovery with Sonos, event driven

Following on from my post UPnP Discovery with Sonos Players I present a revised version which doesn't add much in terms of functionality, but which is a bit tidier and has some changes to how we handle discovery.

In the last versions, we simply printed out whatever we discovered. Processing discovery on-the-fly like this will not suit a lot of real-world programs, especially if it involves something like a GUI. What we need to do is to store the results of out discovery so that we can reference them whenever we want.

This raises an important point about discovery. UPnP discovery is not a "one shot" activity. It is a continuous processes. You start it, and it then runs continuously until you stop it. There is no magic flag that says "discovery has finished".  Normally the start and end of discovery is dictated by the start and end of your program. In my program, discovery (and the rest of the program) is stopped by me running a 2 second timer, after which time discovery is stopped and the program exits.

This is a very important concept to understand as, during the continuous discovery process devices can come and go from the network. Your program has to be able to accommodate devices appearing and disappearing. Of course, we are used to that with the Sonos controllers: if we add a new player to the system it magically appears in the zone menu. If you disconnect power from a Zoneplayer it (eventually) disappears.

So what we need to do in any long-lived UPnP program is use the discovery to maintain a local copy of what is currently on the network.

This next piece of code does that. It is based on the previous versions but with some significant changes. I am using a GHashTable from the Glib collections library. Once again this is common on Linux systems. In fact it's a dependency for GUPnP so it will be there if GUPnP is.

GHashTable gives us a nice key-value table with the ability to easily add and remove items.

Here is the code:


Firstly, I have added some new functions as follows:

device_info (lines 19-21) is a simple print utility function which, given a key value and a renderer reference, prints out some information about that renderer. This is used by main_loop_timeout (lines 26-34) which has been altered to print out the contents of the GHashTable. Remember, main_loop_timeout is called to signal the end of the program.

We already had the callback function device_proxy_available_cb (lines 40-50) but now we have added a new callback function device_proxy_unavailable_cb. These now respectively add or remove the discovered renderer device to the GHashTable. What this means is that at any time our GHashTable should contain a current list of the available devices in the network.

(Note that a device which has its power removed will not normally announce it's departure from the network, so this list is not 100% correct).

These callback functions also print data about the added or removed device to the screen, so you can see what it's doing.

To accommodate these changes, we need to make some simple changes to the main program. Firstly we need to create our empty GHashTable, which I have called renderers (line 79). Then we need to register our interest in the device-proxy-unavailable signal which occurs when a device leaves the network, and point it to use our new callback handler (lines 97-99).

I think the only other change worth mentioning is that I have made the MediaRenderer URN into a constant (line 10 and line 87) as it's better coding practice.

On running this, you should get something similar to the following:

The first block shows the devices first being discovered. Then the 2 second timeout kicks in and this prints out the current contents of the renderers list before stopping discovery. Note that before it stops discovery the system automatically tidies up for us, removing all of the discovered devices (the final block).

If you wish, change the timeout value at line 106 from 2 seconds to something longer if you want to make this more obvious.

Also note that, in this case, a new media renderer showed up on my list "Intel AV Renderer (laptop)". This is the Intel AV Renderer which is part of their UPnP developer toolkit. I ran this on my Windows laptop to show that this is a generic UPnP AV capability that's being used.

If you set the timeout to a longer value, you can launch and close the Intel AV renderer and see it being added to, and removed from the list of devices.

As you can imagine, this could be wrapped in some sort of GUI to give a constantly updating list of the Media Renderer devices on the network, similar to the Zone list on the Sonos controller.

UPnP Discovery with Sonos players

Following on from my previous article on Discovering UPnP Devices this post describes how to be a bit more specific about what we are searching for. Specifically, I will be searching for Sonos music streaming devices.

A crude way of doing this would be to alter the device_proxy_available_cb callback function with an if/then statement that selectively printed out device information based on the values in the model or Friendly Name information, but UPnP provides us with a better approach: When you initiate a discovery, your discovery request includes a specification of what you want to discover. Previously we used the specification upnp:rootdevice which discovered every device. We can limit this by saying we are only interested in certain types of devices.

UPnP devices have a hierarchy. Typically there is a root device which can contain one or more sub-devices. These sub-devices represent specific functionality. Sonos Zoneplayers contain several sub-devices which do different things, but in this case I am interested in the part which plays music. In UPnP terms this is a UPnP AV MediaRenderer.

Each UPnP device type has a URN which identifies what type of device or sub-device it is. The standard URNs for things like UPnP AV are described in the UPnP specification documents at www.upnp.org but these are also available directly from the device itself.

The easiest way to get these is by using a developers too like UPnP Device Spy. Note that Device Spy and similar tools are not "sniffers" as some uninformed people like to claim. They are developer tools. They discover devices and provide an easy way to query them for their capabilities, status and even to execute actions on them.

In this case, examining the UPnP documentation, or using Device Spy and looking at a Zoneplayer, reveals the URN for the UPnP AV Media Renderer is urn:schemas-upnp-org:device:MediaRenderer:1. So if we use that in our discovery, we will only get devices which match this specification returned.

The previous code I present discovered every UPnP device on the network. By modifying this slightly, we can make it so it only returns media player devices. This modified version is shown below with the lines that have changed highlighted:


As you can see, the change is very simple. If we now run this we will get something like the following:
A few things are noteworthy here:

• We only have Media Renderer devices. The firewall and the Sonos WD100 dock no longer show up
• The format of the output is slightly different. This is because we have been returned the MediaRenderer sub-device instead of the root device
• We no longer get the IP address. This isn't a problem as you really should never need it. If you really must have it (e.g. for display info), there are ways to find it.
• In this case we get the Zoneplayer zone name
• In the example above there are no non-Sonos MediaRenderer devices on the network. If there were they would show up in this list

So that is how to restrict UPnP discovery to a specific type of device.

Fuel "Economies"

The "Hydrogen Economy"

In discussions about the future of vehicle energy, I often see people talk about "The Hydrogen Economy".

The use of this term clearly indicates that the person using it is focussing on the commercial and financial aspects of energy supply rather than on any of the other aspects. They are looking at how companies and, by association, those in Government can commercially exploit future energy supply. They are looking to how profits can be made, taxes levied, and empires built or maintained.

This concerns me because, although the health of the economy is important, it's by far not the only issue at stake. In fact I would say it was the least important one, because it will take care of itself.

Whatever our future energy supplies look like, there will be companies making money from that energy supply, and this can support a thriving economy. What frightens people is that it may not be the same companies as the ones that control the market today. In fact it's entirely possible we fuel our vehicles of the future from a mix of suppliers as well as self-generating much of our own energy.

This scares the hell out of the established petrochemical companies, as it erodes their traditional near-monopoly control over the market, and their influence with Governments. And there are already signs it is starting to happen:

Why the Oil Industry is Running Into Major Trouble

The Oil Economy

It's worth pointing out that we currently live in an "Oil Economy" which is largely run under the control of a handful of large corporations and Governments. It's fairly clear to everyone except the wilfully ignorant that the invasion of Iraq (and, probably, the war in Afghanistan) was not about terrorism, 9/11, threat of attack, WMDs, or mistreatment of their civilian populations. It was about oil.

More specifically, the attack on Iraq was most likely about protecting the Petrodollar: currently most trading in oil is done using the US dollar and it is largely this which makes the dollar a strong currency and, to a degree, makes America rich and powerful. Saddam was was hugely influential in the Middle East, and was leading the way to switch the trading currency away from the US dollar to the Euro (see Saddam Turns His Back on Greenbacks). This could have been devastating to the US economy. Many observers believe this could have been the main catalyst behind invading Iraq.

What is clear is that "the oil economy" is so powerful and influential that protecting it can drive Governments to start wars that kill thousands of it's own citizens, as well over 100,000 enemy civilians, and which cost trillions of dollars.

The current oil economy is bad for us as citizens and as consumers. It is an abusive, corrupt, and murderous model that exploits us as consumers, corrupts our Governments, and makes small fortunes for corporations and the handful of people that run or, in the case of politicians, are run by them.

So what's really happening?

When people talk about "The Hydrogen Economy", what is really happening is that the companies who currently control "The Oil Economy" are trying to find a new business model to transition to, to maintain their power and influence.

They are promoting hydrogen as a fuel because it maintains a large part of their monopoly control of the fuel supply chain. It maintains the population's dependence on their product. And it's possible to use misdirection and lies to make it sound like a cheap, abundant, clean and renewable fuel when it is actually none of these things.

The reality is somewhat different. As it stands today, a "Hydrogen Economy" is bad for the environment, and bad for us as citizens.

So when someone talks about "The Hydrogen Economy", I see someone whose main concern is support for maintaining the continuing dependence on, and control of the economy by, the oil companies and their cronies.

Whose primary concern is how they can exploit us as a consumers to line their own pockets and to maintain power and influence.

Car deaths

I learned something interesting today: it seems that pollution caused by ICE cars causes more deaths per year in the UK than road accidents.

These are rough figures, and I got them from various sources such as these:


Estimates of mortality in local authority areas associated with air pollution

Reported road casualties in Great Britain: main results 2012

But the summary is:
25,000 deaths in the UK per annum are attributed to pollution. Roughly 7,000 are directly attributed to small particles from diesel soot. More are attributed to various other pollution causes which aren't so easy to tie directly to road vehicles, but a good proportion of early deaths due to carbon monoxide, nitrogen dioxide, and other poisonous substances including hydrocarbons is likely to come from the tailpipes of cars, lorrys and other ICE vehicles.

Compare that to the number of deaths in road accidents, which is less than 2,000 per annum.

It's a sobering thought, especially if you live or work in a major city where the pollution levels are high.

Coupling

A programmers brain

I am a Software Engineer.

(It's not my primary job, but an important secondary capability which massively enhances my ability to do my normal primary role)

One of the things about Software Engineers, Developers, "coders", is the way they think, the way they analyse things. To me, this is one of the primary reasons why everyone aught to learn how to code: not because everyone needs to be able to code, but because it teaches analytical thinking. And much of the analysis that applies to Software Engineering also applies to real life too.

Fuel supply: tight and loose coupling

Since owning an EV, I've been analysing many of the aspects of EV ownership and long term strategy. I've also had many discussions and debates with people who are for, and against EVs. Many of these discussions end up focussing on fuel consumption, and the fact that EV's are not completely "clean".

It is, of course, completely true that most EVs, including mine, consume electricity generated from fossil fuel. In one discussion I had someone said "so the argument for EVs over ICE cars is about which is consuming fossil fuels more efficiently?"

He has a point. However, that view is focussing on just one aspect of EVs, and this is where my developer brain kicks in.

In Software Engineering, there is a concept of "coupling" which, basically, describes how closely dependent different parts of a system are with each other. If a system is highly dependent on other parts then it is "tightly-coupled" with them. If it is not so dependent on them then it is "loosely-coupled".

Writing software where subsystems are tightly-coupled with other subsystems is almost always considered to be bad practice. Software like that tends to be difficult and expensive to maintain and to change. Good software should be written to be loosely-coupled with other systems as much as possible.

This applies with hardware too: it's much better to have every phone use a common charging connector standard than for every phone to have their own proprietary connectors. Of course, what is good for the consumer and the environment isn't always in the best interests of companies, and some companies will deliberately make their software and hardware proprietary to lock consumers into their ecosystem. Microsoft and Apple are prime examples of this.

There is a strong analogy here with cars and how we fuel them. The status quo is that we have an ecosystem that has been developed over almost a century which drills for oil, delivers it to refineries, processes it into petroleum and other fuels, distributes it to filling stations, and then dispenses it to customers. Every stage of that ecosystem is highly dependent on all other stages, and when we use a petrol or diesel car we are highly dependent on it.

It is a very tightly-coupled ecosystem. Of course this whole ecosystem has evolved out of necessity more than design.

EVs still, mostly burn fossil fuels. The big advantage with electricity as a fuel is that electricity is loosely-coupled to the fuel supply. Electricity can be generated from burning oil, but also from coal, gas, nuclear, hydrogen, wind, solar and wave power, as well as who-knows-what in the future. And that is a very important factor because no-one knows yet what the long-term future of our fuel supplies will be.

And the other advantage plug-in EVs have over every other type of fuel system is that they are totally de-coupled from traditional suppliers: you can charge your EV from solar panels on your roof if you want.

(Of course, I realise that no everyone can install solar panels, but the point is valid even if it doesn't apply universally).

Put another way:
A petrol engine uses 100% fossil fuel and always will always use 100% fossil fuel, because it is tightly coupled to that specific fuel and to the supply chain that provides it.

An electric car may use 100% fossil fuel in the very worse case (and even then it uses less fossil fuel per mile than most ICE cars), but more normally significantly less than 100% of an EV's fuel consumption comes from fossil fuel (currently in the UK more than 10% is from renewable sources) and the percentage of fossil fuel used by EVs is decreasing all the time.

But it also gives us a choice: if we are prepared to invest in it, individually we can increase that percentage dramatically through the choice of electricity supplier, or the use of local (e.g. solar) generation to the point where 0% of the power from our EV comes from fossil fuels. And the more we do this as individuals, the more the power companies will move away from fossil fuels towards renewable energy sources.

What about biofuels

There was a lot of excitement about biofuels a while back, and they still have their place today. I know of people who use vegetable oil in their diesel engined cars, for instance.

Where we are today, we are not in a position where mass production of biofuels to the levels needed to supply a significant percentage of cars on the road is practical. That may change in the future.

Of course, being renewable is only one part of the eco-equation. Biofuel vehicles still produce a significant amount of CO2, and also create a significant pollutant health hazard on our streets.

And, if the problems of biofuel production are solved, there's still the option of using biofuel to generate electricity, which is possibly more efficient and less polluting.

The hydrogen argument

And what about hydrogen? The view put forward by Top Gear and the rest of the petrochemical industry is that hydrogen is our saviour. They envision a world where we fill up our hydrogen fuel-celled cars from hydrogen pumps on the forecourts of filling stations, which are supplied, in turn, by huge tankers delivering hydrogen from production facilities.

In other words, they want to maintain the same crappy, tightly-coupled, monopoly/cartel controlled supply chain that currently has a stranglehold over us.

But, in actual fact, hydrogen isn't currently a very green fuel; the majority of hydrogen production today is part of the petrochemical process. It consumes non-renewable, fossil fuel just like petrol.

Isn't that convenient? For them!

The fact is the petrochemical industry is running scared over plug-in EVs just as certain monopolistic, proprietary software vendors have been running scared over open source software. The push for pumped hydrogen fuelled cars is a distraction designed to turn people away from EVs.

Of course, there are some potential ways to generate hydrogen which aren't from fossil fuels. But the thing to remember is that hydrogen fuel cells are, fundamentally, a way to generate electricity to power an EV. So why on earth do people think that an EV which is limited to only one source of electricity generation technology, sourced by a historic cartel, and delivered through a legacy supply-chain, is a good thing?

The future, if we want it...

Battery technology has a way to go, but it's advancing rapidly. In the next 5 years, cost effective plug-in EVs with a range of 300 miles could be common. Combine this with a network of rapid chargers, home charging points with smart-metering, and street charging posts (if you can power a lamp-post or a parking meter you can power a charging point) then we could move to a much more flexible, cost-effective, and convenient vehicle fuelling ecosystem.

And hydrogen may have a future in this. If renewable, cost-effective ways to generate hydrogen are developed then why not. But I see no reason why hydrogen generation has to be trapped in the current supply chain. If, for instance, we develop a way to harness algae to produce hydrogen, it actually makes most sense to do this locally. Perhaps we even do it in our own homes and use the hydrogen to drive a home fuel-cell unit which provides our home with heat and power, and also charges our EV battery.

Thoughts and observations on car energy consumption

I have found that driving an EV can make one much more aware of the amount of energy that propelling a car takes.

Traditionally, fuel for vehicles has been a "thing"; a tangible object that you can purchase and take home with you. It is measured in physical units, such as gallons or litres, or weight (in the case of fuels like coal). When we consume it, we measure the consumption by those same units. Hence we consider "miles per gallon" as a measurement of how efficient our car is.

As a relative measurement (to other cars) this is, of course, fine. As a consumer purchasing the fuel, it also gives us a view on the cost of motoring. However, it tells us nothing about the actual energy consumption, at least not directly or intuitively.

Energy is not measured in gallons or litres. The official SI unit of energy is the joule (J), but the reality is most people don't think in joules, and have no concept of how much a joule is. However, there are a number of other units of energy are commonly used, such as calorie and electronvolt. In the case of electrical power, energy is most often measured in killowatt hours (kWh). A kWh is also known as a "unit" of electricity. Most people have some understanding of kWh (or "units") as it relates directly to the power consumption of various appliances around the home, and to their electricity bill! (for reference, 1 kWh is equal to 3.6 megajoules)

Related to this, we can measure the rate of power use in watts (W). Power is the rate of energy change or transfer with 1 watt being equal to 1 joule of energy per second. In our case we use kilowatts (kW) which are 1,000 watts each.

We know, for instance:

• An average electric kettle in the UK draws 1.8kW of power
• A typical washing machine consumes around 0.7kW averaged across the wash cycle
• A 1 bar electric heater burns around 1 kW
• A typical filament electric light bulb burns 0.06kW (60 Watts)

So a 1 bar fire in use for 1 hour will consume 1kWh, or 1 "unit" of electricity.

With these as mental benchmarks, if we now look at driving a car. In my EV, driving steadily along a straight, flat road at 30mph, and can easily be burning 10kW. That's equivalent to 10 electric fires, or 5-6 electric kettles!

If I drive at that consumption rate for an hour, I will consume 10kWh of electricity. The maths are simple and obvious and it was quite startling to me how much power is required to propel a small car. If I accelerate, I can easily be burning 30 or 40 kW. That's a lot of power!

As I have shown above, consumption for an EV is easy to work out. It is, of course, significantly different (and more revealing) than for an ICE car. And, instead of mpg, we use mpkWh (miles per kilowatt hour, or per "unit" of electricity). In my example above I burned 10kWh for 30 miles and, hence, I am getting 3 mpkWh from my car. In fact, across a range of journeys which includes everything from edging along in traffic at 5mph to 70+ mph motorway driving, my car gives me 3.8 mpkWh.

My car trip computer showing average fuel consumption

Others, who are more careful drivers than me, have achieved in the region of 4 mpkWh in the ZOE.

Of course, this helps us understand car energy consumption in relation to 1 bar fires and electric kettles, but how does it compare with good-old petrol engines? Petrol has a known energy density, and a calculation can be done to work out the amount of energy consumption, but this is rarely done. In general people merrily drive their cars without the slightest clue of how much energy it is consuming.

So let's do that calculation:
(EDIT: A friend of mine, +Francis Chin , pointed out an error in my calculations, so these have been updated)

A UK gallon of petrol typically contains around 156 megajoules of energy (132 MJ for a US gallon). If your car, on average, burns a gallon of fuel every miles (43 mpg) then every mile of travel consumes 1/43th of a gallon. That contains about 3.6 MJ of energy, which is equivalent to around 1kWh of electricity. Thus 43 mpg in an ICE is equivalent to 1 mpkWh in an electric car.

Of course, there are ICE cars with much better consumption than that, but in order to reach my, relatively heavy-footed, 3.8 mpkWh figure, an ICE would need to be 3.8 times better than 43 mpg. It would need to achieve 163.4 mpg!

And that is only considering the energy content of the fuel and ignoring the substantial energy costs of drilling, pumping, refining, and shipping. The energy used for refining alone is pretty boggling (as we shall see in my update below).

In reality even the most efficient ICE available to purchase today cannot reach half of that figure. And, bear in mind, this is real world driving, not some theoretical controlled test.

I also haven't considered cost in any of the above. Let's do that now:

A litre of unleaded petrol in the UK currently costs around £1.30. That is £5.91 per UK gallon. That is a cost of 3.79 pence per megajoule.

A "unit" of electricity in the UK currently costs about 13.5 pence (inc VAT). That is a cost of 3.75 pence per megajoule.

So, electricity is currently roughly the same price for the equivalent energy content.

However, petrol engines, even the most efficient modern ones, are only 35% efficient at best. The engines in electric cars are in excess of 80% efficient (The motor in the Telsa model S is claimed to have an efficiency of 88%). If we take the case most favourable to petrol, and calculate the cost of realising the energy stored in the fuel to an equivalent energy at the wheels, we end up with a cost of 10.83 pence per megajoule for a petrol car, and 4.69 pence per megajoule for an electric car. That's more than twice as much.

And petrol prices are rising faster than electricity prices.

The result of this is that, for an equivalent specification of car, the energy costs are around 3-5 times more for a ICE car than for an EV.

UPDATE (1 May 2014):
I've recently watched the latest episode of Robert LLewllyn's excellent Fully Charged Youtube show. At 4:55 he starts to discuss how much electricity is used to refine petrol.

Fully Charged - Watch from 4:55

The interesting take out from this is that petrol requires around 4.5 kWh of electricity per gallon to refine. That same power would allow me to drive 17 miles. So, straight away, compared to a petrol car, my electric car's energy consumption has a head-start equivalent to 17 mpg. So our hyper-efficient 60 mpg car above, is (relatively speaking) only doing the equivalent of 43mpg.

Put it another way: if you filled up your car up with 10 gallons of petrol, I could drive from London to Cardiff in my EV and might still consume less electricity than was used to refine the petrol in your tank. You would still be sitting on the petrol station forecourt, not even turned your engine on, I would be sitting in Cardiff, and you would still have burned more fossil fuel than me.

Business as usual

I've not updated the blog with any more of my EV experiences with the Renault ZOE, mainly because there's not been much to say. Once I got over the initial novelty of it, and the learning curve of how to deal with charging and so on, it's becoming a very unremarkable experience.

Of course, I still love how smoothly it drives, how quickly it accelerates from a standstill, and how quiet it is. And I love not having to queue up at filling stations.

But it's become entrenched in my everyday life now. The little things about it which are different from an ICE car, like remembering how to plug it in when I get home, or to take the charging cable with me on longer journeys, or even to not floor it when pulling away, have become habits now.

I even know where the main charging points are on my more regular longer journeys, and factor in a short stop for a boost charge (and a cup of coffee).

1 month and 800+ miles later

It's been a month since I got my Renault Zoe EV, and I thought I would post my views to date.

Concept

I think the EV concept is the future. Once you break through the misinformation spread by the Oil companies and their apologists and sponsored shills (e.g. a certain Mr Clarkson) it can seem quite compelling.

I will say that it's not there yet for a lot of people, maybe even most people. But things are moving fast.  A few short years ago EVs were totally impractical for anyone except the most die-hard environmentalist living in a city. Now, most people's regular journeys can be covered by the range of an EV, and there are versions with range extenders (basically a built-in petrol generator) which will give you the same sort of range as a normal petrol car (albeit with reduced fuel consumption).

At the current rate of change, in three or four years time, the range will be doubled, the number of charging stations in the UK will be enough that travelling long distances will not be an issue (it's very close to that now), and the prices will have dropped.

I would struggle to recommend buying an EV to most people now, because of the cost and the uncertainty about the future value of today's EVs given that the technology is moving so fast. Mine is on a lease so that in 3 years time I can chose to upgrade to a model with better range. My car will then go onto the second hand market and will be a cheap runabout for someone who can't afford a new car. And so the cycle starts, and we start to get more EVs on the roads.

The way I see it, it will never take off if people like me who can afford it, are prepared to take a risk, and whose driving habits it suits decide to believe Jeremy Clarkson's ignorant opinions or, worse still, decide they can't be bothered.

By the way, I do know of people whose only car is an EV and they use it for 99% of their car journeys. For the 1%, they hire an ICE car, and still save a bunch of money.

Getting some free electricity from the Ecotricity windmill at Green Park, Reading.

The Present

At the moment, for most of my travelling, an EV is significantly less hassle than an Internal Combustion Engine (ICE) vehicle. It's also significantly cheaper, more comfortable, quieter, and generally more enjoyable to drive.

For longer journeys, I do have to plan. I also have the option of the other car (which is an ICE car) to fall back on. But planning isn't necessarily a bad thing. The biggest risk at the moment is that, because some of the car chargers are thin on the ground in some places, there can be queues for them, which extends the journey times as you have to wait for other users.

For instance, I travelled to East London the other day, and ended up at Westfields Mall in Stratford. the journey between my home and Westfields was just possible to do on a single charge, but only if I went through central London, and if the traffic was favourable. The alternative was to go via the North Circular, which would have put it out of range by about 10 miles. That's not so bad because there are rapid and fast chargers on the M4 and on the North Circular (at Ikea). However, looking at the map, the Ecotricity charger on the Eastbound Heston services was out of service. Getting to the Westbound one would have meant a significant detour, and as there was an accident on the M4 at the time, this might have added an hour to the journey. I could have used the charger at IKEA, but it was a Saturday and there was a big risk that the chargers would be occupied.

As chargers increase in numbers, and the technology becomes more reliable, this won't be such a problem.

By the way, if I had got to Westfields, there were more that 30 fast chargers across the various car parks by the mall.

On balance I decided it was too much hassle on this occasion, and took the other car.

But this is something I can do easily, and a lot of homes have two cars and could do the same.

As for financially, ignoring the free charges I have been getting (of which I have had quite a few), I reckon if I had been using a typical ICE car with a fuel economy of around 40 mpg (being generous here, my old car got between 26-28 mpg averaged out despite being capable of 45 mpg on specific journeys), I reckon I would have burned 100 litres of petrol at a current cheapest price around £1.30 per litre. Total cost £130.

For these journeys I have consumed around 250kWh of electricity. If I had had to pay for it call at peak rate (14p/kWh) it would have cost me £35, a saving of nearly £100.

in reality, I've not had to pay for a good deal of this, so the saving is far greater.

Getting a 30% top-up in 10 minutes at an Ecotricity rapid charger at the motorway services

The future

Unless someone comes up with something significantly better (and, not Hydrogen isn't it) then I see Plug In EVs continuing to grow. Hydrogen will have it's place, but I see this as a supplemental thing rather than the main fuel source.

Ultimately Hydrogen as a fuel is problematic to manufacture, to store, to ship, and to pump. The fuel companies see it as their future because it's the only future they have where they can continue to control local filling stations and the supply chain to them. In a future where everyone fuels at home, or at work, or at the shops, or anywhere else they visit, there is simply no place for local filling stations, and that must have the oil companies scared out of their minds! Pumped hydrogen fuelled cars gives them a way to maintain this monopoly.

The other thing to bear in mind is that hydrogen, as a fuel, is really just a battery. It's not a source of fuel like Petrol or Coal is. It has to be created. The ingredients to create it are plentiful, but it requires electricity, and creating hydrogen uses more electricity than it gives back. Hydrogen doesn't solve any wider energy issues.

As a battery, I can see hydrogen having it's use in cars: I see most cars being plugin with a hydrogen fuel cell as a range extender. This would be a huge improvement on fossil fuel based range extenders as used in the BMW i3 and the Ampera/Volt.

I also see an opportunity for local generation and distribution of hydrogen, not pumped, but in some sort of cartridge or pack, just like the current small scale hydrogen fuel cell systems like the ones from Brunton. These don't have to come from specialist filling stations. You could pick them up from supermarkets or other retailers, a bit like butane canisters used for barbecues. As long as these are user replaceable, you just rock up to the shop, swap the cartridge, and be on your way.

Ultimately though, hydrogen is a way to create electricity. and EVs don't (or shouldn't) care where the electricity comes from. Getting your electricity direct from the grid into a local battery whilst parked outside your house will always be the most efficient, cheapest and, most importantly, most convenient method for most people, most of the time. I see hydrogen being a possible solution to fast refuelling for longer journeys.

A couple of weeks later, and using an ICE car

I recently had to do another trip to Portsmouth. As I described in a previous post the last trip I made I used the ZOE with mixed results, but I was new to the whole EV thing, wasn't used to charging, and had a distracting colleague with me.

This time I was going to the same area, but to a different office which I knew didn't have a charging point. I could have taken the ZOE and chosen to stop off on the way home to charge, but I decided to swap cars with my wife and use her Diesel Scenic (what can I say, we like Renault cars).

First off, I started with "range anxiety" as she was low on fuel. I had to drive a few miles out of my way, queue up, and stand at a smelly petrol station, with a dodgy pump, freezing my hand off in the rain and wind for a few minutes whilst I filled up (yes the filling station has a "shelter", but the current weather means the rain is pretty much horizontal).

For the Americans, legislation prohibits us in the UK from "locking" the pumps. We have to hold them and squeeze the handle the whole time, and they often are over-sensitive and keep cutting out.

£70 later I was ready to go (that wasn't a full tank, which would have cost nearer £90). That is an experience I definitely do not miss.

Of course, from that point I had no fuel problems because the range of the fully fuelled car is over 200 miles. However, I did find the whole journey fairly uncomfortable.

Prior to leasing the ZOE I had a petrol 4x4, which I actually loved, until it got too old to be worth maintaining. It was a gas guzzler but, at the time, it was comfortable and practical. My wife had the Grand Scenic which was a newer, nicer, more comfortable car, comparatively speaking.

Since I have been driving, and getting used to, the ZOE my opinion of the Scenic has changed. I now find the Scenic to be uncomfortable, noisy, and not nearly as nice to drive as the ZOE. Part of that is due to the lack of gearbox. I have to say I generally do not enjoy driving manual gearbox cars. But the ZOE has no gearbox. That's a subtly important difference. I dislike automatic gearboxes because you can feel them change gears, and I often find they don't change gears when I want to. That's not an issue with the ZOE as it has no gearbox, period. I thought I would miss the gear stick, but I don't. I especially don't miss the clutch when I'm sitting in slow moving traffic.

I found myself, driving back from Portsmouth, wishing I had taken the ZOE. Now I'm used to it I would have stopped off to charge for 20-30 mins at one of the Ecotricity rapid chargers on the M3. As it was, after a long day, I ended up stopping there for a 20 minute break, even though I didn't need to refuel, as I was getting too tired to drive safely. I actually dove past the Ecotricity charge points as a drove in. So I actually saved no time by taking the ICE car, and it cost me around £25 of fuel in the Scenic, where it would have cost me around £3 in the ZOE.

More EV Experiences

I've had my Renault ZOE for just over a week. During this time I'm mainly been driving as normal, but have deliberately undertaken one fairly long journey to understand the challenges of doing so. Here are my experiences.

Day to Day

Driving comfort

For most of my day to day driving, the ZOE is a lovely drive: it is smooth, accelerates pretty well at low speeds, and because there is no gearbox, then there is no clutch or gear changing. In this respect it's areguably like an ICE automatic. However, I feel there is a difference. When I have driven ICE automatic cars, they still actually have a gearbox, and the associated torque curve and so on. You can feel the torque dropping off in some circumstances, as well as the small shudder of the gear change. It often frustrates me when driving such cars because it doesn't always change gear when I would have in a manual ("stick shift" for our US friends) car. I guess part of that is having driven a manual gearbox car for over 20 years.

In the case of the ZOE, there simply is no gearbox, at least doesn't have any sort of gear box in the conventional sense of a car (there may be internal gearing, I don't know, but if there is it is fixed). It doesn't need a gearbox because electric motors can deliver torque across a wide range of speeds. So the ZOE simple accelerates smoothly up through the range. When you get to about 50 mph, the acceleration does drop off quite a bit.

One of the nice features is a speed limiter which you can set on the steering wheel to whatever the current speed limit is. It would have been nice if it could set it for you automatically from the speed limit information on the inbuilt Tom-Tom sat nav. I originally thought this was a gimmick, but I have been surprised at how often I use it. It's great when pootling around town as you can set it to 30 mph knowing that you don't have to worry about speed cameras. I didn't realise how stressful this was until I used this feature.

There are many occasions where driving a car at or below 30/40 mph is actually quite difficult and uncomfortable due to the gearing of the car, or the nature of the road. There is a road near me which was recently changed from a 40mph limit to a 30mph one. It felt slow driving on it at 40, and it's almost impossible to drive on it at 30mph unless you are paying very close attention. This road is a favourite for police traps. Now I can set the limiter to 30 and drive quite comfortably. It still feels slow, but doesn't feel stressful or uncomfortable any more.

I will add that it's also useful having the Tomtom always telling you what it thinks the speed limit is.

The other thing about the ZOE is it is so quiet. I can happily drive at 70 mph on the motorway and have a conversation at normal speaking levels on the built-in hands free system.

Charging

Something that has only occurred to me in the last week: most of the time I simply can forget about fueling my car. In the past I have made special trips to the petrol station to fill up ready for the next day. Now I simply plug in when I park. It has become part of the ritual of getting home. In a lot of cases I don't even bother disconnecting my charge cable from my home charge-point. I leave it connected and dangling so that reconnecting the car is a 20 second job.

In this way, the car is ready and fully fuelled 99% of the time. Most of my journeys are to places I can easily get to and home again on a full charge, and even then there are charge points at many of the places I go.

Ecotricity Charge point at the "Windmill" in Reading

It's worth knowing that, under the Chargemaster/Polar scheme, anyone can have an EV charging point installed in their home for free. You need to have off-street parking and a suitable electricity supply nearby, but you don't even need to have an electric car.

So I am planning to get my parents to install one at their house, so when I visit them I can plug in there.

I was worried plugging in would be a chore, but it really isn't. In fact, in the long run, it will be a huge time saver.

Longer Journeys

This is where it gets a little trickier. I had a journey to make to an office in Portsmouth. It was about 60 miles away, which is within the range of the ZOE, but only one way. The office I was going to had a charge point, and I asked them to reserve a charging bay for me.

I will point out this was a deliberate experiment. Normally I would have swapped cars with my wife and used the Diesel for the journey to be safe, but I specifically wanted to test the range and the charging infrastructure.

Results were mixed, and it was a great learning experience.

My colleague, Nick, came with me because he was interested. Unfortunately Nick lived quite a distance away in Wiltshire. Normally he would either have driven himself, or caught the train all the way. But instead he took the train to a station near me and I picked him up.

The way there was fine. We arrived with just under 20% range left. All good. However, when we got there, one of the charge points was out of order, the other was in use charging one of the company electric vans, and there were petrol cars parked in the charging bays. We had to get the company to find one of the drivers and get them to move, and to get the driver of the van to unplug for us. By this point we had wasted 20 minutes or so, and so I plugged in quickly and walked away to get to the meeting we were now late for.

As it turns out, for some reason it wasn't charging. So when we got back to the car ready to go, it was still at just under 20% charge: not enough to get home!

The lesson there was to check the car is charging before walking away. Some of the charging points are quite complex to operate and it's easy to get it wrong. Part of the exercise was learning how these points work. I have also found some settings on the car itself which will get the car to alert me via email and SMS of the charging status, so I can now know if the charging hasn't started, or if it has stopped for some reason.

Anyway, we checked the map and there was a fast charger at the Renault  car dealer in Portsmouth, about 5 miles away. So we headed over there, plugged in, and sat chatting for 30 mins, during which time Nick made some calculations as to how much charge we needed to get home. He estimated 80% would do it. We checked after 30 mins and it was just over 80% and he pressured me to go, as he had a long way to get home. In retrospect we should have waited another 15 mins to get to 100%, because after we set off, the satnav helpfully told us we probably didn't have enough charge to get all the way. Part of this was due to the traffic conditions, and it was now also night so the drain of the headlights was a factor.

We replanned the route to go via Popham services where there was a charger, thinking we would nip into the services for half an hour for food. Unfortunately the single charge point at Popham came up with an error when I plugged in. I phoned the Chargemaster help line and they were very helpful and tried to reboot it, but it still didn't work. They suggested the post may have an electric fault and they would send an Engineer out during the week to fix it. Obviously that didn't help us.

In retrospect I would have taken the slightly longer route on the M3 where there were more options for charging, but at the time we planned the route we went for the shorter route on the basis we thought we could make it in one go.

So we had a bite to eat, and Nick checked the charge map. There were several options in Basingstoke up the road, although this was getting close to the range we had left. The nearest was a hotel, so we headed there. When we got there, it turned out to not be a proper charging point: it was basically a commando socket on the wall of their barn.

Legacy commando charging point at the hotel

It was totally useless to us. At that point the car was showing a battery level warning. So we headed for the next closest one with fingers crossed.

The lesson there is to check the compatibility. These older, incompatible charge points are few and far between but they do exist and can catch you out if you don't check the description properly.

I should note that the range shown on the ZOE is less than what you can actually do. If you get very low the ZOE will go into a "limp home" mode which uses less battery but which severely limits your speed. We never got to this point. Also, part of the deal with the battery rental aspect of the ZOE is that you get free breakdown recovery if you do run out of charge: they will basically collect you and drop you off at a charge station.

Anyway the next charge station was at the AA offices in Basingstoke, a few miles away. We headed that way, holding our breath that it wouldn't conk out, parked up and plugged in. It was a standard charger so it would take quite a while to fully charge, but I only really needed enough to get home.

Nick jumped onto the train at the nearby Basingstoke railway station so he could get home and I wandered into Basingstoke town centre and played Ingress for about 45 minutes, and then headed back to the car which was now on 35% charge, and drove home.

So, the trip wasn't as smooth as I would have liked, but that was partly down to lack of familiarity with the charging set ups, not checking that the car was actually charging at the office, and inexperience with planning the route. If the car had fully charged at the office then we should have been able to make it all the way home on a single charge, just as we had done on the way down.

 I would certainly do it again, but I would make sure the car was charging properly next time.

UPDATE: I thought I would show the charging information for this day. This is a screen shot of part of the Renault ZE services website where you can view this sort of data.

It's in reverse chronological order (latest at the top). You can see I had charged to 100% the previous day. When I arrived in Portsmouth the next day I was down to about 18% (not shown here). Then we drove to the fast charging point and got there with 12% left. We recharged to 83% before we left, next stop Basingstoke.

We actually charged twice at Basingstoke: I plugged into the charger and sat chatting to Nick whilst he looked up the train times from Basingstoke on his phone, and then unplugged and ran him to the railway station before returning to the charge point for a longer charge so I could get home.

Once I got home I was down to 10%. To charge from 10% to 100% on my home charger took just under 4 hours.

EV Charging

A lot of people ask me about charging my Renault Zoe EV. Here's the situation

Home Charging

There's a couple of schemes that seem to be running to facilitate the installation of a charging point at your home. I took advantage of the offer to have a free charging point installed by Chargemaster. I have higher capacity 30A unit which is attached to the outside wall of my garage.

Chargemaster Home Charging Unit

In fact I did pay a small additional fee to get the higher-capacity unit, but they also fitted a new breaker panel in my garage as well. The higher capacity unit require a suitable electrical feed, but as I already had 40A cabling and breakers into my garage, the high capacity unit was available to me. The high capacity unit will fully charge the battery in about 3-4 hours. In most cases I will just be "topping off" the charge as my day-to-day usage is pretty low. The unit has a lock so it can't be used by random people driving past.

Charging Unit close up

When the unit is unlocked, it will charge, but the cable, once inserted, is locked into the unit and cannot be removed until the charge unit is unlocked.

The Chargemaster installations are being done as part of a Government subsidy scheme. In return, you allow them to gather data on your charging. In fact anyone with off-street parking can have a free charger installed; you don't even need to have an electric car! The aim is to get EV owners to encourage their family, friends, and work locations to install them. I'm trying to get my parents to get one installed, so I can charge when I visit them.

The installed charge point includes a SIM which transmits status and usage data to the Chargemaster server. You also get a free Chargemaster RFID card which gives you access to any of the public chargers in their charging network (see below).

As well as Chargemaster collecting your charging usage data, they present it to you on a website:

Chargevision Web Site

This includes details of usage of public charging points, like this one I used in the Bracknell Waitrose the other day:

Log of usage of public Chargemaster  charging points

The care itself also gathers stats which you can view by logging into Renault's ZE Services web site:

Renault Z.E Services website status page

Charge History

Public Charging

As well has encouraging home charging, the UK Government has been encouraging schemes to install chargers in public places. A number of schemes exist including the Chargemaster/Polar network, which I get free access to for at least a year by having one of their home charging units, Ecotricity, and a number of local schemes in London which fall under the Source London banner. Most of these operate by having RFID unlockable chargepoints which you can apply for a card for. The public charging points are typically located at car parks of various types.

I've detailed a couple of the key ones.

Polar Network

This is the Chargemaster scheme which I currently have a free RFID card to use charging points all over the country. In my local town, Reading, there are at least 3 public points. Nearby Bracknell has a couple including this one I used in the Waitrose car park, whilst shopping:

Their website also has a map where you can locate chargers, and see the status of them:

Example of Chargemaster charging point map

Ecotricity

Ecotricity is one of the large energy supply companies in the UK. They have a eoclogical emphasis compared with most of the other companies. Locally to me they have a large windmill which, amongst other uses, can be used by EV owners to charge their car.

Ecotricity Windmill at Reading

Ecotricity are also installing rapid charge points in many of the Welcome Break service stations on the UK motorway network. Rapid chargers will give you an 80% charge in around 30 minutes. The Ecotricity charging network is currently free to use.

Ecotricity Charge Point Map

General

There are also a number of websites like ZapMap and some associated phone apps which give you details of local charging points.

Zap Map UK charging points

Zap Map details of a charging point.

So, as you can see, in the UK there are plenty of options for charging an Electric Vehicle.

Renault Zoe "unboxing"

Today, after a few months of waiting, my Renault Zoe EV arrived.

My new Zoe, arriving on the transporter

Zoe being unloaded

I've been considering an EV for quite a while. A few years ago I was driving a ten year old, 4x4 Renault RX4 which was hardly "green". It had a 2 litre petrol engine and if I drove it carefully, I could get 45 MPG from it, but with normal driving I would be lucky to get 30 MPG.

I should point out I'm not a petrol-head in any ways. In fact I'm not fond of cars. My BMW, Merc, and Porsche loving neighbour wouldn't get this, but to me a car is simply a nice way to get from A to B.

I should also point out I do live in the country, as you can probably see from the photos, so a car is essential as the nearest town with a supermarket is about an hour's walk away. I need a car to do shopping, to get the kids to school and, in a lot of cases, to get to work. The 4x4 used to be genuinely useful, but hasn't really been in the last few years.

But, and this is the important bit, the vast majority of my journeys are under 10 miles. I rarely drive more than 20 miles in any given day.

We also have another car which runs on diesel which my wife uses. She commutes in it too but, like me, doesn't do journeys more than about 20 miles per day. If we need to do a longer journey, which is rare, we can use this car.

So, an EV is something I could use.

Of course, one of the major problems is cost. EVs have been considerably more expensive. However, with the current Government incentives, EVs like the Nissan Leaf and the Zoe are actually roughly the same price as equivalent cars. Sure there are cheaper cars, but that's not the point.

Another factor is that I run my own company. A lot of the travel I do is on company business but, as a director, if my company buys a car for me to use, I get stung with tax. Unless I buy an EV for, at the moment, the Government "Benefit In Kind" (BIK) for taxation purposes on EVs is... zero! So I don't pay any additional tax. I can also claim 50% of the VAT through my company.

So, with the cheap fuel, zero cost tax disc, no BIK, and 50% VAT offset, an EV makes a lot of financial sense.

I'm actually getting the Zoe on a 3 year lease as, currently, battery technology is improving by around 20% per year, and the costs of building EVs are also reducing year on year. I don't want to be stuck trying to resell a vehicle which is considered obsolete in a few years time. The lease allows me to refresh my car without such issues in 3 years time. I fully expect to get another EV then, but with improved battery capacity and range and maybe with the option of a range extender. You never know, there might even be some Hydrogen Fuel cell range extenders by then.

But for now, the Zoe is where it's at, and I'm loving it.

Roland V-Studio 20 with Linux

Introduction

I recently acquired a Roland V-Studio 20 unit cheaply (£99 from Dawsons). It was a unit I had been interested in, and I have recently been having some discussions about this unit on another forum.

When I saw how cheap it was going for at Dawsons, I had to give it a try. One of my motivations was to see if I could get it working under Linux. This post describes how I got on. It also sort of doubles up as a review and technical description of the V-Studio 20 (VS-20).

Overview of the V-Studio 20

The V-Studio 20 is a computer audio interface, digital FX system and control surface designed for guitar and vocal use. The unit connects to a USB interface on your computer which also powers the unit. There is no option for an external power supply; this has to be used with a computer.

It is designed to be easy to use, and allows you to connect a guitar, bass, or mic directly in (with phantom power support if required). Of course you can also connect any traditional guitar pedals in front of it if you prefer to use them. It also has built in stereo microphones.

The guitar FX and amp/cabinet emulation and vocal processing are based on the latest Roland COSM technology, and you have the option to record "wet" (with FX) "dry" (with FX enabled but not recorded) or to completely bypass the FX. You can also "re-amp" by applying the FX to a previously recorded signal..

Whilst the FX are controlled by software on the computer, the processing is done on the unit itself, not through computer plugins. This means that it places no load on your PC, and can support zero-latency local monitoring.

There are audio line outputs which can be connected to an amp or active speakers as well as a headphone output. The unit also has connections for foot pedal controls.

The control surface has transport controls (stop, record, fast forward, etc.) and faders. These are designed to work in conjunction with software on a PC (the unit itself is not a mixer), and it is supplied with a simple DAW application "Guitar Tracks".

It is also a 24-bit interface which, as I previously mentioned in my Digital recording in a home studio blog, is important to maximise the quality of recordings.

Using with Linux

Drivers and ALSA

Unlike Windows and Mac systems, the approach Linux takes with drivers is different: most of them are already built in. This is because most peripherals are actually based on common standards. When you get a "driver" for a Windows PC, quite often it isn't a program, but really just a configuration file for built-in drivers.

Under Linux, the standard audio subsystem is ALSA (Advanced Linux Sound Architecture). This is equivalent to ASIO on Windows or CoreAudio on Mac. It's a low-level, low-latency sound driver architecture. It has various modules to handle different types of audio interface and protocols. The most common one for USB devices is snd-usb-audio.

With snd-usb-audio, USB sound cards are often completely plug-and-play on Linux, with no driver installs needed.

Unfortunately, whilst most USB audio is fairly standard, there are some vendors that have added additional capabilities, have bugs in their implementation, or are using relatively new or uncommon features. In order to support these the snd-usb-audio module supports a system of "quirks" where a data block can be used to describe a specific device in more detail. Without this data block, some USB audio devices were not recognised by Linux.

Furthermore, to introduce a quirk for a new device requires a new kernel to be built. This is a barrier for typical end-users. In most cases end-users have to wait for someone else to develop the quirk for the device, and for that change to make it through to a production kernel. In the past I have been one of those people who have submitted quirks into ALSA (and, subsequently, into the Linux kernel) for audio devices.

Here is an example of one of the quirks I have previously submitted:

        /* Boss JS-8 Jam Station  */
        USB_DEVICE(0x0582, 0x0109),
        .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) {
                /* .vendor_name = "BOSS", */
                /* .product_name = "JS-8", */
                .ifnum = QUIRK_ANY_INTERFACE,
                .type = QUIRK_COMPOSITE,
                .data = (const struct snd_usb_audio_quirk[]) {
                        {
                                .ifnum = 0,
                                .type = QUIRK_AUDIO_STANDARD_INTERFACE
                        },
                        {
                                .ifnum = 1,
                                .type = QUIRK_AUDIO_STANDARD_INTERFACE
                        },
                        {
                                .ifnum = 2,
                                .type = QUIRK_MIDI_STANDARD_INTERFACE
                        },
                        {
                                .ifnum = -1
                        }
                }
        }
},

ALSA support for Roland

Earlier last year (2013) a couple of the main ALSA developers recognised that there were an increasing number of quirks being added for some vendors equipment (including BOSS/Roland) and that these quirks were all very similar in nature. They then developed changes to snd-usb-audio which provided generic support for Roland devices so that future per-device quirks shouldn't be needed. These changes are now in the newer kernels and should allow full support for most current Roland and Boss audio cards.

For this support you will need a v3.10 or later kernel. Part of my motivation for purchasing the VS-20 was to test this.

To do this I had to compile my own kernel. I was using an older version of Linux Mint (v13) but even the newer versions aren't using the latest kernels yet. I downloaded and compiled the latest stable kernel release, 3.12.7, installed it, and rebooted. After some shenanigans with my Nvidia drivers, I got it working and checked for the sound card. It was there and worked perfectly.

Jacked up

The default sound system on most desktop Linux systems is Pulseaudio. This sits over ALSA and provides the ability to select between audio interfaces and to adjust input and output levels. It's a very flexible system but isn't really suitable for pro-audio use for many reasons. For pro audio use on Linux, we use Jack Audio Connection Kit (JACK for short). JACK does many cool things, including allowing you to connect the audio or MIDI output from one application into the audio or MIDI input of another.

With the latest kernels, the VS-20 works perfectly with JACK.

JACK allows the user to tweak the buffers in order to balance latency versus CPU load, very similar to ASIO. As I'm not worried about latency too much (due to the built-in monitoring on the VS-20) I set my settings pretty conservatively as shown below:

This gives nearly 35ms delay, which is quite a lot, but it reduces the occurrence of buffer glitches known as "xruns". Low latency is normally only important for real-time audio monitoring. If you are relying on PC based plugins to handle processing, then latency is important as the audio has to go from your sound card, to the PC, through the plugin, and back to the sound card. Each of these adds a little delay to the signal which can all add up to horrible latency unless you tweak and tune your system.

In the case of the VS-20, the processing is all done onboard the unit and there is a zero-latency monitoring point on the VS-20. As such, I don't have to worry about minimising latency.

In and Out

The VS-20 provides a stereo input and output pair, plus two MIDI inputs and outputs. Note the VS-20 has no MIDI synth capability: the MIDI ports are used for control purposes. Here's how JACK reports the device:

Tue Jan 14 13:30:42 2014: Starting jack server...
Tue Jan 14 13:30:42 2014: JACK server starting in realtime mode with priority 10
Tue Jan 14 13:30:42 2014: control device hw:2
Tue Jan 14 13:30:42 2014: control device hw:2
Tue Jan 14 13:30:42 2014: Acquired audio card Audio2
Tue Jan 14 13:30:42 2014: creating alsa driver ... hw:2|hw:2|512|3|44100|0|0|nomon|swmeter|-|32bit
Tue Jan 14 13:30:42 2014: control device hw:2
Tue Jan 14 13:30:42 2014: configuring for 44100Hz, period = 512 frames (11.6 ms), buffer = 3 periods
Tue Jan 14 13:30:42 2014: ALSA: final selected sample format for capture: 24bit little-endian
Tue Jan 14 13:30:42 2014: ALSA: use 3 periods for capture
Tue Jan 14 13:30:42 2014: ALSA: final selected sample format for playback: 24bit little-endian
Tue Jan 14 13:30:42 2014: ALSA: use 3 periods for playback

Note that it reports it as a 24-bit device with a sample rate of 44.1kHz.

Controlling the VS-20

One of the potential stumbling blocks with using the VS-20 on Linux is that it requires a PC based control program to manage and select the COSM effects.

The good news is this works without an problems on WINE. In fact, the filename for the download from the Roland site was "vs20_wine_v100.zip". This was a point and click install for me.

The VS-20 Editor provides full control of the VS-20 through an emulated pedal board model, where patches can be edited, selected and saved. It communicates to the VS-20 through one of the MIDI ports. On Windows the driver names this MIDI port to make it obvious which one to use. On Linux the generic driver just calls the MIDI ports "VS-20 MIDI 1" and "VS-20 MIDI 2". FOr the VS-20 Editor, you need to use MIDI 2.

Here is the VS-20 Editor running on Linux:

Using with a DAW

Using the VS-20 with a DAW at a basic level is as simple as any other sound card. I used it with Ardour 3 and you just connect the JACK inputs to tracks as normal. In fact Ardour normally does this for you when you create a new track.

Setting levels

Setting the recording level is important: there is an "OUTPUT LEVEL" control on the VS-20 itself, but this only seems to control the local output level, not the USB levels.

There is also an INPUT SENS control which seems to be the analogue preamp setting. The VS-20 manual suggests you set this so that the PEAK indicator occasionally goes on to get the best quality.

This may result in the recording level to the USB input being too high. To adjust this you need to use the VS-20 Editor and click on the SETTING button. You will get a pop-up which allows you to configure various settings including REC LEVEL:

This also lets you adjust the audio routing. A good way to approach this is to select the patch you want and then play (or sing) loudly and adjust the VS-20 INPUT SENS control to peak. Then watch the input meters on Ardour and adjust the REC LEVEL on the VS-20 editor so that the peaks are well below full-scale. (10-12dB is recommended).

You can then start recording.

Control Surface

The final piece of the puzzle in getting the VS-20 working optimally with Linux is the control surface capability. Each of the buttons and sliders on the VS-20 is a MIDI control. By mapping these controls to and application like Ardour 3, you can control the transport buttons, faders and so on from the VS-20, which is quite cool.

The only problem I had with this is that the way control surfaces are defined in Ardour 3 is slightly restrictive in that the MIDI feedback cannot be configured. On the VS-20, for instance, the track arm buttons have LED indicators. When you press one of the track arm buttons it sends a MIDI Note On to Ardour, but Ardour assumes that the feedback MIDI message back to the VS-20 should be the same Note On. On the VS-20 it is not. This means that, whilst you can control Ardour from the VS-20, the LED lights do not reflect the status of the controls. This isn't a big issue as under normal circumstances you will have the Ardour screen in front of you, and will read the status from that.

It may be possible to use qmidiroute or similar to translate the default Ardour feedback into the correct MIDI event, and I may experiement with that. For any Ardour 3 users, the MIDI Control surface definition is attached below:

<?xml version="1.0" encoding="UTF-8"?>

<ArdourMIDIBindings version="1.0.0" name="Roland V-Studio 20">

<DeviceInfo bank-size="8"/>

      

<!-- Track Group UP -->

<Binding channel="1" note="47" function="prev-bank" momentary="yes"/>

<!-- Track Group DOWN -->

<Binding channel="1" note="46" function="next-bank" momentary="yes"/>

<!-- Transport controls -->

<Binding channel="2" note="33" action="Transport/GotoZero" momentary="yes"/>  <!-- Fix for non-working transport-zero action -->

<Binding channel="1" note="91" function="transport-start" momentary="yes"/>

<Binding channel="1" note="92" function="transport-end" momentary="yes"/>

<Binding channel="1" note="93" function="transport-stop" momentary="yes"/>

<Binding channel="1" note="94" function="transport-roll" momentary="yes"/>

<Binding channel="1" note="95" action="Transport/Record"  momentary="yes"/> <!-- Makes record toggle -->

<!-- Track Select -->

<Binding channel="1" note="24" uri="/route/recenable B1"/>

<Binding channel="1" note="25" uri="/route/recenable B2"/>

<Binding channel="1" note="26" uri="/route/recenable B3"/>

<Binding channel="1" note="27" uri="/route/recenable B4"/>

<Binding channel="1" note="28" uri="/route/recenable B5"/>

<Binding channel="1" note="29" uri="/route/recenable B6"/>

<Binding channel="1" note="30" uri="/route/recenable B7"/>

<Binding channel="1" note="31" uri="/route/recenable B8"/>

<!-- Faders -->

<Binding channel="1" pb="0"   uri="/route/gain B1"/>

<Binding channel="2" pb="0"   uri="/route/gain B2"/>

<Binding channel="3" pb="0"   uri="/route/gain B3"/>

<Binding channel="4" pb="0"   uri="/route/gain B4"/>

<Binding channel="5" pb="0"   uri="/route/gain B5"/>

<Binding channel="6" pb="0"   uri="/route/gain B6"/>

<Binding channel="7" pb="0"   uri="/route/gain B7"/>

<Binding channel="8" pb="0"   uri="/route/gain B8"/>

<!-- Gain controls -->

<Binding channel="9" pb="0" uri="/bus/gain master"/>

</ArdourMIDIBindings>