This page is devoted to implementation issues for hw41_D41.c and hw41_D53.c. Polly Powledge maintains this page.

release 1.0 (revision 63)

2-13-2009 - polly polly

At long last, our 1.0 release is here! It includes quick accelerometer sampling; Dan and Richa's power management fixes (r61 and r23); state machine fixes; slotting fixes; session fixes; and read command fixes.

WISP hardware version: WISP 4.1
WISP number: # 1
Reader firmware version: Speedway 3.0.0
Protocol: Gen 2
Modulation method: Miller 4
Code Location: firmware/trunk

application
test type
range (ft)
query-ack
20 hz
5'8"

10 hz
9'

5 hz
9'5"

cold start
10'3"
query-ack-quick-accel-sensor
10 hz
5'8"
query-ack-regular-accel-sensor
10 hz
5'8"
query-ack internal temperature
5 hz
5'10"
fixed read command
5 hz
3'6"


r61 - Quiescent current draw reduction

2-13-2009 - yeagerd yeagerd - ripras ripras

WISP hardware version: WISP 4.1
WISP number: # 7
Reader firmware version: Speedway 3.0.0
Protocol: Gen 2
Modulation method: Miller 4
Code Location: firmware/branches/HW_4_1/pinDefWISP4.1DL.h

Firmware Changes
1. Bug: Quiescent current draw is high when pins are left floating.
Fix: Drive all pins according to their functionality.

Validation
The first experimental setup was to hook the power supply in series with the multimeter and the WISP. Table 1 shows the quiescent current draw when the WISP is in LPM4.

Power Supply Voltage (V)
Leakage Current (uA) - pins floating
Leakage current (uA) - pins NOT floating
2.0
14.62
1.76
2.5
21.83
1.85
3.0
29.17
1.89
3.5
36.60
1.96
4.0
44.15
2.06
4.5
51.94
2.40
5.0
61.15
4.22
Table 1: Quiescent current draw at different voltages with pins floating and not floating

The second experimental setup is actual RFID communication between the reader and WISP. The pink line is the RX line, yellow the TX line, and green is the Unregulated Voltage line. In this particular screenshot, Impinj sends out the garbage it always does when it first starts up (the part of the trace where voltage is rising rapidly), and then after a gap, starts communicating (portion of the trace with yellow spikes). The figure below shows the quiescent current draw when the pins are floating.

2attempts-voltage-graph.bmp

The current draw during the gap between garbage and communication is 93 uA.

The following figure shows the quiescent current draw when all pins are driven as per their functionality.

2attempts-voltage-graph-improved.bmp

The current draw during the gap between garbage and communication is 23 uA.

In both cases, the current draw is still higher than that expected by our first experimental setup (power supply in series with WISP and multimeter). We are unsure why at this point in time.

r23 - Port 2 and Sleep functions simplified, "0B" accelerometer demo - quick sensor sample code, Monitor debug hooks

2-2-2009 - yeagerd yeagerd - ripras ripras

WISP hardware version: WISP 4.1
WISP number: #1,3,6
Reader firmware version: Speedway 3.0.0
Protocol: Gen 2
Modulation method: Miller 4
Code Location: firmware/branches/HW_4_1/pinDefWISP4.1DL.h

Firmware Changes
1. Bug: Accelerometer is lurchy due to long ADXL RC time constant which requires 15ms to settle causing brownout / Vreg droop. Reducing cap value causes ADC aliasing because input bandwidth may exceed sampling rate.
Fix: New accelerometer sampling code based on experiments documented in WISP Code Examples. Implemented as a second accelerometer demo "0B" ("quick_accel_sensor.h") versus fully settling code "0D" ("accel_sensor.h"). Also, ADC_BUSY is accomplished via polling, which simplifies the code to reduce chance of interrupt state errors. This code may be disabled by selection of "0D" demo.

A new validation suite is needed to demonstate the bug and also to demonstrate that the new code meets validation standards. Proposal: C# GUI app now provides MIN/MAX and DELTA = MAX-MIN on x and y ADC channels. Run demo at x range for y minutes and record deltas. Initial results: 1 meter test, 1 minute of data - "0D" delta = 25 to 35 "0B" delta = 5 to 10

Potential drawback: Accelerometer RC constant may vary from WISP to WISP, causing an offset in saturn. Error has been tolerable with current prototypes, but this is a fundamental issue - there will be component variation causing error. A "Calibrate" button on the GUI with the wisp held relatively level could potentially fix this.

2. Bug: Power management code has a bug shown below (Accelerometer Bug and Brownout Bug).
Fix: Power management code simplified to reflect conventional wisp power model - only sleep and p2int are changed. Modifications to the power management code should provide a detailed explanation of interrupt enable conditions. Trunk integration subject to validation.

3. New Feature: Monitor compatibility. Addition: #defined monitor code

Validation

6 dBi Alien Antenna, #3 WISP, horizontal / serial facing down, using the C# GUI, 100ms polling time.
Query-ACK-accel sensor ran 12 hours successfully at 2.75 m (9 feet) range averaging 2.2 reads/second.

Full validation with 8 dBi Cushcraft Antenna (antenna center 1 meter above ground):

    • Usual multipath null around 2.5 meter encountered - need to rethink test conditions to improve consistency.

application
test type
range (ft)
range (m)
accel delta
Query-ACK
20 hz




10 hz




5 hz




cold start



Query-ACK-accel sensor
20 hz




10 hz




5 hz




cold start



Query-ACK-temp sensor
20 hz




10 hz




5 hz




cold start




