1. Krishna Chintalapudi, John Caffrey, Ramesh Govindan, Sami Masri
A Wireless Sensor Network for Structural Health Monitoring: Performance and Experience (Wisden)
Jeongyeup Paek
Krishna Chintalapudi, John Caffrey, Ramesh Govindan, Sami Masri

2. Overview Introduction Wisden Overview
Impact of Application Requirements on Design
System Performance and Characterization
Conclusion

3. Introduction Structural Health Monitoring (SHM)
Assess the integrity of structures.
Detection and localization of damages in structures.
Why wireless sensor network (WSN)?
Ease and flexibility of deployment
Low maintenance and deployment cost

4. Wisden
A wireless multi-hop sensor network based data acquisition system for structural health monitoring.
Reliable data delivery over multiple hops.
Time-synchronized data delivery from multiple sensor nodes.
Data compression at the source node to relieve bandwidth bottleneck.
Ease and flexibility of deployment.
“A Wireless Sensor Network for Structural Monitoring”, Ning Xu, Sumit Rangwala, Krishna Chintalapudi, Deepak Ganesan, Alan Broad, Ramesh Govindan, Deborah Estrin, In Proceedings of the ACM Conference on Embedded Networked Sensor Systems, Nov.2004

5. Wisden Overview (Software)
Reliability
Application layer NACK mechanism
Hybrid hop-by-hop and end-to-end loss recovery over self-configured multi-hop tree topology
Data Synchronization
Calculate residence time of a packet within each node.
Time-stamp data at the base station by estimating the generation time.
Data Compression
Lossy run-length encoding for silence suppression
Required to reduce data rate and relieve the bandwidth limitations of the motes

6. Wisden Overview (Hardware)
Mica2 or MicaZ mote
MDA400 Vibration card : 4-channel, 16-bit ADCs, 20kHz
Modified firmware to support continuous sampling.
Accelerometer : tri-axis (-2.5g ~ 2.5g)

7. What you’ve designed in the lab may not work in the real deployment…

8. Deployment and Re-design
Application Requirements
Wisden
Re-design
Initial Design
New Wisden
In-lab Experiments
Realistic Deployments
Hardware Limitations

9. Overview Introduction Wisden Overview
Impact of Application Requirements on Design
System Performance and Characterization
Conclusion

10. Application Requirements
Roadmap
Application Requirements
Platform Limitations
Fidelity of Data
Higher Sampling Rate
Onset Detector
System Engineering
Re-design of Wisden

11. High Damping Characteristics and Need for High Sampling Rates
Real structures are heavily damped.
Vibration is completely damped within 1 second.
Need more than Nyquist rate
50Hz is not enough although structure’s modal frequencies are ~20Hz.
Higher sampling rate required in highly damped structures.
Experimental data from our test structure: 50Hz Sampling

12. High Damping Characteristics and Need for High Sampling Rates (cont’)
How high?
‘10 times over sampling’
At least 200 Hz ~.
But, hardware artifacts limit the achievable sampling rates.

13. Transmission Rate Limits
Bandwidth ≠ real achievable data rate
The rate at which the Wisden application in a single node can send “data”, excluding any overheads.
Expected Packet Rate from nominal bandwidth
Achievable Packet Transmission Rate
Mica2
36.36 pkts/sec
22.17 pkts/sec
MicaZ
pkts/sec
pkts/sec

14. Transmission Rate Limits (cont’)
Number of nodes and the topology also affects the rate at which each node can transmit, due to contention. …
1/N
sink
In one-hop topology of 14 nodes:
Achievable Packet Rate
Achievable Sampling Rate
Estimation from ‘bandwidth’
Mica2
1.58 pkts/sec
28.50 Hz
46.74 Hz
MicaZ
10.95 pkts/sec Hz Hz
In one-hop topology of 14 nodes:
Achievable Packet Rate
Achievable Sampling Rate
Estimation from ‘bandwidth’
Mica2
0.82 pkts/sec
14.78 Hz
24.24 Hz
MicaZ
5.68 pkts/sec Hz Hz …
1/(2N-1)
sink
Achievable sampling rate without compression

