Professor Pai H. Chou


Wireless sensor hardware platforms

  • Eco node, EcoSpire, EcoSD, and latest based on BLE (Bluetooth Low Energy)
  • DuraMote = Roocas (data aggregator) + Gopher (underground sensor node) for water pipe monitoring.

Wireless Sensor Software and Tools, including programming, runtime support, protocol, and methods - EcoCast interactive object-oriented macroprogramming

  • EcoExec: python-based interactive environment
  • Enix, EcoSwap, Rappit, Tapper: Runtime Systems
  • Telescribe, RPFU: Wireless Reprogramming
  • EcoPlex: Infrastructure Support
  • Protocols: RIPE-MAC, BinMAC, EcoIR (optical communication),

Energy Harvesting

  • AmbiMax sensor-driven, multi-supercapacitor MPPT charger
  • Everlast feed-forward PFM charger + sensor node
  • DuraCap IV-curve sweeping, autonomous MPPT, cold boot-up capacitor + reservoir supercapacitor array
  • EscaCap charge pump MPTT, reconfigurable supercapacitor topology

Civil/Environmental Engineering Applications - PipeTECT project: Noninvasive water pipe monitoring (w/ M. Shinozuka, Civil Engineering) - SSG (Smart Sediment Grains): Underwater sediment motion monitoring (w/ D. Foster, U. of New Hampshire) based on gyro-free EcoIMU with wireless charging - Debris flow monitoring (w/ B. Lee @GIS, Fenchia Univ, Taiwan)

Infant monitoring Applications:

  • SIDS monitoring (w/ Dr. R.-K. Chang, Harbor Medical, UCLA)
  • Infant ECG (w/ Dr. R.-K. Chang, Harbor Medical, UCLA)
  • Cerebral Palsy detection (w/ D. Cooper @ICTS, UCI; and D. Patterson, ICS, UCI)

Optical Sensing System

  • mcLSI: multi-camera laser speckle imaging, for bloodflow perfusion monitoring (w/ B. Choi, BME, UCI)
  • Optical sensor modules for Eco (in planning)
  • Mini-FDPM: noninvasive breast cancer detector based on frequency-domain photon migration (w/ B. Tromberg, BLI, UCI)

Emulators and Profilers - B# (B-sharp): battery emulator and power profiling instrument %br/

  • S# (S-sharp): solar panel emulator
  • EmPro (superset of B-sharp): sensor signal and RF interference emulator

General interests:

  • Hardware/software codesign of embedded systems, system synthesis
  • distributed real-time systems
  • low-power system design,
  • Wireless sensing systems, medical devices,

I work on the following topics in embedded systems:

  • Platforms for wireless sensing, including both hardware and software

  • Power for wireless sensors, including energy harvesting using supercapacitor-based storage

  • Applications of embedded systems, including civil engineering, medicine, motion tracking

I used to be more active on the following topics but am currently not as active. They are power optimization tools IMPACCT, B# battery emulator, and Chinook hardware/software codesign and system synthesis of embedded systems

1. Wireless Sensor Platforms

In my lab, we build a number of hardware platforms for wireless sensing and for other uses.

  • Eco ultra-compact wireless sensor
  • DuraMote (Roocas+Gopher): wireless nodes for civil engineering
  • Mini-FDPM (aka HBS): noninvasive breast cancer detector

1.1 Eco (2004–), EcoSpire (2009), EcoSD (2011)

1.1.1 Eco

Eco is one of the smallest wireless sensor node to date (C33). Only 557mm 3 in volume and 1.6 grams in weight, the original Eco is designed to be worn on the limbs of pre-term infants to monitor their spontaneous movement in response to assisted exercises. Professor Andrei Shkel of Mechanical Engineering, an expert on sensor devices, was working with UCI Medical researchers on this problem, and we designed this ultra-compact sensor node that is only 11% the volume of the smallest of the most popular commercial sensor node at the time, the Mica2DOT from Crossbow (which unfortunately no longer sells motes as of this writing, August 2011). This required overcoming many engineering challenges that are currently still in the publication pipeline, but the novelty was also recognized with our third Low Power Design Contest Award (another $2,825 in cash prize) at ISLPED 2004.

