MintyBoost

MintyBoost

The MintyBoost is an open-source, small form-factor, USB charger which runs on AA batteries – and lets you charge your mobile phone, tablet or other USB device, without the need for mains power or a computer.  It was designed by one of the leading proponents of the open-source hardware movement, LadyAda – aka MIT Engineering graduate: Limor Fried

All the details of the circuit can be found on the project’s web-site.

Continue reading “MintyBoost”

Getting started with BeagleBone

I’ve just picked up a BeagleBone

BeagleBone

BeagleBone is a small, low(ish) cost, open-source Linux computer on a  board – using an ARM Cortex-A8 processor running at 720 MHz, with 256 MB of RAM.  Unlike an Arduino – this is a fully-fledged computer. This makes it extremely powerful – and makes it a nice device to play with, to learn about embedded Linux.

This added power and sophistication does come at a cost though: this is not (or at least not currently) a tool for complete beginners in the way that an Arduino can be.  This is a Linux computer – so if you want to use it to it’s full potential, then you’d better know your way around the Linux command-line.

It runs Ångström Linux – which is a flavour of Linux specifically produced for embedded devices. It’s used as the embedded OS on a number of commercial products. Whilst this is great because it means that there are a large number of people working on keeping Ångström really up-to-date; it’s also a challenge for the hobbyist – because it is very strongly focussed on the embedded device community.

BeagleBone itself is quite a new product (it only came out a few months ago) – so although there’s quite a community around it’s big-brother (the BeagleBoard) some of the documentation for the BeagleBone is a bit patchy.

The first instruction in the getting started manual is to update the software on the board to the latest version of Ångström Linux.  This posed quite a challenge, even for me – and I’ve quite a few years of Linux experience (and I’m a some-time sysadin): so it’s definitely not something for someone completely new to the command-line.

If you’re struggling with this – I do have a couple of tips, however. The instructions on the various web pages aren’t really all that well written – unless you’re already familiar with the process.  Telling novice users to “Learn to use ‘dd‘ and ‘gzip‘ “ or “know which /dev/sdX or /dev/diskX is your SD card through use of ‘dmesg‘” isn’t very helpful. If you’re already familiar with these tools then this instruction adds nothing – and if you’re not: then the provided links aren’t really going to help…

The first thing that I’d recommend is that you do the update using another Linux computer. Whilst Mac OS X is just a pretty front-end for UNIX, and therefore everything should be just as easy under OS X – it didn’t really turn out to be quite that simple.  I could only find the latest version of Ångström in an img.xz archive, and out-of-the-box OS X doesn’t have any tools to let you work with that format: and although adding a suitable command-line tool is quite trivial it’s one extra step that you (almost certainly) wouldn’t have to make with a Linux box.

More of a problem is the way that OS X mounts the SD card. Despite spending several hours digging about, I couldn’t actually find the device representing the SD card. Because the download is (essentially) a disk image – you need to point the archive tools at the low-level device rather than it’s mount-point in the file-system.

Anyway, the long and the short of it is that if you download the image file on a Linux system, and then run the following incantation (obviously replacing the filename with the name of the image file you just downloaded) – it’ll probably work just fine.  The only caveat on that is if you have more than one physical drive on your computer – in which case you may need to change the /dev/sdb to something else).

sudo xz -dkc Angstrom-Cloud9-IDE-beaglebone-2012.01.27.img.xz > /dev/sdb --verbose

Note the addition of the --verbose flag to the command. This is going to take quite a while (~20 minutes) to run – so it’s nice to be able to see that something is indeed happening!

Once you’re up and running the latest version of Ångström, then what?

One of the things that the BeagleBone flavour of Ångström has running is the Cloud9 web-based IDE. This gives you the opportunity to write Bonescript code.  Bonescript is a Javascript-based scripting language for BeagleBone which lets you write Arduino-style code. I’m not sure I really get the idea of this though: if that’s all you want to be able to do – then why not use an actual Arduino? It’d be vastly easier, simpler, and cheaper.

That said, Bonescript & Cloud9 do let you very easily run some classic blink light code (the hardware / embedded equivalent of “Hello World!”)

Cloud9 IDE

This blinks one of the user LEDs on the board itself – and will blink an external LED driven from pin 3 on header 8 (the bottom header, if you have the board facing up, and have the ethernet port on the right).

