The Passive Data Logger

This page has information on how to convert WISP4.1DL into a data logger.

Please help cleanup this page - click the edit button above!

Publication Link

Wirelessly-Charged UHF Tags for Sensor Data Collection
Daniel Yeager, Richa Prasad, David Wetherall, Pauline Powledge, Joshua Smith. Second annual IEEE Conference on RFID.
Power Point Slides


The passive data logger is a sensor tag which includes an RFID communication interface, re-charges its energy supply wirelessly, and stores sampled sensor measurements to non-volatile memory in the absense of a nearby RFID reader.

Hardware Changes

The only hardware modification required to convert WISP4.1 into a data logger is to solder a large capacitor into the thru-hole connectors.

To log data to the onboard EEPROM, you'll need to include this code.
To log data to on-chip flash memory, a higher regulated voltage is required (2.2V). Kevin Fu's group has done some work on writing at lower voltages with reduced reliability and compensating for errors.

Firmware Changes

The firmware builds on the base WISP communication firmware, but adds a periodic timer interrupt to perform the data logging. A more advanced power management scheme is used because long term energy conservation is paramount. The communication interface includes the ability to read data by address, to erase the NVM and to silence the communication for a period of time (or until N new samples have been logged).

Practical Notes:
- Use the watchdog timer as a periodic wakeup timer.
- Change all LPM4 references to LPM3. Set the clock source to VLO or 32khz crystal.
- Enable watchdog interrupts, service the interrupt vector.

Implementation Notes:
Thanks to Aaron Parks - anparks anparks

-First, add the following code to the initialization routines in the beginning of main():

WDTCTL = WDTPW | WDTHOLD;         //Put the WDT on hold during init routines
BCSCTL3 |= XCAP_3;                //Match LFTX1 load capacitance to xtal (12.5 pF)
IFG1 &= ~WDTIFG;                  //Clear WDT interrupt flag
IE1 |= WDTIFG;                    //Enable WDT interrupt
WDTCTL = WDT_ADLY_1000;           //Put WDT into interval timer mode, clocked by ACLK, with prescaler 1 for 1000ms interrupts.

-Next, change the P2SEL initialization value to 0xC0. This is required to make the external crystal run.

-Next, change all the LPM4's to LPM3's, including the _BIC_SR() lines. Just do a find & replace for LPM4 -> LPM3.

-Lastly, add a WDT interrupt service routine like the following, with no function prototype:

#pragma vector=WDT_VECTOR
__interrupt void WDT_ISR( void )
    //Your ISR code here.


this needs to get parsed into a proper explanation:

Where can I learn the logging and reading rate of the milk carton application that is referenced in many of the papers?

The sample rate is adjustable; I believe it was about 1 second in the paper (although logging was only performed if the data changed to conserve memory).

The read out rate is between 10 to 100 packets/sec depending on the reader, data encoding method (Read command vs. Encode into ID), reader to tag distance, and modulation settings. The data rate is bytes/packet * packets/sec. For ID-encoded data, the wisp supports about 96bits * 50 hz (although longer or shorter IDs can be used). For the Read command the data rate is more like 16 bits * 10 hz, although longer read packets can be configured.

Thanks for the quick response. I was also wondering how frequent the reader retrieved the data and also how frequent did you free up the memory? Is it after each download?

The reader retrieved data and cleared the memory whenever it could. The application was meant to mimic a shipping container; the tag was not readable while it was inside the refrigerator. Data transfer occurred when the tag (milk carton) was outside the refrigerator.

Recently I read your paper "Wirelessly-Charged UHF Tags for Sensor Data Collections", and was impressed by the design of such kind of WISP. I personally think the WISP-PDL has great potential applications in the supply chain, and highly appreciate the work you did.
I am just a beginer abut the WISP, and I do not understand clearly about the software state diagram in the Fig.5 in the paper. It seems that the framework falls into two aspects: i) wake the device to periodically sample and add data logging, ii) turn on the RFID interface to communicate with reader. My question is the relationships of the two aspects with the sleep mode. Do these two aspects work only when the state is active mode, or only the data logging cycle is performed at the active state, and the RFID interface can work independently of the sleep mode? I am not sure about this. Futthermore, I have a sample WISP 4.1DL device which is offerred by the Intel Corp. You mentioned there are a few significant hardware changes in the WISP-PDL over the existing WISP. Can I implement the algorithms described in the paper in this 4.1DL device? Can you send me the corresponding codes implemented in the WISP-PDL? Thanks!

The communication and data logging events are interrupt-driven. The data logging interrupts are driven from a timer interrupt. The communication interrupts are driven from the external input pin interrupt (which comes from the hardware demodulator) - demodulator activity (which generates the interrupt) occurs when the reader is in range of the wisp.

The microcontroller is single-threaded; only one process occurs at one time. The device stays in sleep mode until one of the two interrupts are triggered. Interrupts automatically wake the msp430 from sleep mode (it enters active mode and enters the interrupt handler), does the appropriate task, and goes back to sleep after it exits the interrupt.

The hardware changes were made to an earlier wisp version; many of these changes (ex, the ability to sample the stored voltage as well as the external EEPROM) were integrated into the wisp 4.1DL (DL = data logger). We successfully converted WISP 4.1DL into a data logger for a demo; the only thing required is to add a large capacitor to the board which is to be soldered into the two large holes in the WISP board and load new firmware. We used a 10milliFarad (not microFarad) tantalum capacitor from Digikey - the part number is on the wiki somewhere on the FAQ page I think. Alternatively, you could use a super capacitor (ex, 0.1 farad MapCap as we did in the paper) - we may be able to send you one or two for prototyping if we have any left.

I can post the data logger firmware. Unfortunately we lost the firmware to read/write to the external EEPROM. For the last demo we just used the internal flash memory, which in turn requires a 2.2V supply voltage - a change to the regulator part on the WISP.

In the reply, you mentioned the communication interrupts are driven from the external input pin interrupt, which comes from the hardware demodulator. My understanding is when receiving the query from the reader, the WISP will respond. What if when there is no logged data in the external EEPRoM? The communication interrupt will also be generated? When WISP has logged data and it receives the query from the reader, how to let the WISP not to respond to the reader. The essential question is abuot how to control the communication interrupt.

Interrupts can easily be enabled or disabled in real time in the firmware.

If the supercapacitor voltage is too low (like a low battery) or if
there is no logged data then the communication interrupts are
disabled. If the EEPROM or flash is full, then data logging is

There is also an optional "charge" mode where the first time it boots
up it does not log or communicate until the supercapacitor is full.

One important thing: WISP will use more power than the reader is
sending while communicating. So, in order to store up energy (charge
the supercapacitor), WISP must ignore the reader. The way I did this
is once the WISP comes into range of the reader, a data download takes
1. Reader reads out data by addressing the memory on the eeprom/flash
2. Sampled are numbered in memory starting at "1". If memory is
empty, WISP returns an all-zeros packet, which signifies the end of
logged data.
3. Reader issues erase command
4. WISP erases flash and starts logging at the beginning of memory.
Communication is disabled until "N" logged data events occur. N > 0
and N is chosen based on the sampling interval - a value like 5 to 10
is good.

Step 4 allows WISP to charge up and not respond to the reader all the
time. Optionally, the reader can issue a command to simply prevent
WISP from communicating until it logs another data point. This allows
the reader to not have to erase the WISP all the time if there is not
much data in the memory.

The last modification was made by - yeagerd yeagerd on Nov 15, 2010 5:23 pm