How To Measure Temperature with a Soldering Iron

Forget those expensive temperature sensors. Now you can use an ordinary heating element like a soldering iron to measure temperature. Daniel Maliks’s upgraded soldering iron will be a great addition to your workbench.

In Circuit Cellar 191, Malik writes:

There are many applications that involve the conversion of electric current into heat by means of a heating element with some degree of temperature control. Hot water boilers, kettles, and irons are typical examples. In this article, I’ll explain how you can eliminate the need for a temperature sensor by using the heating element itself to accurately measure temperature.

dsa

The finished soldering station. Think of it as a heating element turned temperature sensor.

I appreciate that electronics enthusiasts don’t necessarily want to read about cooking and ironing. So, I’ll describe a device you might be more comfortable thinking about: a soldering iron. All of the aforementioned appliances and tools have one important thing in common that makes them different from, say, a hair dryer. Any thoughts?

The important common factor is that the thermal resistance between the heating element and the heated medium is much lower than the thermal resistance between the medium and the ambient world. Thus, if electric current stops flowing through the heating element, the temperatures of the element and the medium will equalize long before the medium loses much of its temperature via heat radiation and conduction.

Because the resistance of all the conductors used for constructing heating elements has some temperature coefficient, you can measure the temperature of the heating element by measuring its resistance and comparing it to its resistance at, say, 25°C. This brings us neatly to the basic idea behind this project.

First, you turn on the heating element for a while. Then, switch it off and wait for the temperatures to equalize. After that, you must measure the resistance and calculate the temperature. And then do it again: switch on, switch off, measure, and so on. It’s easy to see why this approach wouldn’t work with a hair dryer. The air forced through a hair dryer moves quickly and has poor heat conductivity.

I can hear you asking the obvious questions. How difficult is it to measure the element resistance? How much does it change with temperature? Wouldn’t a simple sensor be cheaper and easier to use? It depends on the application. I will address these concerns as I describe the soldering iron example.

The schematic below shows Malik’s complete application. The power supply is the only part not shown in the schematic of the soldering station. The current source is powered
by 8 V to reduce power dissipation.

In the measurement circuit, the current source is built from an adjustable linear regulator. The current is set to a little higher than 200 mA. The main power switch Q1 is connected to an additional transistor circuit to translate the control voltages down to the 0- to 5-V range the Freescale MC68HC908QT4 microcontroller is capable of generating.

The complete application, without the power supply

The complete application, without the power supply

The MC68HC908QT4 microcontroller is an inexpensive 8-bit HC08 device housed in an eight-pin DIL package that’s easy to work with. The microcontroller is connected to an LED that indicates whether the soldering tip is below, equal to, or above the desired temperature. A potentiometer regulates the desired temperature. The remaining pieces of the circuit are two trimmers that are used to calibrate the offset and gain of the temperature regulation.

A schematic of the power supply I used isn’t shown here. I used a small, lightweight custom switch-mode power supply. However, the circuit will work equally well with a mains transformer-based power supply.

This temperature measurement application is very simple. As a result, the small amount of code for the ’HC908QT4 is little more than 700 bytes.

Download the entire CC191 article.

