The Future of Wireless: Global Internet Network

Advances in wireless technologies are driving innovation in virtually every industry, from automobiles to consumer electronics. We recently asked 10 engineers to prognosticate on the future of wireless technology. Eileen Liu, a software engineer at Lockheed Martin, writes:10 Liu

Wireless technology has become increasingly prevalent in our daily lives. It has become commonplace to look up information on smartphones via invisible networks and to connect to peripheral devices using Bluetooth connections. So what should we expect to see next in the world of wireless technology? One of the major things to keep an eye on is the effort for a global Internet network. Facebook and Google are potentially collaborating, working on drones and high-altitude helium balloons with router-like payloads. These solar-powered payloads make a radio link to a telecommunications network on Earth’s surface and broadcast Internet coverage downwards. Elon Musk and Greg Wyler are both working on a different approach, using flotillas of low-orbiting satellites. With such efforts, high-speed Internet access could become possible for the most remote locations on Earth, bringing access to the 60% of the world’s population that currently do not have access. Another technology to look out for is wireless power transfer. This technology allows multiple devices to charge simultaneously without a tether and without a dependency on directionality. Recent developments have mostly been in the realm of mobile phones and laptops, but this could expand to other electronic devices and automobiles that depend on batteries. A third technology to look out for is car-to-car communications. Several companies have been developing autonomous cars, using sensor systems to detect road conditions and surrounding vehicles. These sensors have shown promise, but have limited range and field-of-view and can easily be obstructed. Car-to-car communications allow vehicles to broadcast position, speed, steering-wheel position, and other data to surrounding vehicles with a range of several hundred meters. By networking cars together wirelessly, we could be one step closer to safe autonomous driving. — Eileen Liu, United States (Software Engineer, Lockheed Martin)

The Future of Wireless: Deployment Matters

Each day, wireless technology becomes more pervasive as new electronics systems hit the market and connect to the Internet. We recently asked 10 engineers to prognosticate on the future of wireless technology. Penn State Professor Chris Coulston writes:9 Coulston green

With the Internet of Things still the big thing, we should expect exciting developments in embedded wireless in 2016 and beyond. Incremental advances in speed and power consumption will allow manufactures to brag about having the latest and greatest chip. However, all this potential is lost unless you can deploy it easily. The Futurelec FT-232 serial-to-USB bridge is a success because it trades off some of the functionality of a complex protocol for a more familiar, less burdensome, protocol.  The demand for simplified protocols should drive manufacturers to develop solutions making complex protocols more accessible. Cutting the cord means different things to different people. While Bluetooth Low Energy (BLE) has allowed a wide swath of gadgets to go wireless, these devices still require the presence of some intermediary (like a smart phone) to manage data transfer to the cloud. Expect to see the development of intermediate technologies enabling BLE to “cut the cord” to smart phones. Security of wireless communication will continue to be an important element of any conversation involving new wireless technology. Fortunately, the theoretical tools need to secure communication are well understood. Expect to see these tools trickle down as standard subsystems in embedded processors. The automotive industry is set to transform itself with self-driving cars. This revolution in transportation must be accompanied by wireless technologies allowing our cars to talk to our devices, each other and perhaps the roadways. This is an area that is ripe for some surprising and exciting developments enabling developers to innovate in this new domain. We live in interesting times with embedded systems playing a large role in consumer and industrial systems. With better and more accessible technology in your grasp, I hope that you have great and innovative 2016! — Chris Coulston, United States (Associate Professor, Electrical & Computer Engineering, Penn State Erie)

The Future of Wireless: IoT “Connect Anywhere” Solutions

Wireless communications have revolutionized virtually every industry, from healthcare to defense to consumer electronics. We recently asked 10 engineers to prognosticate on the future of wireless technology. France-based engineer Robert Lacoste writes:3 Lacoste purple

