Acceleration Sensing

1. Acceleration Sensing Dec 10, 2004 Zhong-Yi Jin William Chang

2. Introduction • Motivation: Motion Tracking • Hardwares • DPAC Airborne Wireless Node Module • Analog Devices 2D ±5g Accelerometer • 802.11b Wireless Access Point

3. Goals • Interface Accelerometer Sensor to the DPAC Module • Sample Sensor Data • Process Acceleration Data • Present Data

4. DPAC Preloaded Software 1: Establish TCP Connection 3way Handshaking DPAC Board Server Client 2: Send Request: Eg: “Read Port G0” 4: Send data back 3: Interpret Request, read data from G0 G0 G1 G2 G3 Accelerometer Problem: Crash if client try to send request at a rate more than 25HZ !!!

5. What Happened? • No source code for the Preloaded DPAC server. A black box. • Have to experiment and observer. • The faster we send request, the quicker the server will crash • If send request slowly, everything fine • We must have somehow saturated the server with too many requests. But 25 Hz is so slow!

6. Not efficient to send request for every read Old Approach New Approach DPAC Client DPAC Client • Needs allocate memory for incoming packets • Needs CPU time to unpack packet from each layer. • Needs CPU time to interpret the request.

7. Waste bandwidth by Not having enough data in one packet • Combine multiple samples into one packet • Will introduce latency • Nagle’s algorithm? Old Approach New Approach

8. Not Real time Old Approach New Approach Data (10bits) Data (10 bits) Time Stamp 16 bits 16 Bits • TCP and 802.11b is not real time by natural (interference • retransmission) • 2) Time stamp records the time right before the data is being read • from the accelerometer. • 3) Provides extra information for client to detect problems.

9. IPOS Startup Code • a. The FCFG register is updated so that code execution speed is optimized for the clock frequency. • b. The stack pointer is set to point to the end of the data memory. • c. start_filemedia_init() is called to initialize the filesystem if FILEMEDIA_SUPPORT is defined. • d. The .pram section is loaded from flash to the start of the program SRAM. • e. An area of program SRAM is set to zeros to accomodate the .pram_data section. • f. start_init_ip2kvm() is called to load ip2kvm external memory • g. The .data section is loaded from the flash to the start of the data memory. • h. An area of data memory is set to zeros after the .data section, to accomodate the .bss section. • i. The general purpose registers are initialized to zero. • j. The bootstrap code is complete and it jumps to system_main() which is a weak alias for a call to main() which is retained for backwards compatibility with versions prior to 5.0. • k. system_main will call the user's 'init()' and 'start()' routines prior to entering an inner system polling loop for which the user may registered to be polled.

10. //excerpt form iphal/src/ip2k/system.c { /* * System Loop */ except_try { while (TRUE) { watchdog_reset(); event_notify(system_event_poll, 0); } } except_catch(ex) { DEBUG_ASSERT(0, "unhandled exception"); system_reset(); } } IPOS Scheduler System Event Pool callback callback callback callback callback callback 1) A single program approach in core. 2) Hide the loop in the system_main

11. IPOS Timer System Event Pool Timer Event Pool callback Callback Expire 20 callback Call back Expire 10 Timer callback Call back Expire 5 callback callback System Clock = 5 callback

12. IPOS Interrupt • Interrupt handlers will always run to completion • Uses shadow registers for ISR context switch • => context switch time is fast and predictable • Can’t be used to implement foreground/background system since context switch from interrupt service routine to a task other than the one originally being interrupted would flush the shadow registers and thus the original task won’t be able to run again after the return of ISR

13. Events Callbacks(Descriptions) 1 SystemEvent telnet_app_connect/telnet_app_close (Listens For new connection or disconnection) 2 SystemEvent telnet_app_recv (Processes requests from existing connections, including requests for application level disconnection). Request will specify what data to read, at what frequency and how many data should be delivered at once in one TCP packet. Through out this report, the number of samples to put into one packet for delivery is called piggyback factor.) 3 OneShot Timer Event adcCallback (Reads data from specified IO at the specified frequencies. Piggyback multiple data into one packet.) 4 OneShot Timer Event adcCallback (Send packet with data as payload back to the client, at the specified frequency and piggyback factor) Implementation

14. Results 1) Sustained sampling rate of 1000 Hz (1000Hz + 20 Piggyback factor) is achieved. 3 Hours of test, no missing or out of order time stamp. 40 Times Better than DPAC 2) Returned Packet Rate = Sampling Frequency / Piggyback Factor Min Piggyback = 3 Max Returned Packet Rate = 1000/3 = 333 TCP Packet/ Second 3) Typical TCP packet has payload of 1460 bytes. Thus, we have Max theoretical Throughput Rate = 1460 * 333/Second = 486180 Bytes/Second = 3.7Mbits/Second

15. Client Application • DPAC Module Connection • Data Calibration • Data Processing • Compute Voltage • Compute Acceleration • Noise Reduction • Data Display

16. DPAC Module Connection • Using TCP/IP on 802.11b Wireless Protocol • Java.net.Socket on Static IP & Port 23 • Request Command: “o” vs. “w”

17. Data Processing • Data Format2 byte data (6 bits timestamp + 10 bits data) • Voltage ComputationV = (Data / 1022) x 2.5 • Acceleration Computationg = (V – V0) x 1000 / ratio • Noise Reductionaverage of samples

18. Data Calibration • 0g Calibration • ±1g Calibration • Conversion RatiosmV/g = (Vmax - V0) x 1000mV/g = (V0 - Vmin) x 1000

19. Application Implementation • Java Program • Thread 1: DPAC Interface • Connect to the DPAC Module • Calibrate Data • Process Data Stream • Thread 2: Display Using AWT Library

20. Demo

21. Q & A

22. Thank You