What’s the difference between resistor types?

Assorted resistors. Which type is useful when?
(Source: Wikimedia Commons)

Anyone who’s ever had to buy resistors from sites like RS, Farnell or DigiKey will know that there are myriad types to choose from: “carbon composite”, “wire-wound”, “carbon film”, “metal film”… what do these mean, and in which applications are they useful and harmful?

Carbon composite resistors


  • Cheap
  • Withstand high current transients


  • High temperature coefficient
  • Resistance drifts with time when used with high current
  • High tolerance

These are made from conductive carbon dust packed together with clay, with the ratio determining the resistance. They are generally available only for low power applications, but can withstand short high current bursts. The material properties are such that it is difficult for manufacturers to precisely define the resistance, so tolerances are generally poor. The temperature coefficients of carbon composite resistors are also generally poor (typically 1000 ppm/°C or greater), meaning that these resistors are useful mainly for hobby and general purpose circuits.

Carbon composite resistor. These have mostly been superseded by film resistors.
(Source: Wikipedia)

Carbon composite resistors have been largely superseded by film resistors, of which there are two main types: carbon film and metal film.

Film resistors


  • Low temperature coefficient
  • Low tolerance
  • Available with very high resistances


  • Tenancy to be damaged by current overloads
  • Generally only available in low power ratings

Film resistors are the bread-and-butter of most designs. They are made with a mix of ceramic and metal (“cermet”) or metal oxide deposited in a film over an insulating substrate. The resistance is determined by the deposited thickness of the film, and very high resistances can be achieved in small packages with this technique. Precise tolerances are reached during manufacturing by using a laser to etch a spiral around the film to create a longer effective path around the outside of the substrate.

Carbon film resistor with exposed film. Note the spiral etched into the film at the factory to trim to a precise resistance.
(Source: Shaddack, via Wikimedia Commons)

Film resistors have very good temperature coefficients (typically 50-1000 ppm/°C, with carbon and metal types tending to have opposite signs), providing stability for precision circuit applications. Due to the deposition of layers of metal without a clay matrix, these resistors are susceptible to damage from high currents and therefore are not generally available in high power packages.

Wire-wound resistors


  • Suitable for high current applications


  • High series inductance
  • Only available with relatively small resistances

Wire-wound resistors are, as the name suggests, made by tightly winding conductive wire around an insulating substrate. The thickness (“gauge”) of the wire and the number of turns made determine the resistance, but this creates a volume constraint and so these resistors are typically only available with small (less than 100 kΩ) resistances.

Available tolerances are typically fine for most applications, but precision laser trimming is not an option unlike with film resistors and so tolerances are generally not lower than 1%.

Wire-wound resistor. Note the metal packaging and ability to mount the resistor to a panel for good heat sinking.
(Source: Olli Niemitalo via Wikimedia Commons)

Given the relatively thick (thin wire is still much thicker than film) conductors used in the construction, these resistors are able to carry large currents and are available in very high power packages – 50 W or more – making them ideal as heating elements (intentional or otherwise). The downside, however, is that the wound wire creates a coil which induces an electric field in the middle, creating a phase shift in signals particularly at high frequencies. Some wire-wound resistors combat this effect by counter-winding the wire to cancel the inductance, but it is difficult to remove the inductance entirely. Use of wire-wound resistors in precision circuits – which typically don’t require high power anyway – is discouraged in favour of film resistors.


Spectra Microvision Plus install guide for modern operating systems

The Spectra Microvision Plus is a nice residual gas analyser (RGA), allowing one to examine the elements and molecules present within a vacuum system. In the speed meter group at the Institute for Gravitational Research, we use it to test our vacuum system for cleanliness, leaks and the presence of unwanted elements before we place our delicate optical surfaces inside and shine high power lasers upon them.

Spectra Microvision Plus. This box is able to analyse the residual gas profile of a vacuum system, but it’s tricky to install the aged software on modern machines.

Despite being around 15-20 years old, this hardware is solid and still works nicely. The problem is that the software used to control the box is a similar age, and has well and truly suffered from bit rot. In fact, it came with the unit in the form of three floppy disks. These were old even when I was growing up, and CDs and later DVDs became the standard distribution channel for software. Adding insult to injury, the software is only designed to work on Windows 3.1 (!), 95, 98 or XP, meaning any modern computer is going to struggle to run it. Finally, it demands a physical RS-232 connection to the machine, since it harks from the days when USB was but a teenager with braces and oily hair, and Apple and IBM were still preventing one standard from ruling them all by pushing FireWire.