I don’t know if the forecasts about the Internet of Things (IoT) are realistic (some analysts predict from 20 to 100 billion devices in the next five years), but I’m sure it will be a huge market. And 99% of IoT products are and will be wireless. Currently, the vast majority of “things” connect to the Internet through a user’s smartphone, used as a gateway typically through a Bluetooth Smart link. Other devices (e.g., home control or smart metering) require the installation of a dedicated fixed RF-to-Internet gateway, using ZigBee, 6lowPan, or something similar. But the next big thing will be the availability of “connect anywhere” solutions, through low-power wide area networks, nicknamed LPWA. Even if the underlying technology is not actually new (i.e., using very low bit rates to achieve long range at low powers), the contenders are numerous: LORA Alliance, INGENU, SIGFOX, WEIGHTLESS, and a couple of others. At the same time, the traditional telcos are developing very similar solutions using cellular bands and variants of the 3GPP protocols. EC-GSM, LTE-MTC, and NB-IOT are the most discussed alternatives. So, the first big question is this: Which one (or ones, as a one-size-fits-all solution is unlikely) will be the winner? The second big question has to do with whether or not IoT products will be useful for society. But that’s another story! — Robert Lacoste, France (Founder, Alciom; Columnist, Circuit Cellar)

New Pre-Certified HumRC Series Remote Control Transceiver

Linx Technologies recently introduced new pre-certified remote control and sensor transceiver modules. Built on the Hummingbird platform, the HumRC Series transceiver is a frequency hopping spread spectrum (FHSS) transceiver designed for reliable bidirectional remote control and sensor applications. Available in 900 MHz, the HumRC outputs up to 10 dBm, which results in a line-of-sight range of up to 1 mile.HumRC pre-cert-series-pr-art

The HumRC Series module is a completely integrated RF transceiver and processor designed for bidirectional remote control. It employs a fast-locking FHSS system for noise immunity and higher transmitter output power as allowed by government regulations.

The remote control transceiver has eight status lines that can be individually configured as inputs to register button presses or as outputs to drive application circuitry. A selectable acknowledgement indicates that the transmission was successfully received. Primary settings are hardware-selectable, which eliminates the need for an external microcontroller or other digital interface.

The transceiver also has two analog-to-digital (ADC) inputs for sensors or circuits that output an analog voltage. The module can automatically respond to a command with these values, so a sensor node does not need an additional microprocessor.

To aid rapid development, the HumRC Series low-cost RF modules are available as part of a newly conceived type of Master Development System. This development kit is intended to assist in the rapid evaluation and integration of the HumRC Series data transceiver modules. It features several preassembled evaluation boards that include everything needed to quickly test the operation of the transceiver modules.

Source: Linx Technologies

IoT Project: DIY, Net-Connected Wireless Water Heater

Some people like to remotely start their cars when it’s cold outside. Dan Beadle took this idea one step further by Internet-enabling his mountainside retreat’s hydronics system. The innovative design enables him to warm the house well in advance of his arrival.

Serving up the current temperature involves several computers, a Wi-Fi access point, and the DPAC Airborne module.

Serving up the current temperature involves several computers, a Wi-Fi access point, and a DPAC Airborne module.

In “Wireless Water Heater” (Circuit Cellar 163), Beadle writes:

My mountain home, where I have vacationed for years, is well insulated, making it a snap for the heater system to keep warm. I have a small, efficient heater; however, it takes forever to warm the house from a 50°F standby to a livable 68°F. Typically, I arrive late and shiver in my jacket for three or four hours until the house warms up—and that does not warm the entire house, just the portion needed to get through the night.

I had been thinking for a while about Internet-enabling the system. The idea was to turn on the heater before we start up the mountain. I have DSL at the house with a fixed IP. So, it seemed like it would be a simple task to enable a thermostat. I considered using an X10 thermostat, but, after a few of our X10-enabled lights found a mind of their own, I decided that I wanted better reliability. My next thought was to use simple copper to do the hook-up. I started planning a cable from my office/DSL entry up to the logical thermostat location. Then I procrastinated. I could not bring myself to run the wires along the surface of my redwood paneling. (And it was not at all feasible to remove the paneling.) Wireless makes the problem a lot simpler: there are no wires to run, and the applications processor and digital I/O on the module make the hardware design trivial.

Download the entire article.

 

Wireless Remote Control of the AVMux

In 1994, Circuit Cellar’s founder, Steve Ciarcia, asked: “What good is having ultimate control over your virtual audio/video environment if you have to get out of your chair to change the setup?” Great question. His answer was even better: “Outfit your home theater in style by adding an RF interface to the AVMux.”

In Circuit Cellar 46, Steve writes:

