The Fundamentals of Fuseology

Purposeful Protection

Just because an electronic device is simple, you shouldn’t relegate it to an afterthought in your embedded system design. Such is the case with fuses. Robert explores the fundamentals of this seemingly simple device. In this article, he dives into the history, key specifications and technology of fuses. He also steps you through an experiment to analyze the performance of fuses and shares his results.

By Robert Lacoste

Welcome back to the “Darker Side.” As electronic system designers, we’ve become used to dealing with some fantastic and ultra-complex pieces of silicon in our projects—microcontrollers running at hundreds of megahertz, multi-core processors with billions of transistors, wireless transceivers with Gbps of throughput, miniature power converters with close to 100% efficiency and so on. Ok, of course some small discrete parts are still required around those key building blocks, but we’re inclined to disdain such components in the design phase. That’s because they represent a very small portion of the overall bill of materials and have low perceived value.

All that said, if you are a regular reader of this column, you already know that’s a bad choice. Some electronic components seem very simple—passives in particular. But such devices may be the source of incredible trouble if you don’t understand the intimate details of their behavior. If you have any doubt, go and re-read my articles on capacitors—for example, Circuit Cellar 283 “Dielectric Absorption;” Circuit Cellar 317 “Decoupling Capacitors and RLC Networks;” Circuit Cellar 321 “All Ceramic Capacitors Aren’t Equal.”

This month, I will talk about another very simple part that isn’t as simple as it seems: The fuse.


Of course, you’ve all seen a fuse before. Fuses are as old as electricity. According to Wikipedia, their first documented use was in 1864 for telegraph installations [1]. The first patent on a fuse was registered by Thomas Edison (him again?) in 1890. Today, fuses are everywhere, and range from ultra-miniature, surface-mounted devices to massive units used in nuclear-powered generators. Let’s restrict the discussion to small fuses common in electronic devices, such as the ubiquitous 20 mm x 5 mm fuse cartridge, illustrated in Figure 1. The picture speaks for itself—a fuse is nothing more than a wire. It is designed to be a protection device, and open the circuit in case of overcurrent. The wire is designed to melt above a given current threshold and to open the circuit.

Figure 1
A typical 20 mm x 5 mm miniature fuse, nothing more than a wire in a sealed glass tube.

Let’s spend a few minutes on these words: “protection device.” What does this mean? What is protected by the fuse? The answer to this question is not as obvious as it seems, because a fuse serves two purposes. First, it helps to protect the components of the device itself—meaning the device after the fuse— from extensive damage in case of a fault. For example, a fuse at the input of a power supply could save sensitive parts from destruction if the power supply malfunctions. Second, a fuse isolates the device from the outer world when the device is faulty, and this helps to prevent greater damage to other equipment.

“Protection device” also means that a fuse should not be, by itself, a potential source of hazard. When the wire in a fuse is melting, it will be hot and liquid, and could start a fire without adequate precautions. That’s why a fuse wire is always hermetically sealed, like the glass tube in Figure 1. That’s a requirement. Fuses are regulated by standards, mainly IEC 60269 [2] (for residential or large fuses) and IEC 60127 (for miniature fuses like my 20 mm × 5 mm example). Ok, Americans prefer UL248, which is a different standard—but the spirit is the same. In any case, these standards state that a fuse should not allow any external sign when a fault occurs. In other words, that means that everything should be contained within the fuse body. No smoke or other material is expelled. This is true as long as the fuse is used within its specifications. More on that in a minute.

The term “overcurrent” also needs some explanation. What is an overcurrent? Is it a current just above the nominal current? For how long? Or a short circuit with thousands of amperes? Let’s dig into more details …


At this point, I encourage you to look for the datasheet of any standard fuse, and to read it carefully. Of course, you will find that a fuse is first specified by its package type and rated current. The rated current, written on the fuse, is simply the maximum current that it can continuously conduct without any problem.

Table 1
Here are some typical miniature fuse tripping times, depending on current and fuse type (from IEC60127-2:2014).

The second key characteristic of a fuse is its speed. How fast will it blow in case of trouble? As you might expect, this depends on several parameters, and the first is the current. The greater the current passing through the fuse, the faster the wire will melt and cut the link. What are the tolerated limits? For miniature fuses, two speed grades are available and specified by EIC60127-2: Quick acting (“F” type, for “fast”) and time-lag (“T” type). Typical values, their respective minimum and maximum breaking times, depending on the effective current are given in Table 1. A caution here: Standards are evolving, so always consult the latest official version of the standards for any precise information. Now, look again at Table 1. You will see, for example, that a quick-acting miniature fuse, when a current 275% higher than its rating is applied, must cut the wire in less than 2 seconds, but not less than 10 ms. These durations become respectively 10 seconds and 600 ms for a time-lag version. …