Incidentally, if you’re looking to download the Spectra RGA For Windows software that is used with the Spectra Microvision Plus, it’s unfortunately not available directly from the manufacturer. They apparently insist on users paying $2k for newer hardware. If you want the software, though, just send me an email – I’ve made images of the floppy disks for safe keeping.

Spectra RGA For Windows software running on VirtualBox on a Linux host

I managed to get the software to work by using VirtualBox to emulate Windows XP on a Linux host. I run Ubuntu on my machine, so VirtualBox is easily installable via the package manager. Fortunately, my university still has XP campus licences kicking around, so I fired up an ISO and installed XP as a virtual machine within VirtualBox. If you need to know how to install XP on VirtualBox, just google it. If you run Windows or Mac OSX, don’t dismay – VirtualBox is also available on those platforms, so this will still work provided you can obtain a Windows XP disk or image.

Interface to RS-232

Now comes the slightly more tricky part. As stated earlier, the RGA uses RS-232 for communication between the hardware and the RGA For Windows software, and modern computers don’t come with RS-232 ports. However, given that USB is, eponymously, universal, you can buy an adapter which emulates an RS-232 serial interface over USB for a few pounds:

RS-232 to USB adapter. Could it be any simpler?

I got mine from StarTech.com, but you’ll find them anywhere with a quick search. Ubuntu 16.04, but probably all recent Linux kernels, supports this adapter out of the box, giving you a virtual RS-232 port that you can hand over to the virtual machine.

If you use Ubuntu or a Debian derivative, make sure your user account is part of the “dialout” group (run usermod -a -G dialout [your-username] as root, then log out and back in again), otherwise you won’t be able to read from and write to the serial adapter.

Once you’ve got an RS-232 USB adapter, plug it in and fire up VirtualBox after having installed Windows XP. Before starting the operating system, however, you need to tell VirtualBox to pipe the RS-232 connection through to the virtual Windows XP system. In the settings for the Windows XP virtual machine, go to “Serial Ports” and enable Port 1. Then choose “COM1” for the port number and “Host Device” for the port mode, assuming that your kernel has successfully identified the adapter (run dmesg in a terminal and look at the kernel messages to check). Put /dev/ttyUSB0 as the Path/Address, but check that this is actually the path to the serial adapter you plugged in (again, use dmesg or similar to find out). Once this is done, you should be able to fire up Windows XP and look in the device manager to see a new COM port present.

Installing, configuring and running the RGA For Windows software

Given that the software was distributed on floppy disks, I first had to get a USB floppy disk drive and create images for each of the three disks (using dd in the terminal – again, Google is your friend). VirtualBox can mount these images in turn, allowing your virtual Windows XP machine to think it actually has a real floppy disk drive attached. I inserted the first “disk”, opened up “A:” in Windows and started “INSTALL.EXE”. It is very simple: after clicking next a few times and inserting the second and third virtual floppy disks when asked, it was installed.

To get the software to run, the first thing to do is to run the “Configure” program from the start menu. For me, it found the only COM port configured on the computer (COM1) and was happy. After that, fire up the “RGA” software with the RS-232 connector plugged in to the Spectra Microvision Plus unit. You should be presented with the default screen – hurrah! – and after that, you can take some measurements. Here is a screenshot of the RGA For Windows software running on a Windows XP virtual machine, itself running on Kubuntu 16.04:

The Spectra RGA For Windows software running on a virtual Windows XP machine, running on an Ubuntu host.

There we go! A virtual machine that is able to talk to the Spectra Microvision Plus RGA, future proof and fit for modern operating systems. Hopefully this allows this old but solid hardware to continue to serve a purpose in modern research labs. Let me know if you run into any issues when getting the software to work – I’d rather not let Spectra hustle thousands of dollars out of customers just by refusing to update or release 20 year old software…

Real time updating slideshow with webcam photos

I recently hosted a Halloween party and I thought it would be a cool idea to have my Raspberry Pi set up to take photos every few seconds and display them in some sort of slideshow. After a few hours of tinkering with my Raspberry Pi and Camera Module (technically the Pi Noir module), I ended up breaking the camera by sticking it too violently to a mount with Blu-tac. Oops. Not to worry though – I fished out a decent USB webcam and hooked it up to my laptop instead. I didn’t get to use my Raspberry Pi in a nerdy way, but this still did the job.