Using a couple of new chips from Maxim and Analog Devices, the AVMux facilitates effortless switching of up to eight video channels and up to eight sets of stereo audio channel pairs. Using the AVMux, I can effortlessly attach and reconfigure the connections between multiple VCRs, CD players, a Pro Logic decoder, a laserdisc player, and various other audio/video sources to the same set of amplifiers or in any number of different electronic combinations.CiarciaCC46-AVMux

With the possible exception of the actual wiring chore itself, the basic multiplexer and control unit is quite straightforward and easily constructed. Unfortunately, solving the basic switching problems only served to create further design necessities. Let me explain.

The primary problem with commercial multiplexers (when they used to be available) is that they are housed in a box much like traditional stereo equipment with all the input/output jacks on the back. Such shortsightedness on their part also requires taking a chainsaw to your expensive CWD oak stereo cabinets to widen the minuscule wire access holes to actually route all these wires.

Download the complete article.

Wireless Data Link

In 2001, while working on self-contained robot system called “Scout,” Tom Dahlin and Donald Krantz developed an interesting wireless data link. A tubular, wheeled robot, Scout’s wireless data link is divided into separate boards, one for radio control and another containing RF hardware.

Dahlin and Krantz write:

This article will describe the hardware and software design and implementation of a low-power, wireless RF data link. We will discuss a robotic application in which the RF link facilitates the command and control functions of a tele-operated miniature robot. The RF Monolithics (RFM) TR-3000 chip is the core of the transceiver design. We use a straightforward interface to a PIC controller, so you should be able to use or adapt much of this application for your needs…

Photo 1: The robot measures a little over 4″. Designed for tele-operated remote surveillance, it contains a video camera and transmitter. Scout can hop over obstacles by hoisting its tail spring (shown extended) and quickly releasing it to slap the ground and propel the robot into the air.

Photo 1: The robot measures a little over 4″. Designed for teleoperated remote surveillance, it contains a video camera and transmitter. Scout can hop over obstacles by hoisting its tail spring (shown extended) and quickly releasing it to slap the ground and propel the robot into the air.

The robot, called Scout, is packed in a 38-mm diameter tube with coaxial-mounted wheels at each end, approximately 110-mm long. The robot is shown in Photo 1. (For additional information, see the “Key Specifications for Scout Robot” sidebar.) Scout carries a miniature video camera and video transmitter, allowing you to tele-operate the robot by sending it steering commands while watching video images sent back from Scout. The video transmitter and data transceiver contained on the robot are separate devices, operating at 915 and 433MHz, respectively. Also contained on Scout are dual-axis magnetometers (for compass functions) and dual-axis accelerometers (for tilt/inclination measurement).

Figure 1: For the radio processor board, a PIC16F877 provides the horsepower to perform transceiver control, Manchester encoding, and packet formatting.

Figure 1: For the radio processor board, a PIC16F877 provides the horsepower to perform transceiver control, Manchester encoding, and packet formatting.

Scout’s hardware and software were designed to be modular. The wireless data link is physically partitioned onto two separate boards, one containing a PIC processor for radio control, message formatting, and data encoding (see Figure 1). The other board contains the RF hardware, consisting of the RFM TR3000 chip and supporting discrete components. By separating the two boards, we were able to keep the digital noise and trash away from the radio.

Read the full article.

SimpleLink Simplifies IoT Prototyping

Texas Instruments recently introduced the next-generation SimpleLink SensorTag development kit, which enables the fast integration of sensor data with wireless cloud connectivity.TI Simplelink

Features of the new SensorTags include:

  • Flexible development with wireless connectivity options including Bluetooth low energy, 6LoWPAN and ZigBee based on the SimpleLink ultra-low power CC2650 wireless microcontroller
  • 10 integrated low-power sensors
  • New DevPack plug-in modules that extend the kits’ functionality and programmability
  • Out of the box capabilities with a free iOS or Android app
  • Connect to the cloud in minutes via TI’s IoT cloud ecosystem including IBM’s Bluemix IoT Foundation
  • Available TI Design reference designs, including 3-D print files of the SensorTag enclosures, that enable you to reuse the SensorTags for new designs

The SensorTag kits come with ready-to-use protocol stacks, a free Code Composer Studio IDE license, online training, and 24/7 online TI E2E community support. In addition, TI’s cloud-based software development tools provide instant access to examples, documentation, software and even an integrated development environment (IDE) all from the convenience of the web.

