At first glance, the calculation of current to an LED seems simple – you need a resistor to limit the current flow to the LED so it doesn’t draw to much and burn out.

But what value of resistor do you need, and how do you work that out?

It turns out the answer gets quite complicated, mainly due to the forward voltage (Vf) property of an LED. Forward voltage, voltage drop, or Vf, indicates the voltage that the LED reduces the circuit voltage by when current is flowing through it. The value of Vf varies according to the current and the colour and quality of the LED. As a rough guide:

So what does that mean? Well basically it means that having an LED in your circuit will reduce the voltage in the circuit by the amounts shown above.

All of the voltages in the circuit are relative to the source voltage (Vs).

So if I have a 6V lantern battery (6Vs) and I hook up a green LED to it, suddenly there’s only 3.8V flowing through the rest of the components in the circuit.

To prevent the LED from burning out, you need to limit the amount of current that flows through it, usually to a maximum of between 20 and 30 milliamps (mA). The way you do that is by using a current-limiting resistor.

To calculate the required resistor value, you need a new voltage measurement: Vs –Vf, or Vresistor. Vs-Vf is the amount of voltage flowing through the ‘other components in the circuit’, namely the current-limiting resistor being used to restrict current flow through the LED and prevent damage occurring to it or the rest of the circuit.

LEDs are pretty flexible and they will happily light up with 5mA or even less. With smaller currents they will not be at their brightest and it will be much nicer to see them shining away with their maximum of 20mA or 30mA.

So as an example, lets say I have a red LED rated at a maximum 30mA and I want to light it up as brightly as possible with the full 30mA current supply. How would I calculate the resistor values required? To do that you need to go back to Ohm’s law and apply a bit of theory. Ohm’s law states that current is equal to voltage divided by resistance:

I = V/R

or in this case I = Vs-Vf / R

Lets take our 6V lantern battery and a red LED to start with. In the chart above the red LED’s Vf is shown as 1.7 volts. These values are all entirely hypothetical at this point - in reality the LED’s Vf will vary and the battery will not produce a stable 6V. We’re going to start needing some real numbers soon, but as a place to start let’s calculate the resistor you’d need using the chart values and the lantern battery’s theoretical 6V as a voltage source (Vs):

30mA = (6Vs – 1.7Vf) / R

so 0.03A = 4.3V / R

so R = 4.3 / 0.03

so R = 143.3333333333333

so R = 143 ohms

To get started calculating the actual resistor required, you first need to get a more accurate measure of the LEDs real forward voltage drop (Vf). The easiest way to do that is to take a battery and a resistor, hook up the LED and measure it with a multimeter.

The resistor value calculated with the theoretical values should be close enough that nothing will be damaged by using it to test the actual values. Different colour LEDs will vary their voltage characteristics based on the current passing through them so you’ll get inaccurate readings if you supply a different current in your tests. In this case I calculated 143 ohms, which I’ve added to the circuit using a 100 ohm and a 43 ohm resistor in series:

Gator clips are your friend when working with a lantern battery, so that’s how I’m hooking up my LED to test. If you had a 9V battery you’d be better off with a breadboard and a nine-volt battery connector.

Here are the measurements I’ve taken with the multimeter on this circuit:

Source voltage 6.34Vs

LED forward voltage 2.54Vf

Resistor voltage 3.79V

So the actual voltage of the source was wrong in theory and so was the forward voltage of the LED. If you’d used the theoretical calculated 143 ohms you would have been way off, supplying a mere 26.5mA to your LED and how dull that would be :). A much more accurate calculation can now be made with the real values:

R = Vs-Vf/I

so R = 6.34-2.54 / 0.03

so R = 3.8 / 0.03

so R = 126.6 ohms

so R = 127 ohms

That works out quite nicely because I happen to have a 100 ohm and a 27 ohm resistor in my kit here, so connected in series I can create a 127 ohm resistor. Here’s the LED now fulfilling its potential and shining away with a clear 30mA flowing through it:

I’m still blinking and seeing little LEDs from the image burned into my retina from looking it straight in the eye. A new moon has appeared on the ceiling, an angry red moon. In other words, the thing is on and it’s bright. It is also nice and cool and has remained cool for a few minutes. It should remain cool as it is within its operating parameters. I think I’ll leave it on all day and test that theory (and the staying power of the lantern battery).

For further reading I’d recommend taking a look at these links:

Technical Charts Showing LED Characteristics:
http://www.maxim-ic.com/appnotes.cfm/an_pk/3070