On the laptop I ran standard webcam software (Cheese) which saved the photos into a specified directory (/home/sean/Pictures/Webcam/). I then ran a cron job every five minutes to synchronise these photos with my web server. In the crontab, I specified a line:

# m h  dom mon dow   command
*/5 * * * * /home/sean/scripts/sync-photos.sh

And in /home/sean/scripts/sync-photos.sh I made an executable script with the following contents:


cd /home/sean/Pictures/Webcam/
rsync *.jpg user@example.com:/path/to/web/directory/halloween/

I had already setup my laptop user account with an SSH key for the server, meaning the rsync command would not ask for a password. This can be done quickly on Ubuntu by doing something like this (but you should Google for a proper guide if you’re unsure):

~$ cd ~/.ssh
~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa): <filename here>
Enter passphrase (empty for no passphrase): <password here - this can be blank>
Enter same passphrase again: <password again, or blank>
The key fingerprint is:
a1:a3:32:ff:24:dc:ff:21:10:44:0e:ed:95:c2:ac:e3 user@hostname
The key's randomart image is:
+--[ RSA 2048]----+
<random art>
~$ ssh-add -i <filename here>

So now, anyone taking a photo with the webcam would have their photo uploaded to my server. So far, so good. I still needed some way of displaying the photos. It turns out that there don’t seem to be very many decent, free and open source slideshow scripts which work in a browser and update their slideshow images periodically. Since the server would potentially receive a bunch of new photos every five minutes, I couldn’t be hitting refresh all night.

I ended up using a nice, simple slideshow script called slides.js. It uses jQuery, a really awesome Javascript library which makes Javascript a bearable programming language. I then crafted a bit of AJAX to grab the directory index page. By default, Apache web server will list all files in a directory if there doesn’t exist a file called index.html, index.php or similar. Index pages are predictable structure – they use simple HTML lists to display a link to each file – so it’s easy to grab out the relevant data with jQuery.

Finally, I had to find a way to update the slideshow periodically. This was not done with Javascript, but rather a rudimentary piece of HTML in the page’s header which tells the user’s browser to refresh every X seconds. I set this to fifteen minutes.

Here is the full slideshow script, which sits in the same web-accessible directory as the images on the server. I also added a piece of code to shuffle the images found in the directory, just to mix things up a bit!