As I say, not particularly useful – but at least it shows that everything is working!

The real power of BeagleBone is using it to control hardware from Python or C code: and coupling it with the device’s on-board web server.

So look out for a follow-up post, looking at some more interesting things to do with a BeagleBone, in the near future (just as soon as I’ve worked it all out myself!)… 🙂

555 Astable Oscillator

In my last few posts I’ve been writing about using an Arduino to generate waveforms. Part 3 of that series is still in the works (I’ve not forgotten, honestly!) – but this time I want to write about an alternative way to make a simple waveform: using good old analogue electronics, without the need for a microcontroller.

To do this we’ll use the ubiquitous NE555 timer chip (or just a 555 for short). The 555 is almost certainly the first IC you’ll play with if you’re learning analogue electronics at school or college – and for good reason, you can do all kinds of things with 555 timers – and whole books have been written on the subject. I’m not going to compete with any of those (Google, Amazon and Wikipedia will be your friends if you want to find out more). Or have a look at the datasheet

Using a 555 to produce a square wave is a really nice easy circuit to have a go at if you’re new to electronics: as it’s not too complicated to build – and it’s pretty easy to understand what’s going on.

There are a handful of different basic ways to use a 555 – known as monostable, bistable, and astable.  In a monostable configuration, the 555 will generate a single pulse (or a length determined by the configuration of the rest of the circuit), so it can be used, for example, as the basis of a simple electronic timer (such a circuit was my first ever electronics project – about twenty years ago!).  In a bistable circuit, the 555 can be used as a latched  flip-flop – turning on or off an output, depending on the state of two pulse inputs.

We’re interested in the astable configuration though – as that will let us generate a series of pulses in the form of our square wave.

Let’s start by looking at the circuit.

555 Astable circuit diagram

As you can see it’s a pretty simple circuit – with just the 555 IC, two resistors, and two capacitors.  Additionally if we want to be able to vary the frequency, we can add a potentiometer (variable resistor) in series with R2, and to drive larger loads we can use a transistor switched by the output from pin 3 (as I’ve done here)…

555 astable circuit breadboard

So how does it work?

First of we need to understand an RC (resistor – capacitor) network.  A capacitor charges and discharges at a rate proportional to the value of the resistance. This means that there’s an exponential relationship between the capacitor voltage and time… Specifically:

RC time equation

When the voltage on the timing capacitor (C1) reaches 2/3 of the supply voltage (Vcc) the 555 triggers the flip-flop (via pin 2) and the capacitor starts to discharge, when it drops to 1/3 Vcc, the flip-flop flips again, and starts the capacitor charging again. When C1 is charging the RC is dependant on both R1 and R2; when it’s discharging only R2 comes into play because of the connection to pin 7 between the two resistors.

Don’t worry if you don’t understand exactly how the 555 flip-flop works (it’s slightly out of the scope of this post – but maybe I’ll write something about that if people are interested): the important thing is the that the time taken to perform these charge / discharge cycles is what determines the frequency of the square wave generated.

Specifically the frequency is the reciprocal of the time taken for the circuit to go high + the time taken to go low…

So in our case the frequency should be:

And, sure enough – here’s what the oscilloscope gives us…

The death of the mouse?

'all wireless again...' photo (c) 2010, macreloaded.com - license: http://creativecommons.org/licenses/by-nd/2.0/

I’ve seen the future, and there are no mice in it.

Apple certainly have a history of setting the trends in popular computing. From the mass-market appeal of the Apple II, through to the revolution in mobile computing brought about with the iPhone & iPad; not forgetting, of course, the introduction of the mouse with the Macintosh in 1984…

Since then, the graphical user-interface (GUI) has become truly ubiquitous. Whether you favour Windows, Mac, Linux or a mobile device the GUI is the way we interface with our computers today. Even the hard-core geeks who often value the speed and power of the command-line interface, do so from within a terminal application within a GUI. No-one short of a masochist would choose anything else.

With the ubiquity of the GUI has come the near-ubiquity of the mouse. Laptop users will often make do without one (especially when on the move), and a few desktop users will choose the trackball ahead of the mouse. But the mouse has been the predominant interface device for the best part of 25-years.

But I think that’s about to change.

There are two trends driving this, I think.