Read the full article in the August 349 issue of Circuit Cellar
(Full article word count: 2723 words; Figure count: 8 Figures.)

Don’t miss out on upcoming issues of Circuit Cellar. Subscribe today!

Note: We’ve made the October 2017 issue of Circuit Cellar available as a free sample issue. In it, you’ll find a rich variety of the kinds of articles and information that exemplify a typical issue of the current magazine.

Experimentation and Engineering

Frederic Vecoven is software engineer living in Luxembourg who enjoys experimenting with everything from his home’s central heating controller to FPGAs. He has been designing micrcontroller-based projects for more than a dozen years and is currently working on an EPROM emulator.—Nan Price, Associate Editor


NAN: What is your current occupation?

FREDERIC:: I am a software principal engineer at Oracle.

NAN: Your website features projects involving capacitors, microcontrollers, and EEPROM and hardware emulators. Tell us a little about the projects and your design process.

vecovenFREDERIC: At work I design firmware for high-end servers. At home I like to design my own stuff, so I have full control and can create new devices and/or enhance existing ones. I work on various projects and I don’t find enough time to document all of them on the website. For example, I designed a controller for the central heating in my house, but never documented it (it’s too “custom”). I love retrocomputing, which is how my FreHD project started. This is a hard-drive emulator for TRS-80 computers.

My design process starts from an idea (I have too many, so I must carefully select one) then a lot of thinking about the future implementation (as always, designing something is about compromises). Once I have a clear view in my mind about how things should work, I start prototyping. If possible, I use a breadboard or I create a PCB. Sometimes I do a lot of simulation before starting the prototyping, as this will save a lot of time. However, that cannot be done for all projects.

NAN: How long have you been designing microcontroller-based systems?

FREDERIC: More than 15 years.

NAN: How did you become interested in technology?

FREDERIC: When I was 13 years old I fell in love with computers when I saw a TRS-80 model in high school. I am thankful to my parents, who gave me a computer one year later.
I went to college and got a master’s degree in computer science. But I wasn’t satisfied, so I studied some more years to get another master’s degree, this time in electrical engineering. The combination of software and hardware is really powerful. A few years later, I relocated to the San Francisco Bay Area, but I am back in Europe now.

NAN: Describe the first embedded system you designed. Where were you at the time? What did you learn from the experience?

FREDERIC: My first big experience with a real embedded system was when I was working for Sun Microsystems. My group was writing the firmware for the system controllers of the SunFire 3800-6900 line. The embedded system was a small SPARC CPU running Wind River Systems’s VxWorks and the firmware was almost entirely written in Java.

NAN: What was the last electronics design-related product you purchased and how did you use it?

FREDERIC: I bought some FPGAs recently. I haven’t released any project with it yet, it is still a work in progress. My hobby time is very limited.

My idea is to use a CPU core and enhance it with new instructions to enable the generation of real-time signals. FPGAs are very powerful in that area, where a microcontroller would spend most of its time processing interrupts.

NAN: Are you currently working on or planning any projects?


This is Frederic’s PWM prototype for his Roland Super JX synthesizer.

FREDERIC: Yes, I have rewritten the Roland JX-10/MKS-70 firmware from scratch because I wanted to add PWM waveforms. This quickly turned into a big project. Currently, the prototype setup involves a simulator running the “assigner” code on my laptop. The laptop sends the sound board commands in System Exclusive (SysEx) Musical Instrument Digital Interface (MIDI) messages, which go to a microcontroller that extracts the payload from the SysEx. The payload is then sent to the sound board, which believes it got its instructions directly from the assigner. The sound board (which runs its own microcontroller) uses an EPROM emulator connected over USB, so I can easily modify the assigner code (running in the simulator) or the sound board code (running in the EPROM emulator) without having to program any chip. Note that I didn’t have an EPROM emulator, so I designed mine.


This oscilloscope capture shows the generated PWM signal.

FREDERIC: The power of CPUs and GPUs are really exciting. You can pretty much do everything with software now (a 32-bit core costs less than $5).
On the other side, people don’t pay enough attention to optimization, so I am sad anytime I see poorly written code. I am also excited with all the tools and hardware available today for so little cost. That wasn’t the case in the past, so it opens door to students and hobbyists.

NAN: Last question. Let’s say you had a full year and a nice budget to work on any embedded design project you wanted. Call it your “dream project.” What would it be?

