UNIVERSITY OF CINCINNATI
Date:__February 4, 2005__
I, _____________________Daniel Alford_______________________,
hereby submit this work as part of the requirements for the degree of:
Master of Science
in:
Mechanical Engineering
It is entitled:
Lightweight, Low Cost, Automotive
Data Acquisition and Telemetry System
This work and its defense approved by:
Chair:
_Dr. Randall Allemang________
_Dr. David Brown_____________
_Dr. Allyn Phillips__________
Lightweight, Low Cost, Automotive
Data Acquisition and Telemetry System
A Thesis Submitted to:
Division of Research and Advanced Studies
Of The University of Cincinnati
In Partial Fulfillment of the
Requirements for the Degree of:
MASTER OF SCIENCE
In the Department of Mechanical, Industrial, and Nuclear Engineering
Of the College of Engineering
2005
By:
Daniel Alford
B.S., University of Cincinnati, 2002
Committee Chair:
Committee:
Dr. Randall Allemang
Dr. David Brown
Dr. Allyn Phillips
Abstract
Dynamically, testing small, lightweight automobiles can be very difficult on a limited
budget. Several quality data acquisition systems exist that are designed for automotive
applications, but most are large cumbersome units that require an AC power inverter. It
would not be possible to use one of these systems on a small lightweight vehicle, like a
Formula SAE racecar. A device powered from a 12 volt DC power supply is required for
this type of application. Also, typical data acquisition systems are far too bulky and
costly to be fitted to a Formula SAE vehicle. As with any system, recording actual
operating conditions will provide useful information, leading to system improvements.
In order to achieve these goals, several data acquisition with telemetry systems were
investigated.
The most interesting system, Dataq DI-720-EN and Linksys wireless
router, were purchased and characterized through a barrage of testing. The system was
first characterized by logging a random signal and transferring the data through a typical
wired setup. The system was then methodically tested in the lab with Ethernet wired and
wireless data transfer methods. The data acquisition and telemetry system was also tested
dynamically, on the 2004 Bearcat Motorsports FSAE vehicle, using wireless data transfer
methods. The testing results were promising, with minimal signs of poor data. Some
gaps were seen in the data, but were deemed insignificant for the majority of potential
testing. Lastly, several likely improvements are discussed.
Acknowledgements
I would like to thank everyone that has been involved in the development of this thesis.
To my committee members Dr. Randall Allemang, Dr. David Brown, and Dr. Allyn
Phillips, I thank you all for your support, because without it this research would not have
been completed.
I want to especially thank my advisor, Dr. Randall Allemang, for his countless hours of
discussion and guidance at nearly any hour of the day. The teaching assistant position for
Automotive Design I, II, and III not only paid the bills, but has also enhanced my
engineering and leadership skills just as much if not more than all of my years in the
undergraduate mechanical engineering program at the University of Cincinnati. I am
amazed by your ability to find support for student projects and research interests.
I want to thank PCB Piezotronics for their donation of six single axis capacitive
accelerometers. Thanks to Todd Dahling and Brian Lewis of Manta Corporation for
loaning the SoMat and Freewave equipment. To all of the students and staff of the
SDRL, I want to wish the best of luck, you made the days more enjoyable and there was
never a dull moment. Thanks to all my friends and family for all the motivation to
complete this research. I should also thank the Bearcat Motorsports teams of 2003, 2004,
and 2005 for the use of their race car for testing.
Thank you all.
Oh, and thanks B.J. Stoney and Bill Wise for manufacturing those parts.
Table of Contents
Table of Contents................................................................................................................. i
List of Figures .................................................................................................................... iii
List of Tables ...................................................................................................................... v
List of Tables ...................................................................................................................... v
Chapter 1 Introduction ........................................................................................................ 1
1.1 - Introduction ............................................................................................................ 1
Chapter 2 Background ........................................................................................................ 6
2.1 - Telemetry Systems ................................................................................................. 6
2.2 - Data Acquisition Systems....................................................................................... 7
2.2.1 - Larson Davis DSS ........................................................................................... 8
2.2.2 - National Instruments Compact RIO .............................................................. 10
2.2.3 - Motec ADL.................................................................................................... 13
2.2.4 - Pi Research Delta System.............................................................................. 14
2.2.5 - DaTaq DI-720-EN ......................................................................................... 15
2.3 - Data Acquisition Theory ...................................................................................... 26
2.3.1 - Sampling Theory ........................................................................................... 26
2.3.2 - Aliasing.......................................................................................................... 27
Chapter 3 Applications ..................................................................................................... 29
3.1 - Lab Testing ........................................................................................................... 29
3.1.1 - Parallel Port: .................................................................................................. 30
3.1.2 - Local Area Network: ..................................................................................... 34
3.1.3 - Wireless Local Area Network: ...................................................................... 41
3.1.4 - Wireless LAN w/Parabolic Antenna ............................................................. 44
3.2 - Onsite Testing....................................................................................................... 46
3.2.1 - Static Testing ................................................................................................. 47
3.2.2 - Dynamic Testing............................................................................................ 56
Chapter 4 Conclusions & Future Work ............................................................................ 59
References......................................................................................................................... 63
Appendix - A
Instrumentation ..................................................................................... 66
Appendix - B
Matlab Script......................................................................................... 71
B.1
CSV Converter.................................................................................................. 71
B.2
Main Executable ............................................................................................... 73
B.3
Windows ........................................................................................................... 79
B.4
Load Data.......................................................................................................... 81
B.5
Cyclic Averaging .............................................................................................. 83
B.6
Overlapping....................................................................................................... 86
B.7
Autopower......................................................................................................... 88
B.8
Crosspower ....................................................................................................... 89
B.9
H1...................................................................................................................... 92
B.10 Hv...................................................................................................................... 93
B.11 H2...................................................................................................................... 94
B.12 Multiple Coherence for H1 ............................................................................... 95
B.13 Multiple Coherence for Hv ............................................................................... 95
i
B.14
B.15
Plot Output ........................................................................................................ 96
Plot Output 2 ..................................................................................................... 99
ii
List of Figures
Figure 1.1 Basic System ..................................................................................................... 4
Figure 2.1 Channel Selection............................................................................................ 16
Figure 2.2 Max Sample Rate Selection............................................................................. 17
Figure 2.3 Sample Rate Selection..................................................................................... 17
Figure 2.4 Channel Settings Selection .............................................................................. 19
Figure 2.5 Sine Wave on +-10V Scale ............................................................................. 20
Figure 2.6 Sine Wave on +-5V Scale ............................................................................... 21
Figure 2.7 Fixed Calibration ............................................................................................. 22
Figure 2.8 Low Calibration............................................................................................... 22
Figure 2.9 High Calibration .............................................................................................. 23
Figure 2.10 Sine Wave Phase Shift................................................................................... 24
Figure 2.11 Parallel Sampling Example ........................................................................... 25
Figure 2.12 Multiplexed Sampling (Equal Sampling & Scan Rates) ............................... 25
Figure 2.13 Multiplexed Sampling (Non-equal Sampling & Scan Rates)........................ 26
Figure 2.14 Sampling Relationships ................................................................................. 27
Figure 2.15 Aliasing Example .......................................................................................... 27
Figure 2.16 Aliasing Contribution .................................................................................... 28
Figure 3.1 Parallel Port Testing Block Diagram............................................................... 30
Figure 3.2 Parallel Port Frequency Response Functions .................................................. 33
Figure 3.3 Typical Coherence........................................................................................... 33
Figure 3.4 Parallel Port Random Time History ................................................................ 34
Figure 3.5 Wired Ethernet Block Diagram ....................................................................... 34
Figure 3.6 LAN Frequency Response Functions.............................................................. 36
Figure 3.7 LAN Sine Wave Time History ........................................................................ 38
Figure 3.8 LAN Sine Wave Close Up .............................................................................. 39
Figure 3.9 Bellcrank Rotation........................................................................................... 40
Figure 3.10 Basic Wireless System Block Diagram......................................................... 41
Figure 3.11 WLAN Frequency Response Functions ........................................................ 42
Figure 3.12 WLAN Sine Wave Time History .................................................................. 43
Figure 3.13 Parabolic Testing Block Diagram ................................................................. 44
Figure 3.14 Parabolic Frequency Response Functions ..................................................... 45
Figure 3.15 Parabolic Sine Wave Time History ............................................................... 46
Figure 3.16 Vehicle Testing Block Diagram .................................................................... 46
Figure 3.17 Center Hill FRFs............................................................................................ 48
Figure 3.18 Center Hill Coherence ................................................................................... 49
Figure 3.19 Bad Channels FRFs ....................................................................................... 50
Figure 3.20 Bad Channels Coherence............................................................................... 51
Figure 3.21 Bad Channels................................................................................................. 52
Figure 3.22 Throttle Position (Engine Off)....................................................................... 53
Figure 3.23 Throttle Position (Engine On) ....................................................................... 53
Figure 3.24 Typical Acceleration ..................................................................................... 54
Figure 3.25 Isolated Accelerometer Acceleration ............................................................ 55
Figure 3.26 Isolated Accelerometer.................................................................................. 55
Figure 3.27 Bad Channel FRF .......................................................................................... 57
Figure 3.28 Bad Channel Time History............................................................................ 57
iii
Figure 3.29 Dynamic Frequency Response Functions ..................................................... 58
Figure A.1 Wiring Diagram.............................................................................................. 67
Figure A.2 Damper Position ............................................................................................. 69
Figure A.3 Lateral Accelerometer .................................................................................... 70
Figure A.4 Accelerometers ............................................................................................... 71
iv
List of Tables
Table 2.1 Performance Information of DSS DSIT ............................................................. 9
Table 2.2 Performance Information for RIO I/O Modules ............................................... 12
Table 2.3 Delta Systems ................................................................................................... 14
Table 2.4 Data Acquisition Device Comparison .............................................................. 15
Table 2.5 Channel Comparison......................................................................................... 15
Table 2.6 IOS Example Parameters .................................................................................. 19
Table 2.7 Resolution Increases with applied Gain............................................................ 21
Table 3.1 Vehicle Sensors................................................................................................. 29
Table 3.2 Lab Test Setups................................................................................................. 30
Table 3.3 Data Transfer Throughput ................................................................................ 31
Table 3.4 Random & Sine Logging Parameters ............................................................... 35
Table 3.5 Vehicle Logging Parameters............................................................................. 35
Table 3.6 MTS Test File Information ............................................................................... 39
Table 3.7 Onsite Test Setups ............................................................................................ 47
Table 3.8 Center Hill Logging Parameters ....................................................................... 49
Table A.1 Suggested Sampling Frequency....................................................................... 68
v
Chapter 1 Introduction
1.1 - Introduction
Over the history of motor racing, racers have been looking for the elusive perfect vehicle. In
reality a perfect vehicle does not exist, at least not for a reasonably difficult course with varying
weather conditions. To be competitive, a team needs to know what their vehicle will be doing on
track. In the early days of racing, the only feedback race engineers had, was what they could see
and what the driver could see, feel, and hear. This “seat of the pants” data logging was really the
only solution to perfecting a race car at the time, computers were unheard of. Once computers
were invented, they were still too heavy and bulky to use on a race car, so the seat of the pants
method was still utilized.
The major concerns when selecting a data acquisition device are size, cost, expandability, and
capability. Some data acquisition devices are now small, lightweight, and almost affordable, so
data logging has become the preferred solution to finding the perfect vehicle, because a data
logger does not lie, or miss anything, like a driver might. While a data logger is a great
improvement from the seat of the pants method, it can still be improved. Data acquisition is not
all benefit, it has drawbacks too. Some of the drawbacks are price, weight, and memory. Weight
is less of an issue when it comes to a racing series that has a minimum weight rule, but in
Formula SAE there is no such rule, so every pound counts. Cost of a data acquisition system can
be very overwhelming. Some systems cost well above $100,000, sensors included, well beyond
the budget of most racers.
Another downfall of a data logger is that the data has to be
downloaded after the race and then processed. This means no change can be made during a pit
stop to improve the vehicle’s performance and win the race; but it can produce an abundance of
1
information that the team could use to prepare a better vehicle in the future. The typical racecar
data acquisition system contains an analog to digital converter for each channel of data to be
collected and some form of memory. The memory, where all of the digitized signals are stored
for later analysis, can be very pricey. To reduce the cost of memory, the amount of data taken
could be reduced, by recording fewer channels or lowering the sampling frequency. Either could
lead to many headaches for the race engineer; there may be something important happening that
was not observed, which would lead to a large amount of wasted time searching for a problem
that cannot be seen.
Telemetry is the transfer of data from the data acquisition system to another data analysis system
in real time and wirelessly. If the race engineer could use telemetry to analyze the vehicle data
as it comes in, the engineer could deduce improvements for the vehicle-driver system. When the
vehicle comes in for a pit stop the team can make modifications based on the data the engineer
analyzed from the last track stint. The current method in racing is the use of a dual band UHF
radio frequency to telemeter data. Another popular option is to log the data, and then transfer the
data once a lap. Telemetry is currently too costly for widespread use outside of the top levels of
professional motorsports. This thesis will explore the possibility of using a new technology,
wireless local area networks (Wireless LAN or WLAN) as a means of transferring data at a much
lower cost. Wireless local area networks are not that different from the dual band UHF radios
currently used. Their benefit is the lower cost structure, and the drawback is the reduced range.
Looking back 50 years, it seems quite obvious on where the biggest advantage to be gained was;
and 50 years from now it will be quite obvious where the biggest improvement will be. But as of
right now, racecar engineers are spending enormous amounts of time and money trying to find
2
the smallest advantage. The top teams in Formula 1 (F1) are spending in the range of $700
million a year to find any advantage they can. While the F1 teams may not be too concerned
with a budget, at least not a normal sized budget, club racers, who are into racing only for the
thrill, are concerned with how every penny is spent, because they are on a tight budget of their
own hard earned money. The wireless local area network technology is not currently expected to
work at a range large enough to encompass a typical racetrack, but it could be of use at a vehicle
dynamics testing area, or a parking lot used for testing. Although the range is currently limited,
the wireless local area networking technology is rapidly changing and may produce a
technological advance capable of significantly increasing the range. This technology could also
be very useful to the SCCA Solo2 racers, as their autocrosses typically run in open parking lots.
Where club racers may spend $10,000-20,000 a year, autocrossers are more concerned with their
budget; they will probably only spend around $2,000 a year. Figure 1.1 depicts the basic
concept, utilized to approach this lightweight, low cost, automotive data acquisition and
telemetry system. A data acquisition and telemetry system of this type would be in the $2,000
range where a professional motorsports data acquisition and telemetry system is 5-10 times that.
3
Wireless Game
Adapter
Sensors
Data Acquisition
Device
Wireless Router
Wireless Link
Figure 1.1 Basic System
A Linksys wireless router, Linksys game adapter, Cisco access point with parabolic antenna, and
Dataq DI-720-EN were chosen to be characterized by the testing for this document, for their low
cost, small size and ability to be powered by a 12 volt DC power supply. The IEEE has created
standards utilized by several manufacturers to create wireless networking devices. The 802.11b
at 11 Mbps and 802.11g at 54 Mbps standards operate on a 2.4 GHz frequency band, and differ
only by their throughput capability. Another standard, 802.11a operates in a 5 GHz frequency
band and has capacity similar to the 802.11g standard, but had a decreased range due to its
higher operating frequency. At the time of procurement, there were no game adapters available
operating in the 802.11a and g wireless standards, therefore the 802.11b standard was chosen for
testing. The Cisco access point, also working in the 802.11b standard, and parabolic antenna
were borrowed from the UCIT department, to test for the additional range expected by using a
parabolic antenna. The Dataq unit was the chosen data acquisition device, because of its
Ethernet output, low cost, small size, and ability to be powered by the 12 volt DC power supply
4
available on the test vehicle. The Dataq unit is a multiplexed system, which means that the
multiple data channels are not being digitized simultaneously.
5
Chapter 2 Background
2.1 - Telemetry Systems
Historically, telemetry used an analog frequency modulation, normally operating in the FM radio
broadcast band, to transfer data from one sensor to the data logger. That meant if ten sensors
needed to be logged, ten distinctive FM radio frequencies were required to transmit the data.
These systems have many disadvantages including interference from FM radio stations, and
frequency shift issues. The FM broadcast band is fairly populated, so finding a frequency band
large enough to transfer large amounts of data has become nearly impossible. Frequency drift
issues arise when the transmitter is located in a thermally active area, imposing another
limitation.
There are some more complex ways around the drawbacks of FM telemetry, FM-FM and PWMFM. FM-FM modulation performs a frequency modulation of the signal on a low frequency
carrier, and then on the radio carrier frequency. This works well for near DC signals, but when
rapidly changing sensor signals, high bandwidth signals, are being observed, FM-FM telemetry
is much less useful. “Pulse width modulation-FM first modulates samples of the signal as the
time duration of short pulses, and then frequency-modulates the pulses.”[19]
The main
drawback is that when the signal to noise ratio of the recovered signal becomes low, the receiver
cannot determine the precise frequency.
6
2.2 - Data Acquisition Systems
Typically in motorsports and automotive testing several different types of data are recorded.
They may range from various temperatures, pressures, positions, accelerations, and many more.
These data types create an additional problem, knowing how to record them. Many vehicle
signals are nearly DC, therefore very low frequency, while others are very active, changing
several hundred thousand times a second, and some are on or off (digital). The ideal system
would allow the user to set each channel’s sample rate, gain, and calibration individually. Many
temperatures are slow to change, therefore a low sampling frequency (1-2 Hz) would be desired
to reduce the amount of memory need, and eliminate extraneous information. Brake rotor
temperatures may need to be sampled more frequently than other temperatures, due to their quick
changes during braking, but it is unlikely to reach more than 10 Hz. Probably, the most extreme
case for the need to sample at high frequency would be to record cylinder pressure. For a
motorcycle engine the speeds can reach above 15,000 rpm, and attempting to capture the
pressure change of the explosion of fuel and air requires a sampling frequency in the 100,000 Hz
range. It is highly unlikely cylinder pressures would ever be recorded on a vehicle, as this is
much more common during engine dynamometer tuning. A multiplexed data acquisition system
would not be recommended for measuring multiple cylinder pressures, as in this case it is
important to know the relative time difference between peak cylinder pressures, and a
multiplexed unit will not provide an accurate estimate. Much more reasonable high frequency
signals likely to be measured on a vehicle are the damper positions, and strain gauges placed on
particular parts. Strain gauges and damper positions are typically sampled at 500 Hz. A
sampling frequency of 500 Hz and vehicle moving at 30 mph, results in traveled distance of
about 1 inch between data points. Many motorsports data acquisition devices contain inputs
7
specifically for rpm measurements, which contain signal conditioning that converts the rpm
sensor’s output to a recordable signal. Digital inputs are also quite common in data acquisition
systems, and are used to record on/off situations. Digital inputs are typically used to signify fan
and button/switch usage. Another requirement for a lightweight, low cost, automotive data
acquisition and telemetry system is the ability to be powered by a 12 volt DC power source.
Several data acquisition systems exist that will fit in the back seat of a typical automobile, and
can be plugged into a power inverter, but these systems are far too large, bulky, and heavy to be
used on a racecar, let alone a Formula SAE racecar.
There are several hundred, maybe thousand, data acquisition systems available commercially.
The difficulty lies in finding a suitable low cost solution that provides room for future expansion.
The comparison discussion for this thesis will be limited to five systems, two popular
motorsports data acquisition systems, two lab systems, and the chosen Dataq DI-720-EN. The
Motec ADL and Pi Research Delta systems are the motorsports specific systems, while the
Larson Davis DSS and National Instruments Compact RIO are oriented more towards the lab
testing environment.
2.2.1 - Larson Davis DSS
The Larson Davis Digital Sensing System (DSS) is typically used to record structural dynamics,
sound pressure, and vehicle/engine noise. The DSS consists of a Master Module with either a
parallel or Ethernet port for communicating with a personal computer; it also stores the digitized
data. The Ethernet port allows this system to be used with the same 802.11 wireless networking
technology explored throughout this thesis. The 8 slots of the DSS can be filled with any
combination of receiver, source, and/or data acquisition modules. A DSS full of data acquisition
8
modules is capable of logging 64 channels. The DSS utilizes a new technology, Digital Sensor
Interface Transmitters (DSIT), to reduce the cost of expensive low noise cabling by locating a 24
bit ADC near the sensor. A 24 bit ADC could provide a significant advantage over lower bit
units, as a higher number of bits increases the available dynamic range and provides less need to
fill the entire dynamic range. The DSIT digitizes the signals and sends the digitzed data to the
receiver card in the mainframe through inexpensive ribbon cabling. The DSITs are capable of
sampling all channels simultaneously at sampling frequencies up to 61 kHz. One, two, or three
sensor DSITs are available with direct voltage inputs. Many sensors require an ICP power
source and some DSITs are capable of providing ICP power. Another useful feature was the
ability to read the Transducer Electronic Data Sheets (TEDS) data on the sensor. In today’s
world of high channel data acquisition systems, it becomes cumbersome and tedious to keep a
good record of test setups. TEDS sensors attempt to alleviate this record keeping problem by
storing sensor specific information in the sensor. This information ranges from the standard
information like serial number, model number, and calibration sensitivity to user defined fields.
Table 2.1 describes the performance characteristics of the available DSITs. For
Table 2.1 Performance Information of DSS DSIT
9
2.2.2 - National Instruments Compact RIO
The National Instruments company produces several types of data acquisition devices, from PC
card based applications to the mainframe and card systems. The system of particular interest in
this application was the Compact RIO. One of the most interesting features of the Compact RIO
was its size, only 3.5 by 3.5 by 10.75 inches for the premium system. The Compact RIO is
developed around the RIO (Reconfigurable Input Output) FPGA (Field Programmable Gate
Array) technology. The Compact RIO has a similar architecture as the Larson Davis DSS. They
both contain a chassis integrated, real time processor with bays for input-output modules. The
Compact RIO can operate as a control system as well as operating as a data acquisition device.
The Compact RIO system utilizes National Instruments graphical programming software,
LabVIEW, to control the input-output modules. This means that the user must write a program
using LabVIEW to control the input-output modules. The real time processor, the brains behind
the Compact RIO, controls the I/O modules independently which allows the I/O modules to
operate in parallel. The real time controller also contains the communication ports, serial and
Ethernet, again enabling the Compact RIO to be used with 802.11 wireless networking
technology. The Compact RIO allows the user to define the measurement hardware circuitry
using FPGA chips and LabView. The field programmable gate arrays are the major contributors
to the Compact Rio’s low cost, reconfigurability, and high performance features. National
Instruments has developed several modules to be used with the Compact RIO. Analog input
modules are available for small (+-80 mV), medium (+-10 V), and large (+-60 V) voltage inputs,
as well as thermocouples and a +-5 volt module with simultaneous sampling, antialias filtering,
10
and TEDS capability. Table 2.2 lists all of the input-output modules available for the Compact
RIO and their features.
11
Table 2.2 Performance Information for RIO I/O Modules
12
2.2.3 - Motec ADL
The Advanced Dash Logger (ADL) from Motec is one of the most popular motorsports data
acquisition devices. It combines a data acquisition device with a dash that can be used to display
vehicle information to the driver.
The dash display is configurable, allowing the user to
determine what information is important for the driver. It can be used to replace many if not all
of the gauges found on a typical race car dash. The tachometer has 70 segments that can be set
up to a maximum of 19,000 rpm, and the shift point can also be programmed such that the
redline is dependent upon gear selection. The current gear is also displayed. The dash has 3 user
definable numeric displays and 1 alpha numeric display; which can be used to display any of the
200+ ECU (Engine Control Unit) or ADL channels available.
The standard Motec ADL comes with 6 (12 bit ADC) analog voltage inputs, 4 analog
temperature inputs, 2 speed inputs, 2 digital inputs, 4 switch inputs, and 4 auxiliary outputs for a
total of 22 I/O (input-output) channels. For an additional cost it can be expanded to 50 I/O
channels as follows, 20 analog voltage inputs, 8 analog temperature inputs, 4 speed inputs, 4
digital inputs, 4 switch inputs, 2 low voltage analog inputs, and 8 auxiliary outputs. The analog
inputs have a signal input range of 0-15 volts. The ADL is capable of sampling 8 channels at
1000 Hz, and the rest at 500 Hz, with the exception of the ECU channels which can be sampled
at a maximum of 20 Hz. The standard system comes with 384 kilobytes of memory for digitized
signal storage and can be upgraded to 8 megabytes. All of the systems allow 40 channels from a
Motec ECU to be input through an RS232 connection. Obviously, 50 ADL channels plus 40
ECU channels does not match the 200+ channels previously mentioned. The additional Motec
ADL channels are derived from any combination of the 90 ADL and ECU channels. These math
13
channels provide additional flexibility to the ADL. The base system has a cost of about $4600,
while the 50 I/O system sells for about $6500; Motec also sells a 30 I/O system for about $5100.
The memory expansions also add significant cost to the system, ranging from $900 to $1875 for
1 to 8 Mb respectively. Telemetry, which enables the user to view real time data, is an additional
cost of $5300 for the radios and $1100 to enable this option in the ADL. The total cost of a
system with telemetry could range from $11,000 to almost $15,000.
2.2.4 - Pi Research Delta System
Pi Research is one of the most respected data logging companies in motorsports. They sell a
variety of systems from their entry level System 1 to their top of the line Sigma Elite system.
The System 1 contains 6 analog inputs, wheel speed, rpm, lap time and lateral acceleration. The
System 1 provides a good start into race car data acquisition, but it does not provide enough
flexibility to be appropriately compared with the previously mentioned systems. The Sigma
Elite comes standard with 40 analog channels and 8 digital channels with 128 Mb of memory; it
can be expanded to 64 analog channels and 12 digital channels. This system was eliminated
from discussion due to its complexity and expected cost. It is typically only used in the highest
levels of professional motorsports. The Delta and Delta Lite systems are very similar. They
only differ in expandability, storage memory and telemetry, seen in Table 2.3.
Expandable
Telemetry
Memory (Mb)
Delta Lite
No
No
2
Delta
Yes
Yes
8
Table 2.3 Delta Systems
The basic Delta system contains 10 analog inputs, 2 wheel speeds, lap time, rpm, 2 accelerations,
and ECU signals. The system can be expanded to provide an additional 24 analog inputs and 2
wheel speeds. For additional costs, the Delta system can be attached to a dash and/or a telemetry
14
system. The radios for the telemetry option, operate in the 450-470 MHz frequency range, and
require an appropriate license from the FCC. The Delta system is capable of logging 0-5 volt
signals at sampling rates up to 500 Hz. Table 2.4 provides a general system comparison of the
five devices, while Table 2.5 details the quantity of the different type of channels.
Channel
Count
64
64
Max Sampling
Frequency (Hz)
61,000
800,000
Size
(in X in X in)
6 X 9.25 X 14.5
3.5 X 3.5 X 10.75
Type
Price
DSS
Compact RIO
ADC
(bits)
24
12-24
Simultaneous
Both
Motec ADL
12
22-50
1,000
1.5 X 3.5 X 7
Simultaneous
Pi Delta
Dataq
10
16
42
44
500
250,000
1.5 X 4 X 4
1.5 X 7 X 9
Unknown
Multiplexed
Unknown
~$6,000
$4,600$6,500
Unknown
$1,500
Device
Table 2.4 Data Acquisition Device Comparison
Device
DSS
Compact
RIO
Motec ADL
Pi Delta
Dataq
Analog
Input
0-64
Temperature
Input
0
Digital
Input
0
ECU
Input
0
Speed
Input
0
Auxilary
Outputs
0-32
0-64
0-32
0-64
0
0-64
0-64
6-20
10-34
32
4-8
0
0
4-8
0
8
40
Unknown
0
2-4
2-4
0
4-8
0
4
Table 2.5 Channel Comparison
2.2.5 - DaTaq DI-720-EN
The data acquisition device chosen was the DI-720-EN, from Dataq. The Dataq device was
chosen for its low price tag, number of channels, and because it can use the Ethernet to transfer
data. The cost of the device and the software was about $2500. The DI-720-EN can transfer
data from the real time controller to the logging computers hard disc by a parallel cable or, it can
be set up as a network device and the data can be transferred over a local area network. This
Ethernet data transfer method made it particularly interesting, because of the possibilities of
coupling the Dataq device with existing 802.11 wireless networking technologies. The DI-720EN only records voltage signals, so some sensors will not work directly with the DI-720-EN.
15
Two such examples are thermocouples and strain gauges, these sensors will require signal
conditioning. The DI-720-EN contains 32 single-ended or 16 differential channels as well as 8
digital inputs and 4 digital outputs. A differential channel is a channel that has a positive signal,
and a negative signal; these signals are then referenced against each other. A differential channel
should only need to be used when a potential exists between the ground for the data acquisition
device and the ground for the sensor. Figure 2.1 shows the channel selection window.1
Figure 2.1 Channel Selection
WINDAQ/Pro was the version of Dataq’s software used throughout the testing for this paper,
which allows for a maximum sample rate of 250 kHz. The Dataq system utilizes multiplexed
data acquisition which means that the maximum sampling frequency must be divided
1
To setup channels follow the path and directions at the bottom of the window: EditÆ Channels
16
(multiplexed across) each channel. The maximum sample rate is the rate at which the analog to
digital converter (ADC) digitizes the signal. The rate at which each channel is being digitized is
the maximum sample rate divided by the number of channels enabled. The maximum sample
rate is often referred to as the scan rate in a multiplexed system, Figure 2.22.
Figure 2.2 Max Sample Rate Selection
The maximum sample rate should not be confused with the sample rate; an example will be
presented after the discussion of Dataq’s intelligent over sampling (IOS) feature. The sample
rate is the frequency that the software displays and records the digitized signal. It should be
noted that this sample rate is the total sample rate or throughput rate. For example, if sixteen
channels were enabled and the sample rate was set to 16,000 samples per second then each
channel would contain 1000 data points per second recorded or the analog signal of each channel
would be digitized every 1 thousandth of a second. Figure 2.3 shows the sample rate window3.
Figure 2.3 Sample Rate Selection
2
3
Set the maximum sample rate by following this path: Edit Æ PreferencesÆ Max Sample Rate or Ctl+F3
Setup can be performed by following this path: EditÆ Sample Rate or F3
17
The DI-720-EN is equipped with a feature, Dataq calls intelligent over sampling. Intelligent
over sampling is a feature of the DI-720-EN that allows the data that was digitized between
sample points to be used. When the sample rate and the maximum sample rate are not set equal,
the analog to digital converter will digitize the signal at the maximum sample rate divided by the
number of enabled channels; then the processor will down sample digitized data to the user
defined sample rate divided by the number of enabled channels. There are several processes that
can be used while down sampling: average, last point, maximum, minimum, root mean square,
and frequency. The average acquisition method will sum the value of all of the points between
the sample rate points and scale it by the number of points; while the last point method will only
retain the last point. Logically, the maximum and minimum methods will retain the maximum or
minimum value. The RMS acquisition method will take a root mean square average of the
points. Figure 2.4 shows the window used to select the acquisition method and gain level.4
4
To setup the acquisition method and/or gain follow this path: EditÆ Channel Settings
18
Figure 2.4 Channel Settings Selection
As mentioned earlier, an example will be discussed to further clarify the intelligent over
sampling topic, the parameters of which are shown below in Table 2.6.
Maximum Sample Rate
Channels
Sample Rate
50000
2
100
IOS Method
Last Point
Table 2.6 IOS Example Parameters
A signal sent into each of the two channels will be digitized by the ADC at a rate of 25,000 times
per second. The software will then be set to sample at 100 Hz, which means the hardware
created 500 times more data points than required. With the last point method this means every
500th point will be recorded to the logging computer’s hard disk.
19
The DI-720-EN allows each channel to have a gain applied to it. Applying a gain to a sensor
signal is useful to maximize the amount of the dynamic range being used. For example, a sine
wave characterized by the equation below, which would look like Figure 2.5, when recorded on a
+-10 volt scale.
y = sin( x) + 2
(2.1)
Sine Wave on +-10V Scale
10
8
6
4
Amplitude
2
0
-2
-4
-6
-8
-10
0
1
2
3
4
5
Time
6
7
8
9
10
Figure 2.5 Sine Wave on +-10V Scale
But, if the same signal was gained so that the dynamic range was +-5 volts, it would appear as
Figure 2.6 shows. A quick comparison of the two figures shows that the amplitude of the sine
wave was much more defined in Figure 2.6, therefore more of the dynamic range is being used
and the resolution of the signal is better.
20
Sine Wave on +-5V Scale
5
4
3
2
Amplitude
1
0
-1
-2
-3
-4
-5
0
1
2
3
4
5
Time
6
7
8
9
10
Figure 2.6 Sine Wave on +-5V Scale
Gain
1
2
4
8
Scale
(V)
10
5
2.5
1.25
Resolution
(mV/bit)
1.22
0.61
0.31
0.15
Table 2.7 Resolution Increases with applied Gain
Table 2.7, shows the maximum resolution of a signal on each scale. There are two ways
available to calibrate the channels. The first method, called Fixed Calibration, requests the
engineering value equivalent to a +10 volt signal and a -10 volt signal from the sensor, as shown
in Figure 2.7.5
5
The fixed calibrator can be found by following this path: EditÆFixed Calibration or F12
21
Figure 2.7 Fixed Calibration
The second method uses a low and high calibrator value (sometimes called a two-point method).
Using the low and high calibrator method requires the lowest and highest voltage level as well as
the appropriate engineering value for that voltage, setup seen in Figure 2.8 and Figure 2.9.6 7
Figure 2.8 Low Calibration
6
7
The low calibrator can be found following this path: EditÆLow Calibration F9
The high calibrator can be found following this path: EditÆ High Calibration or F11
22
Figure 2.9 High Calibration
The DI-720-EN is a multiplexed data acquisition device, meaning each channel is not digitized at
the same instance as the other channels. This leads to a phase shift, which is most easily seen by
logging the same sine wave on multiple channels. Once the channels are overlaid, as in Figure
2.10, it is quite obvious that the sine wave is shifted (delayed in time). It should be noted that
channel one is the curve furthest to the right and the channel number increases moving to the left.
It is important to note, because this implies channel one was the last to be logged, but this was
not the case. It is a function of how the data was plotted; a single time array was used for all of
the channels. At first glance this seems backwards, that channel two leads channel one, but upon
a closer look at the details it makes perfect sense. If a signal is logged at time t0 on channel one
and again at t0+∆t on channel two, and so on, and the channels are then plotted against the same
time array it will appear as if channel two leads channel one, as in Figure 2.10. While this shift
is not detrimental, it must be known so that the data can be corrected and plotted appropriately.
23
Time History
Ch 1
Ch 2
Ch 3
Ch 4
Ch 5
Ch 6
Ch 7
Ch 8
Ch 9
Ch 10
Ch 11
Ch 12
Ch 13
Ch 14
Ch 15
Ch 16
0.6
0.59
0.58
Volt
0.57
0.56
0.55
0.54
0.53
0.52
0.018
0.019
0.02
0.021
0.8
Time
0.022
Time History
0.023
Ch 1
Ch 2
Ch 3
Ch 4
Ch 5
Ch 6
Ch 7
Ch 8
Ch 9
Ch 10
Ch 11
Ch 12
Ch 13
Ch 14
Ch 15
Ch 16
0.6
0.4
Volt
0.2
0
-0.2
-0.4
-0.6
-0.8
0
0.01
0.02
0.03
0.04
0.05
Time
0.06
0.07
0.08
0.09
0.1
Figure 2.10 Sine Wave Phase Shift
Many high priced data acquisition systems sample all channels simultaneously, while the lower
priced systems contain fewer ADCs and must sample each channel separately. The ideal data
acquisition system utilizes a parallel sample and hold technique that samples all channels at one
instant, seen in Figure 2.11. Figure 2.12 depicts a multiplexed system digitizing a sine wave on
four channels with the scan rate and sample rate equal to one another, notice the time delay
between data points from channel to channel. This delay is the scan rate and in this case it was
also the sample rate. Figure 2.13 shows the sampling characteristics of a multiplexed system
when the scan rate and sample rate are not equal. In this figure, the scan rate is the time delay
from channel to channel and the sample rate is related to the time elapsed between the data
points of one channel.
24
Parallel Sampling
Signal
1
0
Ch 1
-1
10
Ch 2
3
4
5
6
7
8
9
10
1
2
3
4
5
6
7
8
9
10
1
2
3
4
5
6
7
8
9
10
1
2
3
4
5
6
7
8
9
10
1
2
3
4
5
Time (s)
6
7
8
9
10
0
-1
10
Ch 3
2
0
-1
10
0
-1
10
Ch 4
1
0
-1
0
Figure 2.11 Parallel Sampling Example
Multiplexed Sampling (Sampling = Scan)
Signal
1
0
Ch 1
-1
10
Ch 2
3
4
5
6
7
8
9
10
1
2
3
4
5
6
7
8
9
10
1
2
3
4
5
6
7
8
9
10
1
2
3
4
5
6
7
8
9
10
1
2
3
4
5
6
7
8
9
10
0
-1
10
Ch 3
2
0
-1
10
0
-1
10
Ch 4
1
0
-1
0
Figure 2.12 Multiplexed Sampling (Equal Sampling & Scan Rates)
25
Multiplexed Sampling (not equal)
Signal
1
0
Ch 1
-1
10
Ch 2
3
4
5
6
7
8
9
10
1
2
3
4
5
6
7
8
9
10
1
2
3
4
5
6
7
8
9
10
1
2
3
4
5
6
7
8
9
10
1
2
3
4
5
Time (s)
6
7
8
9
10
0
-1
10
Ch 3
2
0
-1
10
0
-1
10
Ch 4
1
0
-1
0
Figure 2.13 Multiplexed Sampling (Non-equal Sampling & Scan Rates)
2.3 - Data Acquisition Theory
2.3.1 - Sampling Theory
Sampling theory is defined by Shannon’s Sampling Theorem, which states:
Fsamp =
1
= FNyq × 2
∆t
FNyq ≥ Fmax
(2.2)
(2.3)
These equations describe the maxim frequency content that can be described by data logged at
any chosen sampling frequency.
Figure 2.14 depicts the previous equations of Shannon’s
Sampling Theorem. The Nyquist frequency is the frequency where foldback begins, and aliasing
becomes an issue.
26
Figure 2.14 Sampling Relationships
2.3.2 - Aliasing
Aliasing is exactly what the term implies; multiple signals can be characterized by a single set of
data points, i.e. has an alias or another name. Figure 2.15 shows a high frequency sine wave that
is characterized by the same data points that were digitized from the low frequency sine wave.
Figure 2.15 Aliasing Example
Figure 2.16 depicts the frequencies that will be aliased back to frequency of interest.
27
Figure 2.16 Aliasing Contribution
The Dataq DI-720-EN does not contain any anti-aliasing filters, so care must be taken when
logging real world sensor signals. A filter must be added to all sensor signals to reduce the
frequency content above the maximum frequency of interest. The random data that was logged
for this thesis was passed through a basic RC low pass filter which was all that was available in
the 12 VDC environment of the moving vehicle.
28
Chapter 3 Applications
3.1 - Lab Testing
The 2004 University of Cincinnati Formula SAE car was used as the test vehicle
throughout the evaluation of the data acquisition system. For the initial tests, a pink noise
generator with a rudimentary 200 Hz filter provided the signal to be measured on 16
single-ended channels. An anti-aliasing filter was added to the output of the pink noise
generator to limit the frequency content; this was controlled by a cascaded pair of
resistor-capacitor (RC) filters tuned to 200 Hz. A single RC filter would reduce the
signal by about 6 dB per octave; with the addition of a second, cascaded RC filter, the
signal is reduced another 6 dB per octave to a total of 12 dB per octave. The second set of
tests measured a 50 Hz sine wave, again on 16 single-ended channels. For the third set of
tests the Bearcat Motorsports vehicle was instrumented according to Table 3.1.
Description
Left Front Bellcrank Travel
Right Front Bellcrank Travel
Left Rear Bellcrank Travel
Right Rear Bellcrank Travel
Throttle Position
Front Lateral Acceleration
Front Longitudinal Acceleration
Front Vertical Acceleration
Rear Lateral Acceleration
Rear Longitudinal Acceleration
Rear Vertical Acceleration
Sensor Type
Rotary Potentiometer
Rotary Potentiometer
Rotary Potentiometer
Rotary Potentiometer
Rotary Potentiometer
Capacitive Discharge Accelerometer
Capacitive Discharge Accelerometer
Capacitive Discharge Accelerometer
Capacitive Discharge Accelerometer
Capacitive Discharge Accelerometer
Capacitive Discharge Accelerometer
Table 3.1 Vehicle Sensors
All of these sensors were then used to observe the vehicle during a test on a MTS four
post road simulator. The test vehicle provided the power for the Dataq DI-720-EN, a
pink noise generator, accelerometers, and a sine wave generator all from the standard 12
29
volt motorcycle battery. The game adapter and potentiometers required a 5 and 10 volt
regulated power source.
The system was tested using four different types of data
transmission, the standard parallel cable transmission, Ethernet cable transmission or
local area network, wireless local area network transmission, and wireless local area
network transmission with a parabolic antenna, which concluded the lab testing. Table
3.2 contains the details of each lab test setup.
Transfer Method
Setup
1
2
3
4
5
6
7
8
9
10
Parallel
LAN
WLAN
Signal
WLANant
Random
200 Hz
9
9
9
9
9
9
9
9
Sine 50
Hz
9
9
9
9
9
9
Car
9
9
9
9
9
9
Table 3.2 Lab Test Setups
3.1.1 - Parallel Port:
Random Noise
Dataq DI-720-EN
Figure 3.1 Parallel Port Testing Block Diagram
30
The parallel port data transfer method, while not the current standard, is still used in
industry today. The purpose of testing this type of data transfer was to provide a standard
to measure the performance of all other data transmission techniques.
The current
method of data transfer in most data acquisition systems is through either a firewire
interface (IEEE 1394) or an Internet interface, both of which provide very fast data
transfer speeds, in comparison to the parallel port method. The block diagram in Figure
3.1 describes the test setup used for the parallel port testing. The DI-720-EN has two
methods of transferring data, parallel port or Ethernet. Parallel port communications
have four different operating modes standard; bi-directional, enhanced parallel port
(EPP), and extended capabilities port (ECP). The mode of communication depends upon
the age and sophistication of the data acquisition’s and computer’s parallel ports. The
extended capabilities mode of communication was used to take the parallel port data used
throughout this document. The throughput sampling frequency (sample rate times the
number of enabled channels) used throughout the testing was 16,000 samples/second, so
this type of communication’s limit was not approached. Dataq has tested the throughput
of these modes of communication for the DI-720-EN; the results can be seen in Table
3.3.
Data Transfer Mode
Maximum Data Throughput
Standard
Bi-directional
EPP
ECP
40,000 Samples/second
80,000 Samples/second
250,000 Samples/second
Not Tested
Ethernet
Wireless Ethernet
50,000 Samples/second
42,000 Samples/second
Table 3.3 Data Transfer Throughput
31
The frequency response functions (FRFs) were computed, assuming the input was logged
on channel one. The FRFs were plotted in Figure 3.2, below, and show that each channel
was logging the same signal. This can be determined by three methods, observation of
the FRF, coherence, and the time history. Observation of the FRFs shows the magnitude
to be nearly one, up to the point where the filter starts rolling off. The coherence was
analyzed as a check; it also has a magnitude of one up to about half the filter cut off
frequency, Figure 3.3. Since there was only one signal considered the input, this is really
ordinary coherence. This was attributed to the rudimentary filtering method, and a more
robust filter would extend the point of initial roll off. Figure 3.4 shows the time history
of all the channels. Because the DI-720-EN is a multiplexed unit, the time history from
channel to channel will not lay on top of one another without adjusting for the
multiplexer. Randomly generated data is not the best suited signal for observing this, or
determining the phase shift, so discussion of the phase shift has been delayed until sine
wave data has been discussed and documented. This should be discussed here since the
phase shift for a multiplexed system is a good way to document the actual time/phase
relationship for the multiplexer.
32
Phase (Degrees)
FRF Hv -- Input 1 On Each Output
Block size = 1024 :Uniform Window P000 :Overlap = None :Cycles ave. = None
200
0
-200
0
50
100
150
200
250
300
350
400
450
0
50
100
150
200
250
300
Frequency (Hz)
350
400
450
500
Amplitude X/F
1.5
1
0.5
Figure 3.2 Parallel Port Frequency Response Functions
H1 Ordinary Coherence -- On Each Output
Block size = 1024 :Uniform Window P000 :Overlap = None :Cycles ave. = None
1
0.9
0.8
Coherence
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
0
50
100
150
200
250
300
Frequency (Hz)
350
400
450
Figure 3.3 Typical Coherence
33
Time History
0.4
0.3
0.2
Volt
0.1
0
-0.1
-0.2
-0.3
0
0.01
0.02
0.03
0.04
0.05
Time
0.06
0.07
0.08
0.09
0.1
Figure 3.4 Parallel Port Random Time History
3.1.2 - Local Area Network:
Figure 3.5, seen below, depicts the system setup utilized for the testing performed
throughout this section, with the data recorded block alternating between random noise,
sine wave, and vehicle sensors.
Random Noise
Linksys Wireless
Dataq DI-720-EN
Figure 3.5 Wired Ethernet Block Diagram
34
The wired local area network data transfer method was the next step in the process. The
goal was to determine if a local area network would affect the data being transferred. A
data acquisition box being used as network device is a concept still just emerging in the
commercial data acquisition market. The University of Cincinnati Structural Dynamics
Research Lab (UC-SDRL) has been working with a developmental network device called
the Digital Sensor System (DSS) from Larson Davis. UC-SDRL has had success using
the DSS as a network device in vibrations testing, so logging data over a local area
network was not expected to cause any issues. Three different forms of data logged over
the local area network were 200 Hz limited random noise, 50 Hz sine wave, and vehicle
data excited by a road simulator. The 200 Hz random noise and 50 Hz sine wave were
logged using the parameters seen in Table 3.4, while the logging parameters for the
vehicle data are shown in Table 3.5.
Max Sample Rate
Throughput Rate
Channels
Sample Rate
16000
16000
16
1000
Table 3.4 Random & Sine Logging
Parameters
Max Sample Rate
Throughput Rate
Channels
Sample Rate
16000
16000
11
1455
Table 3.5 Vehicle Logging Parameters
The random data spreads information across the entire frequency range allowing the
computation of frequency response functions to be useful. Computing the frequency
response function of a signal relative to itself yields a value of one:
H (ω ) =
Output (ω )
Input (ω )
(3.1)
This allows for a simple observation of the frequency response functions to determine if
channel two, three, four, etc, was logging the same signal as channel one. Note that
while this the conceptual definition of the frequency response function, the Hv algorithm
35
from Reference [1], utilizing auto and cross power spectra between the input and
response channels, was actually used to compute the FRF. Figure 3.6 compares nicely to
Figure 3.2, so it appears local area networking (internet interface) does not adversely
affect the data being transmitted.
Phase (Degrees)
FRF Hv -- Input 1 On Each Output
Block size = 1024 :Uniform Window P000 :Overlap = None :Cycles ave. = None
200
0
-200
0
50
100
150
200
250
300
350
400
450
0
50
100
150
200
250
300
Frequency (Hz)
350
400
450
500
Amplitude X/F
1.5
1
0.5
Figure 3.6 LAN Frequency Response Functions
A 50 Hz sine wave was logged according to the parameters in Table 3.4, above. The 50
Hz sine wave was tested for two reasons, observation and location of gaps in the time
history, and determination of the gap length. A gap is a location in the time data stream
where the data was either not digitized or not recorded during a specified time period.
Gaps occur because of three known reasons: large amounts of disk activity, large
amounts of network traffic, and lost communication in which the buffer overruns.
36
The DI-720-EN contains a 7500 sample buffer, which in combination with the
throughput rate determines how fast the data must be transferred from the DI-720-EN to
disk.
Large amounts of disk activity can be eliminated by reducing multitasking,
allowing the computer to only write the information from the DI-720-EN. Reducing the
gaps due to large amounts of network traffic can be achieved with the application of a
dedicated network. The data acquisition system’s software knows when a gap occurred,
but does not know how long the gap lasted. The gap information can be exported into a
modified comma separated variable format, but this modified format is not readily
compatible with Matlab. When the hardware’s buffer overflows, it sends a packet with
an odd number of bytes to signify that a gap has occurred. Several runs were performed
to check for gaps in the data; the results indicated that no gaps occurred when the system
was adequately powered. The test vehicle’s 12 volt battery was inadvertently drained and
a significant number of gaps were seen during this low power testing. Figure 3.7 shows a
few seconds of the total 3 minutes of data collected. Notice the lack of jumps/spikes in
the waveform; this indicates that no gaps occurred in the data during that time frame.
While it is possible for the system to produce a gap exactly N times the wavelength,
where N is any integer number, it is highly unlikely. Therefore, a gap in the data should
produce a noticeable irregularity in the sine wave.
37
Time History
0.8
0.6
0.4
Volt
0.2
0
-0.2
-0.4
-0.6
-0.8
0
0.01
0.02
0.03
0.04
0.05
Time
0.06
0.07
0.08
0.09
0.1
Figure 3.7 LAN Sine Wave Time History
Zooming in on a particular area of Figure 3.7 will produce Figure 3.8. In this close up,
notice the shift in the wave form from channel one to channel two and so on. As
discussed earlier, this is to be expected with a multiplexed data acquisition device. The
phase shift can be calculated from either the measured time delay seen in Figure 3.8 or
from the phase plot in Figure 3.6.
38
Time History
Ch 1
Ch 2
Ch 3
Ch 4
Ch 5
Ch 6
Ch 7
Ch 8
Ch 9
Ch 10
Ch 11
Ch 12
Ch 13
Ch 14
Ch 15
Ch 16
0.6
0.59
0.58
Volt
0.57
0.56
0.55
0.54
0.53
0.52
0.018
0.019
0.02
0.021
0.8
Time
0.022
Time History
0.023
Ch 1
Ch 2
Ch 3
Ch 4
Ch 5
Ch 6
Ch 7
Ch 8
Ch 9
Ch 10
Ch 11
Ch 12
Ch 13
Ch 14
Ch 15
Ch 16
0.6
0.4
Volt
0.2
0
-0.2
-0.4
-0.6
-0.8
0
0.01
0.02
0.03
0.04
0.05
Time
0.06
0.07
0.08
0.09
0.1
Figure 3.8 LAN Sine Wave Close Up
The next portion of testing measured signals generated from vehicle movements. The
MTS four post road simulator was utilized as the method of excitation. The signal sent to
each hydraulic shaker can be characterized by the parameters seen below in Table 3.6.
Many other signals were tested, but none seemed to excite the system as well.
Source:
Shape:
RMS Amplitude:
Min Frequency:
Max Frequency:
Front
Random
1/F
0.8
0.4
2.5
Rear
Random
1/F
0.8
0.4
4
Table 3.6 MTS Test File Information
Figure 3.9 shows the signals captured for the four bellcrank potentiometers. This data
serves as a baseline for the data that will be taken in later data acquisition tests when the
39
car is running with a wireless Internet interface. Notice the DC offset of the signal, this is
because the potentiometer was set with the middle of its travel roughly at the middle of
the bellcrank travel. The minimum potentiometer travel should have been set to the
minimum bellcrank travel, to optimize the dynamic range. AC coupling and analog
summing are two other methods used to remove DC offsets from signals. AC coupling is
essentially a high pass filter which corrupts data from zero to about five Hz and hence
affects many of the interesting signals in vehicle dynamics. The second option, an analog
summing amplifier, would add the negative value of the DC offset to the signal, thereby
centering the signal on zero. If the data acquisition device’s ADC contained more bits
the DC offset would be less of an issue.
5.8
Left Front
Right Front
Left Rear
Right Rear
5.6
5.4
5.2
5
4.8
4.6
4.4
0
0.5
1
1.5
2
2.5
3
3.5
Figure 3.9 Bellcrank Rotation
40
3.1.3 - Wireless Local Area Network:
The testing performed throughout this section was obtained utilizing a Linksys wireless
router to transfer the data from the test vehicle to computer; the system diagram is shown
below in Figure 3.10.
Random Noise
Linksys Game
Adapter
Dataq DI-720-EN
Linksys Wireless
Wireless Link
Figure 3.10 Basic Wireless System Block Diagram
Wireless local area network data was logged according to Table 3.4 and Table 3.5. As
before, the random data was transformed using Fourier transform techniques, and
analyzed. The FRF’s magnitude and phase plots were overlaid, shown in Figure 3.11.
The FRF’s are flat with a magnitude of one up to 200 Hz, this shows that each channel
was logging nearly the same signal, because of the filter on the random noise generator
information above 200 Hz was expected to be partially corrupted. The phase linearly
increases from 0 to 200 Hz, described by:
θ = ω ∗t
(3.2)
41
Phase (Degrees)
FRF Hv -- Input 1 On Each Output
Block size = 1024 :Uniform Window P000 :Overlap = None :Cycles ave. = None
200
0
-200
0
50
100
150
200
250
300
350
400
450
0
50
100
150
200
250
300
Frequency (Hz)
350
400
450
500
Amplitude X/F
1.5
1
0.5
Figure 3.11 WLAN Frequency Response Functions
Figure 3.12 depicts a 50 Hz sine wave that has been captured using a wireless local area
network. It was in Figure 3.12 that the first sign of a potential problem arose; notice the
jump in the sine wave at about 27.72 seconds.
42
Time History
0.8
0.6
0.4
Volt
0.2
0
-0.2
-0.4
-0.6
-0.8
27.68
27.7
27.72
27.74
27.76
Time
27.78
27.8
27.82
Figure 3.12 WLAN Sine Wave Time History
This is a gap or loss of data, which could be a major problem depending upon the type of
data and the nature of the analysis of the data that is required. Consider a vehicle moving
at 30 miles per hour and gap of one second, this equates to about 44 feet traveled or about
4.5 car lengths. The software for many motorsports data acquisition systems calculates a
track map from lateral acceleration, longitudinal acceleration, longitudinal velocity, and
elapsed time. If a gap occurs, this method of track map generation would fail in that
vicinity. If a very low frequency sine wave is always logged on one channel, the gap can
be determined by realigning the data after the spike based upon where it is expected to
be. Although it will not be known what happened during that time period, at least the
length of time or distance traveled will be known, and can be linked to a certain sector of
the course.
43
3.1.4 - Wireless LAN w/Parabolic Antenna
Figure 3.13, below, describes the test setup used throughout 3.1.4 - which discusses the
characteristics of testing with a parabolic antenna in the lab.
Linksys Game
Adapter
Random Noise
Dataq DI-720-EN
Cisco Access
Point
Parabolic
Antenna
Linksys Wireless
Wireless Link
Figure 3.13 Parabolic Testing Block Diagram
The final lab testing task was to test the wireless local area network with a parabolic
antenna. The purpose of a parabolic antenna was to focus the wireless Internet signals
and therefore, optimize the incoming and outgoing data signals between the data
acquisition system and the computer. Essentially, power is being wasted when the signal
is being sent out in all directions. Focusing the signal should increase the range and will
be discussed more elaborately in the onsite testing section. As in the previous FRFs, the
frequency response functions of Figure 3.14 have a magnitude of one up to the filter cut
off which was the limit of reliable data. The phase angle plots show similar results to
previous testing as well.
44
Phase (Degrees)
FRF Hv -- Input 1 On Each Output
Block size = 1024 :Uniform Window P000 :Overlap = None :Cycles ave. = None
200
0
-200
0
50
100
150
200
250
300
350
400
450
0
50
100
150
200
250
300
Frequency (Hz)
350
400
450
500
Amplitude X/F
1.5
1
0.5
Figure 3.14 Parabolic Frequency Response Functions
The sine wave time history, Figure 3.15, shows that gaps still occurred with the antenna.
Upon further examination of the two data sets shows that the number of gaps was
reduced.
45
Time History
1
0.8
0.6
0.4
Volt
0.2
0
-0.2
-0.4
-0.6
-0.8
-1
25.67
25.68
25.69
25.7
25.71
Time
25.72
25.73
25.74
25.75
Figure 3.15 Parabolic Sine Wave Time History
3.2 - Onsite Testing
Linksys Game
Adapter
Random Noise
Dataq DI-720-EN
Cisco Access
Point
Parabolic
Antenna
Linksys Wireless
Wireless Link
Figure 3.16 Vehicle Testing Block Diagram
46
The onsite testing was preformed with similar inputs as used in the lab and only with
wireless data transmission methods. Two types of onsite testing were performed, static
and dynamic. The static testing provided a baseline for onsite testing. The dynamic
testing was used to determine the “real world” range. Table 3.7, seen below, depicts the
onsite testing performed. A diagram of the parabolic antenna test setup used in this
section can be seen in Figure 3.16, above, while the non-parabolic antenna setup can be
seen in Figure 3.10.
Transfer Method
Setup
1
2
3
4
5
6
7
8
WLAN
WLANant
9
9
9
9
9
9
9
9
Signal
Random
200 Hz
Location
Car
9
9
9
9
Onsite
(Static)
Engine
Onsite
(Dynamic)
9
9
9
9
9
9
9
Off
9
9
9
9
9
9
9
9
On
9
9
9
9
9
Table 3.7 Onsite Test Setups
3.2.1 - Static Testing
A variety of types of static testing were performed using either a standard wireless
antenna or a parabolic antenna. The primary signal recorded was a random 200 Hz wave,
vehicle data was also recorded. Both of these types of signals were recorded with and
without the engine running to determine if the noisy radio frequency characteristics of a
vehicle would have a significant impact. The initial static testing was performed at the
University of Cincinnati Center Hill Research Facility. The test vehicle and computer
were placed at opposite ends of the facility, a distance of 70 meters. A random signal
47
was then logged on 16 channels using the wireless local area network transmission
method.
As expected, Figure 3.17 had a magnitude of one up to the filter cutoff
frequency, but interestingly above the filter cutoff is more closely matched than
previously seen.
Phase (Degrees)
FRF Hv -- Input 1 On Each Output
Block size = 1024 :Uniform Window P000 :Overlap = None :Cycles ave. = None
10
0
-10
0
50
100
150
200
250
300
350
400
450
0
50
100
150
200
250
300
Frequency (Hz)
350
400
450
500
Amplitude X/F
1.5
1
0.5
Figure 3.17 Center Hill FRFs
Note the different shape and magnitude in the phase plot of Figure 3.17, compared to
Figure 3.11. Further investigation shows that the phase shift in Figure 3.11 was about 2
degrees and 0.3 degrees in Figure 3.17 at 100 Hz. Figure 3.18 corroborates the data seen
in Figure 3.17 with a coherence level of 0.9 for the entire frequency range. These
differences can be associated with a change in the test setup, note the difference in
maximum sample rates of Table 3.8 and Table 3.4. The difference in FRF phase and
magnitude characteristics above the low pass filter cutoff was not investigated.
48
Max Sample
Rate
Throughput
Rate
Channels
Sample Rate
200,000
16,000
16
1000
Table 3.8 Center Hill Logging Parameters
H1 Ordinary Coherence -- On Each Output
Block size = 1024 :Uniform Window P000 :Overlap = None :Cycles ave. = None
1
0.9
0.8
Coherence
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
0
50
100
150
200
250
300
Frequency (Hz)
350
400
450
Figure 3.18 Center Hill Coherence
Since the Center Hill facility was deemed too small to test the potential range of the
system, the test vehicle was taken to Raymond Walters, a University of Cincinnati
satellite campus, for more conclusive testing. It was during this phase of testing that an
erratic and unexplainable system fault occurred. The logging parameters were set as
stated in Table 3.8. The vehicle was set at one end of the parking lot and the computer
and routers at the other; then a random signal was logged for three minutes, same as the
Center Hill test. When the frequency response function magnitudes and phases were
49
plotted it became obvious that something was different or possibly wrong. Figure 3.19
shows that five of the sixteen channels logged were different, channels 9-13. The bad
channels had a different magnitude from 50 Hz and above. They also had an inconsistent
phase characteristic that was a significant difference in magnitude.
Phase (Degrees)
FRF Hv -- Input 1 On Each Output
Block size = 1024 :Uniform Window P000 :Overlap = None :Cycles ave. = None
100
0
-100
0
50
100
150
200
250
300
350
400
450
0
50
100
150
200
250
300
Frequency (Hz)
350
400
450
500
Amplitude X/F
1.5
1
0.5
Figure 3.19 Bad Channels FRFs
The coherence of those five channels started dropping off at about 100 Hz and continued
much faster than the other channels, which can be seen in Figure 3.20, below.
50
H1 Ordinary Coherence -- On Each Output
Block size = 1024 :Uniform Window P000 :Overlap = None :Cycles ave. = None
1
0.9
0.8
Coherence
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
0
50
100
150
200
250
300
Frequency (Hz)
350
400
450
Figure 3.20 Bad Channels Coherence
The time history of all sixteen channels can be seen in Figure 3.21 for 1/10th of a second
of the three minutes logged. It was not possible to notice a difference in the 1/10th of a
second time history, so the first peak was magnified to show that five of the channels
were indeed not following the others. This test setup was retested in the UC-SDRL, as
well as in several additional tests, attempting to reproduce the results to no avail.
51
Time History
0.28
0.26
0.24
Volt
0.22
0.2
0.18
0.16
0.14
0.12
Time His tory
0.5
0.1
4
6
8
10
Time
12
14
16
0.4
-3
x 10
0.3
Volt
0.2
0.1
0
-0.1
-0.2
-0.3
0
0.01
0.02
0.03
0.04
0.05
Time
0.06
0.07
0.08
0.09
0.1
Figure 3.21 Bad Channels
Before dynamic testing began it was decided to evaluate the level of noise to be expected
in a motorcycle engine powered race car environment. The first step was to instrument
the car with the sensors detailed in Table 3.1. The sensor signals were then logged for
three different test setups, engine not running, engine running, and engine running with
one accelerometer isolated. The test setup with the engine not running was performed
with the ECU (Engine Control Unit) power turned off, thus the throttle position sensor
was un-powered. Figure 3.22 shows one second of the throttle position, where the signal
randomly oscillates between 41 and 34 milli-volts. The possible quantization error was
12 milli-volts, as seen in Table 2.7, therefore the oscillation was from the ADC setting its
bits. Unshielded wires potentially act like antennas creating noise. Figure 3.23 shows
the noise level has increased to about 100 milli-volts, from engine vibration, power
source fluctuation, or RF noise from firing engine coils. The majority of the DC offset in
Figure 3.23 was from the sensor power.
52
Throttle Position (Engine NOT Running)
0.042
0.041
0.04
0.038
0.037
0.036
0.035
0.034
0.033
0
0.1
0.2
0.3
0.4
0.5
0.6
Time (s)
0.7
0.8
0.9
1
0.9
1
Figure 3.22 Throttle Position (Engine Off)
Throttle Position (Engine Running)
4.5
4
Voltage
Voltage
0.039
3.5
3
0
0.1
0.2
0.3
0.4
0.5
0.6
Time (s)
0.7
0.8
Figure 3.23 Throttle Position (Engine On)
53
Figure 3.24 shows the significant differences seen in magnitude between the engine
running, engine not running, and the engine revving test. Figure 3.25 compares the
acceleration of the isolated accelerometer for the three different tests. Figure 3.26 was
created to show the detail that was easily lost in the noise of Figure 3.25. The engine not
running accelerometer magnitude oscillates between about 0.925 and 0.965 volts, a
difference of 40 milli-volts which was above the level attributable to quantization error.
The vehicle was very mechanically noisy because of the rigidly mounted accelerometers,
as seen in Figure 3.25. The accelerometers could be filtered at a much lower frequency
in order to eliminate some of this noise since the primary interest in these signals is to
document the low frequency performance of the vehicle.
Typical Acceleration
5
Engine Reving
Engine Running
Engine Not Running
4
3
2
Voltage
1
0
-1
-2
-3
-4
-5
0
0.1
0.2
0.3
0.4
0.5
0.6
Time (s)
0.7
0.8
0.9
1
Figure 3.24 Typical Acceleration
54
Isolated Accelerometer Accleration
4
Isolated Acclerometer
Engine NOT Running
Engine Running
3
Voltage
2
1
0
-1
-2
0
0.1
0.2
0.3
0.4
0.5
0.6
Time (s)
0.7
0.8
0.9
1
Figure 3.25 Isolated Accelerometer Acceleration
Isolated Accelerometer Accleration
1.1
Isolated Acclerometer
Engine NOT Running
1.05
Voltage
1
0.95
0.9
0.85
0
0.1
0.2
0.3
0.4
0.5
0.6
Time (s)
0.7
0.8
0.9
1
Figure 3.26 Isolated Accelerometer
55
3.2.2 - Dynamic Testing
For actual vehicle data, the maximum frequency of interest was expected to be below 500
Hz, so a sampling rate of 1000 Hz was used throughout the testing. The dynamic testing
was performed at the University of Cincinnati Raymond Walters campus parking lot and
at the Transportation Research Center’s Vehicle Dynamics Area (VDA), in Marysville
Ohio. The parking lot used at Raymond Walters contains several islands with small trees
that can affect the range. The VDA at the Transportation Research Center (TRC) was
used to setup a typical FSAE endurance course for testing. The VDA is a vast wide open
paved area where there are no obstructions for the RF equipment. It was common for one
or two gaps to occur per lap during the TRC testing, but one data set produced zero gaps
and several of the gaps could be attributed to a person walking between the antenna and
the car. A solution for the pedestrian traffic gaps could be a higher mounted computer
antenna. A second day of testing at Raymond Walters revealed another system fault.
Figure 3.27 shows the frequency response characteristics of the system fault, while
Figure 3.28 shows 0.1 seconds of the time history. It was quite obvious from these plots
that the magnitude of one channel was not captured accurately. Dataq was contacted
about this and the previously mentioned system fault but they were unable to provide an
answer. Since the two faults were different and no supplier answer could be provided, it
was assumed that these faults were hardware problems with the relatively low cost
system that was used for the data acquisitioning. It is advised that any future user be
aware of potential hardware problems, and therefore analyze the logged data carefully.
56
Phase (Degrees)
FRF Hv -- Input 1 On Each Output
Block size = 1024 :Uniform Window P000 :Overlap = None :Cycles ave. = None
200
0
-200
0
50
100
150
200
250
300
350
400
450
0
50
100
150
200
250
300
Frequency (Hz)
350
400
450
0.08
0.09
500
Amplitude X/F
1.5
1
0.5
Figure 3.27 Bad Channel FRF
Time History
0.4
0.3
0.2
Volt
0.1
0
-0.1
-0.2
-0.3
-0.4
0
0.01
0.02
0.03
0.04
0.05
Time
0.06
0.07
0.1
Figure 3.28 Bad Channel Time History
57
The 200 Hz random waveform was logged once more on sixteen channels with the FSAE
racecar driving around a small course at Raymond Walters. Even though the course was
small, five gaps still occurred, which were linked to the small trees in the middle of the
course. The phase and magnitude are plotted below in Figure 3.29, this figure was very
typical for what was considered a good frequency response function plot.
Phase (Degrees)
FRF Hv -- Input 1 On Each Output
Block size = 1024 :Uniform Window P000 :Overlap = None :Cycles ave. = None
200
0
-200
0
50
100
150
200
250
300
350
400
450
0
50
100
150
200
250
300
Frequency (Hz)
350
400
450
500
Amplitude X/F
1.5
1
0.5
Figure 3.29 Dynamic Frequency Response Functions
58
Chapter 4 Conclusions & Future Work
Motorsports is highly competitive industry where a minute increase in performance could
mean the difference between first and second place.
An engineer in this type of
environment must utilize every tool at his fingertips at a level of proficiency that is
unrivaled. To achieve such a high level of performance from a motor vehicle a data
acquisition system is a requirement.
The data acquisition methods employed in
motorsports today, include the use of a complex data logger and several sensors,
positions, accelerations, pressures, temperatures, and strains to name a few.
Data
acquisition systems have advanced significantly since their inception, but most are still
not very affordable. The purpose of this thesis was to investigate the possibilities and
capabilities of a low cost data acquisition system. Typical motorsports data acquisition
systems are exorbitantly priced for their capabilities, but they are small and lightweight.
Motorsports data acquisition companies claim the development of their software as the
most costly portion. Lab quality data acquisition systems, while also excessively high
priced, are much more robust, but they are also larger and heavier.
Adding telemetry to any type of data acquisition system has historically been costly.
Historically, telemetry has been analog and several difficulties were involved, including
the large frequency bandwidth requirements and FCC regulations.
Many current
telemetry systems are digital, the signals are digitized and packetized before being
transmitted across the air waves. The FCC has set aside a few frequency bands and
allowed industry to determine their uses and regulations. These frequency bands have
been filled with several useful products ranging from wireless telephones to wireless
59
routers and much more. This wireless router technology was the basis for the low cost
data acquisition and telemetry system.
While Dataq’s DI-720-EN was the data
acquisition device utilized throughout the testing for this document, any data acquisition
device with an Ethernet output should be capable of implementing this technology.
Several lab tests were performed to characterize the data acquisition system, and provide
a baseline before the wireless system was implemented. This characterization involved
recording a random time history on several channels and then comparing the frequency
response functions. The process was then repeated several times varying the data transfer
method, environmental conditions, and system parameters, and evaluating the frequency
response functions after each test setup. The testing performed shows that the wireless
networking technology does not adversely affect the data being transferred. It was also
seen that this system could be used to record a full FSAE sized endurance course without
gaps. To achieve this level of functionality the antennas must be mounted high, well
above the level of pedestrian traffic, and obstructions such as trees, buildings, etc must be
avoided, as line of sight becomes critical at longer distances. The parabolic antenna was
useful at increasing the range of this type of system. It was seen several times that the
standard antenna on the Linksys WRT-54G wireless router was not well suited for this
testing as several gaps occurred.
There are several areas for future work on this topic. As seen throughout this document
the sensor signals will need to be filtered for vehicle testing with good filters, based on
the sampling rates used. The data acquisition system’s wiring must be shielded to reduce
60
electrical noise, including sensor wiring and device power. A precision power supply
should be investigated to provide power to the sensors and acquisition device. Dataq’s
advanced features like intelligent over sampling need to be further investigated to
determine their validity. The integration of a low frequency modulation of a 50 Hz sine
wave should be investigated so that one channel can always record it, which should
enable accurate gap length determination for both large and small gaps. Another area
that needs to be investigated is implementation of an infrared beacon. This would be
helpful in determining the beginning of a new lap and the end of the previous one; it
would also provide a way of calculating lap times and eliminate the human error involved
with a stopwatch. National Instruments’ Compact RIO should be investigated as it may
prove to be a superior data acquisition device.
Wireless networking technology is rapidly evolving and may provide significant future
technological advances, reducing it’s current limitations. Since the beginning of this
research, the IEEE has defined an 802.11g standard which should provide additional
throughput capabilities.
A new technology coined SRX or MIMO (multiple input-
multiple output) claims to increase the range by 3 times the 802.11b range. The game
adapter antenna should be investigated, as it is believed to be the current system
limitation.
The minimum suggested system consists of the Cisco access point with parabolic antenna
mounted high above pedestrian traffic for the computer side. On the vehicle side, it is
suggested that the Linksys game adapter be mounted at the highest point on the vehicle
61
and linked to the Dataq DI-720-EN. The sensors should be connected to the acquisition
device and power supply through shielded wires. Quality filters should be used to reduce
anti-aliasing issues.
62
References
[1]
Allemang, Randall J. Mechanical Vibrations II Class Notes. Course Number 20MECH-662. Vibrations: Analytical and Experimental Modal Analysis. Rev.
February 1999+. http://sdrl.uc.edu/ucme662/ucme662.html
[2]
Allemang, Randall J. Mechanical Vibrations III Class Notes. Course Number 20MECH-663. Vibrations: Experimental Modal Analysis. Rev.
June 1999+. http://sdrl.uc.edu/ucme663/ucme663.html
[3]
Brown, David L. Fourier Transform Techniques Class Notes. Course Number 20MECH-660. Vibrations: Analytical and Experimental Modal Analysis. Rev.
June 1999+. http://www.min.uc.edu/~dave/fourier_min.htm
[4]
Brown, David L. System Dynamic Analysis I Class Notes. Course Number 20MECH-794. Vibrations: Analytical and Experimental Modal Analysis. Rev.
June 1999+. http://sdrl.uc.edu/ucme794/ucme794.html
[5]
DATAQ Instruments. www.dataq.com. DI-720 Product Manual:
http://www.dataq.com/support/documentation/pdf/manual_pdfs/720_730_740.pdf
[6]
DATAQ Instruments. www.dataq.com. Data Acquisition Gain and Dynamic
Range Considerations.
http://www.dataq.com/support/documentation/pdf/article_pdfs/gain.pdf
[7]
DATAQ Instruments. www.dataq.com. Frequency and True RMS Data
Acquisition.
http://www.dataq.com/support/documentation/pdf/article_pdfs/freq_rms.pdf
[8]
DATAQ Instruments. www.dataq.com. Getting Started In PC_Based Data
Acquisition.
63
http://www.dataq.com/support/documentation/pdf/article_pdfs/sensors.pdf
[9]
DATAQ Instruments. www.dataq.com. Enhancing Data Acquisition with
Intelligent Oversampling.
http://www.dataq.com/support/documentation/pdf/article_pdfs/iosda.pdf
[10]
DATAQ Instruments. www.dataq.com. Intelligent Oversampling Methods
Extend Measurement Flexibility.
http://www.dataq.com/support/documentation/pdf/article_pdfs/bkground.pdf
[11]
DATAQ Instruments. www.dataq.com. Four Easy Steps to Wi-Fi Data
Acquisition.
http://www.dataq.com/support/documentation/pdf/article_pdfs/wireless.pdf
[12]
DATAQ Instruments. www.dataq.com. WinDAQ Software Manual.
http://www.dataq.com/support/documentation/pdf/manual_pdfs/windaq_software.
pdf
[13]
MoTeC. www.motec.com. MoTeC USA Components Catalog.
http://www.motec.com/catalog.htm
[14]
Pi Research. www.piresearch.com. Delta Lite System Hardware Reference.
http://www.piresearch.com/assets/29K-071441.pdf
[15]
Pi Research. www.piresearch.com. Delta System Hardware Reference.
http://www.piresearch.com/assets/29D-071397.pdf
[16]
Pi Research. www.piresearch.com. Sigma Elite System Hardware Reference.
http://www.piresearch.com/assets/29M-071443.pdf
[17]
Larson Davis. www.larsondavis.com. DSS Digital Sensing System.
http://larsondavis.com/docs/DSS-1203_D0501_0009_REVB.pdf
64
[18]
National Instruments. www.ni.com. NI CompactRIO – Reconfigurable Control
and Acquisition Systems.
http://zone.ni.com/devzone/conceptd.nsf/webmain/925A7C29B99BE5C286256E
E40079F0B8/$File/WP2480.pdf
[19]
Sensors. www.sensorsmag.com. Digital Rotor Telemetry.
http://www.sensorsmag.com/articles/0900/108/main.shtml
[20]
Fey, Buddy. Data Power: Using Racecar Data Acquisition. Towery Pub. 1993.
[21]
Rouelle, Claude. 3-Day FSAE Vehicle Dynamics Seminar. 2003.
65
Appendix - A Instrumentation
There are several data acquisition techniques and power supply methods not discussed in
the body of this document that any future reader may find pertinent. The basic wiring
diagram was provided below in Figure A.1. The game adapter used required five volt
and one ampere DC power, so a voltage regulator was required to step down the fourteen
volt vehicle charging system. A one ampere fuse was also used to ensure the game
adapter was not overpowered.
The accelerometers were powered directly from the
vehicle’s battery, as they contain a built in power regulation circuit, there was a 30 milliamp fuse in the line for three accelerometers, also to ensure the accelerometers were not
damaged. The accelerometer signal was then sent to a single-ended channel on the Dataq
unit.
The Dataq unit’s maximum voltage range is only ±10 volts.
Therefore, the
vehicle’s charging system voltage was scaled down using a 10 volt regulator to provide
power to the rotary potentiometer. The rotary potentiometer’s resistance can approach
zero and the amperage will approach infinity or short circuit, a condition that will destroy
most electronic devices. To prevent the resistance from approaching zero a fixed resistor
was put in place to eliminate the possibility of creating a short circuit, as seen in Figure
A.1. The data acquisition system’s documentation specifies a maximum power rating, so
the fuse size can be calculated from that power rating and the vehicle’s power supply
voltage. Possibly the most important and most overlooked part in a data acquisition
system is the power supply. If the power supply’s voltage varies, the sensor’s output
voltage will vary, mimicking sensor excitation, even when it was not excited.
A
motorcycle powered race car is a very noisy environment. The alternator or stator
produces power that is regulated by the voltage regulator or rectifier.
This power
66
generation system is one of the major contributors of noise imparted on the system’s
power source. Other sources of noise in this system are the coils that provide the power
to ignite the spark plugs. The electrical fuel pump and electrical water pump will also
add noise into the environment. A precision power supply is of the utmost importance
and where all good data acquisition systems start.
Figure A.1 Wiring Diagram
Once at the track, several tasks should be completed before testing begins.
1. Check operation of Beacon/Transmitter if applicable.
2. Check all connections.
3. Ensure sensors are connected to appropriate power and channel.
4. Ensure all sensors are operational.
Table A.1 details the suggested sampling frequency for several vehicle parameters.
67
Measurement Type
Oil Temp
Water Temp
Oil Pressure
Water Pressure
Brake Pressure
Voltage
Hand Wheel Angle
Accelerometers
Damper Position
Strain Gauges
Sampling
Frequency (Hz)
1
1
2
2
10
5
10-50
50-200
20-500
20-500
Table A.1 Suggested Sampling Frequency
There are several vehicle properties that can be calculated from the measured damper
position and a few known vehicle parameters. The spring force, bump rubber force, and
shock speed can all be directly calculated from the measured damper position, knowing
only the spring rates. With a known spring/wheel motion ratio the bump stop and spring
forces at the wheel can be calculated, as well as wheel movement. Vehicle attitudes (ride
height, roll, and pitch changes) can be calculated from the previously calculated wheel
movements and the known front and rear tracks as well as the wheelbase. The time
derivatives of the vehicle attitudes will provide there respective velocities. The antiroll
bar torsion, antiroll bar forces, and antiroll bar forces at the wheels can be calculated
from the known antiroll bar motion ratios and antiroll bar stiffness. Figure A.2 describes
the responses that can be computed by measuring the damper position and coupling it
with known vehicle parameters.
68
Spring/Wheel
Motion Ratio
RH changes
Roll changes
Pitch Changes
F & R Tracks
Wheelbase
Springrate
Preload
Wheel Mvt
Antiroll
Bar Rate
Spring
Force
ARB Torsion
ARB Forces
Antiroll Bar
Motion Ratio
ARB Force
@ Wheel
Spring Force
@ Wheel
Spring/Damper
Position
Damper
Speed
Bump Rubber Eq.
Clearnce/Prelaod
Known Parameter
Bump Rubber
Force
BR Force
@ Wheel
Measurment
Computed Response
Figure A.2 Damper Position
A lateral accelerometer coupled with some known vehicle parameters can provide several
bits of information which can be used to tune the racecar.
A measured lateral
acceleration and vehicle speed can be used to compute the turn radius, which can be used
to create the corners for a track map by:
V2
Ay =
R
(A.1)
The vehicle speed and elapsed time between lateral accelerations can be used to compute
the length of the straight, used to complete the track map. Figure A.3 depicts the vehicle
responses that can be computed from the measured lateral acceleration, velocity, and
69
push/pull rod strain gauges and the known vehicle parameters.
The measured
longitudinal, lateral, and vertical accelerations can be used with the known vehicle
parameters to compute longitudinal load transfers and road banking values, as seen in
Figure A.4 below. The equations used in Figure A.2, Figure A.3, and Figure A.4 are in
Reference [21].
Bump Rubber Eq.
Clearance/Preload
Spring Rate
Preload
F & R Lat. Geo.
SW Trans.
Spring/Wheel
Motion Ratio
S. Weight
S. Weight Cg Height
Velocity (Vx)
ARB Rate
ARB Motion
Ratio
F & R Antiroll
Moment
F Roll Center
R Roll Center
Turn Radius
Lateral
Acceleration
F & R Lat. NS W
Trans.
F & R NS Weight
NSW Cg Height
Known Parameter
Front Track
Rear Track
Wheelbase
F & R Lat. Elastic SW
Trans. (Strain Gauges)
Measurment
F & R Lat. Elastic SW
Trans.
Computed Response
Figure A.3 Lateral Accelerometer
70
Antilift
Antidive
Antisquat
Rear Wheel
Radius
Brake Balance
Long. NS W. Trans.
Longitudinal
Acceleration
Wheelbase
F & R NS Weight
NS Weight Cg Height
Long Geom. SW
Transfer
Long. NSW. Transfer
Suspended Weight
S. Weight Cg Height
Long. Elastic SW Trans.
(Strain Gauges)
NSW Vertical Banking Load
SW Vertical Banking Load
Vertical
Acceleration
Banking Angle
Lateral
Acceleration
Known Parameter
Measurment
Computed Response
Figure A.4 Accelerometers
Appendix - B
B.1
Matlab Script
CSV Converter
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%DaTaq_convert.m
%Created 8-9-04
%
%
%This file converts the DaTaq csv file to a .mat
%
%Input:
%
Data file in csv format
%
%Output:
%
Data in a structural array .mat file
%Asking user for the file to start conversion
%[filename, pathname] = uigetfile('*.txt', 'Pick the MATLAB file that
contains the data:');
%if filename==0
71
%
disp('The conversion has been aborted')
%
break
%end
%Opening file so user can grab the Sample Rate
%disp('Please See Matlab Editor')
%edit([pathname filename]);
%pause(3);
%Asking the user for the sample rate
sampfreq_cell=inputdlg('What is the sampling frequency?');
sampfreq=str2num(sampfreq_cell{1});
%User command
%msgbox('Please save the csv file without the headers and hit any
button')
%disp('Hit any button to continue')
%pause
%Asking user for the csv file without the headers
clear filename pathname
[filename, pathname] = uigetfile('*.txt', 'Pick the MATLAB file that
contains the data:');
if filename==0
disp('The conversion has been aborted')
break
end
%Prompts for user input dialog boxes
gprompt={'Description','CreatedFrom','DateTime','Location','Course','Am
bientTemperature','TrackTemperature','TrackCondition','Driver','DriverW
eight'};
wprompt={'Description','Weight','Camber','Toe','Caster','RideHeight','S
pringRate','ARBRate','Tire','Compound','ColdPressure','HotPressure','Ti
reTempInside','TireTempCenter','TireTempOutside'};
dprompt={'Description','SensorSerialNo','CalibrationValue','SampleRate'
,'DataValues'};
%Default answers for user input dialog boxes
gdef={'General Information',[pathname filename],datestr(now),'Four Post
Rig','Four Psot Rig','75','80','Dry','B.J. Stoney','170'};
lfwdef={'Left Front Wheel','100','1','1','4','14','285','0','AVON','A45','10','12','100','100','100'};
rfwdef={'Right Front Wheel','100','1','1','4','14','285','0','AVON','A45','10','12','100','100','100'};
lrwdef={'Left Rear Wheel','100','1','1','4','14','350','0','AVON','A45','12','14','100','100','100'};
rrwdef={'Right Rear Wheel','100','1','1','4','14','350','0','AVON','A45','12','14','100','100','100'};
%Titles for use user input dialog boxes
gdlgTitle='General Information';
lfdlgTitle='Left Front Wheel Data';
rfdlgTitle='Right Front Wheel Data';
72
lrdlgTitle='Left Rear Wheel Data';
rrdlgTitle='Right Rear Wheel Data';
ddlgTitle='Data Channel';
%Number of Lines in user input dialog boxes
lineNo=1;
%User input dialog boxes
general=inputdlg(gprompt,gdlgTitle,lineNo,gdef)';
LFWD=inputdlg(wprompt,lfdlgTitle,lineNo,lfwdef)';
RFWD=inputdlg(wprompt,rfdlgTitle,lineNo,rfwdef)';
LRWD=inputdlg(wprompt,lrdlgTitle,lineNo,lrwdef)';
RRWD=inputdlg(wprompt,rrdlgTitle,lineNo,rrwdef)';
%Construction of the final cell array
A{1,1}=cell2struct(general,gprompt,2);
A{2,1}=cell2struct(LFWD,wprompt,2);
A{3,1}=cell2struct(RFWD,wprompt,2);
A{4,1}=cell2struct(LRWD,wprompt,2);
A{5,1}=cell2struct(RRWD,wprompt,2);
%Loading the csv file
disp('Loading csv file')
output=csvread(filename);
ddef={'','','1',num2str(sampfreq./min(size(output))),''};
%Placing data values into the final cell array structure
for ii=1:min(size(output));
data=inputdlg(dprompt,ddlgTitle,lineNo,ddef)';
A{ii+5,1}=cell2struct(data,dprompt,2);
A{ii+5,1}.DataValues=output(:,ii)';
end
%Saving the cell array structure into a .mat file
clear filename pathname
[filename, pathname]=uiputfile('*.mat','Save As');
if filename==0
disp('The conversion has been aborted')
break
end
save([pathname filename], 'A')
clear all
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
B.2
Main Executable
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
function master_script()
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Function:
master_script.m
% Author(s): Jim Parker, Ray Martell, Dan Alford, Matt Giachetto
%
73
% This script is the master or upper level of a bunch of functions that
are
% being used to calculate the frequency response function (FRF) for a
set
% of data. The set of data can have as many of inputs and outputs as
the
% user wants to test. The datafile must have a certain structure type
to
% work with this function. The data file is from a DSS system that was
% converted using a script that was written by SDRL(SCRIPT NAME).
%
% Call the function with NO inputs and outputs. There are menus that
will
% pop up while the funciton is running that ask the user for the needed
% information to process the data.
%
% Version 1 - Date: 11/20/2003 - Author(s): JMP
%
- First version
% Version 2 - Date: 12/3/2003 - Author(s): JMP
%
- Changed how you can crosspower (H2 stuff)
%
- Added H2
%
- Added peak_picker
%
- Added plot_ouput
%
- Added the outfile option
% Version 3 - Date: 12/4/2003 - Author(s): JMP
%
- Removed GFFqq for the output of the autopower function
% Version 4 - Date: 8/11/04 - Author(s): DAA
%
- Changed for WINDAQ data converted using dataq_convert.m
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
clc
tic
debug = 0; % Creating a debug variable, if = 0; some variables will be
cleared
% Finding what data file the use wants to load and location
[filename, pathname] = uigetfile('*.mat', 'Pick the MATLAB file that
contains the data:');
if filename==0
disp('The program has been aborted')
break
end
disp('Loading Data -- Please Wait!!')
load([pathname filename]);
% Finding out the number of data points in the data file, the sample
% frequency, and delta t of the data
f_sam = str2num(A{6}.SampleRate);
delta_t = 1 / f_sam;
number_data_point = length(A{6}.DataValues);
% Prompting the user for the block size
blocksize_c = inputdlg({'Enter the number of data points per
blocksize:'}, ...
'BLOCKSIZE', 1, {'1024'});
74
blocksize = str2num(blocksize_c{1});
% Checking to see that the blocksize is a multiple of the total number
of
% data points
%while rem(number_data_point, blocksize) ~= 0;
%
disp(['The BLOCKSIZE is NOT a multipe of the total number of data
points (' ...
%
num2str(number_data_point) ')']);
%
blocksize_c = inputdlg({'Enter the number of data points per
blocksize:'}, ...
%
'BLOCKSIZE', 1, {'1024'});
%
blocksize = str2num(blocksize_c{1});
%end
% Creating the frequency array
freq = (0: f_sam/blocksize: f_sam - (f_sam/blocksize));
% Is windowing going to be used and what type
% THE ORDER OF THE WINDOWS WILL BE SET BY MATT
window_choice = menu('Choice a type of window to apply to the data:',
...
'1. Uniform (P000)', '2. Hanning (P110)', '3. Flat top (P301)', '4.
P310 Window', ...
'5. Exponential', '6. Force');
% Asking the user if they want to use cyclic averaging, overlapping, or
% either
cyclic_overlap_choice = menu('Do you want to use Cyclic Averaging,
Overlapping or Neither?', ...
'1. Cyclic Averaging', '2. Overlapping', '3. Neither');
if cyclic_overlap_choice == 1
% Since NO overlapping, setting parameter to zero
overlap = 0;
% Finding the number of cyclic averages
n_cyclic_c = inputdlg({'Enter the number of cyclic averages:'},
'Cyclic Averaging', ...
1, {'5'});
n_cyclic = str2num(n_cyclic_c{1});
% Checking to make sure that the number of cyclic averages is a
% multiple of the total number of data points and that the
blocksize *
% n_cyclics isn't greater then the number of data points
while rem(number_data_point, n_cyclic) ~= 0 | n_cyclic * blocksize
> number_data_point
disp(['The number of cyclic averages is NOT a multiple of the
total number of data points: ' ...
num2str(number_data_point)]);
disp(['or'])
disp(['The number of cyclic averages (' num2str(n_cyclic) ') *
blocksize (' num2str(blocksize) ...
') is greater then the total number of data points ('
num2str(number_data_point) ')'])
75
n_cyclic_c = inputdlg({'Enter a different amount for the number
of cyclic averages:'}, ...
'Error in choicing the number of cyclic averages', 1,
{'5'});
n_cyclic = str2num(n_cyclic_c{1});
end
elseif cyclic_overlap_choice == 2
% Since NO cyclic averaging, setting parameter to one
n_cyclic = 1;
% Finding out the amount of overlap to apply to the data
overlap_c = inputdlg({'Enter the amount of overlap (%)'},
'Overlapping', 1, {'25'});
overlap = str2num(overlap_c{1});
elseif cyclic_overlap_choice == 3
% Since there is NO overlapping or cyclic averaging being used
values
% are being set to the following values:
n_cyclic = 1;
overlap = 0;
end
% Finding how the number of averages that are available with the data
set
% and the user inputs (n_cyclic, overlapping, blocksize)
possible_n_averages = floor((number_data_point +
(overlap/100)*number_data_point) ...
/ (n_cyclic*blocksize));
n_averages_c = inputdlg({['With the following settings: n_cyclic ('
num2str(n_cyclic) '), percent overlap (' ...
num2str(overlap) '%), blocksize (' num2str(blocksize) '), &
total data points(' num2str(number_data_point) ...
') - the maximum number of averages in below:']}, 'Number
of averages to be used', 1, {[num2str(possible_n_averages)]});
n_averages = str2num(n_averages_c{1});
% Making sure the number of averages in below the maximum
while n_averages > possible_n_averages
disp(['The number of averages is greater then the maximum allowed
with the settings: (' ...
num2str(possible_n_averages) ')'])
n_averages_c = inputdlg({['With the following settings: n_cyclic ('
num2str(n_cyclic) '), percent overlap (' ...
num2str(overlap) '%), blocksize (' num2str(blocksize) '), &
total data points(' num2str(number_data_point) ...
') - the maximum number of averages in below:']}, 'Number
of averages to be used', 1, {[num2str(possible_n_averages)]});
n_averages = str2num(n_averages_c{1});
end
% Call the window function that will produce a vector that a length of
% (n_cyclic * blocksize)
disp(' '); disp('Calling the window function'); disp(' ');
window_to_apply = window(n_cyclic*blocksize, window_choice);
% Debug statement
if debug == 1; figure; plot(window_to_apply); end
76
% Running the load_data script. The script will output two matrices
that
% have this form
% COLUMNS --> time points
% ROWS --> input / output number
disp(' '); disp('Calling the load_data function'); disp(' ');
tic
[input_matrix, output_matrix, input_location] = load_data(A);
toc
% Debug statement clearing variables
if debug == 0; clear A *_c; end
% Applying cyclic averaging or overlapping depending what the user
wants
% If the user doesn't use cyclic or averaging, in the last part of the
if
% statement, the window is applied to the data only against the number
of
% averages the user wants
if n_cyclic > 1;
disp(' '); disp('Calling the cyclic_averaging function'); disp('
');
[aver_input_matrix, aver_output_matrix] =
cyclic_averaging(n_cyclic, blocksize, input_matrix, output_matrix,
window_to_apply, n_averages);
elseif overlap > 0;
disp(' '); disp('Calling the overlapping function'); disp(' ');
[aver_input_matrix, aver_output_matrix] = overlapping(overlap,
blocksize, input_matrix, output_matrix, window_to_apply, n_averages);
else
disp(' '); disp('Cyclic averaging or Overlapping wasn''t used for
this data set.'); disp(' ');
% Applying window to the data (input) over the number of averages.
aver_input_matrix = zeros(size(input_matrix,1),
blocksize*n_averages);
for input_counter = 1:1:size(input_matrix,1);
block_place = 0;
for average_place = 1:1:n_averages;
aver_input_matrix(input_counter,
1+block_place:average_place*blocksize) = ...
window_to_apply .* input_matrix(input_counter,
1+block_place: average_place*blocksize);
block_place = blocksize + block_place;
end
end
% Applying window to the data (output) over the number of averages.
aver_output_matrix = zeros(size(output_matrix,1),
blocksize*n_averages);
for output_counter = 1:1:size(output_matrix,1);
block_place = 0;
for average_place = 1:1:n_averages;
aver_output_matrix(output_counter,
1+block_place:average_place*blocksize) = ...
77
window_to_apply .* output_matrix(output_counter,
1+block_place: average_place*blocksize);
block_place = blocksize + block_place;
end
end
end
% Removing the input_matrix and output_matrix to free memory
if debug == 0; clear input_matrix output_matrix; end
% Calling the autopower function
disp(' '); disp('Calling the autopower function'); disp(' ');
[GXXpp] = autopower(aver_output_matrix, aver_input_matrix, n_averages,
blocksize);
% Calling the crosspower function
disp(' '); disp('Calling the crosspower function'); disp(' ');
[GXXst, GXFpq, GFFst, GFXqp] = crosspower(aver_output_matrix,
aver_input_matrix, n_averages ,blocksize);
if GFFst==0
disp('There are no inputs! FRFs will not be calculated.')
% Calling the plot_output function
% Inside this function it calls another function called SUPERTITLE
disp(' '); disp('Calling the plot_output2 function for all data');
disp(' ');
[null]=plot_output2(GXXst,freq,blocksize,window_choice,cyclic_overlap_c
hoice,overlap,n_cyclic);
else
% Calling the H1 function
disp(' '); disp('Calling the H1 function'); disp(' ');
h_1 = H1(GXFpq, GFFst);
% Calling the Hv function
disp(' '); disp('Calling the Hv function'); disp(' ');
h_v = Hv(GXXpp, GFFst, GXFpq, GFXqp);
% Calling the H2 function
disp(' '); disp('Calling the H2 function'); disp(' ');
h_2 = H2(GFXqp, GXXst);
% Calling the multicohere function for H1
% WITH THE EQUATION FOR MULTICOHERE THAT WE USE YOU CAN ONLY
CALCULATE
% MULTICOHERE FOR H1!!!!!!!!!!!!!!!!!!!!!!!!!!!
disp(' '); disp('Calling the multicohere function for H1'); disp('
');
[h1_mcoh] = multicohere(h_1, GFFst, GXXpp);
% Calling the multicohere function for Hv
% THIS IS ONLY BEING DUE TO SHOW WHY YOU CAN'T USING THE Hv IN THE
% MULTICOHERE EQUATION!!!!!!!!!!!!!!!!
disp(' '); disp('Calling the multicohere function for Hv'); disp('
');
[hv_mcoh] = multicohere(h_v, GFFst, GXXpp);
78
% Calling the peak_picker function
%disp(' '); disp('Calling the peak_picker function for H1'); disp('
');
%peak_location_h1 = 0;
%[peak_location_h1] = peak_picker(h_1, freq);
% Calling the plot_output function
% Inside this function it calls another function called SUPERTITLE
disp(' '); disp('Calling the plot_output function for all data');
disp(' ');
[null]=plot_output(h_2,h_1,h_v,freq,h1_mcoh,hv_mcoh,blocksize,window_ch
oice,cyclic_overlap_choice,overlap,n_cyclic,input_location);
end
toc
% Asking the user if he wants to save data to a file.
save_data_answer = menu('Do you want to save the analyzed data?',
'YES', 'NO');
if GFFst==0
switch save_data_answer
case 1
save_filename_c = inputdlg({['Enter the filename for the saved
data (w/o .mat)']}, 'Filename', 1, {['analyzed_data']});
eval(['save ' save_filename_c{1} ' freq GFFst GFXqp GXFpq GXXpp
GXXst window_choice blocksize' ...
' f_sam overlap n_cyclic n_averages cyclic_overlap_choice
input_location'])
case 2
disp('NO data was saved to a file')
end
else
switch save_data_answer
case 1
save_filename_c = inputdlg({['Enter the filename for the saved
data (w/o .mat)']}, 'Filename', 1, {['analyzed_data']});
eval(['save ' save_filename_c{1} ' freq h_1 h_2 h_v h1_mcoh
hv_mcoh window_choice blocksize' ...
' f_sam overlap n_cyclic n_averages cyclic_overlap_choice
input_location'])
case 2
disp('NO data was saved to a file')
end
end
disp('Thanks for using the MASTER_SCRIPT. Have a GREAT day!!!')
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
B.3
Windows
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
79
function [window]=Window(block_size,window_flag)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
Function: window.m
%
Author(s): Matt Giachetto, Jim Parker, Ray Martell, Dan Alford
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
A script function to generate the window for "block_size" points
%
%
Inputs:
%
block_size = number of data points to generate within window
%
window_flag = 1 for uniform rectangular window P000
%
= 2 for hanning window P110
%
= 3 for flat top window P301
%
= 4 for P310 window
%
= 5 for exponential window
%
= 6 for force window
%
%
Outputs:
%
window = the points in the window vector
%
%
Function call syntax:
%
[window] = Window(block_size,window_flag)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%
rev 1.0
11/20/03
Initial release
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
Check input arguments
%
if nargin ~= 2; % make sure that block_size & window_flag are inputs
error('The window function was called incorrectly! Type: help
window');
end
if window_flag < 1 | window_flag > 6; % check for a valid window_flag
error('The window_flag must be 1, 2, 3, 4, 5, or 6! Type: help
window');
end
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
Determine the window
%
switch window_flag
case 1, % uniform rectangular window P000
window=ones(1,block_size);
case 2, % Hanning window P110
for k=1:block_size
window(k)=1-cos(2*pi*k/block_size);
end
case 3, % Flat top window P301
a0 = 0.9994484;
a1 = -0.955728;
a2 = 0.539289;
a3 = -0.0915810;
for k=1:block_size
window(k)=a0 + 2*a1*cos(2*pi*k/block_size)+...
2*a2*cos(2*pi*2*k/block_size)+...
2*a3*cos(2*pi*3*k/block_size);
end
case 4, % P310 window
80
a0 = 1;
a1 = -0.684988;
a2 = 0.202701;
a3 = -0.0177127;
for k=1:block_size
window(k)=a0 + 2*a1*cos(2*pi*k/block_size)+...
2*a2*cos(2*pi*2*k/block_size)+...
2*a3*cos(2*pi*3*k/block_size);
end
case 5, % exponential window
beta=-(log(0.01))/block_size; % calc beta for the exp window
for k=1:block_size
window(k)=exp(-beta*k); % calc the exp window
end
case 6, % force window
force_pts = round(0.1*block_size); % calc the length of the
force window
window=zeros(1,block_size); % initialize & zero the force
window
window(1:force_pts)=1;
% set the unit force window length
end
clear beta a0 a1 a2 a3 k force_pts;
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
B.4
Load Data
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
function [Input,Output,in]=load_data(A)
%
function [Input,Output]=load_data()
% Author(s): R. Martell, 11/20/03
%
$Revision: 1.1 $ $Date: 11/20/03
%
$Revision: 1.2 $ $Date: 11/21/03
%
:Removed actual file load will now work with previously
loaded variable U
%
:Added comments
%
$Revision: 1.3 $ $Date: 12/01/03
%
:Removed Sorting aspect of program
%
:Changed Function call to output sorting array for use in
other functions
%
$Revision: 2.0 $ $Date: 12/05/03
%
:Removed redundant varaiables
%
:Added Additional comments
%
$Revision: 3.0 $ $Date: 8/11/04
%
:Changed for WINDAQ data converted by dataq_convert.m
%
-Now uses loaded variable A
%
-a was replaced by b
%
-Removed serial number, location, direcetion, and
sensitivity matrix
%
-Moved if statement in loop and commented out, if an
input is present replace if statement
%
-Removed sorting
%
-Added user defined input(only valid for one input)
% Input/Output Argument checks
if nargout<3
disp('You need two output arguments: [Input,Output]=load_data(A)');
81
return
end
if nargin<1
disp('You need one input argument: [Input,Output]=load_data(A)');
return
end
count1=0;
count2=0;
% Counter for Input sorting
% Counter for Output sorting
%Asking for the location of the input
in_loc=inputdlg('Where is the input','Input Location');
in=str2num(in_loc{1});
% All counters take into account that the first five substructures in
the A variable are the Header and Units structures
% Actual data begins in the sixth substructure
for ii=1:size(A,1)-5,
count2=count2+1;
% Increment Counter
Output(count2,:)=A{ii+5}.DataValues.*str2num(A{ii+5}.CalibrationValue);
% extract data from structure, and scale appropriately
if ii==in;
count1=count1+1;
% Increment Counter
Input(count1,:)=A{ii+5}.DataValues.*str2num(A{ii+5}.CalibrationValue);
% extract data from structure, and scale appropriately
end
end
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%RAY's script for known inputs
%
%
%for ii=1:size(U,1)-2,
%
if ii==9 | ii==15
% If input is encountered
%
count1=count1+1;
%
Increment Counter
%
Input(count1,:)=U{ii+2}.DataValues.*a(ii,4)./1000;
%
extract data from structure, and scale appropriately
%
sortin(count1)=a(ii,2);
% fill
sorting vector
%
else
%
count2=count2+1;
%
Increment Counter
%
Output(count2,:)=U{ii+2}.DataValues.*a(ii,4)./1000;
%
extract data from structure, and scale appropriately
82
%
sortout(count2)=a(ii,2);
% fill
sorting vector
%
end
%end
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%DAN's script for known inputs
%
%
%for ii=1:size(A,1)-5,
%
if ii==1
% If input is encountered
%
count1=count1+1;
% Increment Counter
%
Input(count1,:)=A{ii+5}.DataValues.*str2num(A{ii+5}.CalibrationValue);
% extract data from structure, and scale appropriately
%
else
%
count2=count2+1;
% Increment Counter
%
Output(count2,:)=A{ii+5}.DataValues.*str2num(A{ii+5}.CalibrationValue);
% extract data from structure, and scale appropriately
%
end
%end
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
B.5
Cyclic Averaging
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
function [cyclic_input_matrix, cyclic_output_matrix] =
cyclic_averaging(n_cyclic, blocksize, input_matrix, output_matrix,
window_to_apply, n_averages);
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Function: cyclic_averaging.m
% By: Jim Parker
%
% This script will calculate the cyclic averages for both the inputs
and
% outputs signals of a modal test. It will calculate the number of
cyclic
% averages for any number of inputs and outputs.
%
% Inputs:
% n_cyclic = Number of cyclic averages
% blocksize = Number of data points in each block of data
% input_matrix = All the input data in the time domain
% output_matrix = All the output data in the time domain
% window_to_apply = vector of the window that is going to be applied to
the
%
data
83
% n_averages = number of averages that user wants
%
% Outputs:
% cyclic_input_matrix = matrix that contains the input data after
cyclic
%
averaging
% cyclic_output_matrix = matrix that contains the output data after
cyclic
%
averaging
%
% THE FORM FOR THE INPUT AND OUTPUT MATRIX MUST BE IN THIS FORM:
% ROWS --> NODE OR CHANNEL NUMBER
% COLUMNS --> TIME DATA POINTS
%
% Call this function like this:
% [in, out] = cyclic_averaging(n_cyclic, blocksize, input_matrix,
output_matrix, window_to_apply, n_averages);
%
% Version 1 - Date: 11/20/2003
%
- First version
%
% Version 1.1 - Date: 11/20/2003 - By: JMP
%
- Added checking for output arguments to the function
%
% Version 1.2 - Date: 11/23/2003 - By: JMP
%
- Added the window_to_apply to the number of inputs and the number
of averages.
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% Checking to make sure that there are enough inputs in the function so
it
% will work correctly
if nargin ~= 6 | nargout ~= 2;
error('There are NOT enough inputs or outputs to this function!
Type: help cyclic_averaging');
end
% Initializing variables to make script run
cyclic_input_matrix = zeros(size(input_matrix,1),
blocksize*n_averages);
cyclic_output_matrix = zeros(size(output_matrix,1),
blocksize*n_averages);
% Calculating the cyclic averages for the input_matrix
disp('Calculating the Cyclic Averages for the Input Matrix')
for input_counter = 1:1:size(input_matrix,1);
% Initializing place holders
blocksize_place = 0;
% Using a for loop to calculate the cyclic averages for the number
of
% average the user wants
for place_counter = 1:1:n_averages;
% Appling window over the BIG blocksize (blocksize * n_cyclic)
data_with_window = window_to_apply .*
input_matrix(input_counter, ...
84
1+blocksize_place*n_cyclic:blocksize*n_cyclic+blocksize_place*n_cyclic)
;
% Averaging the cyclic blocksize of data
% Initializing variable and place holder
sum_average = zeros(1,blocksize);
blocksize_counter = 0;
% Summing the small data blocksize to get the cyclic average
for cyclic_counter = 1:1:n_cyclic;
sum_average = data_with_window(1, ...
1+blocksize_counter:blocksize*cyclic_counter) +
sum_average;
blocksize_counter = blocksize + blocksize_counter;
end
average_window_block = sum_average / n_cyclic;
% Placing the data in the overall array
cyclic_input_matrix(input_counter, 1+blocksize_place: ...
blocksize*place_counter) = average_window_block;
blocksize_place = blocksize_place + blocksize;
end
end
% Calculating the cyclic averages for the output_matrix
disp('Calculating the Cyclic Averages for the Output Matrix')
for output_counter = 1:1:size(output_matrix,1);
% Initializing place holders
blocksize_place = 0;
% Using a for loop to calculate the cyclic averages for the number
of
% average the user wants
for place_counter = 1:1:n_averages;
% Appling window over the BIG blocksize (blocksize * n_cyclic)
data_with_window = window_to_apply .*
output_matrix(output_counter, ...
1+blocksize_place*n_cyclic:blocksize*n_cyclic+blocksize_place*n_cyclic)
;
% Averaging the cyclic blocksize of data
% Initializing variable and place holder
sum_average = zeros(1,blocksize);
blocksize_counter = 0;
% Summing the small data blocksize to get the cyclic average
for cyclic_counter = 1:1:n_cyclic;
sum_average = data_with_window(1, ...
1+blocksize_counter:blocksize*cyclic_counter) +
sum_average;
blocksize_counter = blocksize + blocksize_counter;
end
average_window_block = sum_average / n_cyclic;
% Placing the data in the overall array
cyclic_output_matrix(output_counter, 1+blocksize_place: ...
blocksize*place_counter) = average_window_block;
blocksize_place = blocksize_place + blocksize;
end
end
85
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
B.6
Overlapping
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
function [over_input_matrix, over_output_matrix] =
overlapping(percent_over, blocksize, input_matrix, output_matrix,
window_to_apply, n_averages);
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Function: overlapping.m
% Author(s): Jim Parker
%
% This function will apply a certain amount of overlap (user defined)
to
% the data for both the output and input. The function will work for
any
% number of inputs and outputs, but the input and output matrix must be
a
% certain form.
%
% THE FORM FOR THE INPUT AND OUTPUT MATRIX MUST BE IN THIS FORM:
% ROWS --> NODE OR CHANNEL NUMBER
% COLUMNS --> TIME DATA POINTS
%
% Inputs:
% percent_over = Percentage of overlap to apply to the data
% blocksize = Number of data points in each block of data
% input_matrix = All the input data in the time domain
% output_matrix = All the output data in the time domain
% window_to_apply = Vector that has the window to apply to the data
% n_averages = number of averages in the frequency domain
%
% Outputs:
% over_input_matrix = matrix that contains the input data after
overlapping
% over_output_matrix = matrix that contains the output data after
%
overlapping
%
% Call this function like this:
% [in, out] = overlapping(percent_over, blocksize, input_matrix,
output_matrix, window_type, n_averages);
%
% Version 1 - Date: 11/21/2003 - By: JMP
%
- First version
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% Checking to make sure that there are enough inputs in the function so
it
% will work correctly
if nargin ~= 6 | nargout ~= 2;
error('There are NOT enough inputs or outputs to this function!
Type: help overlapping');
end
86
n_cyclic = 1; % This has to be set so the windowing and other functions
work
% Initializing variables to make script run
over_input_matrix = zeros(size(input_matrix,1), blocksize*n_averages);
over_output_matrix = zeros(size(output_matrix,1),
blocksize*n_averages);
% Calculating the new input matrix with the window applied and
overlapping
% The new input matrix will have a length of blocksize * n_averages
for input_counter = 1:1:size(input_matrix,1);
% Applying the window to the all the data
% Initializing place holders
blocksize_place = 0;
overlap_place = blocksize - floor(blocksize*(percent_over/100));
for data_place = 1:1:n_averages;
if data_place == 1
over_input_matrix(input_counter,1:blocksize) =
window_to_apply .* ...
input_matrix(input_counter, 1:blocksize);
else
over_input_matrix(input_counter,1+blocksize_place:blocksize*data_place)
= ...
window_to_apply .* input_matrix(input_counter,
1+overlap_place: ...
overlap_place+blocksize);
overlap_place = blocksize + overlap_place floor(blocksize*(percent_over/100));
end
blocksize_place = blocksize_place + blocksize;
end
end
% Calculating the new output matrix with the window applied and
overlapping
% The new output matrix will have a length of blocksize * n_averages
for output_counter = 1:1:size(output_matrix,1);
% Applying the window to the all the data
% Initializing place holders
blocksize_place = 0;
overlap_place = blocksize - floor(blocksize*(percent_over/100));
for data_place = 1:1:n_averages;
if data_place == 1
over_output_matrix(output_counter,1:blocksize) =
window_to_apply .* ...
output_matrix(output_counter, 1:blocksize);
else
over_output_matrix(output_counter,1+blocksize_place:blocksize*data_plac
e) = ...
window_to_apply .* output_matrix(output_counter,
1+overlap_place: ...
overlap_place+blocksize);
overlap_place = blocksize + overlap_place floor(blocksize*(percent_over/100));
87
end
blocksize_place = blocksize_place + blocksize;
end
end
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
B.7
Autopower
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
function GXXpp=autopower(response,force,n,bs)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%
%Function File:autopower
%
%Computes the FFT of x(t) and f(t)
%Computes the autopower of X(w) and F(w)
%
%Daniel Alford
Ray Martell
Jim Parker
Matt Giachetto
%
%11/22/03
Created
%
%Revised
%11/24/03-------------Removed a=size(response) and b=size(force)
%11/24/03-------------Changed output format
%12/4/03--------------Commented out GFFqq (No longer used)
%
% Input:
%
Response matrix
%
r = node number
%
c = data points
%
%
Force matrix
%
r = node number
%
c = data points
%
%
n (number of averages)
%
%
bs (block size)
%
% Output:
%
GXXpp
(autopower)
%
# Needed to calculate COH & MCOH & Hv
%
r = Xp * Xp
%
c = 1 column
%
d = data points
%
%-------------------------No Longer Outputed-----------------------------------------%
%
%
GFFqq
(autopower)
%
r = Fq * Fq
%
c = 1 column
%
d = data points
%
%
This was useful for the single input case only. The crosspower
of GFFst
%
contains the autopower that was calculated here.
%
88
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%
%Changing format from r-c to r-d
x=zeros(size(response,1),1,size(response,2));
f=zeros(size(force,1),1,size(force,2));
x(:,1,:)=response;
f(:,1,:)=force;
%Initializing GXXpp and GFFqq
GXXpp = zeros(size(response,1),1,bs);
%GFFqq = zeros(size(force,1),1,bs);
%Creating autopower for X
%Loops through and sums block by block the autopower for each frequency
and then
%loops through to account for multiple outputs
for jj=1:size(response,1)
for ii=1:bs:n*bs
GXXpp(jj,1,:) = GXXpp(jj,1,:) + (fft(x(jj,1,ii:ii+bs-1),bs)) .*
conj((fft(x(jj,1,ii:ii+bs-1),bs)));
end
end
%-------------------------------------------------------------------------------------%
%Creating autopower for F
%for jj=1:size(force,1)
%for ii=1:bs:n*bs
%GFFqq(jj,1,:) = GFFqq(jj,1,:) + (fft(f(jj,1,ii:ii+bs-1),bs)) .*
conj((fft(f(jj,1,ii:ii+bs-1),bs)));
%end
%end
%-------------------------------------------------------------------------------------%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
B.8
Crosspower
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
function [GXXst,GXFpq,GFFst,GFXqp]=crosspower(response,force,n,bs)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%
%Function File:crosspower
%
%Computes the crosspower of X(w) to F(w) and F1(w) to F2(w) and X1(w)
to X2(w)
%
%Daniel Alford
Ray Martell
Jim Parker
Matt Giachetto
%
89
%11/20/03 Created
%
%Revised
%11/24/03-------------Removed a=size(response) and b=size(force)
%11/24/03-------------Added GFX
%11/24/03-------------Changed output format added complex to
initialization for speed purposes
%12/02/03-------------Added calculation of GXXst (Giachetto)
%12/4/03--------------Commented
%
% Input:
%
Response matrix
%
r = node number
%
c = data points
%
%
Force matrix
%
r = node number
%
c = data points
%
%
n (number of averages)
%
%
bs (block size)
%
% Output:
%
GXFpq
(crosspower)
%
# Needed to calculate H1 & Hv
%
r = Response crossed with Force
%
c = Response crossed with next Force
%
d = Data points
%
%
GFXqp
(crosspower)
%
# Needed to calculate H2 & Hv
%
r = Response crossed with Force
%
c = Response crossed with next Force
%
d = Data points
%
%
GFFst
(crosspower)
%
# Needed to calculate H1 & MCOH & Hv
%
r = Force crossed with next Force
%
c = next Force crossed with next Force
%
d = Data points
%
%
GXXst
(crosspower)
%
# Needed to calculate H2
%
r = Response crossed with next Response
%
c = next Response crossed with next Response
%
d = Data points
%
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%
%Changing format from r-c to r-d
x=zeros(size(response,1),1,size(response,2));
f=zeros(size(force,1),1,size(force,2));
x(:,1,:)=response;
f(:,1,:)=force;
90
%Initalizing GXFpq and GFFst and GFXqp and GXXst
GXFpq = complex(zeros(size(response,1),size(force,1),bs));
GFFst = complex(zeros(size(force,1),size(force,1),bs));
GFXqp = complex(zeros(size(response,1),size(force,1),bs));
GXXst = complex(zeros(size(response,1),size(response,1),bs));
add
% Matt
%Creating Input/Output crosspower matrix
%Loops through and sums block by block the crosspower for each
frequency and then
%loops through to account for multiple outputs and then loops through
to account for
%mutiple inputs
for kk = 1:size(force,1)
%kk
for jj = 1:size(response,1)
%jj
for ii = 1:bs:n*bs
%ii
GXFpq(jj,kk,1:bs) = GXFpq(jj,kk,1:bs) + (fft(x(jj,1,ii:ii+bs1),bs)) .* conj((fft(f(kk,1,ii:ii+bs-1),bs)));
GFXqp(jj,kk,1:bs) = GFXqp(jj,kk,1:bs) + (fft(f(kk,1,ii:ii+bs1),bs)) .* conj((fft(x(jj,1,ii:ii+bs-1),bs)));
end
end
end
%Creating Input/Input crosspower matrix
%Loops through and sums block by block the crosspower for each
frequency and then
%loops through to account for multiple inputs
for kk = 1:size(force,1)
%%kk
for jj = 1:size(force,1)
%jj
for ii = 1:bs:n*bs
%ii
GFFst(jj,kk,1:bs) = GFFst(jj,kk,1:bs) + (fft(f(jj,1,ii:ii+bs1),bs)) .* conj((fft(f(kk,1,ii:ii+bs-1),bs)));
end
end
end
%Creating Output/Output crosspower matrix (% Matt add)
%Loops through and sums block by block the crosspower for each
frequency and then
%loops through to account for multiple outputs
for kk = 1:size(response,1)
for jj = 1:size(response,1)
for ii = 1:bs:n*bs
GXXst(jj,kk,1:bs) = GXXst(jj,kk,1:bs) + (fft(x(jj,1,ii:ii+bs1),bs)) .* conj((fft(x(kk,1,ii:ii+bs-1),bs)));
91
end
end
end
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
B.9
H1
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
function H=H1(GXFpq,GFFst)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%
%Function File:H1
%
%Computes the H1 FRF estimator
%
%Daniel Alford
Ray Martell
Jim Parker
Matt Giachetto
%
%11/20/03 Created
%
%Revised
%11/21/03-----------Revised to create 3d matrix
%11/24/03-----------Remove a=size and b=size and making script work
%11/24/03-----------Changed input format
%11/25/03-----------Changed H1 function to use GFFst and NOT GFFqq
because
%this is a multiple input system!!!!!! The function now loops through
%frequency and NOT number of inputs and outputs.
%12/4/03------------Commented
%
%
% Input:
%
GXFpq
(crosspower)
%
r = Response crossed with Force
%
c = Response crossed with next Force
%
d = Data points
%
%
GFFst
(crosspower of forces)
%
r = Fs (number of inputs)
%
c = Ft (number of inputs)
%
d = data points
%
% Output:
%
H
(FRF)
%
# Needed to calculate MCOH
%
r = Response crossed with Force
%
c = Response crossed with next Force
%
d = Data points
%
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%
%Initalizing H
H = complex(zeros(size(GXFpq,1), size(GFFst, 1), size(GXFpq,3)));
% Calculating the H1 by looping through the frequency
for freq_spot = 1:1:size(GXFpq,3);
92
H(:,:,freq_spot) = GXFpq(:,:,freq_spot) * inv(GFFst(:,:,freq_spot));
end
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
B.10
Hv
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
function [Hv]=Hv(GXXpp,GFFst,GXFpq,GFXqp)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
Function: window.m
%
Author(s): D. Alford, M. Giachetto, R. Martell, J. Parker
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
A script function to generate the FRF Hv
%
%
Inputs:
%
GXXpp
(autopower)
%
r = Xp * Xp
%
c = 1 column
%
d = data points
%
GFFst
(crosspower)
%
r = Force crossed with next Force
%
c = next Force crossed with next Force
%
d = Data points
%
GXFpq
(crosspower)
%
r = Response crossed with Force
%
c = Response crossed with next Force
%
d = Data points
%
GFXqp
(crosspower)
%
r = Response crossed with Force
%
c = Response crossed with next Force
%
d = Data points
%
%
Outputs:
%
Hv = (FRF)
%
r = Response crossed with Force
%
c = Response crossed with next Force
%
d = Data points
%
%
Function call syntax:
%
[Hv]=Hv(GXXpp,GFFst,GXFpq,GFXqp)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%
rev 1.0
11/22/03
Initial release
%
rev 2.0
11/24/03
Fixed location of hermitian in GXFFp
%
rev 3.0
11/24/03
Changed index
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
Check input arguments
%
if nargin ~= 4; % make sure that there are 4 inputs
error('The Hv function was called incorrectly! Type: help Hv');
end
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%
Get size dimensions for counters
%
response_steps=size(GXFpq); response_steps=response_steps(1);
force_steps=size(GXFpq); force_steps=force_steps(2);
93
time_steps=size(GXFpq); time_steps=time_steps(3);
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%
Concatenate the GXFFp matrix and solve the eigen value
%
problem for each frequency then for each output
%
for jj=1:response_steps;
for ii=1:time_steps;
% assemble the GXFFp matrix: [inputs+1, inputs+1]
GXFFp=[GXXpp(jj,1,ii),GXFpq(jj,:,ii);GFXqp(jj,:,ii).',GFFst(:,:,ii)];
% solve the eigen values and eigen vectors
[x,d]=eig(GXFFp);
% sort the eigen vectors by their eigen values smallest to
largest
orig_lambda=diag(d);
[Y,I]=sort(real(orig_lambda));
lambda=orig_lambda(I);
% just take the eigen vector with the smallest eigen value
psi=x(:,I);
% normalize the vector so the first component (1,1) is -1
Hv(jj,:,ii)=-psi(:,1)/psi(1,1);
end;
end;
% drop the forst component that is -1
Hv=Hv(:,2:force_steps+1,:);
% Take the congugate
% This is being done because our format of the equation is different
from
% the MATLAB formation for the EIG command!!!
Hv=conj(Hv);
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
B.11
H2
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
function H=H2(GFXqp, GXXst);
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
Function: H2.m
%
Author(s): D. Alford, M. Giachetto, R. Martell, J. Parker
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
A script function to generate the FRF H2
%
% Input:
% GFXqp (crosspower)
%
r = Response crossed with Force
%
c = Response crossed with next Force
%
d = Data points
%
%
GXXst (crosspower of response)
%
r = Xs (number of outputs)
%
c = Xt (number of outputs)
%
d = data points
%
% Output:
%
H (FRF)
%
r = Response crossed with Force
94
%
c = Response crossed with next Force
%
d = Data points
%
%
%
Function call syntax:
%
[H]=H2(GFXqp, GXXst);
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%
rev 1.0
12/02/03
Initial release
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% initialize the complex H matrix
H = complex(zeros(size(GFXqp,1), size(GFXqp, 2), size(GFXqp,3)));
% calculate H2 by looping through the frequency
for freq_spot = 1:1:size(GFXqp,3);
H(:,:,freq_spot) = GXXst(:,:,freq_spot) *
pinv(GFXqp(:,:,freq_spot)).';
end
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
B.12
Multiple Coherence for H1
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
function [Co]=Cohere(GFFqq,GXXpp,GXFpq)
%
%
%
%
%
%
%
%
%
%
%
function [Co]=Cohere(Gff,Gxx,Gfx)
Author(s): R. Martell, 11/21/03
$Revision: 1.1 $ $Date: 11/20/03
Gff[q,N]
Gxx[p,N]
Gxf[p,N,q]
p = # outputs
q = # inputs
N = Frequency
for ii=1:size(GXFpq,2),
Direction of Gxf
for kk=1:size(GXXpp,1),
Direction
%Loop along Input
%Loop along Output
Co(kk,:,ii)=(GXFpq(kk,ii,:).*conj(GXFpq(kk,ii,:)))./(GFFqq(ii,:,:).*GXX
pp(kk,:,:));
%Formulate Coherence
end
end
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
B.13
Multiple Coherence for Hv
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
function [Coh]=multicohere(H,GFFst,GXXpp)
%
%
%
function [Coh]=multicohere(H,GFFst,GXXpp)
Author(s): R. Martell, 11/24/03
$Revision: 1.1 $ $Date: 11/24/03
95
%
$Revision: 1.2 $ $Date: 11/24/03
%
Changed matrix dimensions to match new Auto/Cross Power and
H
%
Changed variable names to match nomenclature in Vibes III
and SDA notes
%
$Revision: 1.3 $ $Date: 11/25/03
%
Verified code
%
Initialize temporary vaiable with complex valued zeros
%
$Revision: 2.0 $ $Date: 12/4/03
%
Added addition Comments
%
Final Draft
%
%
Matrix Dimensions Now
%
GFFst[q,q,N]
%
GXXpp[p,N]
%
H[p,q,N]
%
%
p = # outputs
%
q = # inputs
%
N = Frequency
%
% H_out=zeros(size(H,1),size(H,2),size(GFFst,3));
temp=(0+0*j).*ones(size(GXXpp,1),size(GXXpp,3),(size(GFFst,2)^2));
%Initailize Complex valued varibale for temp size [No x Blocksize x
Ni^2]
count=0;
% Counter for depth (Ni squared)
for s=1:size(GFFst,2), %s Input Dimension
for t=1:size(GFFst,2), %t Input Dimension
count=count+1;
%increment counter
for p=1:size(H,1),
% Output Dimension
temp(p,:,count) =
(H(p,s,:).*GFFst(s,t,:).*conj(H(p,t,:)))./GXXpp(p,:,:);
%Calculate
Multiple Coherence for all frequencies for a single output/input
end
end
end
Coh=sum(temp,3);
% Sum along 3rd dimension to create [No x Blocksize]
matrix
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
B.14
Plot Output
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
function
[null]=plot_output(h_2,h_1,h_v,freq,h1_mcoh,hv_mcoh,blocksize,window_ch
oice,cyclic_overlap_choice,overlap,n_cyclic,input_location)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
Function:
plot_output.m
%
Author(s): Jim Parker, Ray Martell, Dan Alford, Matt Giachetto
%
%
This script generates several plots to display the results
%
of the frequency response function (FRF) analysis.
%
96
%
rev 1
11/28/2003
initial release
%
rev 2
11/30/2003
changed plot format
%
rev 3
12/01/2003
removed phase from multicoherence plot
%
added H2 to the FRF comparison plot
%
rev 4
12/03/2003
changed plot axis
%
rev 5
8/17/2004
programed for user defined input
location(only valid for single input)
%
removed several plots
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
Check input arguments
if nargin ~= 12; % make sure that there are 12 inputs
error('The plot_output function was called incorrectly! Type: help
plot_output');
end
%
Set up string information
blocksize_s=num2str(blocksize);
switch window_choice
case 1, window_s='Uniform Window P000';
case 2, window_s='Hanning Window P110';
case 3, window_s='Flat Top Window P301';
case 4, window_s='P310 Window';
case 5, window_s='Exponential Window';
case 6, window_s='Force Window';
end
switch cyclic_overlap_choice
case 1,
overlap_s='None';
n_cyclic_s=num2str(n_cyclic);
case 2,
overlap_s=num2str(overlap);
n_cyclic_s='None';
case 3,
overlap_s='None';
n_cyclic_s='None';
end
%
Assemble strings for output on plots
str1 = ['Block size = ',num2str(blocksize)];
str2 = [window_s];
str3 = ['Overlap = ',overlap_s];
str4 = ['Cycles ave. = ',n_cyclic_s];
%
Get size dimensions for counters
response_steps=size(h_v); response_steps=response_steps(1);
force_steps=size(h_v); force_steps=force_steps(2);
time_steps=size(h_v); time_steps=time_steps(3);
%
Set up the color vector for a maximum of 50 outputs
color=['k','b','r','g','y','m','c','k','b','r','g','y','m','c',...
'k','b','r','g','y','m','c','k','b','r','g','y','m','c',...
'k','b','r','g','y','m','c','k','b','r','g','y','m','c',...
'k','b','r','g','y','m','c','k'];
97
%
Extract each force-response pair from the FRF H1, H2, and Hv
for kk = 1:force_steps
for jj = 1:response_steps
% H1
my_str =
['h1_out_',int2str(jj),'_in_',int2str(kk),'=zeros(1,',int2str(time_step
s),');'];
eval(my_str);
my_str =
['h1_out_',int2str(jj),'_in_',int2str(kk),'(1,:)=h_1(',int2str(jj),',',
int2str(kk),',:);'];
eval(my_str);
% Hv
my_str =
['hv_out_',int2str(jj),'_in_',int2str(kk),'=zeros(1,',int2str(time_step
s),');'];
eval(my_str);
my_str =
['hv_out_',int2str(jj),'_in_',int2str(kk),'(1,:)=h_v(',int2str(jj),',',
int2str(kk),',:);'];
eval(my_str);
% H2
my_str =
['h2_out_',int2str(jj),'_in_',int2str(kk),'=zeros(1,',int2str(time_step
s),');'];
eval(my_str);
my_str =
['h2_out_',int2str(jj),'_in_',int2str(kk),'(1,:)=h_2(',int2str(jj),',',
int2str(kk),',:);'];
eval(my_str);
end;
end;
%
Hv Input on each output plot
figure;
subplot(3,1,1);
hold on;
for jj=1:response_steps;
my_str=['plot(freq(1:time_steps/2),(angle(hv_out_',int2str(jj),'_in_1(1
:time_steps/2))*180/pi),''',color(jj),''');'];
eval(my_str);
end
title(strcat(str1,' : ',str2,' : ',str3,' : ',str4));
set(gca,'XGrid','on');
ylabel('Phase (Degrees)');
%axis([0 (freq(time_steps/2)) -200 200]);
hold off;
subplot(3,1,2:3);
for jj=1:response_steps;
my_str=['plot(freq(1:time_steps/2),abs(hv_out_',int2str(jj),'_in_1(1:ti
me_steps/2)),''',color(jj),''');'];
98
eval(my_str);
hold on; % gotta plot one function prior to hold on to establish
log y axis
end
set(gca,'XGrid','on');
xlabel('Frequency (Hz)');
ylabel('Amplitude X/F');
axis([0 (freq(time_steps/2)) 0.5 1.5]);
hold off;
supertitle(strcat('FRF Hv -- Input 1 On Each Output'));
%
H1 multicohere plot
figure;
title(strcat(str1,' : ',str2,' : ',str3,' : ',str4));
hold on;
for jj=1:response_steps;
my_str=['plot(freq(1:time_steps/2),abs(h1_mcoh(',int2str(jj),',1:time_s
teps/2)),''',color(jj),''');'];
eval(my_str);
end
set(gca,'XGrid','on');
xlabel('Frequency (Hz)');
ylabel('Coherence');
axis([0 (freq(time_steps/2)) 0 1]);
hold off;
supertitle(strcat('H1 Multiple Coherence -- On Each Output'));
null=0;
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
B.15
Plot Output 2
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
function
[null]=plot_output2(GXXst,freq,blocksize,window_choice,cyclic_overlap_c
hoice,overlap,n_cyclic)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
Function:
plot_output2.m
%
Author(s): Dan Alford
%
%
This script generates several plots to display the results
%
of the autopower analysis.
%
%
rev 1
8/12/2004
initial release
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
Check input arguments
if nargin ~= 7; % make sure that there are 10 inputs
error('The plot_output2 function was called incorrectly! Type: help
plot_output');
end
%
Set up string information
blocksize_s=num2str(blocksize);
99
switch window_choice
case 1, window_s='Uniform Window P000';
case 2, window_s='Hanning Window P110';
case 3, window_s='Flat Top Window P301';
case 4, window_s='P310 Window';
case 5, window_s='Exponential Window';
case 6, window_s='Force Window';
end
switch cyclic_overlap_choice
case 1,
overlap_s='None';
n_cyclic_s=num2str(n_cyclic);
case 2,
overlap_s=num2str(overlap);
n_cyclic_s='None';
case 3,
overlap_s='None';
n_cyclic_s='None';
end
%
Assemble strings for output on plots
str1 = ['Block size = ',num2str(blocksize)];
str2 = [window_s];
str3 = ['Overlap = ',overlap_s];
str4 = ['Cycles ave. = ',n_cyclic_s];
%
Get size dimensions for counters
response_steps=size(GXXst); response_steps=response_steps(1);
force_steps=size(GXXst); force_steps=force_steps(2);
time_steps=size(GXXst); time_steps=time_steps(3);
%
Set up the color vector for a maximum of 50 outputs
color=['k','b','r','g','y','m','c','k','b','r','g','y','m','c',...
'k','b','r','g','y','m','c','k','b','r','g','y','m','c',...
'k','b','r','g','y','m','c','k','b','r','g','y','m','c',...
'k','b','r','g','y','m','c','k'];
%
Extract the data points for each channel of GXXst
for kk = 1:force_steps
for jj = 1:response_steps
% GXXst
my_str =
['GXXst_out_',int2str(jj),'_in_',int2str(kk),'=complex(zeros(1,',int2st
r(time_steps),'));'];
eval(my_str);
my_str =
['GXXst_out_',int2str(jj),'_in_',int2str(kk),'(1,:)=GXXst(',int2str(jj)
,',',int2str(kk),',:);'];
eval(my_str);
end;
end;
% Plotting autopowers
figure;
subplot(3,1,1);
100
hold on;
for ii=1:response_steps
my_str=['plot(freq(1:time_steps/2),(angle(GXXst_out_',int2str(ii),'_in_
',int2str(ii),'(1:time_steps/2))*180/pi),''',color(ii),''');'];
eval(my_str);
end
title(strcat(str1,' : ',str2,' : ',str3,' : ',str4));
set(gca,'XGrid','on');
ylabel('Phase (Degrees)');
axis([0 (freq(time_steps/2)) -200 200]);
hold off;
subplot(3,1,2:3);
for ii=1:response_steps
my_str=['semilogy(freq(1:time_steps/2),abs(GXXst_out_',int2str(ii),'_in
_',int2str(ii),'(1:time_steps/2)),''',color(ii),''');'];
eval(my_str);
hold on; % gotta plot one function prior to hold on to establish log
y axis
end
set(gca,'XGrid','on');
xlabel('Frequency (Hz)');
ylabel('Log Amplitude Autopower');
axis([0 (freq(time_steps/2)) 0.001 10000]);
hold off;
supertitle(strcat('Autopowers of Outputs'));
null=0;
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
101