The first is the fact that increasingly users are favouring using the GUI’s menus, toolbars, and context-sensitive pop-ups ahead of the more traditional keyboard shortcuts. This is inevitable really, since keyboard shortcuts are a throwback to the pre-GUI days (the days of DOS, and applications like Word Perfect 5.1 – the PC word-processor of choice, before Microsoft’s Word became the dominant force). There has been a gradual decline the prominence of keyboard shortcuts in user-interfaces, since the GUI was invented. This is true of both Windows and Apple’s operating systems. Whereas once a “power user” would expect to be able to do everything, without taking his or her hands off the keyboard; today’s applications generally have too many complex features to make this a reality.

This is a good thing. Anyone who actually used the old-school word-processor applications will remember the lengthy cheat sheets that they’d need to keep taped up nearby the screen to remind them of the keystroke sequences required to achieve all but the most routine actions. Today’s applications with context-sensitive menus, mean it’s easier than even to apply the correct formatting, or make the required changes: and to use them the user has to use their pointing device. More importantly, it makes the experience of using applications far less daunting for the vast majority of users who aren’t expert power users. And of course, since the advent of the web, and it’s inherently visual presentation, navigating hyperlinks makes no sense with a keyboard.

The second major change in technology is multitouch. Touch screens, and trackpads of the past were all single touch devices. With multitouch devices (now near universal in touch screens – but surprisingly not yet so for trackpads) the experience is changed from just being a way to drive a pointer on the screen – to having a fully fledged vocabulary of gestures to interact with the system (pinching to zoom, swiping, twisting, etc).

Mobile devices are very much at the forefront of driving this revolution. Once someone has used a tablet device, and seen how naturally you can interact with it, it becomes obvious to ask the question “why can’t all computers work like this?”

Apple seem to have asked exactly this question, since the introduction of iOS. With each new version of OS X, more gestures have been introduced. Apple’s laptop users (of whom there are many) can take full advantage of this, since the introduction of the multitouch trackpads on MacBooks a few years ago. But what about the desktop users?

Until fairly recently, they were left a little out in the cold. Although Apple’s innovative Magic Mouse was (is) a very clever piece of technology (combining, as it does, a multitouch sensor with the body of a mouse), it’s a bit limiting. It’s too small for many multi-fingered gestures, and because a mouse user typically keeps their mouse hand on the mouse for extended periods, it’s too easy to accidentally register an unintended gesture.

With the introduction of the Magic Trackpad last year – Apple effectively signed the death sentence for the mouse. Not that things changed overnight. It’s really only now with OS X 10.7 – Lion, and all of the additional gestures it introduced that the compelling case is made.

I’ve had a Magic Trackpad for less than a week now, and already I’m totally sold. There is so much control over the system using all of the gestural controls, that (for the first time ever) a user can do pretty much everything more conveniently, and more quickly, without touching the keyboard. Apple have created a user experience whereby rather than keeping your hands on the keyboard, you keep your hand on the trackpad.

So will the mouse put up a fight or will it go quietly? I think, given the natural propensity for most humans to fear change, and like what they know – it’ll be a good few years before the mouse goes anywhere; but I really believe that once users try a large, multitouch trackpad – they, like me, won’t want to go back.

It’ll also need rather more multitouch trackpads to become available (although the likes of Wacom have introduced an excellent product with their bamboo touch tablet – such products are still few and far between), and it’ll need Microsoft to introduce “Mac-like” multitouch gestures into the heart of Windows (although if the last few years are anything to judge by, where Apple lead, everyone else follows). This is something that I think is likely to accelerate over time, as the simplicity of mobile OS interfaces start to cross back onto the desktop. So I think we have hit a high-water mark for the mouse; and it’s days are now numbered.

Of course the multitouch trackpad isn’t the only device competing with the mouse. There’s also the question of cutting out the middle-man entirely – and using a touchscreen display. After all the tablet market is doing exactly that… The difference, I think is twofold though. Firstly I genuinely don’t think that (for most purposes) a 30″ touchscreen is very convenient. Dragging something from one side of the screen to the other would be just too much like hard work. On a 10″ iPad it’s fine; but something three times that size?