FREDERIC: I would love to do some robotic design, but I am not an expert in mechanics and I don’t have the tools (e.g., lathe, milling machine, etc.). That would fill the gap: hardware, software, and mechanics.

Traveling With a “Portable Workspace”

As a freelance engineer, Raul Alvarez spends a lot of time on the go. He says the last four or five years he has been traveling due to work and family reasons, therefore he never stays in one place long enough to set up a proper workspace. “Whenever I need to move again, I just pack whatever I can: boards, modules, components, cables, and so forth, and then I’m good to go,” he explains.

Raul_Alvarez_Workspace _Photo_1

Alvarez sits at his “current” workstation.

He continued by saying:

In my case, there’s not much of a workspace to show because my workspace is whichever desk I have at hand in a given location. My tools are all the tools that I can fit into my traveling backpack, along with my software tools that are installed in my laptop.

Because in my personal projects I mostly work with microcontroller boards, modular components, and firmware, until now I think it didn’t bother me not having more fancy (and useful) tools such as a bench oscilloscope, a logic analyzer, or a spectrum analyzer. I just try to work with whatever I have at hand because, well, I don’t have much choice.

Given my circumstances, probably the most useful tools I have for debugging embedded hardware and firmware are a good-old UART port, a multimeter, and a bunch of LEDs. For the UART interface I use a Future Technology Devices International FT232-based UART-to-USB interface board and Tera Term serial terminal software.

Currently, I’m working mostly with Microchip Technology PIC and ARM microcontrollers. So for my PIC projects my tiny Microchip Technology PICkit 3 Programmer/Debugger usually saves the day.

Regarding ARM, I generally use some of the new low-cost ARM development boards that include programming/debugging interfaces. I carry an LPC1769 LPCXpresso board, an mbed board, three STMicroelectronics Discovery boards (Cortex-M0, Cortex-M3, and Cortex-M4), my STMicroelectronics STM32 Primer2, three Texas Instruments LaunchPads (the MSP430, the Piccolo, and the Stellaris), and the following Linux boards: two BeagleBones (the gray one and a BeagleBone Black), a Cubieboard, an Odroid-X2, and a Raspberry Pi Model B.

Additionally, I always carry an Arduino UNO, a Digilent chipKIT Max 32 Arduino-compatible board (which I mostly use with MPLAB X IDE and “regular” C language), and a self-made Parallax Propeller microcontroller board. I also have a Wi-Fi 3G TP-LINK TL-WR703N mini router flashed   with OpenWRT that enables me to experiment with Wi-Fi and Ethernet and to tinker with their embedded Linux environment. It also provides me Internet access with the use of a 3G modem.

Raul_Alvarez_Workspace _Photo_2

Not a bad set up for someone on the go. Alvarez’s “portable workstation” includes ICs, resistors, and capacitors, among other things. He says his most useful tools are a UART port, a multimeter, and some LEDs.

In three or four small boxes I carry a lot of sensors, modules, ICs, resistors, capacitors, crystals, jumper cables, breadboard strips, and some DC-DC converter/regulator boards for supplying power to my circuits. I also carry a small video camera for shooting my video tutorials, which I publish from time to time at my website ( I have installed in my laptop TechSmith’s Camtasia for screen capture and Sony Vegas for editing the final video and audio.

Some IDEs that I have currently installed in my laptop are: LPCXpresso, Texas Instruments’s Code Composer Studio, IAR EW for Renesas RL78 and 8051, Ride7, Keil uVision for ARM, MPLAB X, and the Arduino IDE, among others. For PC coding I have installed Eclipse, MS Visual Studio, GNAT Programming Studio (I like to tinker with Ada from time to time), QT Creator, Python IDLE, MATLAB, and Octave. For schematics and PCB design I mostly use CadSoft’s EAGLE, ExpressPCB, DesignSpark PCB, and sometimes KiCad.

Traveling with my portable rig isn’t particularly pleasant for me. I always get delayed at security and customs checkpoints in airports. I get questioned a lot especially about my circuit boards and prototypes and I almost always have to buy a new set of screwdrivers after arriving at my destination. Luckily for me, my nomad lifestyle is about to come to an end soon and finally I will be able to settle down in my hometown in Cochabamba, Bolivia. The first two things I’m planning to do are to buy a really big workbench and a decent digital oscilloscope.

Alvarez’s article “The Home Energy Gateway: Remotely Control and Monitor Household Devices” appeared in Circuit Cellar’s February issue. For more information about Alvarez, visit his website or follow him on Twitter @RaulAlvarezT.