r16 - making aggressive sleeping optional, redefining the alt vs pin, adding a temp sensor and a null (test) sensor


Here are some performance tests I ran on the #3 WISP, with the solder joint forward, using the web app.

application
test type
range (ft)
Query-ACK
20 hz
5'7"

10 hz
7'9"

5 hz
8'10"

cold start
10'10"
Query-ACK-accel sensor
20 hz
5'2"

10 hz
8'7"

5 hz
8'9"

cold start
9'10"
Query-ACK-temp sensor
20 hz
5'8"

10 hz
6'4"

5 hz
6'10"

cold start
9'8"

Query-ACKs and Query-ACK-temp sensor have both run more than seven hours.


r14 - Accelerometer Bug and Brownout Bug

Updated 2-1-2009 - yeagerd yeagerd

We are having some spasms in the accelerometer sensing. Test: accel_sensor.h, sensor_data_in_id, range = 1 meter. Set a debug line high while sampling - look for voltage droop. If Vreg droops, the ADC does not have a stable reference. This manifests itself as peak to peak noise of 25 on the x channel and 30 on the y channel (in ADC counts).

A separate bug, same test setup:

Pink = Vout
Yellow = RX, Blue = TX
Green = Accel sensing active / or

Notice the rapid decline in Vout. Presumably, the MCU is doing something nasty (race condition?).

accel-brownout.jpg


r14 - hw41_D41.c


This firmware version runs on the hardware version 4.1DL. It is derived from hw41_D53.c, but has the following differences:
  • The default EPC is ..D41..
  • This version includes some minor state management bugfixes.
  • This version includes active development work on slots, sessions, inventories, and handle checks. The code is incomplete and is turned off by default.

Here is some characterization data I collected on version 1.0 of hw41_D41.c. Basically, to validate the hardware I went through all the steps in the WISP validation suite for firmware.

My testing setup is below. With all the metal around, you can see that it is not an ideal RF environment.

validation-setup.jpg

This is a closeup of the WISP. In this picture, the solder joints for the WISP antenna are oriented away from the RFID antenna (and the photographer).

validation-setup-closeup.jpg


I collected performance data for hardcoded query-acks on both the old bjt modulators and the new cmos modulators. The 20 Hz, 10 Hz, and 5 Hz data were collected with Richa's LWNet application, using an AISpec duration of 200 ms. The cold start data was collected using the Impinj web app, since for some reason it worked at longer ranges than LWNet.

One thing I found was that there was variation in performance depending on whether the WISP was oriented with its antenna solder joints toward the reader antenna or away from the reader antenna. I collected data in both orientations. For the tests, I used hw41 WISP #1 (cmos modulator) and WISP #4 (bjt modulator).

WISP #1 (cmos) performance, antenna solder joints pointed toward reader antenna

20 hz
3' 6"
10 hz
5' 2"
5 hz
8' 6"
cold start
9' 2"

WISP #1 (cmos) performance, antenna solder joints pointed away from reader antenna

20 hz
3' 9"
10 hz
5' 6"
5 hz
8' 10"
cold start
9'

WISP #4 (bjt) performance, antenna solder joints pointed toward reader antenna

20 hz
3' 5"
10 hz
5' 7"
5 hz
6' 3"
cold start
7' 2"


WISP #4 (bjt) performance, antenna solder joints pointed away from reader antenna

20 hz
3' 10"
10 hz
7' 9"
5 hz
9' 2"
cold start
10' 6"

I was a little surprised at the relative lack of variability of results based on orientation on the cmos modulator device, as compared to the bjt device. So the next day I came back and retook the data for WISP #1, with the antenna joints pointed toward the reader. But I didn't see much difference between the results and what I got the day before:

WISP #1 (cmos) performance, antenna solder joints pointed toward reader antenna

20 hz
3' 7"
10 hz
4' 7"
5 hz
8' 7"
cold start
9'-10'
My cold start statistics bounced around a great deal. It mostly varied between 9' and 10'. I used LWNet for all but the cold start tests, and the web app for the cold start test.

Next, I looked at what kind of distance I could get doing a READ command for cmos and bjt modulator devices:

WISP
solder joint orientation
max. distance for READ command (ft)
#1 (cmos)
toward reader
4' 7"
#1 (cmos)
away from reader
4' 5"
#4 (bjt)
toward reader
3' 6"
#4 (bjt)
away from reader
3' 5"

Here, WISP #1 with the cmos modulator is the clear winner.

You'll notice that I haven't posted any test results using accelerometer data. I figured that the accelerometer is getting tested as a side effect of the work on the Saturn demo, so I punted on those tests.

Next, I moved to the stability tests.

I started out doing a full-power test, intending to allow it to run overnight. However, when I came back in the morning, the reader web app was hosed. I started the tests at 8AM and Alanson confirmed for me that the tests were still running at 7PM, so we know it ran for 11 hours. I'll take that as a "pass."

I did a torture test, with the reader antenna oriented so as to force the WISP to constantly pass from sleep to wake modes. It ran for more than 24 hours and the reader collected 2.9M packet. Here's a screen grab of the test in action:

Hw41_torture_test.jpg

Yellow are packets from the reader to the WISP, blue are packets from the WISP to the reader, purple is Vout, and the horizontal cursors mark the 2.0V level where the WISP transitions from sleep to wake mode.

r14 - hw41_D53.c

This firmware version is what was used to test the prototypes for hardware version 4.1DL. It was derived from hw40A_D51.c. To follow all the power wonkish details involved in the design and building of this prototype, see the power lab notebook page. This version is now deprecated.