LED Resistor Calculator:
http://led.linear1.org/1led.wiz

# posted by Luke Thompson on Sunday, November 29, 2009 -   0 Comments

Is it wrong to feel proud of a hole 0.5mm across?

I bought my first drill press today and couldn’t help but feel a little glow at having drilled a hole in a piece of copper board destined to be my first home made printed circuit board (PCB). It even fits a transistor’s leg :).

# posted by Luke Thompson on Tuesday, October 13, 2009 -   0 Comments

A basic requirement for digital electronics is to switch on a higher current device using the low current capable IO pins of a microcontroller.

A microcontroller is typically capable of outputting only a limited current of 90-200 milliamps (mA) across all of its IO pins. Even if you only have to light up a couple of bright LEDs that will not be enough and drawing more current than allowed could damage the microcontroller. To limit the current drawn whilst still supplying enough power to the controlled devices you need to use a device that can act as a digital switch. A transistor can fill this role, drawing only a few milliamps from the microcontroller whilst the controlled devices draw as much as they require.

There are a several types of transistors which can allow you to switch on or off anything from LEDs to motors. The decision for which transistor to use depends on how fast the switch needs to be flipped, and how much power will flow through it.

Bipolar Junction Transistor (BJT)
A BJT transistor such as the NPN BC547 shown on the right can function as a digital switch. When a small amount of power is supplied to its base (middle leg), power is allowed to flow between its collector (left leg) and emitter (right leg). When the base is grounded no power can flow between collector and emitter.

There are two types of BJT transistor, NPN and PNP. NPN is far more widely used and in the majority of cases NPN is a better choice. The circuit symbols are shown below:

Here is a simple circuit demonstrating an NPN transistor being used to switch on an LED:
 

The circuit uses the 3.3V supply from the microcontroller’s IO pin, limited to 3.3mA by the 1K resistor, to allow the 5V supply, limited to 50mA by the 100 ohm resistor, to flow through the LED.

I built the circuit using the Digi Connect ME microcontroller and a breadboard:

The gator clip wires shown on the left connect up the Digi development board’s 5V supply to the breadboard’s left hand power rail. The white wire connects the first IO pin of the microcontroller (GPIO1) to the breadboard’s 1K resistor at the base of the BC547 transistor:

If you have to switch higher current loads, say to drive a motor or a pump, different types of transistors may be applicable. The BC547 has a maximum current throughput of 100mA, so it’s only suitable for small loads such as the driving this LED. In particular Field Effect Transistors (FET) may be a better choice for many higher current robotics applications.

The Microsoft .NET Micro Framework (.NET MF) C# code used to test out the circuit is here:
http://purerobotdigiconnect.codeplex.com/SourceControl/changeset/view/29696#691604

# posted by Luke Thompson on Sunday, August 02, 2009 -   2 Comments

Here is a small demo application running on a Digi Connect ME JumpStart kit, and an emulator of the kit:

I've started a new open source project for Digi Connect ME sample code, hosted on the TFS servers at CodePlex:

http://www.codeplex.com/PureRobotDigiConnect 

The Pure Robot - Digi Connect ME project demonstrates the basics of interaction with the Digi Connect ME module, as well as emulation of the JumpStart kit hardware.

Emulating Hardware
One of the main features of this project is the Digi Connect ME JumpStart kit emulator. This was an interesting exercise for me since Digi do not supply their own emulator along with the kit and I've never attempted to build an emulator before. I've created one in the solution, in a project named PureRobot.Emulators.Digi.ConnectME.JumpStart. The code is in a beta stage: it's ready to look at with the LightFun sample code being discussed; however the serial emulation UI is not complete so the other sample projects in the solution may not work as expected yet.

The emulation features of the Microsoft .NET Micro Framework (.NET MF) are very easy to work with. Essentially all you need is a few lines of .NET code, an XML configuration file and some kind of UI. You can then execute your .NET MF code against the emulator and (in theory) see the same results as you would on the actual hardware.

I've made a basic attempt at defining the hardware in the emulator XML configuration file:

http://www.codeplex.com/PureRobotDigiConnect/SourceControl/FileView.aspx?itemId=13592&changeSetId=4771

This file outlines the Input / Output (IO) capability of the Digi Connect ME module, and the memory characteristics as defined in the documentation:

Processor: 55MHz NS7520 (Digi Part no. NS7520B-1-I55)
Memory: 2 MB of Flash, 8 MB of SDRAM
IO: 5 GPIO pins, TTL (CMOS 3.3V) serial

