This page has more general information about WISP firmware for the WISP4.1DL hardware version.
For information about specific versions, see the firmware implementation notes.
Questions? - pollyp pollyp maintains this page.

WISP application selection


The WISP firmware supports four types of applications. SIMPLE_QUERY_ACK returns a hardcoded tag value. SENSOR_DATA_IN_ID returns sensor data as an tag value. SIMPLE_READ_COMMAND shows use of the Access command READ and returns a word of counter data. SENSOR_DATA_IN_READ_COMMAND returns sensor data in the response to a READ command.

The benefit to choosing the SENSOR_DATA_IN_ID application over the SENSOR_DATA_IN_READ_COMMAND is that it involves less communications overhead, and so has the best range and performance. The drawback is that it will appear as if you have more than one tag responding, because the tag value varies over time.

Right now, there's firmware support for two types of sensors: the accelerometer and the MSP430's built-in temperature sensor. (Well, there is a third "sensor", used for testing, called the null sensor. It just returns either a hardcoded string or a counter value.). However, for backward as well as future compatibility with the GUI app, the full sensor ID space is defined below.

You can select an application and sensor type by setting the appropriate #define at the top of the source file.

WISP General Protocol

The WISP and GUI app need to agree on a protocol in order to parse things correctly. Here is the EPC format for a standard 12-byte EPC for GUI Release 1.0:

[ 1 byte | tag type ] + [ 8 byte | data ] + [ 1 byte | WISP HW Version ] + [ 2 byte | HW Serial # ]

Tag Type and Data: This is described in the next section

WISP HW Version: {0x20, 0x40, 0x41} for WISP Gen 2.0, 4.0 DL, and 4.1 DL

HW Serial Number: WISP hardware serial number, physically labeled on WISP, right-aligned, hex-coded (ex, WISP #10 = 0x000A). May be written to MSP430 flash user memory for convenience (TODO: specify location).

WISP Tag Type and Sensor Data Protocol


By default, the WISP returns a sensor type id, sensor data (optional), and a tag id that encodes the firmware version. If sensor data is included, 7 bytes will be set aside for for the sensor payload, followed by the tag id. The data will start in the pc field (two bytes in the ACK response), and spread into the epc field (8 bytes in the ACK response).

Sensor
Tag Type
Sensor Data
Length (Bytes)

Sensor Data Format
Other Data
Other Data
Length (Bytes)

Format
Static ID
0x00
0 (padded to 6)
N/A
Static

N/A
Null Sensor
0x0C
2 (padded to 6)
0x02, 0x03, padding
Counter
2
Hi, Lo
Temperature
(internal)
0x0F
2 (padded to 6)
Xhi, Xlo, padding
(10 bits of data, right aligned)
Counter
2
Hi, Lo
Temperature
(external)
0x0E
2 (padded to 6)
Xhi, Xlo, padding
(10 bits of data, right aligned)
Counter
2
Hi, Lo
Acceleration
(standard)
0x0D
6
Xhi, Xlo, Yhi, Ylo, Zhi, Zlo
(10 bits of data per channel, right aligned)
Counter
2
Hi, Lo
Acceleration
(quick)
0x0B
6
Xhi, Xlo, Yhi, Ylo, Zhi, Zlo
(10 bits of data per channel, right aligned)
Counter
2
Hi, Lo
Capacitance
0x0A
tbd
tbd
Counter
2
Hi, Lo
Neural Wisp
0xAA
tdb
tdb
Counter
2
Hi, Lo
Reserved IRS
0x1*
tdb


























Here's how to interpret the value returned by the temperature application:
temperature_in_celsius = ((value_returned_by_wisp - 673) * 423) / 1024;

Here's how to interpret the value returned by the acceleration application (convert to 0 to 100% scale):
"0B": alpha = 1.16
"0D": alpha = 1
acceleration = 100 * alpha * value_returned_by_wisp / 1024;
x,y = 100 - acceleration
z   = acceleration

We've designed the firmware to make it easy to sample new sensors: just add in your own implementations for init_sensor() and read_sensor() in a header file and set the appropriate #defines to call it. You'll have 7 bytes available for your sensor payload. If you want your new firmware to stay compatible with the GUI application, you'll need to pick a non-conflicting sensor type ID and set the SENSOR_DATA_TYPE_ID #define to it.

Other features and settings


There are three other feature options in the WISP firmware: ENABLE_SLOTS, ENABLE_SESSIONS, and ENABLE_HANDLE_CHECKING. Support for these options is both optional and highly experimental. Using these options has the following drawbacks: (1) it's brand new code, and not well tested; (2) it adds a lot of code, which means you'll likely hit the free IAR Kickstart edition compiler's 4K limit; (3) the WISP works well without these features; and (4) enabling these features means more code execution, which translates directly into greater power consumption and diminished range and performance.

The firmware also has #defines for EPC and TID_DESIGNER_ID_AND_MODEL_NUMBER. Feel free to change these to anything you like.

If you look at the firmware, you'll see #defines for reader type and encoding. Don't change these. Right now, we only support Impinj readers and Miller-4 encoding.

More Notes and Links


Here are the implementation notes for the HW_4_1 series firmware. You can also see the implementation notes for the deprecated HW_4_0 series hardware.

Power Lab Notebook was a place where we did our out-loud thinking about the performance of the (now deprecated) HW_4_0 hardware and how to improve it.

WISP Primer (Somewhat dated, but still useful.)

Theory of Operation - todo

more ideas?





The last modification was made by - yeagerd yeagerd on Feb 9, 2009 5:25 pm