Then there’s the question of ergonomics. If I have to hold my arms out in front of me all day to interact with my touchscreen, then my arms are going to get tired… And, as an aside that’s why I doubt that the “Minority Report” style gestural interface will never catch on – it’s just too energetic! On the other hand, if I mount my display (as I might a tablet) horizontally flat on my desktop then I’m going to have to sit with a terrible posture – it’s bad enough using an iPad on your lap: sitting over a table display all day is bound to give you a stiff neck.

Whilst I can’t predict that someone won’t solve these problems, or come up with a new, as yet unthought of user interface device – I really do think that the mouse is heading the way of the light pen…

Arduino Function Generator (Part 2)

Last time, we looked at some Arduino code that we could use to generate some square waves.

The problem with the setup we’ve been looking at so far, is that we can only produce signals of one amplitude – equivalent to the HIGH logic level.

In order to be able to produce any other waveforms we’ll need to be able to produce a variety of different output voltages. Although the PWM method we looked at last time gives us a way to do this, it’s not suitable for producing variable waveforms – as it’s time-based. We can see this, if we try to use PWM to produce a triangular waveform: and view the output with an oscilloscope.

void setup() 
{ 
    pinMode(11, OUTPUT); 
} 

void loop() 
{ 
    for (int i=0; i<0; i--)
    {
        analogWrite(11, i); 
        delay(1); 
    }
}

Creative Commons License


PWM Triangle code is by AJP is licensed under a Creative Commons Attribution-Share Alike 2.0 UK: England & Wales License.


If we hook that up to our oscilloscope – it looks like this:

Failed Triangular Waveform

It’s not too easy to see that as a still image – so here’s a video clip of the same thing…


That’s clearly not really what we wanted: so we need to do something differently.

The solution to this problem, is to use some kind of digital-to-analogue converter (or DAC). To begin with, let’s build our own…

R-2R DAC Breadboard

Or, if you prefer, in schematic…
R-2R DAC Schematic

This circuit is an 8-bit DAC known as an R-2R resistor ladder network. Each of our eight bits contributes to the resultant output voltage. If all 8-bits are HIGH – then the output is approximately equal to the reference voltage… If we switch the most-signifincant bit to LOW – then we get approximately half of that voltage.

More precisely, for an 8-bit DAC if all 8-bits are HIGH – then we get 255/256th of the reference voltage. Switching the most-significant bit to LOW gives us 127/256th of the reference voltages. More generally for any bit value x, between 0 & 255, our DAC will us x/256th of the reference voltage.

There’s a short article on wikipedia explaining R-2R DACs in a little more detail, if you want to know more…

Okay, now that we’ve built our circuit – let’s do something with it.

We’ll start by producing a triangular waveform…

void setup() 
{ 
    pinMode(0, OUTPUT); 
    pinMode(1, OUTPUT);
    pinMode(2, OUTPUT);
    pinMode(3, OUTPUT); 
    pinMode(4, OUTPUT); 
    pinMode(5, OUTPUT); 
    pinMode(6, OUTPUT); 
    pinMode(7, OUTPUT); 
}

void loop() 
{
    for (int i=0;i<255;i++) 
    {
        PORTD=i;
    }
    
    for (int i=255;i>0;i--) 
    {
        PORTD=i 
    }
}

Creative Commons License


R-2R ADC triangle code by AJP is licensed under a Creative Commons Attribution-Share Alike 2.0 UK: England & Wales License.


Triangular Waveform

Note that here we’re using PORTD instead of setting the state of the individual output pins one at a time. This is much faster, and it (critically) ensures that all of the pins change at the same time – and that’s important given we want to switch smoothly though digital values to create a smoothly changing analogue voltage.

PORTD is port register D. Our use of it here works because it maps to the 0-7 digital pins (giving us 8-bits); and writing either a binary or decimal value to the register – we control all 8 pins in one operation. For example, if we assigned it the decimal value 123 (which equates to B01111011) would set pins 6, 5, 4, 3, 1, & 0 to HIGH… Now the problem is that pin 0 is used for communicating serial data – so using PORTD means that we can’t use any serial communications whilst code it running. It is, however, the only way to manipulate 8 output pins simultaneously (and we didn’t need serial communications for this application anyway).

We can modify our code very easily, to produce a saw-tooth waveform – by simply commenting out (or otherwise removing) the second of the two for loops.

Note that if we want to drive anything significant (even something as lowly as an LED) we need add a transistor into the circuit, like this:

DAC with transistor & LED

Finally, on to a sine wave. We’ll need to pre-compute some values for the output voltages over time (the arduino just isn’t quite fast enough to be able to this in real-time, in a situation quite as time-sensitive as producing a waveform).

A sine wave has a cycle of 2π radians – so to produce a sine wave with 256 time-steps per cycle, we just need to calculate y=sin((x/255)*2π) for each point value of x. Since the sine function gives us values between 1 and -1; and we want values between 0 and 255, the simplest way to do this is to multiply the float value by 128 – giving us a value between -128 & +128; and then add 128 – to give us the correct range.

We could do this off-line; but that’s a bit tedious – so we’ll get the arduino to do this for us, in the setup() phase, storing the results in a global array. Then all we need to do in our main loop, is cycle through the array.

int sine[255]; 
void setup() 
{ 
    pinMode(0, OUTPUT);
    pinMode(1, OUTPUT); 
    pinMode(2, OUTPUT);  
    pinMode(3, OUTPUT); 
    pinMode(4, OUTPUT); 
    pinMode(5, OUTPUT); 
    pinMode(6, OUTPUT); 
    pinMode(7, OUTPUT); 
    float x; 
    float y; 
    for(int i=0;i<255;i++) 
    { 
        x=(float)i;
        y=sin((x/255)*2*PI); 
        sine[i]=int(y*128)+128; 
    }
 } 

void loop()
{
    for (int i=0;i<255;i++) 
    { 
        PORTD=sine[i]; 
        delayMicroseconds(10); 
    }
 }

Creative Commons License


R-2R ADC sine code by AJP is licensed under a Creative Commons Attribution-Share Alike 2.0 UK: England & Wales License.


If we run that code, with our DAC, and have a look at that on our oscilloscope we see that we do indeed have something that looks quite a lot like a sine wave.

Sine Wave

That’s all for this part, next time we’ll have a look at varying the frequency of our waveforms; and look at a more compact and accurate way to do the digital-to-analogue conversion, using a dedicated IC…

Arduino Function Generator (Part 1)

I was looking around for an interesting Arduino project, and I came up with the idea of making a function generator (also called a signal generator). The reason I picked a function generator is that it gives us the chance of playing with some interesting circuits – and some interesting code…

Before we start with that – what is a function generator?

A function generator is a circuit that generates some kind of waveform. There are four main types of waveform – the square wave, triangular & saw-tooth waves, and the sine wave.

There’s a good article on function generators on wikipedia.

A dedicated function generator will cost a hundred pounds or more – but it would be very much more capable than anything we’ll build here; but this will give us a chance to look at a few interesting things.

The simplest waveform to get an Arduino to produce is a square wave. The square wave (as the name suggests) simply cycles between the HIGH and LOW logical levels.

An idealized square wave

(Actually it’s not really that simple at all – a square wave produced by an analogue oscillator is actually made up of a complex mixture of multiple harmonics – wikipedia has a description of this; but we won’t concern ourselves with this…)

The circuit we need to produce a square wave, is pretty much the most trivial circuit imaginable.

In fact all we need to do is connect whatever it is we’re driving, to one of the digital output pins of the arduino (I’m using pin 8 here); and the arduino’s ground.

Square Wave Circuit

The code is very simple, too…

void setup()
{ 
    pinMode(8, OUTPUT);
}

void loop() 
{
    // A total delay of 4 ms = 1/0.004 = 250 Hz… 
    digitalWrite(8, HIGH);
    delay(2); 
    digitalWrite(8, LOW); 
    delay(2); 
}

Creative Commons License


Square wave code by AJP is licensed under a Creative Commons Attribution-Share Alike 2.0 UK: England & Wales License.


If we want to drive something like a piezoelectric speaker we can connect it to the pin, and the arduino’s ground; and we’ll be able to hear a tone. Alternatively if we pick a low enough frequency we could hook up an LED to see it blink. In fact, if you do that, you’ll note that this setup and code is actually just the blink demo.

Note that we can also use delayMicroseconds() to enter smaller delay values – giving use the ability to produce higher frequencies than the 500Hz that we’d otherwise be limited to…

In fact it’s even easier than this – as Arduino has a function to generate a square wave. For example, to produce the same 250Hz square wave as we had before, we can use: tone(8, 250); in place of the digital writes…