Translating Values: Number-to-ASCII Conversion (EE Tip #147)

There is a neat trick for performing the number-to-ASCII conversion. (We are not sure of this trick’s origin. We’d love to hear from anyone who saw it long ago and can us more about it.)ASCII-iStock_000007340231_Large

One starts by defining an array in the 8051 family microcontroller’s code segment using the following command:

HEX_NUM: DB ‘0123456789ABCDEF’

Following the conventions that now seem to be pretty standard for 8051 family assemblers, this command cause an array whose values are the ASCII values of the characters within the single quotes to be stored in the code segment (assuming that that is the segment in which you are working). To convert a number between 0 and 15 to the relevant ASCII value, you now need only store the value to be converted in the accumulator, A, and the location of the array HEX_NUM in the data pointer, DPTR. You then give the single command MOVC A, @A+DPTR. This command uses the current value of the accumulator, the value you are looking to translate into an ASCII value, as an offset and reads the relevant value of the array into A (thus overwriting the value you wanted to “translate” with the correct translation). Thus, if A starts off with a 5, it ends up with the sixth element of the array (as there is an element with a zero offset)—which is just the ASCII value of 5, and all of this takes place without any hard work on the part of the programmer.—Ahron Emanuel, Shlomo Engelberg, and Dvir Ophir (“Virtual Instrumentation, Circuit Cellar 294, 2015)

Probe a Circuit with the Power Off (EE Tip #146)

Imagine something is not working on your surface-mounted board, so you decide use your new oscilloscope. You take the probe scope in your right hand and put it on the microcontroller’s pin 23. Then, as you look at the scope’s screen, you inadvertently move your hand by 1 mm. Bingo!ComponentsDesk-iStock_000036102494Large

The scope probe is now right between pin 23 and pin 24, and you short-circuit two outputs. As a result, the microcontroller is dead and, because you’re unlucky, a couple of other chips are dead too. You just successfully learned Error 22.

Some years ago a potential customer brought me an expensive professional light control system he wanted to use. After 10 minutes of talking, I opened the equipment to see how it was built. My customer warned me to take care because he needed to use it for a show the next day. Of course, I said that he shouldn’t worry because I’m an engineer. I took my oscilloscope probe and did exactly what I said you shouldn’t do. Within 5 s, I short-circuited a 48-V line with a 3V3 regulated wire. Smoke and fire! I transformed each of the beautiful system’s 40 or so integrated circuits into dead silicon. Need I say my relationship with that customer was rather cold for a few weeks?

In a nutshell, don’t ever try to connect a probe on a fine-pitch component when the power is on. Switch everything off, solder a test wire where you need it to be, grab your probe on the wire end, ensure there isn’t a short circuit and then switch on the power. Alternatively, you can buy a couple of fine-pitch grabbers, expensive but useful, or a stand-off to maintain the probe in a precise position. But still don’t try to connect them to a powered board.—Robert Lacoste, CC25, 2013

Read Your Technical Documentation (EE Tip #145)

Last year we had a problem that showed up only after we started making the product in 1,000-piece runs. The problem was that some builds of the system took a very long time to power up. We had built about 10 prototypes, tested the design over thousands of power ups, and it tested just fine (thanks to POC-IT). Then the 1,000-piece run uncovered about a half-dozen units that had variable power-up times—ranging from a few seconds to more than an hour! Replacing the watchdog chip that controlled the RESET line to an ARM9 processor fixed the problem.

But why did these half dozen fail?

Many hours into the analysis we discovered that the RESET line out of the watchdog chip on the failed units would pulse but stay low for long periods of time. A shot of cold air instantly caused the chip to release the RESET. Was it a faulty chip lot? Nope. Upon a closer read of the documentation, we found that you cannot have a pull-up resister on the RESET line. For years we always had pull-ups on RESET lines. We’d missed that in the documentation.

Like it or not, we have to pour over the documentation of the chips and software library calls we use. We have to digest the content carefully. We cannot rely on what is intuitive.

Finally, and this is much more necessary than in years past, we have to pour over the errata sheets. And we need to do it before we commit the design. A number of years ago, a customer designed a major new product line around an Atmel ARM9. This ARM9 had the capability of directly addressing NOR memory up to 128 MB. Except for the fact that the errata said that due to a bug it could only address 16 MB. Ouch! Later we had problems with the I2C bus in the same chip. At times, the bus would lock up and nothing except a power cycle would unlock it. Enter the errata. Under some unmentioned conditions the I2C state machine can lock up. Ouch! In this case, we were able to use a bit-bang algorithm rather than the built-in I2C—but obviously at the cost of money, scheduling, and real time.—Bob Japenga, CC25, 2013

Impedance Matching Matters (EE Tip #145)

RF designers, as well as more and more digital-oriented designers, are used to thinking about impedance matching. But it is very easy to forget it when you are designing a non-RF project. A non-matched circuit will generate power losses as well as nasty reflection phenomena. (Refer to my article, “TDR Experiments,” Circuit Cellar 225, 2009.)

Impedance matching must be managed at the schematic stage, for example, by adding provisional matching pads for all integrated antennas, which will enable you to correct a slightly mis-adapted antenna (see Figure 1).

Figure 1: Impedance matching requirements must be anticipated. In particular, any embedded antenna will surely need manual matching for optimal performance. If you forget to include some area for a matching network like this one on your PCB, you won’t achieve the best performance.

Figure 1: Impedance matching requirements must be anticipated. In particular, any embedded antenna will surely need manual matching for optimal performance. If you forget to include some area for a matching network like this one on your PCB, you won’t achieve the best performance.

Impedance matching is also a PCB design issue. As rule of thumb, you can’t avoid impedance-matched tracks when you are working with frequencies higher than the speed of light divided by 10 times the board size. A typical 10-cm board would translate to a cutoff frequency of 300 MHz. A digital designer would then say: “Cool, my clock is only 100 MHz. No problem!” But a 100-MHz square-ware clock or digital signal means harmonic frequencies in the gigahertz range, so it would be wise to show some concern.

The problem could also happen with very slow clocks when you’re using fast devices. Do you want an example? Last year, one of my colleagues developed a complex system with plenty of large and fast FPGAs. These chips were programmed through a common JTAG link and we ended up with nasty problems on the JTAG bus. We still had issues even when we slowed down the JTAG speed to 100 kHz. So, it couldn’t have been an impedance matching problem, right? Wrong. It was. Simply because the JTAG is managed by the FPGA with the same ultra-fast logic cells that manage your fast logic so with stratospheric skew rates which translated into very fast transitions on the JTAG lines. This generated ringing due to improper impedance matching, so there were false transitions on the bus. Such a problem was easy to solve once we pinpointed it, but we lost some days in between.—Robert Lacoste, CC25, 2013

 

Liberally Apply Test Points (EE Tip #144)

When I first started designing, I did not understand the need for the scope posts for hardware test points. I could always tack on a wire or, with many through-hole parts, connect my scope right to the chip. But now test points are essential. My eyesight and steady hands are long gone. But it goes way beyond that. Many of the scope points are buried under the chips. And those that are exposed are smaller than grains of sand. Provide yourself access to the critical points.

Thinking about where you’ll want to probe the  software can also be useful. Linux has done a great job by providing hundreds “test points” for the OS. We should learn to do that with our applications. Planning in advance the places you want to test is also a useful exercise in the whole development cycle because early on it forces you to think about testing.—Bob Japenga, CC25, 2013

Use Watchdog Timers (EE Tip #143)

Watchdog timers are essential to many complete electronic system designs.  As Bob Japenga explains, following a few guidelines will help make your designs more effective.

No longer used in just the realm of fault-tolerant systems, independent watchdog timers are put on systems because we know something can go wrong and prevent it from being fully functional. Sometimes the dogs reset the processor and sometimes they just safe the device and notify a user. However they work, they are an essential part of any system design. Here are the main guidelines we use:

  • Make it independent of the processor. The last thing you want is for the processor to lock up and the watchdog to lock up too.
  • Do not tickle the watchdog during an interrupt. (The interrupt can keep going while a critical thread is locked up.)
  • Do not tickle the watchdog until you are sure that all of your threads are running and stable.
  • Provide a way for your debugger to have break points without tripping the watchdog.
  • If the watchdog can be disabled, provide a mechanism for this to be detected.

I provide many more guidelines for watchdog design in a white paper that’s posted on our website.—Bob Japenga, CC25, 2013

Troubleshoot Electronics Problems with Logging (EE Tip #141)

Electrical engineers often develop “headless” electronic systems—that is, systems without user interfaces. And many of those systems are embedded within product and are generally out of reach when problems occur. Bob Japenga is an engineer with some advice about logging and how it can help you troubleshoot problems as they occur.

Many of our designs are buried in some product or located in remote areas. No one is there when the device hiccoughs. Well defined logging can help make your system more robust because there are going to be problems and you might as well find out as much as you can about the problems when they happen. Here are some general guidelines that we apply here:

• Use an existing logging facility if you can. It should have all of the features discussed here.

• Unless you truly have unlimited disk space, provide a self-pruning cap on all logs. Linux syslog feature has this built in.

• Attempt to provide the most amount of information in the least amount of space. One way we do this is by limiting the number of times the same error can be logged. I cannot tell you how many times I look at a log file and find the same error logged over and over again. Knowing your memory limitation and the frequency of the error, after a set number of identical logs, start logging only one in every 100, or only allow so many per hour, and include the total count. Some failures are best kept in error counters. For example, communications errors in a noisy environment should be periodically logged with a counter; you don’t usually need to know every occurrence.

• Create multiple logs concerning multiple areas. For example, network errors and communications errors are better kept in their own log apart from processing errors. This will help a single error from flooding all logs with its own problem.

• Timestamp all logs—ideally with date and time—but I understand that all of our systems don’t have date and time. As a minimum, it could be in milliseconds since power-up.

• Establish levels of logging. Some logging is only applicable during debugging. Build that into your logging.

• Avoid side effects. I hate it when the designer tells me that if he turns logging on, the system will come to its knees. That’s just a bad logging design.

• Make the logs easy to automatically parse.—Bob Japenga, CC25, 2013

Embedded Security (EE Tip #139)

Embedded security is one of the most important topics in our industry. You could build an amazing microcontroller-based design, but if it is vulnerable to attack, it could become useless or even a liability.  EmbeddSecurity

Virginia Tech professor Patrick Schaumont explains, “perfect embedded security cannot exist. Attackers have a wide variety of techniques at their disposal, ranging from analysis to reverse engineering. When attackers get their hands on your embedded system, it is only a matter of time and sufficient eyeballs before someone finds a flaw and exploits it.”

So, what can you do? In CC25, Patrick Schaumont provided some tips:

As design engineers, we should understand what can and what cannot be done. If we understand the risks, we can create designs that give the best possible protection at a given level of complexity. Think about the following four observations before you start designing an embedded security implementation.

First, you have to understand the threats that you are facing. If you don’t have a threat model, it makes no sense to design a protection—there’s no threat! A threat model for an embedded system will specify what can attacker can and cannot do. Can she probe components? Control the power supply? Control the inputs of the design? The more precisely you specify the threats, the more robust your defenses will be. Realize that perfect security does not exist, so it doesn’t make sense to try to achieve it. Instead, focus on the threats you are willing to deal with.

Second, make a distinction between what you trust and what you cannot trust. In terms of building protections, you only need to worry about what you don’t trust. The boundary between what you trust and what you don’t trust is suitably called the trust boundary. While trust boundaries were originally logical boundaries in software systems, they also have a physical meaning in embedded context. For example, let’s say that you define the trust boundary to be at the chip package level of a microcontroller.

This implies that you’re assuming an attacker will get as close to the chip as the package pins, but not closer. With such a trust boundary, your defenses should focus on off-chip communication. If there’s nothing or no one to trust, then you’re in trouble. It’s not possible to build a secure solution without trust.

Third, security has a cost. You cannot get it for free. Security has a cost in resources and energy. In a resource-limited embedded system, this means that security will always be in competition with other system features in terms of resources. And because security is typically designed to prevent bad things from happening rather than to enable good things, it may be a difficult trade-off. In feature-rich consumer devices, security may not be a feature for which a customer is willing to pay extra. The fourth observation, and maybe the most important one, is to realize is that you’re not alone. There are many things to learn from conferences, books, and magazines. Don’t invent your own security. Adapt standards and proven techniques. Learn about the experiences of other designers. The following examples are good starting points for learning about current concerns and issues in embedded security.

Security is a complex field with many different dimensions. I find it very helpful to have several reference works close by to help me navigate the steps of building any type of security service.

Schaumont suggested the following useful resources:

Don’t Trust Connectors, Solder, or Wires (EE Tip #138)

Engineer Robert Lacoste is one of our go-to resources for engineering tips and tricks. When we asked him for a few bits of general engineering advice, he responded with a list of more than 20 invaluable electrical engineering-related insights. One our team’s favorite “Lacoste tips” is this: don’t trust connectors, solder, or wires. Read on to learn more.

One of my colleagues used to say that 90% of design problems are linked either to power supplies or to connector-related issues. It’s often the case. Never trust a wire or a connector. If you don’t understand what’s going on, use your ohmmeter to check if the connections are as planned. (Do this even if you are sure they are.) A connector might have a broken pin, a wire might have an internal cut, a solder joint might be dry and not conductive, or you might simply have a faulty wiring scheme. (See the nearby photo.)

Using the wrong pinout for a connector is a common error, especially on RS-232 ports where it’s approximately 50% probable that you’ll have the wrong RX/TX mapping. Swapping the rows of a connector (as you see here) is also quite common.

Using the wrong pinout for a connector is a common error, especially on RS-232 ports where it’s approximately 50% probable that you’ll have the wrong RX/TX mapping. Swapping the rows of a connector (as you see here) is also quite common.

Another common error is to spend time on a nonworking prototype only to discover after a few hours that the prototype was working like a charm but the test cable was faulty. This should not be a surprise: test cables are used and stressed daily, so they’re bound to be damaged over time. This can be even more problematic with RF cables, which might seem perfect when checked with an ohmmeter but have degraded RF performance. As a general rule, if you find that a test cable shows signs of fatigue (e.g., it exhibits intermittent problems), just toss it out and buy a new one!—Robert Lacoste, CC25, 2013

 

Test Under Real Conditions (EE Tip #137)

The world’s best engineers have one thing in common: they’re always learning from their mistakes. We asked Niagara College professor and long-time contributor Mark Csele about his biggest engineering-related mistake. He responded with the following interesting insight about testing under real conditions.

Mark Csele's complete portable accelerometer design, which he presented in Circuit Cellar 266.  with the serial download adapter. The adapter is installed only when downloading data to a PC and mates with an eight pin connector on the PCB. The rear of the unit features three powerful rare-earth magnets that enable it to be attached to a vehicle.

Mark Csele’s complete portable accelerometer design, which he presented in Circuit Cellar 266. with the serial download adapter. The adapter is installed only when downloading data to a PC and mates with an eight pin connector on the PCB. The rear of the unit features three powerful
rare-earth magnets that enable it to be attached to a vehicle.

Trusting simulation (or, if you prefer, lack of testing under real conditions). I wrote the firmware for a large three-phase synchronous control system. The code performed amazingly well in the lab, and no matter what stimulus was applied, it always produced correct results. When put into operation in the field (at a very large industrial installation), it failed every 20 minutes or so, producing a massive (and dangerous) step-voltage output! I received a call from a panicked engineer on-site, and after an hour of diagnosis, I asked for a screenshot of the actual power line (which was said to be “noisy,” but we knew this ahead of time) only to be shocked at how noisy. Massive glitches appeared on the line many times larger than the AC peak and crossing zero several times, causing no end of problems. Many hours later (the middle of the morning), the software was fixed with a new algorithm that compensated for such “issues.” This was an incredibly humbling experience: I wasn’t nearly as smart as I had thought, and I really missed the boat on testing. I tested the system under what I thought were realistic conditions, whereas I really should have spent time investigating what the target grid really looked like.—Mark Csele, CC25 (anniversary issue)

Specs & Code Matter (EE Tip #136)

No matter how many engineering hours you’ve logged over the years, it’s always a good idea to keep in mind that properly focusing on specs and code can make or break a project. In 2013, Aubrey Kagan—an experienced engineer and long-time Circuit Cellar author—explained this quite well in CC25:

There was a set of BCD thumbwheel switches that I was reading into a micro. In order to reduce the number of input lines required, each 4 bits of a digit was multiplexed with the other digits and selection was made by a transistor enabling the common line of each switch in turn. This was standard industry practice. The problem was that in order to economize, I had used the spare transistors in a Darlington driver IC. Everything worked fine in the lab, but on very hot days the unit would fail in the field with very strange results.

Long story short, the saturation voltage on the Darlington transistor would increase with temperature to above the digital input threshold and the micro would read undefined switch settings and then jump to non-existing code. I learned three things: read and understand all the specifications on a datasheet, things get a lot hotter in a cabinet in the sun than the lab, and you should make sure your code can handle conditions that are not supposed to occur.—Aubrey Kagan, CC25 (2o13)

Want to share an EE tip of your own? Email our editors to share your tips and tricks.

One-Wire RS-232 Half Duplex (EE Tip #135)

Traditional RS-232 communication needs one transmit line (TXD or TX), one receive line (RXD or RX), and a Ground return line. The setup allows a full-duplex communication. However, many applications use only half-duplex transmissions, as protocols often rely on a transmit/acknowledge scheme. With a simple circuit like Figure 1, this is achieved using only two wires (including Ground). This circuit is designed to work with a “real” RS-232 interface (i.e., using positive voltage for logic 0s and negative voltage for logic 1s), but by reversing the diodes it also works on TTL-based serial interfaces often used in microcontroller designs (where 0 V = logic 0; 5 V = logic 1). The circuit needs no additional voltage supply, no external power, and no auxiliary voltages from other RS-232 pins (RTS/CTS or DTR/DSR).Grun1-Wire-RS232-HalfDup

Although not obvious at a first glance, the diodes and resistors form a logic AND gate equivalent to the one in Figure 2 with the output connected to both receiver inputs. The default (idle) output is logic 1 (negative voltage) so the gate’s output follows the level of the active transmitter. The idle transmitter also provides the negative auxiliary voltage –U in Figure 2. Because both receivers are connected to one line, this circuit generates a local echo of the transmitted characters into the sender’s receiver section. If this is not acceptable, a more complex circuit like the one shown in Figure 3 is needed (only one side shown). This circuit needs no additional voltage supply either. In this circuit the transmitter pulls its associated receiver to logic 1 (i.e., negative voltage) by a transistor (any standard NPN type) when actively sending a logic 0 (i.e., positive voltage) but keeps the receiver “open” for the other transmitter when idle (logic 1). Here a negative auxiliary voltage is necessary which is generated by D2 and C1. Due to the start bit of serial transmissions, the transmission line is at logic 1 for at least one bit period per character. The output impedance of most common RS-232 drivers is sufficient to keep the voltage at C1 at the necessary level.

Note: Some RS-232 converters have quite low input impedance; the values shown for the resistors should work in the majority of cases, but adjustments may be necessary. In case of extremely low input impedance, the receiving input of the sender may show large voltage variations between 1s and 0s. As long as the voltage is below –3 V at any time these variations may be ignore.— Andreas Grün, “One Wire RS-232 Half Duplex,” Elektor July/August 2009.

Low-Drop Series Regulator Using a TL431 (EE Tip #134)

You likely have a stash of 12-V lead acid batteries (such as the sealed gel cell type) in your lab or circuit cellar. Below is a handy tip from Germany-based Lars Krüger for a simple way to charge them.

A simple way of charging them is to hook up a small unregulated 15-V wall wart power supply. This can easily lead to overcharging, though, because the off-load voltage is really too high. The remedy is a small but precise series regulator using just six components, which is connected directly between the power pack and the battery (see schematic) and doesn’t need any heatsink.EL2009-Kruger-SeriesReg

The circuit is adequatele proof against short circuits (minimum 10 seconds), with a voltage drop of typically no more than 1 V across the collector-emitter path of the transistor.

For the voltage source you can use any transformer power supply from around 12 V to 15 V delivering a maximum of 0.5 A. By providing a heatsink for T1 and reducing the value of R1 you can also redesign the circuit for higher currents.

Resource: http://focus.ti.com/lit/ds/symlink/tl431.pdf. This tip first appeared in Elektor July/August 2009.

Measuring Jitter (EE Tip #132)

Jitter is one of the parameters you should consider when designing a project, especially when it involves planning a high-speed digital system. Moreover, jitter investigation—performed either manually or with the help of proper measurement tools—can provide you with a thorough analysis of your product.

There are at least two ways to measure jitter: cycle-to-cycle and time interval error (TIE).

WHAT IS JITTER?
The following is the generic definition offered by The International Telecommunication Union (ITU) in its G.810 recommendation. “Jitter (timing): The short-term variations of the significant instants of a timing signal from their ideal positions in time (where short-term implies that these variations are of frequency greater than or equal to 10 Hz).”

First, jitter refers to timing signals (e.g., a clock or a digital control signal that must be time-correlated to a given clock). Then you only consider “significant instants” of these signals (i.e., signal-useful transitions from one logical state to the other). These events are supposed to happen at a specific time. Jitter is the difference between this expected time and the actual time when the event occurs (see Figure 1).

Figure 1—Jitter includes all phenomena that result in an unwanted shift in timing of some digital signal transitions in comparison to a supposedly “perfect” signal.

Figure 1—Jitter includes all phenomena that result in an unwanted shift in timing of some digital signal transitions in comparison to a supposedly “perfect” signal.

Last, jitter concerns only short-term variations, meaning fast variations as compared to the signal frequency (in contrast, very slow variations, lower than 10 Hz, are called “wander”).

Clock jitter, for example, is a big concern for A/D conversions. Read my article on fast ADCs (“Playing with High-Speed ADCs,” Circuit Cellar 259, 2012) and you will discover that jitter could quickly jeopardize your expensive, high-end ADC’s signal-to-noise ratio.

CYCLE-TO-CYCLE JITTER
Assume you have a digital signal with transitions that should stay within preset time limits (which are usually calculated based on the receiver’s signal period and timing diagrams, such as setup duration and so forth). You are wondering if it is suffering from any excessive jitter. How do you measure the jitter? First, think about what you actually want to measure: Do you have a single signal (e.g., a clock) that could have jitter in its timing transitions as compared to absolute time? Or, do you have a digital signal that must be time-correlated to an accessible clock that is supposed to be perfect? The measurement methods will be different. For simplicity, I will assume the first scenario: You have a clock signal with rising edges that are supposed to be perfectly stable, and you want to double check it.

My first suggestion is to connect this clock to your best oscilloscope’s input, trigger the oscilloscope on the clock’s rising edge, adjust the time base to get a full period on the screen, and measure the clock edge’s time dispersion of the transition just following the trigger. This method will provide a measurement of the so-called cycle-to-cycle jitter (see Figure 2).

Figure 2—Cycle-to-cycle is the easiest way to measure jitter. You can simply trigger your oscilloscope on a signal transition and measure the dispersion of the following transition’s time.

Figure 2—Cycle-to-cycle is the easiest way to measure jitter. You can simply trigger your oscilloscope on a signal transition and measure the dispersion of the following transition’s time.

If you have a dual time base or a digital oscilloscope with zoom features, you could enlarge the time zone around the clock edge you are interested in for more accurate measurements. I used an old Philips PM5786B pulse generator from my lab to perform the test. I configured the pulse generator to generate a 6.6-MHz square signal and connected it to my Teledyne LeCroy WaveRunner 610Zi oscilloscope. I admit this is high-end equipment (1-GHz bandwidth, 20-GSPS sampling rate and an impressive 32-M word memory when using only two of its four channels), but it enabled me to demonstrate some other interesting things about jitter. I could have used an analog oscilloscope to perform the same measurement, as long as the oscilloscope provided enough bandwidth and a dual time base (e.g., an old Tektronix 7904 oscilloscope or something similar). Nevertheless, the result is shown in Figure 3.

Figure 3—This is the result of a cycle-to-cycle jitter measurement of the PM5786A pulse generator. The bottom curve is a zoom of the rising front just following the trigger. The cycle-to-cycle jitter is the horizontal span of this transition over time, here measured at about 620 ps.

Figure 3—This is the result of a cycle-to-cycle jitter measurement of the PM5786A pulse generator. The bottom curve is a zoom of the rising front just following the trigger. The cycle-to-cycle jitter is the horizontal span of this transition over time, here measured at about 620 ps.

This signal generator’s cycle-to-cycle jitter is clearly visible. I measured it around 620 ps. That’s not much, but it can’t be ignored as compared to the signal’s period, which is 151 ns (i.e., 1/6.6 MHz). In fact, 620 ps is ±0.2% of the clock period. Caution: When you are performing this type of measurement, double check the oscilloscope’s intrinsic jitter as you are measuring the sum of the jitter of the clock and the jitter of the oscilloscope. Here, the latter is far smaller.

TIME INTERVAL ERROR
Cycle-to-cycle is not the only way to measure jitter. In fact, this method is not the one stated by the definition of jitter I presented earlier. Cycle-to-cycle jitter is a measurement of the timing variation from one signal cycle to the next one, not between the signal and its “ideal” version. The jitter measurement closest to that definition is called time interval error (TIE). As its name suggests, this is a measure of a signal’s transitions actual time, as compared to its expected time (see Figure 4).

Figure 4—Time interval error (TIE) is another way to measure jitter. Here, the actual transitions are compared to a reference clock, which is supposed to be “perfect,” providing the TIE. This reference can be either another physical signal or it can be generated using a PLL. The measured signal’s accumulated plot, triggered by the reference clock, also provides the so-called eye diagram.

Figure 4—Time interval error (TIE) is another way to measure jitter. Here, the actual transitions are compared to a reference clock, which is supposed to be “perfect,” providing the TIE. This reference can be either another physical signal or it can be generated using a PLL. The measured signal’s accumulated plot, triggered by the reference clock, also provides the so-called eye diagram.

It’s difficult to know these expected times. If you are lucky, you could have a reference clock elsewhere on your circuit, which would supposedly be “perfect.” In that case, you could use this reference as a trigger source, connect the signal to be measured on the oscilloscope’s input channel, and measure its variation from trigger event to trigger event. This would give you a TIE measurement.

But how do you proceed if you don’t have anything other than your signal to be measured? With my previous example, I wanted to measure the jitter of a lab signal generator’s output, which isn’t correlated to any accessible reference clock. In that case, you could still measure a TIE, but first you would have to generate a “perfect” clock. How can this be accomplished? Generating an “ideal” clock, synchronized with a signal, is a perfect job for a phase-locked loop (PLL). The technique is explained my article, “Are You Locked? A PLL Primer” (Circuit Cellar 209, 2007.) You could design a PLL to lock on your signal frequency and it could be as stable as you want (provided you are willing to pay the expense).

Moreover, this PLL’s bandwidth (which is the bandwidth of its feedback filter) would give you an easy way to zoom in on your jitter of interest. For example, if the PLL bandwidth is 100 Hz, the PLL loop will capture any phase variation slower than 100 Hz. Therefore, you can measure the jitter components faster than this limit. This PLL (often called a carrier recovery circuit) can be either an actual hardware circuit or a software-based implementation.

So, there are at least two ways to measure jitter: Cycle-to-cycle and TIE. (As you may have anticipated, many other measurements exist, but I will limit myself to these two for simplicity.) Are these measurement methods related? Yes, of course, but the relationship is not immediate. If the TIE is not null but remains constant, the cycle-to-cycle jitter is null.  Similarly, if the cycle-to-cycle jitter is constant but not null, the TIE will increase over time. In fact, the TIE is closely linked to the mathematical integral over time of the cycle-to-cycle jitter, but this is a little more complex, as the jitter’s frequency range must be limited.

Editor’s Note: This is an excerpt from an article written by Robert Lacoste, “Analyzing a Case of the Jitters: Tips for Preventing Digital Design Issues,” Circuit Cellar 273, 2013.