Expanding the standards supported by the SensorTag, there will be two different development kit versions:

  • The multi-standard SensorTag, based on the SimpleLink ultra-low power CC2650 wireless MCU, supports development for Bluetooth Smart, 6LoWPAN and ZigBee. This SensorTag has a unique feature that enables developers to change between different 2.4-GHz technologies by simply loading new software images directly from the SensorTag app over-the-air. When the SensorTag is used as a ZigBee and 6LoWPAN device, it connects to the cloud via a BeagleBone Black gateway. For Bluetooth Smart development, it connects via a smartphone.
  • The Wi-Fi SensorTag will allow users to demo the SimpleLink CC3200 wireless MCU. Further details and availability information will be coming soon. Start developing today with the CC3200 solution with these development tools.
  • Both SensorTags come with 10 integrated low-power sensors including the TI OPT3001 precision ambient light sensor, TI HDC1000 integrated humidity and temperature sensor and TI TMP007 contactless IR thermopile sensor. Additional sensors include a nine-axis motion sensor (gyroscope, compass and accelerometer), altimeter/ pressure sensor, digital microphone, and magnet sensor.

New to the next-generation CC2650 SensorTag is the ability for developers to customize their kit to fit their design with new DevPack plug-in modules. DevPacks available today include:

  • The $15 Debug DevPack is based on the TM4C1294 microcontroller (MCU) to add debug capabilities to the SensorTag. Plug it into the DevPack expansion header and debug the SensorTag with Code Composer Studio IDE, TI Cloud Tools, or IAR embedded workbench for ARM.
  • The Display (watch) DevPack adds a 1.35 inch ultra-low power graphical display to the SensorTag. The Watch DevPack is designed for development of smartwatches, refrigerator displays and any other application that has a need for a remote display.
  • The LED Audio DevPack consists of four high power multi-color LEDs and a 4W audio amplifier powered by a micro-USB for home automation and smart lighting applications.
  • Create your own! If developers cannot find a specific DevPack to fit their needs, they can create their own by downloading the Build Your Own DevPack guide.

The new SimpleLink multi-standard CC2650 SensorTag (CC2650STK) is available now for $29 in the TI Store and authorized distributors. Related software for each connectivity standard is also available:

  • Bluetooth Smart software
  • 6LoWPAN software
  • ZigBee software

The SimpleLink SensorTag DevPacks are also available on the TI Store and through TI authorized distributors. The Debug DevPack (CC-DEVPACK-DEBUG) costs $15. The Display DevPack (DEVPACK-WATCH) costs $19. The LED Audio DevPack (DEVPACK-LED-AUDIO) is $19. Pricing and availability for the SimpleLink Wi-Fi CC3200 SensorTag will be coming later in 2015.

IoT Project: Wireless Sump Pump Monitor

Do you worry about your basement flooding? You can build a microcontroller-based, three-unit wireless system can monitor the water level in your sump pit. The Pump-Eye is a three-unit water level monitoring system built around a Freescale Semiconductor MC9S08GT60 and MC9S12NE64 microcontrollers.

1—A hose connects the Pump-Eye sensor unit to a copper pipe. The pipe gets fastened to the side of the sump pit.

A hose connects the Pump-Eye sensor unit to a copper pipe. The pipe gets fastened to the side of the sump pit.

The sensor unit monitors the water level in a sump pump pit, the sump pump’s AC power, and the sensor unit’s backup battery. The base unit receives status information from the sensor unit via RF. The sensor and base units use MC9S08GT60 microcontrollers; they communicate with each other via 2.4-GHz transceivers based on an MC13192 SARD board. The Ethernet link creates and sends timestamp and log messages to a host when the pump runs. The system sends a warning e-mail when the water level is high or there’s a power failure. An alarm sounds when the water level exceeds the normal maximum height by 10%.

In “Wireless Sump Pump Monitoring System”  (Circuit Cellar 189), David Kanceruk writes:

The Pump-Eye is a flexible system comprised of three electronic units: a sensor unit, a base unit, and an Ethernet unit. Let’s take a look at each unit.

Figure 1—The base and Ethernet units are optional. There are five ways to set up the Pump-Eye system without having to make any software changes.

Click to enlarge. The base and Ethernet units are optional. There are five ways to set up the Pump-Eye system without having to make any software changes.

