Saturday 25 January 2014

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.








Thursday 23 January 2014

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.

Tuesday 14 January 2014

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>

Digital recording in a home studio

Maximising Quality

When recording performances (music, spoken word, etc.) the aim is normally to capture the best recording possible from the start. This typically means using good quality microphones, pre-amps, and high-quality recording mediums.

In the analogue world the de-facto recording medium was tape, with professional studios using reel-to-reel tape systems costing many thousands of dollars, and would purchase good quality tapes. In the digital world, the medium is data, and the equivalent of the tape machine is the Analogue to Digital Converter (ADC). In a home studio environment the DAC is normally built into the sound card.

In order to maximise quality a good quality sound card should be used with decent pre-amps, low noise, and a reasonable quality ADC.

But to maximise quality, it is important to follow some good recording techniques.

Resolution and bits

Audibility

In the digital world, it is important to consider resolution. Normal full-resolution digital audio follows the "Redbook" standard which defines the format used on audio CDs: 16-bit resolution, 44.1kHz sample rate. This resolution was based around the principle that it fully captures all audio that can be heard by humans. That principle stands today. There are some who claim otherwise, but their claims defy the substantial weight Science and Engineering. They are extraordinary claims which, therefore, demand proof. To date no such proof has been given.

For further information on this subject, I recommend the Xiph article 24/192 Music Downloads ...and why they make no sense.

16 bits of resolution, when used properly, supports a dynamic range of up to 120dB, which will let you listen to music so loud that your ears bleed, whilst the quietest possible sounds are masked by the thermal noise in the components in your amplifier.

Why you should record at 24-bit resolution

When recording, it is recommended to record audio with a 24-bit resolution. If this additional resolution isn't audible, why is this?

To understand this, we need to look at the recording process.

One of the most difficult parts of recording audio is maximising the quality of the recording when recording to a medium with a limited dynamic range. When capturing audio we want to capture even the smallest nuances of sound and so we want to capture a wide dynamic range, but this is difficult when dealing with everything from loud drummers to soft vocal nuances. Traditional analogue tape machines had a relatively low dynamic range of around 60dB (top end systems could get to 80dB) and getting the recording level set to maximise the quality of the recording was always a challenge.

For digital, 16 bits is enough to capture the full range of audio and exceeds the dynamic range of tape. However, it is only just enough, which means that a slight error in setting the recording level can result in loss of quality.

This is compounded by the fact that digital ADCs are far less forgiving of errors than their analogue equivalents. If you set the recording level a bit too high with tape, the tape naturally compresses the audio and it still sounds good. By setting the levels so that VU meters peaked occasionally, you maximised the dynamic range without significantly compromising the audio quality. With digital, if your signal peaks, it has a devastating impact on the audio: it simply chops the top off the audio!!

Trying to maximise the recording level with digital recording is a very, very bad idea!!!

The generally accepted rule is to record so that your peaks are 10-12 db below the maximum level (known as 0dBFS). This prevents any unexpectedly loud peaks from hitting 0dBFS and getting chopped.

However, by doing this, you are reducing the amount of dynamic range you can record by 10-12 dB.

The answer is to increase the dynamic range of the recording system. We can do this by recording in 24-bits. This increases the dynamic range so much that you can actually turn the recording level down far below this, almost to the point where you can't hear the audio on the recording, use digital gain to make the signal audible again, and you shouldn't lose any audio quality.

Simply put, using 24-bit to record removes any issues of dynamic range in the digital domain, which makes making good quality recordings easier.

You still have to consider analogue

Although recording in 24-bits removes the dynamic range constraints from the digital part of the recording chain, prior to the ADC there are a lot of analogue components that still need to be considered, and optimised. As a minimum, there will be some sort of analogue audio pre-amp before the ADC input and if this isn't fed with a good signal it will result in poor quality recordings. There may also be microphones and mic type, directionality, placement, and room acoustics all play a part in this as they always have done. Just because using 24-bit to record solves one part of the recording equation, that doesn't mean you can ignore the other parts.