HumDT Wireless UART Data Transceiver

Linx Technologies recently announced the launch of its 11.5 mm × 14.0 mm HumDT wireless UART data transceiver with built-in networking with encryption. Each module can act as one of three components in a wireless network: an access point that controls a network, a range extender (to repeat messages and expand the network’s range, or an end device.

Linx Technologies HumDT

Linx Technologies HumDT

Each access point can connect to up to 50 range extenders and end devices. The access point also supports routing so end devices can communicate with each. The transceiver automatically manages all routing and network maintenance functions.

The 900-MHz HumDT version outputs up to 10 dBm, which results in a line-of-sight range of up to 1,600 m (1 mile), depending on the antenna implementation. The 2.4-GHz version outputs up to 1 dBm, resulting in a line-of-sight range of 100 m (300′).

To aid rapid development, the HumDT Series transceiver is available as part of a newly conceived type of Master Development System. This development kit is designed to assist in the rapid evaluation and integration of the HumDT Series data transceiver modules. The all-inclusive system features several preassembled evaluation boards, which include everything needed to quickly test the operation of the transceiver modules.

At below $9 in volume, the Hummingbird platform is a low-cost complete wideband transceiver with microcontroller module.

Source: Linx Technologies

 

Wearable Medical Computing and the Amulet Project

Health care is one of the most promising areas for employing wearable devices. Wearable mobile health sensors can track activities (e.g., count steps or caloric expenditure), monitor vital signs including heart rate and blood pressure, measure biometric data (e.g., glucose levels and weight), and provide alerts to medical emergencies including heart failures, falls, and shocks.

Applying wearable computing to support mobile health (mHealth) is promising but involves significant risks. For instance, there are security issues related to the reliability of the devices and sensors employed, the accuracy of the data collected, and the privacy of sensitive information.

The Amulet bracelet-style prototype for developers enables users to control its settings

The Amulet bracelet-style prototype for developers enables users to control its settings

Under the federally funded Amulet project, an interdisciplinary team of Dartmouth College and Clemson University researchers is investigating how wearable devices can effectively address medical problems while ensuring wearability, usability, privacy, and security for mHealth applications. The project aims to develop pieces of “computational jewelry” and a software framework for monitoring them. This computational jewelry set comprises wearable mobile health devices collectively named Amulet. An Amulet device could be worn as a discreet pendant or bracelet that would interact with other wearable health sensors that constitute the wearer’s wireless body-area network (WBAN). The Amulet device would serve as a “hub,” tracking health information from wearable health sensors and securely sending data to other health devices or medical professionals.

The project’s goals are multifold. Regarding the hardware, we’re focusing on designing small and unobtrusive form factors, efficient power sources, and sensing capabilities. With respect to the software, we’re concentrating on processing and interpreting the digital signs coming from the sensors, effectively communicating and synchronizing data with external devices, and managing encrypted data.

Amulet’s multiprocessor hardware architecture includes an application processor that performs computationally intensive tasks and a coprocessor that manages radio communications and internal sensors. Amulet’s current prototypes contain an accelerometer and a gyroscope to monitor the wearer’s motion and physical activities, a magnetometer, a temperature sensor, a light sensor, and a microphone. To save power, the application processor is powered off most of the time, while the coprocessor handles all real-time device interactions.

By employing event-driven software architecture, Amulet enables applications to survive routine processor shutdowns. Amulet is reactive, running only when an event of interest occurs. To handle such events, programmers can define their application as a finite-state machine and set appropriate functions. Amulet’s architecture enables applications to identify the computational states that should be retained between events. Explicitly managing program state (rather than implicitly managing state in a thread’s run-time stack) enables the run-time system to efficiently save the application state to persistent memory and power down the main processor without harming applications.

Amulet provides a secure solution that ensures the accuracy and the integrity of the data sensed and transmitted, continuous availability of the services provided (e.g., data sensing and processing and sending alerts and notifications), and access to the device’s data and services only by authorized parties after their successful authentication. Two key features enable Amulet to provide security in mHealth applications: sandboxing and the authorization manager. The former enforces access control, protects memory, and restricts the execution of event handlers. The latter enables applications to run small tasks until their completion, managing all resources by receiving requests and forwarding them to a corresponding service manager.

Amulet also aims to protect privacy, enabling users to control what is sensed and stored, where it is stored, and how it is shared (with whom). Amulet devices use privacy policies to protect patients’ sensitive information, which ensures confidentiality through authorized access and controlled sharing.

To guarantee easy wearability, the Amulet team focuses on understanding the user’s wishes, needs, and requirements and translating them into appropriate design decisions. Amulet provides a list of principles and guidelines for wearability, which will aid designers in providing high levels of comfort, aesthetics, ergonomics, and discretion in their projects.

Amulet includes a framework to support stakeholders involved in similar projects during all phases of development. It is intended to aid developers and designers from industry or academia. Amulet provides a general-purpose solution for body-area mobile health, complementing the capabilities of a smartphone and facilitating the development of applications that integrate one or more mHealth wearable devices.

Amulet also provides intuitive interfaces and interaction methods for user input and output, employing multimodal approaches that include gestures and haptics. Amulet has developed and continues to refine bracelet-style prototypes with a variety of envisioned applications, including: emergency responders (e.g., providing immediate notifications and quick responses in medical emergencies), stress monitoring, smoking cessation, diet (e.g., bite counting), and physical therapy (e.g., knee sensors).

Dr. Vivian Genaro Motti

Dr. Vivian Genaro Motti

ABOUT THE AUTHOR

Dr. Vivian Genaro Motti holds a PhD in Human Computer Interaction from the Université catholique de Louvain in Belgium. She is a Postdoctoral Research Fellow in the School of Computing at Clemson University in Clemson, SC. She works on the Amulet project, which is funded by a three-year, $1.5 million grant from the National Science Foundation’s Computer Systems Research program. As part of the Amulet project, Vivian is investigating how to properly ensure wearability and privacy in wearable applications for mobile health. Vivian has a BA in Biomedical Informatics and an MS in Human Computer Interaction from University of Sao Paulo in Brazil. Her main research interests are human computer interaction, medical applications, wearable devices and context awareness.

This appears in Circuit Cellar 288, July 2014.

Eco-Friendly Home Automation Controller

The 2012 DesignSpark chipKIT Challenge invited engineers from around the world to submit eco-friendly projects using the Digilent chipKIT Max32 development board. Manuel Iglesias Abbatemarco of Venezuela won honorable mention with his autonomous home-automation controller. His design enables users to monitor and control household devices and to log and upload temperature, humidity, and energy-use sensor data to “the cloud” (see Photo 1).

The design comprised a Digilent chipKIT board (bottom), my MPPT charger board (chipSOLAR, middle), and my wireless board (chipWIRELESS, top).

Photo 1: The design comprised a Digilent chipKIT board (bottom), my MPPT charger board (chipSOLAR, middle), and my wireless board (chipWIRELESS, top).

The system, built around the chipKIT Arduino-compatible board, connects to Abbatemarco’s custom-made “chipSOLAR” board that uses a solar panel and two rechargeable lithium-ion (Li-on) cells to provide continuous power. The board implements a maximum power point tracking (MPPT) charger that deals with a solar panel’s nonlinear output efficiency. A “chipWIRELESS” board integrating a Quad Band GSM/GPRS modem, an XBee socket, an SD card connector, and a real-time clock and calendar (RTCC) enables home sensor and cloud connectivity. The software was written using chipKIT MPIDE, and the SD card logs the data from sensors.

“Since the contest, I have made some additions to the system,” Abbatemarco says. “The device’s aim is uninterrupted household monitoring and control. To accomplish this, I focused on two key features: the power controller and the communication with external devices (e.g., sensors). I used DesignSpark software to create two PCBs for these features.”

Abbatemarco describes his full project, including his post-contest addition of a web server, in his article appearing in Circuit Cellar’s May issue. In the meantime, you’ll find descriptions of his overall design, power management board, and wireless board in the following article excerpts.

DESIGN OVERVIEW
The system’s design is based on a Digilent chipKIT Max32 board, which is an Arduino-compatible board with a Microchip Technology 32-bit processor and 3.3-V level I/O with almost the same footprint as an Arduino Mega microcontroller. The platform has all the computational power needed for the application and enough peripherals to add all the required external hardware.

I wanted to have a secure and reliable communication channel to connect with the outside world, so I incorporated general packet radio service (GPRS). This enables the device to use a TCP/IP client to connect to web services. It can also use Short Message Service (SMS) to exchange text messages to cellular phones. The device uses a serial port to communicate with the chipKIT board.

I didn’t want to deal with cables for the internal-sensor home network, so I decided to make the system wireless. I used XBee modules, as they offer a good compromise between price and development time. Also, if properly configured, they don’t consume too much energy. The XBee device uses a serial port to communicate with the chipKIT board.
To make the controller”green,” I designed a power-management board that can work with a solar panel and several regulated DC voltages. I chose a hardware implementation of an MPPT controller because I wanted to make my application as reliable as possible and have more software resources for the home controller task.

One board provides power management and the other enables communication, which includes additional hardware such as an SD card, an XBee module, and an RTCC. Note: I included the RTCC since the chipKIT board does not come with a crystal oscillator. I also included a prototyping area, which later proved to be very useful.

I was concerned about how users inside a home would interact with the device. The idea of a built-in web server to help configure and interact with the device had not materialized before I submitted the contest entry. This solution is very practical, since you can access the device through its built-in server to configure or download log files while you are on your home network.

POWER MANAGEMENT BOARD
To make the system eco-friendly, I needed to enable continuous device operation using only a solar panel and a rechargeable Li-ion battery. The system consumes a considerable amount of power, so it needed a charge controller. Its main task was to control the battery-charging process. However, to work properly, it also had to account for the solar panel’s characteristics.

A solar panel can’t deliver constant power like a wall DC adapter does. Instead, power varies in a complex way according to atmospheric conditions (e.g., light and temperature).
For a given set of operational conditions, there is always a single operating point where the panel delivers its maximum power. The idea is to operate the panel in the maximum power point regardless of the external conditions.

I used Linear Technology’s LT3652 MPPT charger IC, which uses an input voltage regulation loop. The chip senses the panel output voltage and maintains it over a value by adjusting the current drawn. A voltage divider network is used to program the setpoint.
You must know the output voltage the panel produces when operated at the maximum power point. I couldn’t find the manufacturer’s specification sheet for the solar panel, but the distributor provides some experimental numbers. Because I was in a hurry to meet the contest deadline, I used that information. Based on those tests, the solar panel can produce approximately 8 V at 1.25 A, which is about 10 W of power.

I chose 8 V as the panel’s maximum power point voltage. The resistor divider output is connected to the LT3652’s VIN_REG pin. The chip has a 2.7-V reference, which means the charge current is reduced when this pin’s voltage goes below 2.7 V.

I used a two-cell Li-ion battery, but since the LTC3652 works with two, three, and four cells, the same board with different components can be used with a three- or four-cell battery. The LT3652 requires an I/O voltage difference of at least 3.3 V for reliable start-up, and it was clear that the panel’s 8-V nominal output would not be enough. I decided to include a voltage step-up stage in front of the LT3652.

I used Linear Technology’s LT3479 DC/DC converter to get the panel output to around 18 V to feed the MPPT controller. This only works if the LT3562’s voltage control loop still takes the VIN_REG reference directly from the panel output. Figures 1 and 2 show the circuit.

Power management board

Figure 1: Power management board

Figure 2: Power management board

Figure 2: Power management board

I could have fed the chipKIT on-board 5-V linear regulator with the battery, but I preferred to include another switching regulator to minimize losses. I used Linear Technology’s LTC3112 DC/DC converter. The only problem was that I needed to be able to combine its output with the chipKIT board’s 5 V, either through the USB port or the DC wall adapter option.

The chipKIT board includes a Microchip Technology MCP6001 op-amp in comparator configuration to compare USB voltage against a jack DC input voltage, enabling only one to be the 5-V source at a given time. Something similar was needed, so I included a Linear Technology LTC4411 IC, which is a low-loss replacement ORing diode, to solve the problem.

To my knowledge, when I designed the board a battery gauge for two-cell lithium batteries (e.g., a coulomb counter that can indicate accumulated battery charge and discharge) wasn’t available. The available options needed to handle most of the computational things in software, so I decided it was not an option. I included a voltage buffer op-amp to take advantage of the LTC3112’s dedicated analog voltage output, which gives you an estimate of the instantaneous current being drawn. Unfortunately, I wasn’t able to get it to work. So I ended up not using it.

Building this board was a challenge, since most components are 0.5-mm pitch with exposed pads underneath. IC manufacturers suggest using a solid inner ground layer for switching regulators, so I designed a four-layer board. If you have soldering experience, you can imagine how hard it is to solder the board using only a hot air gun and a soldering iron. That’s why I decided it was time to experiment with a stencil, solder paste, and a convection oven. I completed the board by using a commercially available kitchen convection oven and manually adjusting the temperature to match the reflow profile since I don’t have a controller (see Photo 2).

Photo 3: Custom chipSOLAR board

Photo 2: Custom chipSOLAR board

WIRELESS BOARD
The wireless board has all the components for GPRS communication and the 802.15.4 home network, as well as additional components for the SD file system and the RTCC. Figure 3 shows the circuit.

Figure 3: The communication board schematic is shown.

Figure 3: The communication board schematic is shown.

At the time of the contest, I used a SIMCom Wireless Solutions SIM340 GPRS modem. The company now offers a replacement, the SIM900B. The only physical differences are the board-to-board connectors, but the variations are so minimal that you can use the same footprint for both connectors.

During the contest, I only had the connector for the SIM340 on hand, so I based almost all the firmware on that model. Later, I got the SIM900B connector and modified the firmware. The Project Files include the #if defined clause for SIM900 or SIM340 snippets.

A couple of things made me want to test the SIM900B module, among them the Simple Mail Transfer Protocol (SMTP) server functionality and Multimedia Messaging Service (MMS). Ultimately, I discovered that my 32-MB flash memory version of the SIM900B was not suitable for those firmware versions. The 64-MB version of the hardware is required.
The subscriber identity module (SIM) card receptacle and associated ESD protection circuitry are located on the upper side of the board. The I/O lines connected to the modem are serial TX, RX, and a power-on signal using a transistor.

The chipKIT Max32 board does not have a 32,768-Hz crystal, so Microchip Technology’s PIC32 internal RTCC was not an option. I decided to include Microchip Technology’s MCP79402 RTCC with a super capacitor, mainly for service purposes as the system is already backed up with the lithium battery.

I should have placed the SD card slot on the top of the board. That could have saved me some time during the debugging stage, when I have had some problems with SD firmware that corrupts the SD file system. When I designed the board, I was trying to make it compatible with other platforms, so I included level translators for the SD card interface. I made the mistake of placing a level translator at the master input slave output (MISO), which caused a conflict in the bus with other SPI devices. I removed it and wire-wrapped the I/O lines.

Another issue with this board was the XBee module’s serial port net routing, but it was nothing that cutting some traces and wire wrap could not fix. Photo 3 shows all the aforementioned details and board component location.

Photo 3: This communication board includes several key components to enable wireless communication with sensors,  the Internet, and cellular networks.

Photo 3: This communication board includes several key components to enable wireless communication with sensors,the Internet, and cellular networks.

Editor’s Note: Visit here to read about other projects from the 2012 DesignSpark chipKIT Challenge.

Remote-Control Powered Trapdoor Lift

William Wachsmann, a retired electronic technologist from Canada, has more than 35 years of experience working with minicomputers, microcomputers, embedded systems, and programming in industries ranging from nuclear and aerospace to voicemail and transportation systems.

But despite the complexity of the work he has done over the years, when it came to building a remote-controlled, powered trapdoor lift system for his home, he had two priorities: simplicity and price.

“Although it can be fulfilling to design your own hardware, why reinvent the wheel if you don’t have to? Many reasonably priced modules can be wired together,” Wachsmann says in his article about the project, which appears in Circuit Cellar’s May issue. “Add some software to express the functionality required and you can quickly and inexpensively put together a project. Not only is this method useful for a homebuilt one-of-a-kind application, but it can also be used for proof-of-concept prototyping. It leaves you free to concentrate on solving the problems pertinent to your application.”

Wachsmann’s project relies on off-the-shelf modules for the electrical functions of a trapdoor lift system that provides access to his basement.

“Lifting the trapdoor was hard on my wife’s back,” he says. “If her arms were full when she came upstairs and the door was open, she had to twist her body to release the mechanical latching mechanism while simultaneously stopping the door from falling on her head.”

The multidisciplinary project includes mechanical, electronic, and software components. For the full details—including programming of the project’s Freescale Semiconductor FRDM-KL25Z microprocessor using the mbed online IDE—check out the May issue now available for membership download and single-issue purchase.

(And if you’re interested in other articles about remote-control projects, check out Raul Alvarez’s Home Energy Gateway system, which enables users to remotely monitor home energy consumption and monitor household devices. Alvarez’s project won second place in the 2012 DesignSpark chipKIT challenge administered by Circuit Cellar.)

Excerpts from Wachsmann’s article below describe his system’s mechanical and hardware elements.

INS AND OUTS
I used a screw lift from an old treadmill. It has a 48-VDC motor that draws about 1 A under a 100-lb load. The screw mechanism has a 6” travel distance. Built-in limit switches shut off the motor when the screw reaches the end of its travel in each direction. The screw’s length is nominally 30” when closed and 36” when open. The length can be adjusted slightly by rotating the screw by hand, but the overall travel distance is still 6”.

A simple switch would have sufficed to control the screw lift’s DC motor, but I wanted it to be remotely controlled so the trapdoor could be raised and lowered from anywhere upstairs and from the basement. When someone is in the basement with the trapdoor closed there is no visible way for them to know if the door is obstructed. Initially, I was going to install a warning beeper that the door was opening, but that wouldn’t help if an inanimate object (e.g., a bag of groceries) was on top of the door. I needed to incorporate some form of sensing mechanism into the design.

Figure 1: This diagram represents the trapdoor mechanics. The arm’s down position is shown in red; the up position is shown in blue. Vertical red arrows are labeled with the downward force in pounds

Figure 1: This diagram represents the trapdoor mechanics. The arm’s down position is shown in red; the up position is shown in blue. Vertical red arrows are labeled with the downward force in pounds

THE MECHANICS
I needed a levered system design that used a pivoted bar and the motorized screw lift. The lift also had to enable the door to be manually opened in case of a power failure.
I used IMSI/Design’s TurboCAD program for the mechanical design. By using CAD software, I could experiment with the pivot position, moment arms, and torque requirements to meet the mechanical constraints imposed by the screw lift and the trapdoor’s size and weight.

Photo 1: The screw lift and pivot arm mechanism with a spring assist are shown.

Photo 1: The screw lift and pivot arm mechanism with a spring assist are shown.

Figure 1 shows a diagram of the trapdoor, which is hinged on the left. The opposite side of the door exerts a 15.2-lb downward force. This means the torque (force × distance) required to open the door is 509.2 in-lbs. The pivot arm in red is the position when the door is closed. The blue pivot arm shows the position when the door is open to an 80° angle.

To keep within the 6” lift constraint, I used a 4.25” moment arm to pull down on the pivot arm. This left me with the force required to initially lift the door at 119.5 lb. Also this did not include the added torque due to the pivot arm’s weight.

After mulling this over for a couple of days (and nights) I had an idea. I realized that 119.5 lb is only needed when the door is completely closed. As the door opens, the torque requirement lessens. I incorporated a heavy spring (see Photo 1). When the door is closed the spring extension provides an additional downward force of about 35 lb. This is enough to lessen the load on the screw lift and to compensate for the pivot arm’s additional 2.2 lb. Using a screw lift meant the arm would not spring up if the door was manually opened.

I used an angle iron for the pivot arm. It is 28” long because it had to push up on the door to the right of the door’s center of gravity at 16.75” without adding too much additional torque. The roller is the type used as feet on beds. I used an arbor and 0.75”-diameter bolt through the floor joist for the pivot (see Photo 2).

An arbor is used as a bearing with a 0.75” bolt through the floor joist. The lift mechanism pivots at this point.

Photo 2: An arbor is used as a bearing with a 0.75” bolt through the floor joist. The lift mechanism pivots at this point.

THE HARDWARE
I had set an arbitrary $100 limit for the rest of the system and I quickly realized I would easily come in under budget. I used a $24.25 two-channel RF wireless garage door remote-control receiver, which I purchased from eBay (see Photo 3). This controller can be used in a latched or an unlatched mode. The latched mode requires a momentary push of one of the buttons to cause one of the relays to switch and stay in the On position. When the controller is in unlatched mode, you must hold the button down to keep the relay switched.

Photo 3: The two-channel wireless remote control is shown with the cover removed from the receiver. It came with two keychain-style remotes, which I marked with Up and Down arrows.

Photo 3: The two-channel wireless remote control is shown with the cover removed from the receiver. It came with two keychain-style remotes, which I marked with Up and Down arrows.

Unfortunately, this remote control and any similar ones only come with single-pole double-throw (SPDT) relays. What I really wanted were double-pole double-throw (DPDT) relays to switch both sides of the motor to enable current reversal through the motor.
A remote control system with two remotes seemed ideal and was possible to design with SPDT, so I purchased the relays. Figure 2 shows the circuit using two bridge rectifier DC power supplies. It turns out there were problems with this approach.

SW1 and SW2 represent the Up and Down relays. In latched mode, the door would open when SW1 was energized using the A button on a remote. Pressing the A button again would stop the motor while the door was opening. So would pressing the B button, but then to continue opening the door you needed to press the B button again. Pressing the A  button in this state would cause the door to close because SW2 was still energized. Added to this confusion was the necessity of pressing the A button again when the door was fully opened and stopped due to the internal limit switches. If you didn’t do this, then pressing the B button to close the door wouldn’t work because SW1 was still energized.

Figure 2: It would be theoretically possible to use dual-power supplies and single-pole double-throw (SPDT) switches to control a motor in two directions. When SW1 (b,c) is connected, current flows through D2. When SW2 (b,c) is connected, current flows through D1 in the opposite direction.

Figure 2: It would be theoretically possible to use dual-power supplies and single-pole double-throw (SPDT) switches to control a motor in two directions. When SW1 (b,c) is connected, current flows through D2. When SW2 (b,c) is connected, current flows through D1 in the opposite direction.

I decided to just use the door in unlatched mode and continuously hold down the A button until the door was fully open. What was the problem with this? Noise! Interference from the motor was getting back into the control and causing the relay to frequently switch on and off. This is not good for mechanical relays that have a finite contact life.

After playing around for a while with both operation modes, I noticed that even in the latched mode the motor would sometimes stop and it would occasionally even reverse itself. This was really bad and it became worse.

If both SW1 and SW2 happened to switch at the same time and if the current was at a maximum and there was arcing at the terminal, there could conceivably be a momentary short through a diode in each of the bridge rectifiers that would burn them out. Arc suppression devices wouldn’t help because when active at high voltages, they would almost look like a short between the switch’s terminals A,C. I needed to step back and rethink this.

I found an $8.84 two-channel DPDT relay switch board module on eBay. The module enabled me to use a single-power supply and isolated the motor current from the remote-control board. These relays boards have TTL inputs, so it is tricky to use relays on the remote control board to control the relays on the second relay board. You have to contend with contact bounce. Even if I incorporated debounce circuits, I still didn’t have a way stop the door from opening if it was obstructed.

It was time to get with the 21st century. I needed to use a microcontroller and handle all the debounce and logic functions in firmware.

I bought a $12.95 Freescale Semiconductor FRDM-KL25Z development board, which uses the Kinetis L series of microcontrollers. The FRDM-KL25Z is built on the ARM Cortex-M0+ core. This board comes with multiple I/O pins, most of which can be programmed as required. It also has two micro-USB ports, one of which is used for downloading your program onto the microcontroller and for debugging (see Figure 3).

Figure 3: This is the system’s complete wiring diagram. On the left is a 48-V AC supply and an unregulated 12-V DC motor. A 2.7-Ω, 5-W resistor, which is used for current sensing, is in series with the motor.

Figure 3: This is the system’s complete wiring diagram. On the left is a 48-V AC supply and an unregulated 12-V DC motor. A 2.7-Ω, 5-W resistor, which is used for current sensing, is in series with the motor.

Pulse-Shaping Basics

Pulse shaping (i.e., base-band filtering) can vastly improve the behavior of wired or wireless communication links in an electrical system. With that in mind, Circuit Cellar columnist Robert Lacoste explains the advantages of filtering and examines Fourier transforms; random non-return-to-zero NRZ signaling; and low-pass, Gaussian, Nyquist, and raised-cosine filters.

Lacoste’s article, which appears in Circuit Cellar’s April 2014 issue, includes an abundance of graphic simulations created with Scilab Enterprises’s open-source software. The simulations will help readers grasp the details of pulse shaping, even if they aren’t math experts. (Note: You can download the Scilab source files Lacoste developed for his article from Circuit Cellar’s FTP site.)

Excerpts from Lacoste’s article below explain the importance of filtering and provide a closer look at low-pass filters:

WHY FILTERING?
I’ll begin with an example. Imagine you have a 1-Mbps continuous digital signal you need to transmit between two points. You don’t want to specifically encode these bits; you just want to transfer them one by one as they are.

Before transmission, you will need to transform the 1 and 0s into an actual analog signal any way you like. You can use a straightforward method. Simply define a pair of voltages (e.g., 0 and 5 V) and put 0 V on the line for a 0-level bit and put 5 V on the line for a 1-level bit.


This method is pedantically called non-return-to-zero (NRZ). This is exactly what a TTL UART is doing; there is nothing new here. This analog signal (i.e., the base-band signal) can then be sent through the transmission channel and received at the other end (see top image in Figure 1).


Note: In this article I am not considering any specific transmission channel. It could range from a simple pair of copper wires to elaborate wireless links using amplitude, frequency and/or phase modulation, power line modems, or even optical links. Everything I will discuss will basically be applicable to any kind of transmission as it is linked to the base-band signal encoding prior to any modulation.

Directly transmitting a raw digital signal, such as this 1-Mbps non-return-to-zero (NRZ) stream (at top), is a waste of bandwidth. b—Using a pulse-shaping filter (bottom) reduces the required bandwidth for the same bit rate, but with a risk of increased transmission errors.

Figure 1: Directly transmitting a raw digital signal, such as this 1-Mbps non-return-to-zero (NRZ) stream (top), is a waste of bandwidth. Using a pulse-shaping filter (bottom) reduces the required bandwidth for the same bit rate, but with a risk of increased transmission errors.


Now, what is the issue when using simple 0/5-V NRZ encoding? Bandwidth efficiency. You will use more megahertz than needed for your 1-Mbps signal transmission. This may not be an issue if the channel has plenty of extra capacity (e.g., if you are using a Category 6 1-Gbps-compliant shielded twisted pair cable to transmit these 1 Mbps over a couple of meters).


Unfortunately, in real life you will often need to optimize the bandwidth. This could be for cost reasons, for environmental concerns (e.g., EMC perturbations), for regulatory issues (e.g., RF channelization), or simply to increase the effective bit rate as much as possible for a given channel.


Therefore, a good engineering practice is to use just the required bandwidth through a pulse-shaping filter. This filter is fitted between your data source and the transmitter (see bottom of Figure 1).


The filter’s goal is to reduce as much as possible the occupied bandwidth of your base-band signal without affecting the system performance in terms of bit error rate. These may seem like contradictory requirements. How can you design such a filter? That’s what I will try to explain in this article….


LOW-PASS FILTERS

A base-band filter is needed between the binary signal source and the transmission media or modulator. But what characteristics should this filter include? It must attenuate as quickly as possible the unnecessary high frequencies. But it must also enable the receiver to decode the signal without errors, or more exactly without more errors than specified. You will need a low-pass filter to limit the high frequencies. As a first example, I used a classic Butterworth second-order filter with varying cut-off frequencies to make the simulation. Figure 2 shows the results. Let me explain the graphs.

Figure 2: This random non-return-to-zero (NRZ) signal (top row) was passed through a second-order Butterworth low-pass filter. When the cut-off frequency is low (310 kHz), the filtered signal (middle row) is distorted and the eye diagram is closed. With a higher cutoff (410 kHz, bottom row), the intersymbol interference (ISI) is lower but the frequency content is visible up to 2 MHz.

Figure 2: This random non-return-to-zero (NRZ) signal (top row) was passed through a second-order Butterworth low-pass filter. When the cut-off frequency is low (310 kHz), the filtered signal (middle row) is distorted and the eye diagram is closed. With a higher cutoff (410 kHz, bottom row), the intersymbol interference (ISI) is lower but the frequency content is visible up to 2 MHz.

The leftmost column shows the signal frequency spectrum after filtering with the filter frequency response in red as a reference. The middle column shows a couple of bits of the filtered signal (i.e., in the time domain), as if you were using an oscilloscope. Last, the rightmost column shows the received signal’s so-called “eye pattern.” This may seem impressive, but the concept is very simple.

Imagine you have an oscilloscope. Trigger it on any rising or falling front of the signal, scale the display to show one bit time in the middle of the screen, and accumulate plenty of random bits on the screen. You’ve got the eye diagram. It provides a visual representation of the difficulty the receiver will have to recover the bits. The more “open” the eye, the easier it is. Moreover, if the successive bits’ trajectories don’t superpose to each other, there is a kind of memory effect. The voltage for a given bit varies depending on the previously transmitted bits. This phenomenon is called intersymbol interference (ISI) and it makes life significantly more difficult for decoding.


Take another look at the Butterworth filter simulations. The first line is the unfiltered signal as a reference (see Figure 2, top row). The second line with a 3-dB, 310-kHz cut-off frequency shows a frequency spectrum significantly reduced after 1 MHz but with a high level of ISI. The eye diagram is nearly closed (see Figure 2, middle row). The third line shows the result with a 410-kHz Butterworth low-pass filter (see Figure 2, bottom row). Its ISI is significantly lower, even if it is still visible. (The successive spot trajectories don’t pass through the same single point.) Anyway, the frequency spectrum is far cleaner than the raw signal, at least from 2 MHz.

Lacoste’s article serves as solid introduction to the broad subject of pulse-shaping. And it concludes by re-emphasizing a few important points and additional resources for readers:

Transmitting a raw digital signal on any medium is a waste of bandwidth. A filter can drastically improve the performance. However, this filter must be well designed to minimize intersymbol interference.

The ideal solution, namely the Nyquist filter, enables you to restrict the used spectrum to half the transmitted bit rate. However, this filter is just a mathematician’s dream. Raised cosine filters and Gaussian filters are two classes of real-life filters that can provide an adequate complexity vs performance ratio.

At least you will no longer be surprised if you see references to such filters in electronic parts’ datasheets. As an example, see Figure 3, which is a block diagram of Analog Devices’s ADF7021 high-performance RF transceiver.

This is a block diagram of Analog Devices’s ADF7021 high-performance transceiver. On the bottom right there is a “Gaussian/raised cosine filter” block, which is a key factor in efficient RF bandwidth usage.

Figure 3: This is a block diagram of Analog Devices’s ADF7021 high-performance transceiver. On the bottom right there is a “Gaussian/raised cosine filter” block, which is a key factor in efficient RF bandwidth usage.

The subject is not easy and can be easily misunderstood. I hope this article will encourage you to learn more about the subject. Bernard Sklar’s book Digital Communications: Fundamentals and Applications is a good reference. Playing with simulations is also a good way to understand, so don’t hesitate to read and modify the Scilab examples I provided for you on Circuit Cellar’s FTP site.  

Lacoste’s full article is in the April issue, now available for membership download or single issue purchase. And for more information about improving the efficiency of wireless communication links, check out Lacoste’s 2011 article “Line-Coding Techniques,” Circuit Cellar 255, which tells you how you can encode your bits before transmission.