For the user interface I used an image of the JumpStart kit board and added some overlaid bitmaps for the LEDs in the on state.

The emulator framework provides a nice set of objects to listen out for GPIO state changes. The only complexity in the UI code is that IO events will occur on another thread, so you need to synchronize with the UI thread before modifying the Windows Forms components to represent changes. When I first tried this, I used the InvokeRequired/BeginInvoke pattern of Windows Forms controls, but found the performance sucked. Instead I went for a synchronized set of integer variables which are modified by the IO thread using .NET thread synchronisation objects, then read on a timer from the UI thread - this seems to give a more realistic emulation experience.

The code for the UI form is here:

http://www.codeplex.com/PureRobotDigiConnect/SourceControl/FileView.aspx?itemId=159650&changeSetId=4771

Running the Demo Code
To run the sample code:

• Download the Visual Studio 2005 source and open the solution
  • You might have to cancel a few dialogs that attempt to access the source control server, then choose to 'Permanently remove source control association bindings'
• Build the solution
  • When you build the solution the emulator will be added to the registry
• Open the Project Properties of PureRobot.Digi.ConnectME.JumpStart.LightFun -> Micro Framework tab, and set the Transport to Emulator and the Device to 'PureRobot.Emulators.Digi.ConnectME.JumpStart'
• Set the PureRobot.Digi.ConnectME.JumpStart.LightFun to the startup project
• Run (hit F5)
  • If everything has been successful you should see the lights flashing away on the emulator application as they do in the video above.

Please feel free to play with the code and if you have any bugs, problems or improvements please don't hesitate to contact me through comments to this post or through the CodePlex site.

Labels: Microsoft .NET Micro Framework

# posted by Luke Thompson on Monday, October 13, 2008 -   2 Comments

A common requirement for powering a microcontroller based circuit is to regulate voltage to a steady level, protecting the sensitive equipment from fluctuations in power.

One of the simplest devices that can be used to achieve this result is a voltage regulator, such as the Sipex SPX1117U shown to the right.

Using the SPX1117U (the 3.3 volt variant of the SPX1117 range), I have hooked up a small circuit on the breadboard to demonstrate the process. The circuit below consists of the following components:

• 9V Battery
• Gator clip wires
• Home made power jack - two strips from a ribbon cable crimped onto a two pin socket
• Assorted jumper wires - mainly borrowed from a spare bit of CAT5 cable
• An SPX1117U voltage regulator
• Three 100 ohm resistors (Brown, Black, Brown)
• A bright blue LED
• A dull three colour LED
• A DIP switch block used to control the colour of to the three colour LED

The resistors are required here to protect two components: the LEDs which have a maximum current of around 30 milliamps and the voltage regulator itself which can supply a maximum current of 800 milliamps. The brightness of the LEDs will be determined by several factors to do with the quality of the material they were constructed with and the amount of current passing through them. The current flowing through the LEDs is limited by two 100 ohm resistors protecting each LED. The choice of 100 ohm resistors was somewhat arbitrary, being enough to ensure a small current is supplied so that the LEDs will light up brightly without overburdening the voltage regulator or burning out the LEDs.

Improving the Stability
The circuit above is fine for LEDs, but if you want to power something which requires a steadier voltage you'll need some additional components. According to the SPX1117U documentation, an output capacitor with a minimum value of 2.2uF but recommended 100uF will make the output stable.

In order to increase the output voltage stability, I've added a 100uF aluminium capacitor to the circuit. It is placed across the 3.3 volt output power rail:

In simplified circuit diagram form, this is the above circuit, including the stabilizing capacitor:

The use of capacitors as filtering and decoupling agents is especially important when one power source will be used for both sensitive components like microcontrollers and for rough components like motors. In the circuit above the capacitor is purely used for stabilizing the power output from the voltage regulator, however a more robust design to protect a sensitive circuit could be implemented like this:

Because of the different electrical characteristics and capacities that different materials allow for, a 100uF aluminium capacitor is used here as a filter and two 2.2uF tantalum capacitors for decoupling.

The circuit can be simplified into the diagram below:

This power supply circuitry can provide a stable platform for a simple robot, allowing the microcontroller to enjoy a steady voltage level whilst the other components of the robot introduce spikes and drains on the supply as they grind their way across the deserts of Mars or are picked up and hurled by a toddler.