15. Achievable Rate (details)
Wisden uses 69 and 66 byte packet for MicaZ and Mica2 respectively.
10 and 7 bytes for header, and 59 byte for the payload.
36 bytes/packet contain the vibration data.
Transmission time is calculated at the application layer
In TinyOS terminology, this is the time between ‘send()’ and ‘sendDone()’
In the worst-case high fan-out N-node topology, the achievable rate of each node is “max_rate/(2N-1)”

16. EEPROM Access Latency
Wisden uses EEPROM to store packets to ensure reliable delivery of samples.
EEPROM read/write takes time, and this directly limits the packet processing rate
Bus conflict between the vibration card and EEPROM made it worse.

17. EEPROM Access Latency (cont’)
Sampling rate is limited by EEPROM access latency.
And this cannot be relieved by compression.
“We can go around the transmission rate limitation by compression (iff the duty cycle of seismic activity is low enough). We can just send it later”
“But if we cannot store it in the EEPROM at any time, we can never guarantee the delivery”
Packet generation rate limit
Limits on sampling rate
Worst Case
9.03pkts/s
162.5Hz

18. Sampling Rate Limits (Summary)
Limit due to transmission rate
Depends on number of nodes and topology.
In the worst case topology of 14 nodes, we can only inject 5.6 pkts/sec. Without compression, this can only achieve 100Hz. (MicaZ)
Can be relieved by compression.
Limit due to EEPROM access latency
Independent of number of nodes or topology.
But cannot be relieved by compression.
In the worst case, we can safely achieve around 160Hz only.
Wisden Re-design
With careful design of buffering and compression, we were able to achieve 200Hz.

19. Application Requirements
Roadmap
Application Requirements
Platform Limitations
Fidelity of Data
Higher Sampling Rate
Onset Detector
System Engineering
Re-design of Wisden

20. Need for Re-designing Wisden Compression Scheme
Original Wisden compression scheme
Allow for variation in noise, and suppress quiescent period.
low frequency modes are often clipped !!

21. Need for Re-designing Wisden Compression Scheme (cont’)
Also, low-energy / faster decaying high frequency modes are eliminated.
 Need to re-design the compression scheme.

22. Onset Detector Motivation Onset Detection
To preserve the fidelity of the structure’s frequency response.
Onset Detection
Track noise mean, noise stdev, and signal envelope.
If the signal envelope jumps out of the expected noise variation range, onset is detected.

23. Onset Detector (cont’)
Data Compression with Onset Detector
Detect the start and the end of significant event.
Transmit data without compression during this period.
Deployment experience
Mathematically predicted parameter didn’t work well.
Noise characteristics are not Gaussian!

24. Overview Introduction Wisden Overview
Impact of Application Requirements on Design
System Performance and Characterization
Conclusion

25. Seismic Test Structure
Full-scale realistic imitation of a 28’ X 48’ hospital ceiling
Instrumented with drop ceiling, electric lights, fire sprinklers, and water pipes carrying water.

26. Deployment Setup 14 MicaZ node network
2~4 hop: multi-hop network
200Hz, single-axis sampling
5 minute experiment with 40 seconds of forced vibration

27. Data validation

28. Onset Detector Performance

29. System Evaluation Achieved 100% delivery
With 9.5% of the packets being retransmitted

30. Latency Calculation 1/R Packet Generation: R Packet Transmission: r

31. Comparison of deployments on Mica2 and MicaZ platforms
Setup
7 Mica2 node, and 7-MicaZ node Wisden network co-located.
100 Hz, dual-axis sampling.
Data collected simultaneously.

32. Results: Mica2 and MicaZ Comparison
MicaZ outperforms Mica2
Not surprising!!
Mica2 had 7 times larger average latency.
Better link quality. (97.8% vs. 93.4%)
Less retransmissions. (3.5% vs. 7.2%)

33. Conclusion and Future Work
Wisden
Data acquisition system for Structural Health Monitoring.
Re-designed through the experiences learned from the series of realistic deployments and experiments.
Delivers time synchronized vibration data reliably at a sampling frequency of 200Hz across multiple hops.
Future Work
Wisden on hierarchical network for scalability
Wisden software (ver-0.2) is available at

34. Thank you