<!DOCTYPE html>
    <meta http-equiv="refresh" content="900">
    <script src="jquery.js"></script>
    <script src="jquery.slides.min.js"></script>
      #slides {
      /* Prevents slides from flashing */
      /* Sets width of photos to fit the screen (in my case, 1750px) */
	width: 1750px;
      function shuffleArray(array) {
	for (var i = array.length - 1; i > 0; i--) {
	  var j = Math.floor(Math.random() * (i + 1));
	  var temp = array[i];
	  array[i] = array[j];
	  array[j] = temp;
	return array;

      function getImages() {
	var images = [];

	  url: "http://example.com/path/to/images/",
	  success: function(data){
	    $(data).find("td > a").each(function(){
		var name = $(this).attr("href");

		if (name.slice(-4) == '.jpg') {

	    // randomise
	    images = shuffleArray(images);

	    var imgstr = "";

	    for (var i = 0; i < images.length; i++) {
	      imgstr += "<img src=\"" + images[i] + "\">";


		//width: 200,
		//height: 200,
		play: {
		  active: true,
		  effect: "slide",
		  interval: 5000,
		  auto: true,
		  swap: true,
		  pauseOnHover: false,
		  restartDelay: 2500

    <div id="slides"></div>

The above script cannot be saved as index.html, otherwise it won’t be able to get an index page list of the files in the directory! There are ways around this, e.g. with PHP or similar, but as this was just a hack I renamed the file to slideshow.html.

With all of this set up properly, I opened a browser on my TV, pointed it to this script and entered into full screen mode. It displayed a nice slideshow of photos people took of themselves on my laptop, and updated throughout the night with the latest photos. Awesome!

Sonos-Like Synchronised Streaming, Part 2

In my last post I outlined my intention to make a Sonos-like audio streaming system. Today I managed to get a single Raspberry Pi playing music from a Spotify through a server on my home network. I’ll explain how I did it, and what I’m going to do next.

As I hinted at in my previous post, I don’t particularly fancy playing about with a Perl behemoth like Logitech Media Server. It also just seems a bit of a dead end to me – the server’s code is open source, but it’s hosted by Logitech, and it was open-sourced after they mothballed their Squeezebox range. Who can say how long Logitech will keep hosting and maintaining the code? Surely they will lose interest, without a product range to back up their investment of time and money. Additionally, the software seems so featureful that the community aren’t forking it and actively adding new features or refactoring the code. This state of play led me to try to find another solution, and it seems I have found it in Mopidy.


Mopidy is a Music Player Daemon (MPD) service, hence the name. It supports a subset of the standard features of MPD, but most of the important ones. Staying close to MPD means that Mopidy can be controlled with one of the many MPD clients available. For instance, during my testing I was using ncmpcpp, a terminal client.

The feature I love about Mopidy is that it is written in Python. I can open it up and work out what’s going on, with enough effort, and I can add extensions if I am so inclined. It also supports PulseAudio, which brings me on to the next part of the setup…


PulseAudio is a piece of software that acts as an interface between audio sources (programs, games, microphones, etc.) and audio ‘sinks’. A ‘sink’ is a place where audio goes, be it a sound card, an audio editor or a network stream. PulseAudio supports streaming via RTP, which brings me on to the next part…

Real-time Transport Protocol

Real-time Transport Protocol, or RTP, is a method of transport on networks which tries to make sure that data is sent in a timely fashion. It is intended for use with audio, and often forms part of VoIP packages a la Skype. We can tolerate packet loss with audio, in favour of keeping everything timely.


Since I currently only have two Raspberry Pis, and one is spending its life forwarding electricity and temperature data to another server, I can only set up one Pi as a receiver. This is a good opportunity to test the concept of the Mopidy-PulseAudio-RTP audio stack.

In terms of hardware…

  • I need a server to host Mopidy and stream its audio via PulseAudio-RTP. I have a Philips Living Room PC Core 2 Duo server that’s about 5 years old that I use for this kind of thing, running, as of yesterday, Ubuntu 14.04 LTS Server Edition.
  • I have a Raspberry Pi, of course, with a 16 GB memory card with Raspbian. The 16 GB is only there because I don’t have any other SD cards larger than 2 GB (standard install Raspbian needs about 3 GB). Mopidy and PulseAudio won’t need anywhere near 16 GB of storage, and I’ll probably eventually strip out all the extra stuff in Raspbian I don’t use and copy the whole card to a 2 GB one. I am using headphones on the Pi to listen to music. The output jack won’t drive anything more powerful, so you’ll need an amplifier if you want to play music through speakers. It’s also possible to output audio via the HDMI port, so that might work for others.
  • A laptop to control what’s playing. Not strictly necessary, if the server is also a useable desktop computer. You can also use one of the many MPD clients available for Android and iOS to control Mopidy, if you want.
  • A router running DHCP or similar, with every device connected to it. Again, strictly, the DHCP server can be the same as the music server, but I use my home router as the DHCP server so I’m using that. The Raspberry Pi and server are connected via wire to a switch which in turn is connected to the router. The room I’ve got this stuff set up in has only one ethernet wired connection, and I split it into two with the switch. The laptop is connected wirelessly.

In terms of software, this is what I’ve used:

  • Server: Ubuntu 14.04, PulseAudio, Mopidy
  • Raspberry Pi: Raspbian, PulseAudio
  • Laptop: Ubuntu 12.04, ncmpcpp terminal client


Here’s how to do it:

PulseAudio setup on both the server and the Pi

server~$ sudo apt-get install pulseaudio
pi~$ sudo apt-get install pulseaudio

That should work for both Ubuntu and Raspbian.

Next, set up an RTP sink on the server. Change directory and edit /etc/pulse/default.pa:

server~$ cd /etc/pulse/
server~$ sudo nano default.pa

Fill it with the following content:

#! /usr/bin/pulseaudio -nF

load-module module-native-protocol-unix auth-anonymous=1
load-module module-suspend-on-idle timeout=1

load-module module-null-sink sink_name=rtp format=s16be channels=2 rate=16000
load-module module-rtp-send source=rtp.monitor

This will set the audio sample rate to 16 kHz. This is low, but I found that setting it to 44.1 kHz or 48 kHz would congest the network to the extent it is unusable. I need to tweak this later and get it to work, perhaps using a separate network altogether.

Next, edit daemon.conf:

server~$ sudo nano daemon.conf

Leave everything in there, but uncomment and edit the line exit-idle-time to be:

exit-idle-time = -1

And uncomment and edit the line default-sample-format to:

default-sample-format = s16le

On the Raspberry Pi, configure the /etc/pulse/default.pa file:

pi~$ cd /etc/pulse
pi~$ sudo nano default.pa

Uncomment the line that says #load-module module-rtp-recv .

Next, edit daemon.conf on the Pi:

pi~$ sudo nano daemon.conf

Add at the bottom:

default-sample-rate = 16000
resample-method = src-sinc-fastest
default-fragments = 10
default-fragment-size-msec = 10

Mopidy and Spotify on the Server

Following the installation instructions from Mopidy, on the server, add the repository key:

server~$ wget -q -O - http://apt.mopidy.com/mopidy.gpg | sudo apt-key add -

Add the repository sources as a file:

server~$ cd /etc/apt/sources.list.d/
server~$ sudo nano mopidy.list

Add to the file:

# Mopidy APT archive
deb http://apt.mopidy.com/ stable main contrib non-free
deb-src http://apt.mopidy.com/ stable main contrib non-free

Update the repositories and download the packages:

server~$ sudo apt-get update
server~$ sudo apt-get install mopidy mopidy-spotify

Run Mopidy once to make it generate the configuration file:

server~$ mopidy

Press Ctrl+C to kill the server. Edit the file ~/.config/mopidy/mopidy.conf:

server~$ sudo nano ~/.config/mopidy/mopidy.conf

Edit the configuration options under [audio] and [mpd] to look like this (you can leave the commented values already there):

output = pulsesink device=rtp
enabled = true
hostname = ::
port = 9999

Set the port in [mpd] to whatever you want. I found the default Mopidy port was already used, even on the default Ubuntu 14.04 install, so I set it to 9999.

For Spotify, edit the values under [spotify]:

enabled = true
username = [username]
password = [password]

Obviously setting [username] and [password] as appropriate. I found that this pair was all I needed to get Mopidy to access my playlists successfully. It’s also possible to specify bitrates and timeouts, but I left these commented.

(Optional) ncmpcpp on Controller

Follow the instructions on the ncmpcpp website. I didn’t want to add the unstable Debian repository so I compiled it from source, but there are alternatives.

Getting it to Work

Everything is configured, so it should then be possible to start everything up and play music on the Pi. On the server, start PulseAudio as a daemon and Mopidy in userspace:

server~$ pulseaudio -D
server~$ mopidy &

Pay attention to /var/log/syslog if you have any trouble.

On the Pi, start PulseAudio:

pi~$ pulseaudio -D

Again, any trouble and check the syslog.

Now, play something on the server using the laptop or other controller:

laptop~$ ncmpcpp -h -p 9999

The IP address corresponded to my server. The port is set to the one I specified in the configuration.

In ncmpcpp, I can look at my Spotify playlists and play them, and I hear the tunes through my Raspberry Pi’s headphones. The music quality isn’t great, because I set the sample rate quite low. I will need to investigate network issues to see how to improve audio quality while keeping network congestion minimal. PulseAudio’s RTP uses multicast, and this in general is a heavy protocol. For instance, reports all over the web say it can floor a WiFi connection with ease. Sonos uses a separate wireless network, and presumably this is because quality and throughput can’t be guaranteed on a regular network.

So, I have the ability to play music across the network. Next up, I will get another Raspberry Pi and set it up to listen to the same stream, to test how multicast works with two clients. Hopefully the timing provided by RTP will mean the music steams will be in sync.

Credit to ianmacs’ posts on this Raspberry Pi forum thread, and this blog post from rozzin.

Sonos-Like Synchronised Streaming, Part 1

I got a Sonos kit a little while back through an employee offer at my old workplace. For anyone that doesn’t know, this is an easy-to-use solution to playing audio from local computers, internet radio, Spotify, Napster and so on. You buy a Sonos speaker and base station, and connect the latter to your internet connection. It finds network attached media servers and can interface with your Spotify account (or other online music service). Then, you either buy the ridiculously expensive Sonos controller or download the free app to control what the speaker plays.

I’ve used a controller at a friend’s house and it is nice, but the app is just as featureful. It combines searches across the different sources quite nicely, though this is only a recent feature. You can create queues, random shuffles and so on, just like any good media player.

The really nice thing about the system is the fact that it works seamlessly. You can add new speakers to the mix by plugging it in and holding down two buttons. It then appears in your app, and you can control what is played on it. You can play different songs in different rooms, or synchronise one audio stream across all of the players. Really cool.

I can completely understand the problem the Sonos system tries to solve. It has the Apple-esque “it just works” feeling about it. I would love to purchase a second Sonos to make use of the multi-room synchronisation features. However, the Sonos system has an Apple-esque pricetag, and, as a massive nerd and tinkerer, I find myself wondering how much effort it would take to make a homebrew version.

The obvious way to do this is with a Raspberry Pi. This credit card sized computer is great for hacking together web-connected controllers. It has its own native Linux distribution and there are loads of tutorials on the web concerning most features of the device. What’s more, they are cheap. Whereas a Sonos system is many hundreds of pounds, a Raspberry Pi starts at £25. Once you add a few extras for playing music, I don’t think this will come close to breaking the bank.

There are numerous reasons why a homebrew setup might be difficult:

  • The Raspberry Pi’s analogue audio output is not so brilliant in terms of quality, and therefore of little use for a Sonos-rivalling music system. Instead I expect a solution would either involve the Pi’s HDMI output or a USB sound card.
  • Synchronisation across distributed units is potentially difficult, and might involve something like Real-time Transport Protocol.
  • Interfacing with music services like Spotify and Napster together with files on a home server or connected laptop is a whole project in itself.
  • Latency can cause all sorts of issues, especially for synchronised audio. The Raspberry Pi has limited CPU power, and connecting it to a WiFi network or congested wired network will no doubt impact performance.
  • Controlling the various distributed units will require some topology thoughts. Should there be a web interface to a single server (not necessarily a Raspberry Pi but a computer on the same network), which can control the connected Pis? Or a mesh network where each Pi is both a client and server, passing around packets to each other? How should the server know about each connected unit? Should it send a message to the whole network to find them, or should the user need to register the IP address of each device in an admin panel or configuration file?

Sonos has addressed some of these issues by insisting that it has its own dedicated network. The base station that is a requirement of the Sonos system creates a wireless network of its own which the networked speakers can listen to. Other network traffic therefore does not impact the system. It also, handily for the shareholders, means that only Sonos speakers work with other Sonos speakers. Once you’ve shelled out £250 for the first kit, if you want to add any more you need to shell out more for further Sonos speakers.

The open-source community excels at providing alternatives to systems exactly like Sonos. The gap in the market that Sonos fills is to take these ideas and create a product. Open-source implementations often involve many different pieces of independent software, and lots of configuration to get them to talk to each other. This is what I would like to try to impact. There are various homebrew setups of Sonos-like systems described in blogs, but there doesn’t appear to be a system that covers the whole Sonos stack from app to speaker to Spotify.

Technologies exist for the individual layers on the Sonos stack:

  • Synchronisation of audio streams across different devices: Real-time Transport Protocol
  • Playing of audio from network: various Linux technologies such as PulseAudio or ALSA
  • Streaming audio from a combination of local and remote sources: Mopidy
  • Control via web interface or Android/iOS app: Moped or similar

It can be done. It will take time to do though. Others appear to have managed to get the synchronised audio part working properly, but I don’t know if anyone has managed to get Spotify to work too. Various solutions also involve Logitech Media Server, which is (somewhat weirdly) open-source and written in Perl (eugh). That might be an option, but I doubt I’d want to make any code modifications in Perl. Happily, Mopidy is written in Python, a glorous language, so I would be happy to dive in and start tinkering.

I’m going to give this a go at some point. I’ll keep you posted.

Update: view the second post in this series.

The Future of Electricity Supply and Demand: Smart Devices Responding to The Grid’s Health

This is a cross-post from The GIST, a student-run science and technology magazine. I wrote this article to accompany the publication of a scientific paper I was part of. Most of the content refers to work I undertook during my Masters project.

Increased use of renewable energy sources in the future will bring about challenges in being able to meet electricity demand with sufficient supply. This is because, unlike conventional power plants, renewable electricity sources such as wind turbines and solar panels provide a fluctuating output that is difficult to control and difficult to predict. Current plans by the Scottish Government involve the country becoming self-sufficient in terms of electricity supply from renewables in the next decade. The ‘2020 Routemap for Renewable Energy’ sets out “to meet an equivalent of 100% demand from renewable energy by 2020” [1]. In addition to the Scottish Government’s ambitious target, the UK government is also targeting a reduction in CO2 emissions by 34% compared to 1990 levels by the same year [2]. The UK government is also looking to renewable energy sources as a way of being able to turn off the fossil fuel power plants which produce greenhouse gases. The problem that is increasingly being encountered is that the fluctuations caused by renewable energy sources – such as the fluctuation in output from wind turbines as the wind speed and air density changes throughout the day – have an impact on the stability of the National Grid. The National Grid controllers fight every minute of every day to keep the level of electricity supply matched with the electricity demand at any given time. Every time you turn on the kettle, a power plant somewhere in the country has to slightly increase its output to cope. Conversely, every time you switch off your TV, a power plant has to slightly lower its output. On occasions where the supply-to-demand balance is not maintained perfectly, the frequency of the alternating current supplied by the National Grid to your wall sockets will fluctuate above and below 50 Hz. During times of excess demand, the frequency falls slightly below 50 Hz, and during times of excess supply it rises slightly above it. Ordinarily these changes are small enough not to be a problem, and it is easier for grid controllers to maintain a certain level of electricity supply with the current fleet of fossil fuel power plants. Fossil fuel power plants are in this sense ideal, as they can quickly produce a vast amount of stable electricity output which is useful for keeping the grid in balance. However, if the country is to meet its targets for reducing greenhouse gas emissions and if it is to become an electricity self-sufficient nation, then some of these plants are going to need to be switched off. If there were enough wind turbines in the UK to generate enough electricity to match the electricity demand, then the output would look something like the green series in this graph:

A hypothetical wind supply (green) and electricity demand (blue) profile across a day. Wind production data from Ireland has been scaled so that the total electricity supply matches the total demand. It is clear to see that throughout the day there are occasions when there is either too much or too little electricity production to meet demand. Unscaled wind production data provided by EirGrid, corresponding to the Republic of Ireland and Northern Ireland wind supply on 23rd October 2011. Demand data provided by National Grid for same date.

A hypothetical wind supply (green) and electricity demand (blue) profile across a day. Wind production data from Ireland has been scaled so that the total electricity supply matches the total demand. It is clear to see that throughout the day there are occasions when there is either too much or too little electricity production to meet demand. Unscaled wind production data provided by EirGrid, corresponding to the Republic of Ireland and Northern Ireland wind supply on 23rd October 2011. Demand data provided by National Grid for same date.

The blue series shows the electricity demand profile for the same day. Despite the wind turbines on this day producing one joule of electricity for every one joule of electricity consumed, production and supply are out of sync, and so there are occasions where there is an electricity deficit or surplus.

At present, any excess electricity production from wind turbines is lost. In this event, National Grid controllers would be forced to switch off supply from some renewable energy sources to avoid the AC frequency rising beyond legal limits. What if we could store that excess energy? This is where ‘dynamic demand control’ becomes useful. Dynamic demand control is a concept whereby the electricity consumption of a series of devices is managed in a way that it responds to the state, or ‘health’, of the grid. It can sense the frequency of the grid and from that infer the level to which supply and demand are matched, and take action accordingly. If there were to be a spike in supply, such as after EastEnders (when, famously, the Great British public add up to 1 GW, equivalent to two Cruachan Dams, of extra load to the grid as they simultaneously turn on their kettles), the device could then ramp down its electricity usage temporarily until the spike has passed, before increasing its demand to compensate later. This would then help to smooth out fluctuations in the supply-demand curve, resulting in less wasted renewable energy. If the nature of the device is such that it does not require a constant source of electricity, then it can take part in dynamic demand control.

The concept has previously been demonstrated in fridges [3] and cars [4], but recent work in the University of Glasgow has shown that the concept is also suitable for laptops [5]. The high number of laptops and consumer electronics devices with built-in batteries in use at any given time can have a significant positive impact on the stability of the grid. Collectively, the millions of laptops in use at any given time can provide mitigation of the order equivalent to a large power plant coming online.

The system developed by the scientists in the School of Physics and Astronomy at the university involves two different approaches: a hardware device which sits in between the laptop’s charger and the wall socket, controlling the electricity flow to the laptop; and a software approach, obtaining information about the grid frequency using the World Wide Web and controlling the battery’s charging in this manner. The former approach allows for current laptops to be retrofitted with a device which can regulate the charging of any laptop, and the same device is not necessarily restricted to laptops but to any device with a suitable form of buffer such as a battery (the insulated thermal mass in a fridge is another example). The latter approach requires a laptop to be manufactured with suitable hardware which the device’s software can interface with. During the course of the study, the researchers only found a few models from only one brand suitable for this software technique, so this technique would primarily apply to future hardware.

Despite the pitfalls, the advantage of a software solution is clear: no changes to the device’s hardware are required except for a suitable battery management software interface, which is often just a case of having the manufacturer make available the necessary drivers. Additionally, the software could be user configurable so that smart charging is not performed during unwanted hours. For example, a user with a presentation to give at 9am the following morning may wish to make sure that their laptop’s battery has at least 80% charge as of 8am, regardless of the health of the grid. The software could then assist the grid as required except in the case where it would interfere with the user’s own requirements.

But what incentive does the laptop owner have to use such a system? The laptop is being used by the National Grid to store power with seemingly nothing being given to the laptop owner in return. To solve this dilemma, it is necessary to consider how the wholesale electricity market in the UK operates. The utility companies that supply electricity to our homes tender for electricity on a market under the administration of the National Grid PLC. Each utility company does not need to produce its own customer’s electricity, rather it may purchase supply from other providers or sell its own excess. The price of a unit of electricity is set by the economics of supply and demand, meaning that during times of excess electricity demand surplus or supply deficit the prices will increase, and vice versa. The difference that utility companies can pay between peak and off-peak times can be as much as 500%. Although this sounds dramatic, in reality it only results in a small cost saving for the electricity companies. Reduced tariffs for users of dynamic demand devices are unlikely to be worthwhile. Therefore, an incentive to end users could come in the form of a monthly prize draw, though realistically it might rely on government legislation or the ‘goodwill’ feeling of a user being ‘green’ to make sure these devices become widely used.

Wholesale electricity prices available to utility companies during a week in November 2012. The price companies pay can vary by as much as 500%. Data taken from bmreports.com.

Wholesale electricity prices available to utility companies during a week in November 2012. The price companies pay can vary by as much as 500%. Data taken from bmreports.com.

Would a smart charger have a negative effect on the laptop’s battery? Surprisingly, this might not be the case. Some laptops charge their battery even when plugged in (‘trickle charging’), and large, quick charges can cause excess heat, which is a big battery life killer [6]. Using a smart charging system can result in slower, shallower charges and discharges, keeping the temperature down, and less time spent trickle charging, which can allow the battery to maintain its longevity. Frequent, small discharges also allow the laptop’s operating system to obtain a more accurate reading of its estimated battery life.

With demand on the increase and the burning of fossil fuels becoming less attractive, the electricity grid of the future will have to be highly adaptive to the natural conditions affecting renewable energy production. With techniques such as dynamic demand control, perhaps in the form of smart laptop chargers, the grid can safely integrate more renewable energy sources, bringing about a sustainable energy future.

Link to the article on The GIST


  1. http://www.scotland.gov.uk/Publications/2011/08/04110353/2
  2. Climate Change Act, 2008
  3. J.A. Short, D.G. Infield, and L.L. Freris. Stabilization of Grid Frequency Through Dynamic Demand Control. Power Systems, IEEE Transactions on. 2007; 22(3):1284 – 1293.
  4. Chang-Yu Huang, J.T. Boys, G.A. Covic, J.R. Lee, and R.V. Stebbing. Implementation and Evaluation of an IPT Battery Charging System in assisting Grid Frequency Stabilisation through Dynamic Demand Control. In Vehicle Power and Propulsion Conference (VPPC), 2010; IEEE: 1 – 6.
  5. Stefan Hild, Sean Leavey, Christian Gräf, Borja Sorazu. Smart Charging Technologies for Portable Electronic Devices, IEEE Transactions on Smart Grid. Jan 2014. DOI: 10.1109/TSG.2013.2281853; also available at http://arxiv.org/abs/1209.5931.
  6. I Bloom, B.W Cole, J.J Sohn, S.A Jones, E.G Polzin, V.S Battaglia, G.L Henriksen, C Motloch, R Richardson, T Unkelhaeuser, D Ingersoll, H.L Case. An accelerated calendar and cycle life study of Li-ion cells. Journal of Power Sources. 2001; 101(2): 238-247.

Original content licenced under the Creative Commons Attribution 3.0 Unported License.