Note: Thanks to the kind people on Electro Tech Online forums for helping me understand the issues surrounding LED current calculations, which I’ll cover further in a later post.

Labels: Electronics

# posted by Luke Thompson on Wednesday, September 17, 2008 -   0 Comments

Since I began researching the Microsoft .Net Micro Framework (.NET MF) I've come across some very handy white papers and resources. Here's a reading list:

• Introducing the .NET Micro Framework (Word Doc)
  A Microsoft 'Product Positioning and Technology' white paper written by Donald Thompson and Colin Miller. This white paper includes a nice discussion of the background of and business case for the .NET MF. It sells the idea that the lower development costs of using a managed environment and great tools like Visual Studio can offset the slightly higher per unit cost of using a 32-bit processor and licensing the .NET MF.
   
• Official .NET MF Site
  • Main Site (HTML)
  • Developer Centre (HTML)
  • Official Supporting Hardware List (HTML)
     
• Porting the .NET Micro Framework (PDF or HTML)
  A Microsoft technical white paper for device manufacturers about porting the .NET MF to their hardware platform. Includes interesting insights into the underlying framework.
   
• Embedded Development Kit for the Microsoft .NET Micro Framework Step by Step Guide (PDF)
  A tutorial for the SJJ Embedded Micro Solutions EDK module, which includes a great introduction to the .NET MF.
   
• Introducing Devices Profile for Web Services (DPWS) (PDF)
  Great introduction to DPWS, including an overview of the libraries, namespaces and important classes. Includes sample code for getting started with DPWS.
   
• .NET Micro Framework on miloush.net
  A great site, full of straight forward information, sample code and discussion of the .NET MF. Particularly useful is the list of available modules including approximate prices and the product comparison page, which appear to be kept up to date as new modules are released.
   
• The .NET MF News Group (newsreader, HTML, ATOM or RSS)
  The official newsgroup for .NET MF questions. The forum is very active, with knowledgeable people contributing to help with practical problems.
   
• The .NET MF Team Blog (HTML, ATOM or RSS)
  From the horses mouth, news and announcements on the .NET MF.

Labels: Microsoft .NET Micro Framework

# posted by Luke Thompson on Sunday, September 07, 2008 -   0 Comments

The Microsoft .NET Micro Framework (.NET MF) is licensed differently according to the volume you will be selling. There are three basic scenarios:

Pre-licensed Modules
Several original equipment manufacturers (OEMs) have ported the .NET MF to a 'module' which can be bought prepackaged with a number of connectivity and peripheral options. When you buy a module from an OEM, the license fee has already been paid to Microsoft, and there are no licensing fees for you to consider. Just buy the module, include it in your design and you're done.

An example of a pre-licensed module is the Digi Connect ME (DC-ME-01T-MF), which can be bought for approx. USD $50, and includes the .NET MF license. For a full list of available pre-licensed modules, see the comparison chart on miloush.net.

Discrete Custom Designs for Existing Ports
If you are building a device for mass distribution, a prepackaged module from an OEM may not exactly meet your connectivity, peripheral or pricing requirements. In this case you can use one of the processors that an OEM has already ported to the .NET MF in your design. If you choose this approach, you first contact Microsoft at netmfbiz@microsoft.com and send them information about your company, project, and potential volume. They will put you in contact with processor manufacturers from whom you can buy a CPU at volume, and then Microsoft will agree a per-unit license fee for the .NET MF in your particular case. For example, in a high-volume device project you may create a discrete design around an ARM processor supported in the porting kit or using a public board support package (BSP).  You could buy processors from Arrow, Digi-Key or some other distributor, and since those processors could be used with any platform, they won't have the license built in.

New Platform Port
If you have a processor architecture which the .NET MF has not yet been ported to and you want to use the .NET MF on this platform, you can sign a 'porting agreement' with Microsoft. The porting process involves working closely with Microsoft developers to incorporate your platform into the .NET MF. Processor and microcontroller manufacturers such as ARM and NXP have been through this process, sometimes directly and sometimes through specialists in porting new architectures to the .NET MF such as Adeneo. OEMs such as Digi use these processors and microcontrollers as part of the design of their prepackaged modules. To create such an agreement contact Microsoft at netmfbiz@microsoft.com. A Microsoft technical white paper for device manufacturers about porting the .NET MF to a new hardware platform can be found here: PDF or HTML.

Labels: Microsoft .NET Micro Framework

# posted by Luke Thompson on Wednesday, September 03, 2008 -   0 Comments