The sensor unit monitors the sump pit’s water level (see Photo 1). Data is displayed on a 10-segment LED bar graph so you don’t have to remove the sump pit’s lid to determine the water level. An alarm sounds when the water level exceeds the height you program into the system. A switch enables you to cancel the alarm at any time. LEDs illuminate when the AC power is off and when the sensor unit’s 9-V backup battery needs to be replaced.

The base unit features the same indicators as the sensor unit. It sounds the same alarm signal as the sensor unit. I chose the SOS Morse code sound (an old sound that’s recognizable to some of us) because it’s notably different than the sounds generated by my appliances. Canceling the alarm on the base unit cancels the alarm on the sensor unit and vice versa. Because the units are connected wire- lessly, I can place the base unit anywhere in my house. Therefore, I don’t have to go to my basement to read the sensor unit’s front panel.

The Ethernet unit can connect to either the sensor unit or the base unit via an RS-232 connection. I can place the Ethernet unit in the most convenient location for connecting to an uninterruptible power supply (UPS) and network. The Ethernet unit receives commands from the unit to which it’s attached. It then sends syslog messages to a syslog server so that pump cycles can be time stamped and counted. A record is kept of the pump’s run times. The Ethernet unit can also send me an e-mail or text message regarding conditions that require immediate attention (e.g., high water levels and a loss of AC power).

The sensor and base units feature Freescale MC9S08GT60 microcontrollers. They communicate with each other via 2.4-GHz ZigBee transceivers based on a Freescale MC13192 SARD board using IEEE 802.15.4 MAC soft- ware. The sensor unit monitors the sump pump’s AC power and its 9-V back-up battery.

The front panel electronics on the two units are similar, but there are a few differences. The sensor unit is larger. It also has an extra connector that’s used for passing signals to the rear panel’s electronics for the sensors. Because the base unit simply acts as a remote display to show what’s happening on the sensor unit, it doesn’t need sensing electronics on the rear panel.

When you cover the top of a straw with your finger and place it in a glass of water, the air in the straw becomes pressurized. The amount of pressure depends on the height of the water in the straw, and this depends on factors such as ambient air pressure, the mass density of the water, gravity, and the height of the water outside the straw: P = Pa + rg∆h. In this formula, P is the pressure, Pa is the ambient pressure, r is the mass density of fluid, g is 9.8066 m/s2, and h is the height of fluid.

You can nullify the effect of a change in ambient pressure if you use a gauge pressure sensor to measure pressure relative to ambient pressure. The formula then becomes P = rg∆h. You can assume that the mass density of water and gravity are constants, so the pressure will be proportional to a change in the water’s height. The sensor unit measures this pressure with a Freescale MPXM2010GS temperature-compensated gauge pressure sensor. The pressure is then converted to a percentage of normal water levels observed in the sump pit.

I tried placing a hose in the sump pit to sense the water level, but I quickly discovered that it wasn’t too reliable. This was probably because of the surface tension of the water clinging to the inside of the thin hose (5/64 inches in diameter). Therefore, I decided to use a 0.5 inches in diameter copper pipe as a sensor interface. The ratio of the area affected by surface tension to the total area is less significant with the larger diameter. I bought a length 0.125 inches in diameter brass pipe to use as a nipple for the hose that connects the MPXM2010GS to the cop- per pipe. I soldered the brass pipe to a standard 0.5 inch copper cap in which I had drilled a hole. The cap is soldered to the top of the copper pipe.

The copper pipe solved the problem of holding the open end of the hose at a fixed height, and it also alleviated my concerns about dirt clogging the thin hose. A plastic clamp screwed to the side of the plastic sump pit holds the pipe in place. I had originally placed the pipe to the bottom of the sump pit, but I found a negative pressure developing in it after numerous pump cycles. I concluded that this was the result of scavenging around the bottom of the pipe because of water currents caused by the pump. Keeping the end of the pipe at the height of the low water level pre- vented this from happening.

Read the full article.

Gecko Bluetooth Smart Solutions for Low-Power Wireless Connectivity

Silicon Labs today has launched a Bluetooth Smart solutions portfolio intended to minimize the energy consumption, cost, and complexity of wireless Internet of Things (IoT) designs. Silicon Labs’s new Blue Gecko solutions include ultra-low-power wireless system-on-chip (SoC) devices, embedded modules, and Bluegiga’s software development kit (SDK) and Bluetooth Smart software stack. Blue Gecko wireless SoCs and modules help you simplify design and speed time to market for a wide range of applications (e.g., connected home, wearable, and automotive).