Let’s see exactly what this square wave looks like – buy hooking it up to an oscilloscope…

Apart from the frequency of the wave, there are a couple of other main characteristic that we might want to modify: the amplitude (a measure of how much higher the HIGH level is, compared to the LOW), and the symetry of the wave – the so-called duty cycle. We’ll leave the amplitude aside until next time – as that’ll require us to do a little more work; but let’s look at the duty cycle of the wave.

The duty cycle is simply a measure of how much of the time our wave is at the HIGH level – compared with the total time of the cycle. So far all of our square waves have been symmetrical: with an equal amount of time spent in both states. This is known as a 50% duty cycle.

If we want to change that, we can’t use the tone() function – as that’s designed to produce a symmetrical wave. Instead we need to use the digitalWrite() and delay() functions. So to create a 25% duty cycle square wave at 250Hz – we’d use delays of 1 ms after the LOW, and 3ms after the LOW.

If we use an oscilloscope we can see the shape of the resulting wave…

250Hz 25% Square Wave

With the timebase set to 2ms per division, we can clearly see the 1ms width of the pulse, and the 3ms gap between the pulses.

What’s interesting is what happens if we try measuring the voltage with an instrument that’s less time-sensitive – such as a multimeter. A 250Hz signal with a 50% duty cycle, yields an average of 2.4V (which is exactly half of the 4.8V my meter shows the +5V output of the arduino to be). With a 25% duty cycle – we get 1.2V (one quarter of the HIGH voltage); and so on…

In fact, this concept may already be familiar to you – if you’ve used the analogWrite() function – we have just reimplemented the pulse width modulation (PWM) technique that Arduino uses to provide analog (or analog-like) voltages. We can show this in a couple of ways. Firstly we’ll measure the voltage across an LED during an analogue write with our oscilloscope; and then we’ll show that by adjusting the duty cycle of our code, we can dim an LED.

First lets look at a PWM voltage, giving us a 50% duty cycle (or an average output of around 2.4V).

Arduino PWM 50% Duct Cycle

As you can see the shape is identical to what we saw before in our own version – although the frequency here is different (the Arduino reference document states that the PWM frequency should be approximately 490Hz…

Now let’s try implementing our own version of PWM…

First here’s a schematic of the new circuit…

As you can see we’re simply driving an LED via pin 8 (not forgetting the current limiting resistor, of course); and we’re getting a voltage (between approximately 0V and the reference voltage) from the potentiometer, and feeding it into analog pin 2.

Now for the code.

int value=0; 
void setup() 
{ 
    pinMode(8, OUTPUT); 
    pinMode(2, INPUT); 
} 

void loop() 
{
    value=analogRead (2); 
    value=map(value, 0, 1023, 1, 19); 
    digitalWrite(8, HIGH); 
    delay(1); 
    digitalWrite(8, LOW); 
    delay(value); 
}

Creative Commons License


PWM demo code by AJP is licensed under a Creative Commons Attribution-Share Alike 2.0 UK: England & Wales License.


As you can see this is also very simple code. We call analogRead() to get the voltage – and then (for simplicity) we map it onto a range between 1 & 20 – and then use that as our millisecond delay value on the LOW part of the cycle – giving us a (theoretical) duty cycle of between 50% and 5%. I say a theoretical duty cycle – because in reality the time it takes the arduino to do the read and the map will actually throw off our timings. My multimeter shows a voltage of 2.16V rather than the expected 2.4V – dividing the reference voltage (4.8V) by the measured voltage (2.16V) gives us a a duty cycle of around 45%…

PWM Demo

As we can see from a more accurate measurement of the duty cycle, we see it’s around 46% – which implies that the time spent in the LOW state is actually around 1.08ms: hence approximately 80µS of additional time in the cycle spent at LOW whilst arduino executes the analog read and map functions). So if we were going to use this in reality – we’d probably need to find a more efficient way of determining the value for the second delay.

Or, more realistically, we could just use the analogWrite() function (which uses it’s own timer – independent of the main processing loop…

If we adjust the ‘scope to show the average voltage – we see that we get approximately the same voltage as the volt meter gave us…

Okay; that’s all for now. But be sure to come back soon for part two – when we’ll start to look at some ways to implement one of the more interesting waveforms: the sine wave.