The pre-v1.0 Eco had a 2-board stacked design, but it had poor RF performance due to physical design and it was not expandable. After several iterations, we went with a single 4-layer, thin PCB where the inner, flex-PCB layer is used as the 16-pin expansion connector.  The version-1.0 Eco was first manufactured successfully for 100 units (in Korea) in June 2006, after failing the first batch of 40. Subsequently, a batch of 1000 units was made in March 2007 (in Taiwan), and another batch of 3000 units was made in 2008.  We have been making Eco hardware and software development tools available to other researchers in the form of EcoKit.  Spec of the Eco node:

  • MCU: nRF24E1, with an 8051-compatible core and nRF2401 radio @1Mbps
  • On-board Peripherals:  Hitachi H34C triaxial acceleromter, +/- 3g range, temperature sensor; light sensor, LED
  • Expansion: SPI, UART, digital I/O, ADC
  • Battery:  90mAh lithium-polymer
  • Antenna: Rainsun 2.4 GHz chip antenna, 1.5 dBi, 10-meter range @0dBm Tx power
  • Memory:  4 KB on-board EEPROM for code,  4KB shared code-data RAM (in addition to 8052's internal 256-byte)
1.1.2 EcoSpire (2009-)

By 2008, Nordic, the vendor of the nRF24E1 integrated MCU+RF chip used in Eco, had stopped making the chip and had switched to a newer family, the nRF24LE1 and nRF24LU1.  They are faster, more efficient, and smaller than the predecessor, and there was really no reason not to take advantage of this new chip.  Besides, the 4KB memory (shared data and code) on the original Eco has been quite limiting. Thus EcoSpire was hence born.

There were actually two kinds of EcoSpire: a "SimpleNode" and a "SuperNode".  Both use the same nRF24LE1 MCU. The SimpleNode mimics Eco but with a different connector. The initial version uses a female connector rather than a male flex-PCB connector for better robustness.  A later version switches to the snap-on connector.  The SuperNode is larger with more prototyping area and a Micro-SD Card connector for storage expansion.  The SuperNode is really meant to be a convenient board for developers who don't want to bother with adapters or breakout boards just to get access to the pins.  It turns out to be useful also for applications that don't care as much about size or cost.  The name EcoSpire actually was coined to mean Eco + inspire: it hopes that developers get inspired to create great applications for WSN.

Specs for the EcoSpire.

  • MCU: nRF24LE1, with an enhanced 8051-compatible core and nRF24L01 radio @2Mbps

  • On-board peripherals: SimpleNode: ADXL triaxial accelerometer (analog); SuperNode: ST triaxial accelerometer (digital) with programmable threshold detection; light sensor, LED

  • Expansion: SPI, UART, digital I/O, ADC; Micro-SD card (SuperNode)

  • Battery: 90 mAh lithum-polymer

  • Antenna: Rainsun or Antenova 2.4 GHz chip antenna, 1.5-3 dBi depending on the model, >10 meter range @0dBm Tx power

  • Memory:  16 KB on-chip flash for code, 1 KB on-chip data RAM, in addition to 8052’s internal 256-byte RAM; 1 or 4 MB serial flash on-board (SuperNode)

1.1.3 EcoSD (2011-)
EcoSD EcoSD is the smallest Eco node to date. It uses a 4mm x 4mm nRF24LE1 MCU+RF, which is the smallest such IC available.  It has the same shape as a Micro-SD card, which is 15mm x 11mm, and it uses the same 9-pin connector as the Micro-SD card even though it is not electrically compatible with it. The reason we use it is because we don't have to make a custom connector for it, and it is much more robust than flex-PCB, which becomes unreliable with hairline cracks after a number of mating cycles.  After clipping off the connector part, EcoSD ends up being about 35-40% smaller than the original Eco node.  Compared to the Tmote Mini, which was a sensorless MCU and radio module on a full-sized SD card (32 x 24 x 21 mm^3), EcoSD integrates the same ST triaxial accelerometer from EcoSpire SuperNode and is a fully working system.  This makes EcoSD possibly the world's smallest board-level design.  (we don't quite count those millimeter-cube SoCs because they run at low duty cycle).  Another reason for the Micro-SD form factor is that if we need to perform data logging to a MicroSD card, we can just use a double connector to connect a MicroSD card and an EcoSD either in a plane or a stack. making it compact and robust. Why make EcoSD so small? Because our users want these as small as possible while operating at nontrivial rates (e.g., 50-100 samples per second).  EcoSD is still very much ongoing work, but we are gearing up for mass production after we iron out a few more details.  The features are
  • MCU: nRF24LE1 in 4mm x 4mm package

  • Expansion connector: 9-pin in the form factor of MicroSD

  • On-board I/O:  ST triaxial digital accelerometer with threshold detection, light sensor

  • Board: same shape as Micro-SD

  • Battery: 90 mAh lithium-polymer

  • Antenna: Rainsun 2.4 GHz 1.5 dBi

  • Switch option:  sliding on/off switch, magnetic on/off switch (work in progress), pushbutton

  • Charging option: wireless using PowerCast 900 MHz module (work in progress)

  • Memory: 16 KB on-chip flash, 1 KB on-chip data RAM in addition to 8052’s internal 256-byte RAM

1.2 DuraMote (2008–), a.k.a. PipeTECT sensing system

DuraMote was a follow-on design to address limitations with DuraNode. Also, some components have been discontinued, and we would need to replace them with newer parts anyway.  The DuraMote effort started in 2008 as Prof. Shinozuka and I wrote the NIST proposal. We received funding in 2009 and started the PipeTECT project.

gopher nodes Roocas
3-board stacked
Problems: sensor in the middle layer, decreased accuracy; not good for underground operation
Separate data aggregator (Roocas) from sensor (Gopher) nodes, with sensor on its own board in its own box, daisy-chained to data aggregator by CAN bus, good for underground
Upload: Wi-Fi; possible for serial port, fiberoptic (not implemented)
Upload: Wi-Fi by default, but also connectors for
Xstream, X-Bee, Ethernet, Eco, and others.
Sensor-to-aggregator: CAN (Controller Area Network, 1Mbps)
Data logging
Not available
SD Card slot, plus on-board MRAM for meta-data
Time sync
No hardware support
Option for GPS or WWVB (atomic time broadcast) add-on module

DuraMote uses Silicon Design's SD1221L02 high-precision MEMS accelerometers in conjunction with a QuickFilter chip (4-channel ADC+digital signal conditioning).  Its accelerometer performance has been extensively tested on a shaker for 0.1 Hz to 300 Hz vibration.

As of September 2011, 100 units of DuraMote are being manufactured and tested.  We have done field tests on the water pipes of OCSD (Orange County Sanitation District) in Newport Beach, IRWD (Irvine Ranch Water District) in Tustin, SAWPA (Santa Ana Watershed Project Authority) in Corona, PACE (Pacific Advanced Civil Engineering) in Costa Mesa, on Vincent Thomas Bridge in Long Beach, and the new Hwa-myung Bridge in Korea.

1.4 Medical Instrumentation: Mini-FDM

Mini-FDPM is a noninvasive, optical handheld breast-cancer detector based on the principles of frequency domain photon migration (FDPM), developed by Professor Bruce Tromberg at the Beckman Laser Institute (BLI) at UCI. In addition to shrinking a refrigerator-sized instrument down to a handheld unit, I overcame challenges in broadband and low-power system design. The result is a medical instrument that is higher performance and significantly lower cost than current systems, making it practical for replication and wide distribution. The version from Fall 2004 was published in (C31). I have been invited to participate in the meeting for NTROI – Network for Translational Research on Optical Imaging, a National Cancer Institute sponsored Network administered through the BLI – to showcase the Mini-FDPM design to other researchers who would benefit from this technology. This work also lays the foundation for research on a system-on-chip implementation and FDPM-based imaging system.

2. Software and Tools

A lot of the effort has gone into the software part of the platforms to work with our own hardware.

  • Runtime support, including Remote Reprogramming and Macroprogramming
  • Protocols and infrastructure support
  • Motion tracking

2.1 Runtime Support and Remote Reprogramming

have been developing runtime support techniques for our own hardware platforms.They are

  • Telescribe – wireless, resumable whole firmware-image replacement
  • RPFU – incremental remote firmware patching for flash-based embedded systems
  • Enix – a cooperative threading OS for EcoSpire nodes
  • EcoCast – interactive, object-oriented macroprogramming with on-demand compilation and firmware patching
  • Nucleos – a threaded-code-based runtime dispatching system

Currently, my main focus is on EcoCast, which will serve as the framework for unifying all of the other pieces of work.

2.1.1 EcoCast

EcoCast has two ideas: interactive invocation with on-demand code patching, and macroprogramming support.  The first idea is based on EcoExec, which uses Python shell as its user interface, and sensor nodes are accessed through their representative objects called node handles.  By invoking a method on the object, it causes the corresponding function on the node to be invoked; in other words, the shell makes an RPC (remote procedure call) for it.  Arguments and results are type-checke and type-marshalled.  If the function does not exist in the firmware of the node, then the shell invokes the compiler and linker as needed, constructs the new image, creates the patch, patches the firmware on-demand wirelessly (or over a wired network if that is the chosen interface), and invokes the function normally.  In the mean time, a version control system tracks the changes so that the user can always undo to go back to the previous version if they mess up.  We believe interactive programming encourages experimentation and can increase productivity significantly. Moreover, a GUI can be built easily by accessing nodes as objects in Python.  EcoExec itself occupies about half a kilobyte of program memory, and it allows the firmware memory to act more like a code cache.  Because the firmware is flexible, it enables code to evolve over time.  This is what enables our nodes to appear to have the same level of functionality while requiring only a small fraction of the resources as much larger nodes.

The macroprogramming part uses functional programming constructs such as map, reduce, and filter spatially for invoking functions or evaluating conditions on whole groups of nodes at a time, rather than one node at a time.  The given function to be RPC’d is passed as the first argument to map, reduce, or filter, rather than using loops and if/then/else constructs to test individual nodes.  This is very powerful and concise, although the syntax and semantics still take some getting used to.  Map and filter work with start networks and multi-hop; we still have a lot more work to extend these to reduce.

I envision that most if not all of embedded systems to be programmed this way eventually.  By the way, the “cast” in the name EcoCast is used both in the sense of an ensemble of actors that perform according to scripts (scripting languages), as well as communication sense.

2.1.2 Telescribe

Telescribe is a runtime support system for remote firmware update of many nodes at a time (by one-hop broadcasting).  What makes it special is that it is resumable.  That is, you can turn off any number of nodes, or the base station may crash due to any number of reasons such as power loss or system hanging, but that is ok… Telescribe is robust so that the update can resume on any node wherever it left off.  This has been shown to work on 100 Eco nodes, and the practical limit is either 256 or 65536.  It takes about 2.7KB of code memory.  It is also the same mechanism used in EcoCast, except the firmware is patched incrementally.  Unlike other reprogramming systems such as Deluge, Telescribe confirms success of reprogramming.

2.1.3 RPFU – Remote Progressive Firmware Update

RPFU tries to optimize the patching cost from the ground up – i.e., from the code layout of the very first version of the firmware!  An observation is that for flash memory (even for NOR-flash, used for firmware), to modify even one byte of memory, you have to erase the entire page first and rewrite it.  That is very costly in power and time.  So, you want to consolidate the changes to as few pages as possible.  But how can you predict what changes the user will make? It turns out some metrics for characterizing code complexity of functions such as Cyclomatic Complexity, when augmented with proper weighing functions (call dependency), are good predictors of likelyhood of change.  So, the linker can place these code blocks together as much as possible.  This has been shown to be very effective at reducing both the delta transmitted and the perturbation to the firmware memory (and therefore its power).

2.1.4 Enix

Enix is a mini OS for EcoSpire nodes, which are based on the 8051 instruction set architecture. Why did we bother when there are so many other OSs out there for wireless sensor nodes?  Because they don’t run on the 8051.  TinyOS has been having a working group for 8051 for a long time but the last update was October 2008 (version 0.1 pre4) as of this writing (September 2011).  We saw a need for 8051 support, because over 95% of the SoCs (integrated microcontrollers and radios on the same chip) such as TI’s CC2430/25xx, Nordic nRF ones, and many more are all 8051 based, and it seems rather ironic that there has been very little support.

Enix supports coroutines (cooperative multithreading) with an option for preemptive multithreading (though the code size increases); a WSN-oriented file system called EcoFS (log structure, name-value pairs, routine table etc), booting/running code from flash memory card (MicroSD), and a lot more.  It is more of a traditional runtime support system packed into a very small footprint.

2.1.5  Nucleos

Nucleos (“nucleus + OS”) is a scheme for supporting scripting using threaded code.  Threaded code is a classic technique for representing the instructions of a virtual machine as the addresses to the functions that implement the virtual instructions, and a virtual program can be represented as a table of these addresses.  This way, an “interpreter” entails  a double-indirect call with auto-postincrement, which is much ligher weight than a switch/case statement on some arbitrary byte code.  Unlike Java, we don’t try to represent a program virtually this way; instead, we do it at the script level (“instructions” = API).  Control flow is handled as virtual instructions as well, making the interpreter very lightweight.  In fact, programs represented this way tend to be very compact, and sometimes run faster than their all-native counterparts. Another thing we do differently from traditional threaded code is that our threaded code interpreter is recursive.  This means we can build up different levels of abstraction using high-level primitively very quickly and tightly, all using the same mechanism.

Nucleos can also be a good match as the dispatching structure for the synchronous dataflow (SDF) model of computation. The virtual instructions can correspond to actors to be fired, and the memory buffer between actors can be either shared memory or dedicated FIFOs.

2.2  Protocols and Infrastructure Support

2.2.1 Protocols

I have devloped several protocols to support our applications.  Unlike most works in the WSN literature, which assume ad hoc networking with relatively low data rates (one sample every couple of seconds to minutes if not hours), ours tend to require tens if not hundreds of samples per second of streaming data (acceleration, ECG, etc), in both infant monitoring and structural health monitoring applications.   EcoDAC is a single-channel multiple-access pull-based protocol (i.e., nodes are passive and respond when the base station makes requests) that has been shown to work with as many as 50 streams over the same frequency channel without requiring time synchronization.  RIPE-MAC is an extended version that consolidates the pulling message to further increase the payload bandwidth.  It is currently used in the infant monitoring application.

2.2.2 Infrastructure Support: EcoPlex

EcoPlex is our infrastructure support for WSNs.  It actually serves two purposes:

  • provide a network of base stations for supporting mobility of Eco nodes
  • provide the protocol translation layer so that Eco nodes appear as virtual ZigBee nodes in the ZigBee world.

Each base station (which is really a gateway) in the EcoPlex network has at least four interfaces: TCP/IP over Ethernet, two nRF2401’s ShockBurst transceivers for Eco, and ZigBee on top of IEEE 802.15.4 MAC.  They are connected to each other via TCP/IP and to a name server, which is somewhat similar to a DNS for tracking the association of nodes to gateways.  The nodes can roam around, and when the packet loss drops below a certain level, they switch to handoff mode and negotiate for a better base station on a different channel.  Each base station uses a distinct frequency channel for data and a common frequency channel for handoff and other control.  We currently do not support spatial reuse of frequency channels but that can be added.  For every connected Eco node, the associated base station (which acts as a ZigBee coordinator node) constructs the data structures so that the Eco node has a virtual identity in the ZigBee network. This allows a ZigBee network to take advantage of the more compact, low-power Eco nodes, and vice versa.  More generally, it is our approach towards enabling heterogeneity support for WSN.  Like the Internet, we believe that nodes in WSNs should be able to work with each other regardless of their connection media.

2.3  Motion Tracking

I have developed techniques for motion tracking. Specifically, we use accelerometers on Eco nodes for this purpose. We also explore the use of cameras.

2.3.1  EcoIMU

EcoIMU is an inertial measurement unit (IMU) based on Eco nodes.  Unlike traditional IMUs that rely on gyroscopes and accelerometers, our EcoIMU is gyro-free (GF-IMU).  It has the advantages of lower power consumption and (potential) ability to handle faster angular velocity, since gyros are often limited this way.  However, error accumulation and yaw rate sensing present greater challenges to GF-IMUs.  Moreover, the use of wireless communication, a lossy medium, can greatly exacerbate the motion tracking problem if only raw acceleration data is transmitted.  We have built the base model for our dual-triaxial-accelerometer design of EcoIMU for body sensor and gesture recognition applications; we are continuing to improve this model in terms of local integration before transmission, communication protocol, and use of non-parallel accelerometer configurations.   One version of the EcoIMU is being used in the Smart Sediment Grain application (underwater sediment monitoring).

2.3.2  Camera-Based Motion Tracking

This is a way to complement GF-IMU by using cameras.  Unlike IMUs, which track the motion relative to an inertial frame, cameras themselves are ideally located on the inertial frame, but in practice cameras themselves are subject to motion as well due to hand shaking or perturbation to the tripod, etc., causing the captured image to blur.  We have developed techniques (publication pending) to automatically derive the “blur kernel” (trajectory) on the camera so as to remove the camera’s own motion, and only then is motion tracking meaningful.

3.  Energy Harvesting

I am mainly working on energy harvesting systems that use supercapacitors as the energy storage. They are primarily for wireless sensor platforms such as the ones that we develop ourselves (DuraMote, Eco, etc), which consume 10s to 100s of mW.  Although energy harvesting systems have been developed and some are even available commercially, they usually don’t work very well: they harvest less power than expected, and their rechargeable batteries don’t last for more than a year or two.

To address these problems, we include circuitry for maximum power point tracking (MPPT) and by storing the energy in supercapacitors instead of batteries. However, MPPT incurs overhead that can actually be a loss when the harvest power is on the order of 10s or 100s of mW for micro-solar harvesters, rather than 100s-1000s of watts for macro-solar harvesters.  So, we perform approximated MPPT that trades precision for low overhead so that the absolute amount of converted power can be maximized.

The problems that need to be addressed in such a system include

  • how to minimize the high leakage in supercapacitors
  • how to minimize residual charge, i.e., stored energy below a usable threshold voltage
  • how to properly and efficiently handle cold booting, i.e., futile cycles of booting up but crashing shortly after due to insufficient usable energy, despite sufficient stored energy
  • how to widen the charging zone by lowering the harvesting power threshold (voltage, current), not just maximizing the conversion efficiency while assuming a high threshold, such that the total amount of harvested energy (not just power) is maximized over time.

I have developed a number of systems to address several of the issues outlined above. In chronological order:

  • Ambimax (sensor-driven, multi-supercapacitor MPPT charger)
  • Everlast (feed-forward PFM charger + sensor node)
  • DuraCap (IV-curve sweeping, autonomous MPPT, cold boot-up capacitor + reservoir supercapacitor array)
  • EscaCap (charge pump MPTT, reconfigurable supercapacitor topology)

3.1 AmbiMax

AmbiMaxAmbiMax is an MPPT circuit that can harvest power from potentially multiple sources such as solar and wind, and it charges a reservoir supercapacitor array (RSA).  It performs approximate MPPT by using a sensor, which may be a light sensor or a wind-speed sensor. The observation is that the voltage from such sensors can be used directly to control the hysterisis band of a Schmitt trigger to achieve the effect of MPPT. This means MPPT can be accomplished without involving a microcontroller or even logic.  It also uses a switching regulator rather than a diode to avoid the 0.3-0.7V voltage drop caused by diodes, which are commoly used in solar panels to prevent reverse current flow. However, AmbiMax has some problems, particularly during cold booting. The problem is with the switching regulator that charges the supercapacitor: when nearly depleted, a supercapacitor appears like a short circuit, causing the switching regulator's feedback mechanism to limit the current to a level far from the MPP.  As a result, it will not charge efficiently when the supercapacitor is near depletion, but AmbiMax should be charged first before deployment.

3.2  Everlast

Everlast boardEverlast

is a wireless sensor node that also performs MPPT and charges a supercapacitor.  The MPP tracker shares the microcontroller with the sensor node, although it can also be designed to operate autonomously without an MCU. It addresses the feedback problem of the switching regulator by using a feed-forward pulse-frequency modulation (PFM) charging scheme.  MPPT is done by the open-circuit voltage method with a table lookup. Our approach enables charging to be performed normally even in the boundary cases.

One issue with Everlast and table-lookup-based methods in general is the pre-deployment characterization of the solar panel required to build the lookup table.  We worked with companies that wanted to use Everlast, but the solar panels they had did not match the characteristics of our panels, and they did not know how to characterize the new panel.  This became problematic because it is not readily usable by users that may want to customize the panel sizes.

3.3  DuraCap

DuraCapDuraCap was invented to address several problems:
  • automatic characterization of the panel by I-V curve sweeping
  • efficient cold-booting support with autonomous MPPT, with a dedicated capacitor for fast bootup. Automatic I-V curve sweeping is performed only very rarely to refresh the characterization of the panel, so that those of different sizes, brands, and quality can all be plugged in without extra manual setup step, a problem we experienced with Everlast (and AmbiMax).  This is also a useful feature for long-term use, where the same panel is expected to change its characteristics over time due to aging and dusts. To support I-V curve sweeping, we divide the charge into two (banks of) supercapacitors so that the system can be powered by one while sweeping and charging the other.  This is controlled by an 8-bit (PIC) microcontroller, which is active only sporadically.

For cold-booting support, the charger first charges a smaller supercapacitor, called the bootcap, dedicated to booting time. The reason is that a larger capacitor will take more charge and more time to reach the usable voltage; before then, the charger and MPPT circuitry has to work autonomously without a separate controller. To accomplish this, we have the default power path that is controlled by a pair of nonvolatile programmable potentiometers for the autonomous MPPT circuitry. Once the bootcap charges up to a level that is not only sufficiently high in voltage but also in energy for booting up, the system starts up. DuraCap is being used in a landslide/debris flow monitoring project.

3.4  EscaCap

The primary goal of EscaCap is to “widen the charging zone” by lowering the charging threshold, so that it can weather well over extended periods of poor weather.  For example, many harvesters may have the charging zone from 10am-5pm, whereas ours may work from 7am-7:30pm on the same sunny day.  This is important because not every day may be sunny, and so that means a traditional harvester will harvest little energy, even if it boasts high conversion efficiency; however, when below threshold, its conversion efficiency is zero!  By lowering the threshold we can increase its overall harvesting efficiency, because our system discards less usable energy. EscaCap improves over DuraCap in the following ways:

  • It uses a charge pump to lower the charging threshold, thereby making use of even more available energy
  • It makes use of reconfigurable supercapacitor array topologies in order to achieve lower leakage and higher efficiency over different scenarios

First, many chargers use buck-boost regulators to charge the energy storage device at a stable voltage. This is good for batteries but unnecessary for supercapacitors.  One advantage of a charge pump is the smaller size and ability to work with lower voltage than most chargers or DC-DC converters (0.7V). 

Second, we configure the supercapacitor topology for series and individual configurations.  Series composition increases the voltage and reduces capacitance, which means it can charge up to a higher voltage more quickly; singles configuration allows the voltage among the different capacitors to be kept balanced as a way to minimize leakage, which increases exponentially as the voltage approaches the capacitor’s rated voltage.

EscaCap has been prototyped and is being set up for field deployment as of this writing (September 2011).

3.5 Summary of Energy Harvesting Systems

Energy Storage
MPPT method
Cold boot
Reservoir supercapacitor array (RSA)
sensor driven
open-circuit voltage
feed forward
MCU table lookup
Bootcap + RSA
open-circuit voltage
Analog control during booting, MCU table lookup normally
Reconfigurable RSA
hill climbing, MPTT
boot configuration
DDS controlled charge pump
charge pump frequency sweeping with current feedback

4. Applications

I have been working on several applications of wireless embedded systems alongside the respective domain experts.

  • Civil and Environmental Engineering
  • Infant Monitoring
  • Performance arts
  • Optical Sensing System

4.1 Civil and Environmental Engineering

  • Structural Health Monitoring

  • Noninvasive water pipe monitoring (w/ M. Shinozuka, Civil Engineering)

  • Underwater sediment motion monitoring (w/ D. Foster, U. of New Hampshire)

  • Debris flow monitoring (w/ B. Lee @GIS, Fenchia Univ, Taiwan)

4.2 Wearable Medical Devices

  • Infant monitoring Cerebral Palsy detection (w/ D. Cooper @ICTS, UCI; and D. Patterson, ICS, UCI)

  • Infant monitoring - SIDS monitoring (w/ Dr. R.-K. Chang, Harbor Medical, UCLA)

  • Optical sensor modules for Eco (in planning)

4.3 Performance Arts

  • Quantifying bioelectric and biomechanical data for synthesizing live visual and audio media (w/ N. Eidsheim, UCLA)

4.4  Spectroscopy and Medical Imaging

  • Mini-FDPM: noninvasive breast cancer detector based on frequency-domain photon migration (w/ B. Tromberg, BLI, UCI)
  • mcLSI: multi-camera laser speckle imaging, for bloodflow perfusion monitoring (w/ B. Choi, BME, UCI)

5. Previous Research (no longer active)

5.1 IMPACCT (2000–2004) (no longer active)

I developed a new tool called IMPACCT, for Integrated Management of Power Aware Computing and Communication Technologies, sponspred by DARPA PAC/C program. During Phase 1 (2000-2002) (J2) IMPACCT focused on constraint-driven (C12) power-aware scheduling (C13) and system-level mode-dependency modeling (C14) For data regular applications, power-aware task motion (C15).

(J3) applies software pipelining towards satisfaction of timing and power constraints. Communication speed in a multi-speed interface was considered as a knob for power management (C17) with simultaneous functional partitioning among multiple voltage-scalable CPUs (C18, J4) and data compression (C22) more recently. The target applications included NASA/JPL’s Sojourner Mars Pathfinder and ATR (automatic target recognition) algorithms.

For phase 2 of the PAC/C program, we work with Rockwell Collins to reduce power in their software-defined radios (SDR). A new tool called ImpacctPro was developed (C30) to enables designers of a software-defined radio (SDR) to explore many options in improving power efficiency. The tool supports high-level modeling of the sytem architecture (C20), tasks, real-time scheduling (C24, C29) power management (C22, C23), C28 co-simulation, and profiling. Innovations include

  • (C29) Generalized, multiple power-mode dynamic power management that subsumes the traditional break-even time analysis. We use a novel energy-over-time geometric formulation for optimization on multi-mode transition sequences.
  • (C30) ability to control an SDR system in real-time, so that the system can be tested and measured while operating normally.
  • (C23, C28) ultra-fast and efficient evolutionary algorithm for slack distribution. It uses very few voltage/frequency steps to accomplish the same level of energy saving as the best published but slow technique, while running hundreds of times faster.

The system design effort is complementary and synergistic with the design tools effort described in Section 1 above. The effort from 2002–present has resulted in three award-winning system designs and a prototype of a medical device.

5.2 B#: Battery Emulator and Power Profiling Instrument (2002–2005) (no longer active)

B# (pronounced “B-sharp”) is a system that can perform battery emulation and power profiling, as described in (C21, J5). The novelty is the combination of the hardware and software: the hardware controls the electrical property, while the software defines the behavior by real-time simulation of the battery chemistry. The most important value of B# is reproducibility: it enables experiments involving embedded systems that track power levels to behave exactly the same way each time. This concept has been extended from lithium-ion batteries to solar panels and fuel cells.

The B# system is available to research groups in academia and industry, and the software is freely downloadable on the Internet for academic research use. We have developed the world's most accurate (1% error) battery models that have been calibrated and validated empirically with B#. This is a unique capability that it is needed by many. The novelty of this work was recognized with the Low Power Design Contest Award at the International Symposium on Low Power Electronics and Design (ISLPED) 2003. It carried a $2,000 cash award and was one of the six winning entries out of 16 submissions worldwide.

5.3  DuraNode

(2003–2007) (No longer active – superceded by DuraMote)

The first sensor node is called DuraNode, a wireless sensor node for monitoring the structural health in civil engineering. Professor Masanobu Shinozuka of Civil and Environmental Engineering, has long identified the significance of this approach but found that existing sensor nodes fail to perform in the intended settings. I worked with my students to build this new solar-powered sensor node that overcame many engineering challenges in power management, real-time scheduling, and communication protocols. The result was a durable, robust wireless sensor system that can collect data and transmit the results in real-time over a wireless Internet connection. This sensor node has been demonstrated in April 2004 on the green steel bridge on East Peltason Dr., UCI, and in the CalIT2 building. This sensor node design not only provides a new technology for civil engineering as articulated in (C25), but it also encompasses many innovations in electrical and computer engineering, including solar power management (C27) and reduction of power fragmentation with multiple ambient power sources (C26). These novel aspects were recognized with our second Low Power Design Contest Award ($2,825 in cash prize) at ISLPED in 2004. It was one of the four winners out of 11 submissions.  In November 2004, a new dual-microcontroller DuraNode has been constructed and demonstrated at the Cal(IT)2 open house. Details of this paper will be published in (C32). It supports low-jitter operation, aggressive power management capabilities, and ability to interface with sensors with very different voltage levels.

Summary of features: - Dual microcontroller (PIC18): one for sensing control, one for protocol stack, FIFO chip in between

  • Voltage converter for a wide range of sensors, including +/-15V for piezoelectric
  • 4000 mAh battery, Wi-Fi (802.11b) card based on Prism 2 controller
  • Ability to be powered with solar and wind generators

5.4 Chinook hardware/software cosynthesis framework (1992–1998) (no longer active)

I was a contributor to the Chinook hardware/software co-synthesis tool during 1992–1998 as a graduate student at the University of Washington. In the first phase (B1, C4 Chinook focused on hardware/software interface synthesis (C1, C5) with the goal of minimizing hardware; and scheduling for multi-mode systems (C2) and for meeting interface-level timing (J1, C3) In the second phase, interface-synthesis was raised to the higher level to IP blocks (C10) Here the “interface” is not so much the detailed signaling, but the higher-level coordination protocol which is often hardwired in the control-flow constructs and is the primary obstacle to reuse (C8). propose a way to compose control (C9) and synthesize the distributed protocol controllers (C6, C11) The coordination protocol (CP) view represents a departure from the model-of-computation (MoC) view popularized by Ptolemy: an MoC captures a class of CP’s, but MoC’s are either over-constraining or over-generalized.