ISM Basics (EE Tip #100)

The industrial, scientific, and medical (ISM) bands are radio frequency ranges freely available for industrial, scientific and medical applications, although there are also many devices aimed at private users that operate in these bands. ISM devices require only general type approval and no individual testing.

Source: Wolfgang Rudolph & Burkhard Kainka’s article, “ATM18 on the Air,” 080852, Elektor, 1/2009.

Source: Wolfgang Rudolph & Burkhard Kainka’s article, “ATM18 on the Air,” 080852, Elektor, 1/2009.

The radio communication sector of the International Telecommunication Union (ITUR) defines the ISM bands at an international level. Wi-Fi and Bluetooth operate in ISM bands, as do many radio headphones and remote cameras, although these are not usually described as ISM devices. These devices are responsible for considerable radio communications interference (especially at 433 MHz and at 2.4 GHz).

ITU-R defines the following bands, not all of which are available in every country:

  • 6.765 to 6.795 MHz
  • 13.553 to 13.567 MHz
  • 26.957 to 27.283 MHz
  • 40.66 to 40.70 MHz
  • 433.05 to 434.79 MHz
  • 902 to 928 MHz
  • 2.400 to 2.500 GHz
  • 5.725 to 5.875 GHz
  • 24 to 24.25 GHz

Some countries allocate further ISM bands in addition to those above. ISM applications have the lowest priority within any given band. Many bands available for ISM are shared with other spectrum users: for example the 433 MHz ISM band is shared with 70 cm amateur radio communications.

ISM users must not interfere with other users, but must be able to tolerate the interference to their own communications caused by higher-priority users in the same band. The band from 868 MHz to 870 MHz is often mistakenly characterized as an ISM band. It is nevertheless available to short-range radio devices, such as RFID tags, remote switches, remote alarm systems, and radio modules.

For more information, refer to Wolfgang Rudolph & Burkhard Kainka’s article, “ATM18 on the Air,” 080852, Elektor, 1/2009.

Internet of Things (IoT) Resources

Here we list several handy resources for engineers interested in the Internet of Things (IoT).IoT-WordCloud

  • The IoT Events site is an easy-to-use resource for find IoT events and meet-ups around the world.
  • The Internet of Things Conference is a resource for information relating to “IoT applications, IoT solutions, IoT example and m2m opportunities in smart cities, connected cars, smart grids, consumer electronics and mobile healthcare.”
  • The IoT Counsel website includes useful info such as bios and contact info for engineers, innovators, and thinkers working on IoT-related projects.
  • Michael Chui, Markus Loffler, and Roger Roberts present a comprehensive article on IoT in the McKinsey Quarterly. While this isn’t a design-centric document, you’ll find it’s an interesting in-depth overview of the technology and its applications.
  • The Business Leaders Network (BLN) has a page on the IoT. The most recent IoT even took place in June, but the site still has some interesting info about speakers, partners, and more.

Let us know about other good resources. Send your links via email or Twitter @circuitcellar.

CC278: Battery Basics

Front of a battery analyzer

The University of Washington recently announced its engineers have created a wireless communications system that enables everyday devices to power up and connect to the web without the use of batteries. Instead, such devices would tap the energy available in wireless signals.

According to an August article on the university’s website,  engineers have developed a communication system that takes advantage of what they call  “ambient backscatter,”  the TV and cellular transmissions all around us. You can read more about the breakthrough by checking out the university article.

It will be some time before such an approach becomes commercially viable. In the meantime, we’ll still be relying heavily on batteries. With that in mind, you should check out columnist George Novacek’s article in Circuit Cellar’s September issue. Novacek goes “back to the basics” of batteries in this first installment of a two-part series.

“Battery usage has increased due to the proliferation of mobile and cordless devices,” Novacek says in Part 1. “This article describes battery types generally available in retail stores. I’ll discuss their features, operation, and usages. While many exotic batteries and custom packages are available, this article focuses on standard batteries, which are the type you are most likely to encounter.”

He opens his discussion by distinguishing between batteries vs. cells and describing common battery packages.

“Although we tend to use the words ‘battery’ and ‘cell’ interchangeably, there is a difference,” Novacek says. “Batteries comprise cells (e.g., the well-known 9-V battery contains six 1.5-V cells, while the omnipresent AA ‘battery’ and many others are just single cells). I will use the common terminology, even though it may be at times technically incorrect.

“Batteries store chemical energy. When activated, the chemical process occurring internally converts the chemical into electrical energy. Alessandro Volta, an Italian physicist, is credited with inventing the “voltaic pile” in the early 19th century, although archeological discoveries suggest that some form of an electrical battery was known in ancient Babylon. National Carbon Company, known today as Eveready, began marketing a precursor of the ubiquitous carbon-zinc battery in 1896…

“According to Wikipedia, the most common battery packages available today include AA, AAA, C, D, 9-V pack, and different types of “button cells”. There is also a plethora of custom-made battery packs for power tools, cordless telephones, and so forth. No matter what kind of packaging, the battery principles for the given type remain the same.

“There are two categories of batteries: primary (i.e., single use) and rechargeable. Carbon-zinc is the oldest—and at one point the most common—primary battery. They are available in standard packages and inexpensive. Consequently, carbon-zinc batteries are often included by original equipment manufacturers (OEM) with devices (e.g., TV remote controls, portable radios, etc.). Although they have been improved over the years, some significant shortcomings remain, so I avoid using them.”

Novacek goes on to examine the drawbacks and advantages of carbon-zinc, alkaline, lithium, mercuric-oxide, silver-oxide button cell, lead-acid, nickel-cadmium (NiCad), and nickel-metal hydride (NiMH) batteries.

To learn more about what may be powering your handheld or other device, check out the September issue.

Embedded Sensor Innovation at MIT

During his June 5 keynote address at they 2013 Sensors Expo in Chicago, Joseph Paradiso presented details about some of the innovative embedded sensor-related projects at the MIT Media Lab, where he is the  Director of the Responsive Environments Group. The projects he described ranged from innovative ubiquitous computing installations for monitoring building utilities to a small sensor network that transmits real-time data from a peat bog in rural Massachusetts. Below I detail a few of the projects Paradiso covered in his speech.

DoppleLab

Managed by the Responsive Enviroments group, the DoppelLab is a virtual environment that uses Unity 3D to present real-time data from numerous sensors in MIT Media Lab complex.

The MIT Responsive Environments Group’s DoppleLab

Paradiso explained that the system gathers real-time information and presents it via an interactive browser. Users can monitor room temperature, humidity data, RFID badge movement, and even someone’s Tweets has he moves throughout the complex.

Living Observatory

Paradiso demoed the Living Observatory project, which comprises numerous sensor nodes installed in a peat bog near Plymouth, MA. In addition to transmitting audio from the bog, the installation also logs data such as temperature, humidity, light, barometric pressure, and radio signal strength. The data logs are posted on the project site, where you can also listen to the audio transmission.

The Living Observatory (Source: http://tidmarsh.media.mit.edu/)

GesturesEverywhere

The GesturesEverywhere project provides a real-time data stream about human activity levels within the MIT Media Lab. It provides the following data and more:

  • Activity Level: you can see the Media Labs activity level over a seven-day period.
  • Presence Data: you can see the location of ID tags as people move in the building

The following video is a tracking demo posted on the project site.

The aforementioned projects are just a few of the many cutting-edge developments at the MIT Media Lab. Paradiso said the projects show how far ubiquitous computing technology has come. And they provide a glimpse into the future. For instance, these technologies lend themselves to a variety of building-, environment-, and comfort-related applications.

“In the early days of ubiquitous computing, it was all healthcare,” Paradiso said. “The next frontier is obviously energy.”

Q&A: Colin O’Flynn (Engineering and “Pure” Research)

Colin O’Flynn

NAN: Where are you located?

COLIN: I’m currently living in Halifax, Nova Scotia, Canada. I’m originally from Hamilton, Ontario, Canada, and had been living in Edinburgh, Scotland for almost two years before I moved to Halifax.

NAN: How did you become interested in electronics?

COLIN: Like many people in this area, I did start at a very young age. If I had to pin one event as the starting of my life-long interest in electronics, it was getting one of those “20-in-1” kits from RadioShack as a present. My parents always encouraged my interest in electronics, but as they were a commercial airline pilot and a chartered accountant, it wasn’t the case of them initially pushing me in the same direction they started!

My dad found me a few small “learn-to-solder” kits, which I enjoyed. At age 8, I assembled my first real kit, the LED-Tric Christmas tree featured in the December 1994 issue of Popular Electronics. My parents have kept bringing that tree out as a Christmas decoration every year since, and it still works.

Besides my parents, I also had help from local people interested in electronics and became friends with many of the local electronics store owners. I spent many hours building projects from magazines like Electronics Now, Popular Electronics, Circuit Cellar, and the various Forrest M. Mims III books. I find it interesting to see the recent surge in “maker” culture. It’s something that has really been going on for years. Growing up, there wasn’t such a thing as maker spaces, but there were local people with interesting workshops who would share projects. It’s great to see this a little more mainstream now, as it means more opportunities for people to get involved at any stage of their life in this fascinating world.

NAN: What is your current occupation? Are you still consulting for projects related to 802.15.4 wireless communications?

COLIN: I’m currently a graduate student at Dalhousie University pursuing a PhD. I decided to go back to school for the chance to do more “pure” research. It’s also fun to have access to a range of tools I wouldn’t otherwise get—the lab I sit in has an anechoic chamber, for example. And we have most of the latest versions of high-end software like MATLAB (including most of the add-ons), 3-D electromagnetic antenna simulation software, FPGA design software, and so forth.

RadioBlocks

I’m only loosely involved in 802.15.4 projects for now, and not actively following the latest developments and standards. Having said that, a friend of mine has gotten involved in creating small, wireless modules called RadioBlocks.

They use an IEEE 802.15.4 radio combined with a small ARM Cortex-M0 microcontroller. They use an open-source mesh networking software we created called SimpleMesh, so most of my recent work on 802.15.4 has been around this project. The mesh software is designed to do the basic job of sending a block of data to another node, and otherwise staying out of the way. I previously did a lot of work using IPv6 on such small sensor networks, but haven’t been active in that area lately.

At Dalhousie, I’m working on the area of side-channel analysis of cryptographic systems, specifically power analysis. This area has a simple idea: if you have a microcontroller or other embedded controller, it typically has some internal data bus. When those data lines switch state, it takes power. But the power actually depends on the data. Imagine a databus switching from all 1s to all 0s in a clock cycle, compared to staying at all 1s. Likewise, different operations, such as a MUL compared to a LDI, have different power signatures. If you measure the current consumption on each clock cycle, you can learn something about the data being processed, and then often the secret key. Practically speaking, you can measure this current even with an electromagnetic probe, so you don’t need to physically modify the circuit board.

I gave a presentation at Black Hat Abu Dhabi in December 2012 about some of this work. If you are interested, the slides and white paper are available online at Blackhat.com, or from my personal website NewAE.com. You can see the photo above showing an example of attacking a microcontroller-based smart card. The capture software might look something like where you can see different computations the card is performing directly from the power trace. In this case, each burst is a round of the AES-128 computation.

NAN: Many of your projects include Atmel microcontrollers. Why Atmel?

COLIN: It’s no secret I’ve been a big fan of Atmel’s AVR microcontroller, but it wasn’t my first. I don’t know the exact lineage of my microcontroller work, but one of the first things I learned on was an AMD 2900 Evaluation and Learning Kit. A local electronics store happened to have it in stock. They had gotten it from someone cleaning out old inventory, as even at that time it was old. I added heatsinks, as the several amps it drew when powered with 5 V made a lot of those chips very hot. And, of course, you had to keep the entire board powered up if you didn’t want to lose you program you’d been manually entering. From there, I moved onto a Z80 trainer board, which let you program with a hex-entry keypad, and eventually I moved onto programming it from the computer. I designed a Z80 computer board but never built it—I still have the piece of transparency with the taped out PCB design and photosensitive PCB on which I was to expose it. That’s more than 10 years old now, so I suspect the chemicals in it have degraded a little!

I forget exactly why I picked up the AVRs, but I had one of the first AVRs released, Atmel’s AT90S1200, which I programmed in Assembly. After Assembly, I programmed them in BASIC (using MCS Electronics’s BASCOM-AVR), going as far to write a neural network in

BASCOM-AVR. Even today, I think BASIC gets a bad rap. It was almost the original “Arduino” environment, as you could drop down LCD drivers, ADC, and so forth without ever knowing much about how it worked, and with a really intuitive feel. I moved onto C sometime later, and used C almost exclusively for embedded development since. For some time, I was fairly involved in the tools used in the AVR world, such as WinAVR. Atmel donated a considerable amount of equipment to me, as at the time I was a high school student using these devices for science fair projects. I think that’s a great example of how such corporate donations pay off. I’ve almost exclusively used AVR processors since I am so familiar with them because of that. In addition, as a student with little money but lots of time, I was happy to spend hours each day on AVRFreaks.net or working on open-source tools. While Atmel probably ended up giving me around $3,000 worth of tools, I’m sure the value of work I performed for free in terms of open-source tool contributions or forum posts would be worth many times this.

A funny story around all this work: In undergrad, we used the Atmel AVR microcontrollers. During one of the first labs they distributed a tutorial on how to set up the WinAVR tools and compile your first program. As it turned out, this guide was something I wrote years prior and had posted to the WinAVR website. Sufficient to say, I did OK in that class.

NAN: Tell us about NewAE.com. What kind of information is available on the site?

COLIN: I’ve run NewAE.com since 2001, although it’s not really designed to be the type of website one checks for new content daily. If I’ve spent some time solving a problem that I think other people could use, I’ll put a post up. Sometimes this is a complete project, such as my IEEE 802.15.4 sniffer. Sometimes it’s just a small post, such as how to set up the AVR USB keyboard for 5-V operation, which wasn’t described in the manual. I also use it for keeping copies of any published papers or presentations.

I’ve more recently been posting some ongoing research to the site, including blog posts with ongoing projects, rather than just waiting until it’s completely finished! In that vein, I started a YouTube channel with some technical videos (www.youtube.com/user/colinpoflynn). A big collection of these are from when I taught a digital logic course and recorded all my presentations from that.

My content spans a huge range of topics—everything from showing my students how to get screen captures, to a demonstration of my soldering station, to recordings of my academic paper presentations. I don’t like duplicating work. I’ll only go to the effort of making a video or website post if I really couldn’t find the information elsewhere. Because of this, I don’t have one specific topic you could expect to learn about. I’ve never been aiming to be like EEVBlog!

NAN: You wrote “It’s a SNAP: A Flexible Communications Protocol” (Circuit Cellar 139, 2002) more than 10 years ago. Do you still use SNAP in any of your current projects?

COLIN: I have to admit that I haven’t used SNAP in probably eight years! Of course now, when needing to network devices, I’m more likely to turn to a wireless standard.

NAN: Your article “Open-Source AVR Development” (Circuit Cellar 196, 2006) provides an introduction to the AVR-GCC toolchain for AVR microcontrollers. The article references the Cygwin project and Sourceforge’s WinAVR project. How do these components work in the design?

COLIN: The Cygwin project is still something I use regularly, as it lets you run a variety of Unix-like tools on Windows. The Linux command line is extraordinarily powerful, and it is makes it simple to access things like C compilers, text parsing utilities, and scripting tools. With Cygwin, one can have a Linux-like experience under Windows, which I used in that article to build some of the tools you are developing for AVR. By comparison, WinAVR is just a number of prebuilt tools for the AVR development. While it’s more work to build your own tools, sometimes you require special features that were not available in the premade tools.

NAN: Atmel products have played a starring role in several articles you have published in Circuit Cellar. For example, an AT90S4433 microcontroller was featured in “It’s a SNAP: A Flexible Communications Protocol” (Circuit Cellar 139, 2002), an ATmega88 AVR RISC microcontroller was featured in “Digital Video in an Embedded System” (issue 184, 2005), an AT45DB041 DataFlash and an ATmega88 microcontroller were featured in “Open-Source AVR Development” (issue 187, 2006), and an AT90USBKEY demonstration board was featured in “Advanced USB Design Debugging” (issue 241, 2010). Why Atmel microcontrollers/boards? What do you prefer about these products?

COLIN: As I mentioned before, I have a long history with Atmel products. Because of this, I already have the debug toolchains for their chips and can get projects up very quickly.

When picking boards or products, one of the most important considerations for me is that readers can buy it easily. For me, this means I can get it at DigiKey (and I’ll check Farnell for our UK friends). Part of this comes from being in Canada, where DigiKey was one of the first distributors offering cheap and fast shipping to Canada.

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

Binary Explorer Board

COLIN: My current big project is something I designed over the summer of 2012. It’s called the Binary Explorer Board and is something I used when teaching a course in digital logic at Dalhousie University. I needed a simple, programmable logic board and nothing I could find was exactly right. In particular, I needed something with an integrated programmer, several switches and LEDs, and an integrated breadboard. The students needed to be able to use the breadboard without the CPLD to learn about discretely packaged parts. All the CPLD-based trainers I found didn’t have exactly what I wanted in this regard.

The embedded part is the USB interface using an Atmel AT90USB162 microcontroller, although I plan on later upgrading that to an XMEGA for lower cost and more code room. The firmware is powered by Dean Camera’s excellent open-source USB library called LUFA (www.fourwalledcubicle.com/LUFA.php). This firmware lets students program the CPLD on the board easily over USB. But the cool thing is you can go even further and use the device as a generic programmer for other AVRs or CPLDs/FPGAs. For example, you can mount an AVR on the breadboard, connect it to the USB interface, and program that through the Arduino IDE. The entire board would retail for $35 in single-unit quantity, so it’s cheaper than most textbooks. I’m working on making it a real product with Colorado Micro Devices right now.

The design environment is the standard Xilinx toolchain, although I’ve made a number of predefined projects to make it simple enough for students with zero previous design experience to use. The idea is to get students familiar with the real tools they might see in the industry. Around this project, it’s interesting to note I choose a Xilinx CPLD because of my familiarity with Xilinx devices and design tools. This familiarity comes from years ago when Xilinx donated to me a part for a project I was working on. Now throngs of students will be exposed to Xilinx devices, all because Xilinx was willing to donate some parts to a student.

There is always an assortment of half-finished projects, too. I started designing a battery tester, which could simulate characteristics you’d typically see when driving small wireless nodes from coin-cell batteries. I started planning on using an AVR USB microcontroller and doing all the data logging myself. I then found this LabJack device, which simplified my life a lot, as they had basically a generic USB-based logging/control module.

NAN: What do you consider to be the “next big thing” in the embedded design industry?

COLIN: Wireless and the “Internet of Things” will eventually be a big thing, which means design engineers will need to become more familiar with things like protocols and realistic transmission characteristics. I use the word “realistic,” as part of this world is separating hype from reality. There’s certainly a huge disconnect between the marketing hype around all these various wireless protocols and how well they work in practice. When designing a product that will use a wireless technology, it’s likely some commercial off-the-shelf (COTS) module will be used, so the engineer may think they can remain blissfully unaware of RF or networking things. But the engineer still needs to have a rough idea about how many devices might fit in an area on a single network or the advantage of selecting certain protocols.

Another thing of interest to me is programmable logic, such as FPGAs. It’s been interesting to see the tools that try to turn anybody into an FPGA designer becoming more mainstream, or at least letting you program FPGAs in more common languages (e.g., C/C++). They are still fairly specialized and more likely to be used by a hardware engineer looking to improve productivity, compared to a software engineer who needs to offload an algorithm into a FPGA. But I think they could fairly quickly get to the point that engineers with some FPGA experience could implement considerably more complex designs than they would have otherwise been able to had they been required to design everything from scratch.

In a somewhat similar vein, we are starting to see the availability of multicore devices coming down to embedded levels. Learning to program them in a way to take advantage of these new cores is a useful skill to pick up. I recently started using both the OpenMP API and Cilk++ development software on some of my programs. My work wasn’t targeting an embedded project, but instead regular full-size multicore computers, but it’s still a useful (and fairly simple) skill to pick up.

NAN: Tell us a little about your workbench. What are some of your favorite design tools?

Colin’s Workbench

COLIN: My initial workbench was the kitchen table, although other family members were frequently concerned about eating in the same space as these various items with warning labels about lead. My next workbench was a long, custom-built bench in Hamilton, Ontario. My current bench in Halifax was again custom-built, and I’ll take you few of its features. I’d like to point out by “custom-built” I mean built by myself with a jigsaw and some plywood, not an artesian finely crafted piece of furniture.

Due to a back injury, I work standing up, which you can’t see in the photo. It’s actually quite refreshing, and combined with a good quality antifatigue mat and stool to lean up against means I can work long hours without tiring. A cover comes down to hide everything in my desk, which was a feature partially required by my significant other, who didn’t want guests to see the typical mess of wires it contains. When closed, it also gives it some protection against any rogue water leaks. For my computer, I use a trackball instead of a mouse, and the keyboard and trackball are mounted on a plate tilted underneath the desk in a “negative” tilt angle, adjusted to most natural angle. And, because there is no way to see the keyboard while typing, it tends to keep anyone else from borrowing my computer to look something up!

I’ve wired a ground fault interrupter (GFI) into the desk, so all my power outlets are protected. If I ever did something dumb like dropping a scope ground on a live wire, the GFI socket would at least give me a hope of protecting the scope and myself. There are many outlets above and below the desk, and also a ground jack for the antistatic strap beside the thermal wire strippers. The outlets under the desk let me plug in things in a hidden manner—printers, USB hubs, and other permanent devices get wired in there. I’ve wired a number of USB hubs to the top of my desk, so I typically have around 12 free USB slots. You always seem to run out otherwise!

Most of my tools are off the desk and stored in the drawers to either side. I made the “drawers” just pieces of wood with minimal sides—the idea being most of the time you are placing PCBs or tools down, so the lack of high sides prevents you from piling too much into them! All the cables get stored on hooks to the left of my desk, and I’ve got a whiteboard that sticks up when I’m working on a problem.

SMD Organization

I store all my SMD parts in small envelopes stored in index card holders in the bottom left of my desk. While I’m not a static-phobic, I also didn’t want to use plastic film strips or plastic bags. So the paper envelopes at least I hope don’t generate much static, even if they don’t dissipate it. It’s very easy to label all your parts and also this system holds up to a high dynamic range of stock numbers. For example, capacitors get split into 10.1–99.9 nF, 100 nF, 100.1–999.9 nF, and so forth. Because you seem to end up with loads of 100-nF capacitors, they get their own envelope. It’s trivial to change this division around as you get more parts, or to group part sizes together.

In terms of interesting tools: my soldering station is probably my favorite tool, a Metcal MX500 I got used from eBay. The response time on these is unbelievable. I put a video up to show people just because I’ve been so impressed with it. There are other manufactures that now make stations with the same RF-heating technology I believe, and I always encourage everyone to try one. I’ve been using the DG8SAQ Vector Network Analyzer (VNWA) for a while too. It’s a very affordable way to get familiar with VNA and RF measurements. It’s especially fun to follow along with some of the “Darker Side” columns in Circuit Cellar. Rather than just hearing about the mysterious world of RF, you can do experiments like viewing the response of several different decoupling capacitors mounted in parallel. I’ve got an old TiePie TiePieSCOPE HS801 parallel-port oscilloscope mounted underneath my desk, and still use it today. A lot of my work is digital, so have an Intronix LogicPort digital analyzer, a Beagle USB 480 protocol analyzer, and oodles of microcontroller programming/debug tools from different manufacturers.