The Blue Gecko portfolio addresses the largest, fastest-growing low-power wireless connectivity opportunity in the IoT market. It provides developers with the flexibility to begin development with modules and transition to SoCs when needed with little to no system redesign.SiliconLabs-Blue-Gecko

The first in a family of wireless SoCs optimized for IoT applications, Blue Gecko SoCs combine Silicon Labs’ energy-friendly EFM32 Gecko MCU technology with an ultra-low-power Bluetooth Smart transceiver. This innovative, single-die solution provides industry-leading energy efficiency, the fastest wake-up times, superior RF sensitivity and no-compromise MCU features combined with the Bluegiga Bluetooth Smart software stack to help developers reduce system power, cost and time to market. Unlike other Bluetooth Smart IC alternatives, a Blue Gecko SoC can transmit +10 dBm or higher output power with its fully integrated power amplifier and balun, further reducing design complexity.

Blue Gecko SoCs are based on the ARM Cortex-M3 and M4 cores and offer 128- to 256-KB flash sizes and 16- to 32-KB RAM sizes. The SoCs integrate an array of low-energy peripherals as well as Silicon Labs’s Peripheral Reflex System (PRS) for autonomous peripheral operation. The Blue Gecko SoC family also offers a roadmap of enhanced flash and RAM memory sizes and additional package options to meet future application needs.

Bluegiga modules based on Blue Gecko SoCs are designed to help developers accelerate time to market and reduce development costs and compliance risks by providing a precertified, plug-and-play RF design. Bluegiga Bluetooth Smart modules incorporate all features of Blue Gecko SoCs and are certified for use in all key markets including North America, Europe, Japan and South Korea. Bluegiga modules include the Bluegiga Bluetooth Smart software stack and profile toolkit and come with 256 kB flash and 32 kB RAM, providing ample available memory for onboard applications. Flexible hardware interfaces enable easy connection to a variety of peripherals and sensors, and an integrated antenna makes RF operation consistent and straightforward for the design engineer. Bluegiga Bluetooth Smart modules provide very low power operation, enabling wireless system designs to be powered from a standard 3-V coin cell battery or two AAA batteries.

Samples of Bluegiga modules based on Blue Gecko SoCs are scheduled to be available in late Q2 2015. Samples of Blue Gecko wireless SoCs are planned to be available in early Q3 in 5 mm × 5 mm QFN32 and 7 mm × 7 mm QFN48 packages. Pricing for Blue Gecko-based Bluegiga modules starts at $4.99 in 10,000-unit quantities. Blue Gecko SoC start at $0.99 in 100,000-unit quantities. The Bluegiga SDK and Bluetooth Smart software stack will be available to Silicon Labs customers at no charge.

Source: Silicon Labs

12-W Receiver IC for Wireless Mobile Device Charging

At CES 2015, Toshiba America Electronic Components introduced its newest IC enabling wireless mobile device charging. The TC7765WBG wireless power receiver controller IC can manage the 12-W power transfer required for the wireless charging of tablet devices. The TC7765WBG is compatible with the Qi low-power specification version 1.1 defined by the Wireless Power Consortium (WPC). It delivers a user experience comparable to that of conventional wired charging for tablets, as well as smartphones and other portable devices.Toshiba TC7765WBG

The TC7765WBG was built with Toshiba’s mixed-signal process using a high-performance MOSFET design that maximizes power efficiency and thermal performance. The IC combines modulation and control circuitry with a rectifier power pickup, I2C interface, and circuit protection functions. Compliance with the “Foreign Object Detection” (FOD) aspect of the Qi specification prevents heating of any metal objects in the path of wireless power transfer between the receiver and the transmitter.

The 12-W TC7765WBG is designed in a compact WCSP-28 2.4 mm × 3.67 mm × 0.5 mm package. This further facilitates design-in and contributes to the new chipset’s backward compatibility with the lower-power receiver IC. Combining the TC7765WBG with a copper coil, charging IC, and peripheral components creates a wireless power receiver. Joining the receiver with a Qi-compliant wireless power transmitter containing a Toshiba wireless power transmitter IC (e.g., TB6865AFG Enhanced version) forms a complete wireless power charging solution.

Toshiba announced that samples of the TC7765WBG wireless power receiver IC will be available at the end of January, with mass production set to begin in Q2 2015.

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.