CIERRE DE ESPACIO INDUCIDO POR LA ALVEOLOCENTESIS SEGÚN

All data presented in this chapter was collected using the acoustic goniometer without the aid of any computer system for any part of the data processing. The ADC reader (Chapter 5.1.2) was used to collect raw data in order to check the performance of

the acoustic goniometer and provide further insight during analysis. All graphs showing raw data were generated using Matlab, and all raw data analysis was performed using the simulation algorithms described in Chapter 4.

As mentioned in Chapter 5.1.2, the ADC Reader has to store data as quickly as possible due to the large quantity of data collected at a significant sampling rate. One unfortunate consequence of this form of storage is a completely human unreadable data file (see Figure 6.1). The figure shows the stored data in the columns labeled 0-b. The “Address” and “Dump” columns show the address of the data within the file on the card and the computer’s attempt to display the data in ASCII characters, respectively. Figure 6.1 makes clear the need for the Hex File Processor program discussed in Chapter 5.1.2 for converting the file into a known/readable format for further processing in an analysis program. Another drawback to storing such a large amount of data so quickly is the lack of time stamps for correlating data in the raw file to detected events in the acoustic goniometer data file. Recording time stamps for each piece of raw data would be

impossible for the embedded platform while maintaining the necessary sample rate. Thus, all graphs of the raw data from the ADC Reader have an x-axis whose ticks measure 94 us (sampling period) starting from time zero rather than a specific date and time. While this is not ideal, the results are still accurately recorded and the data can still be used to serve its intended purpose.

Figure 6.1 ADC Reader Raw Data File

Previously, all data presented in this dissertation has been in the form of raw data collected from the acoustic goniometer’s ADC reader accompanied by post processing calculations and analysis. This chapter presents data from the actual acoustic goniometer calculated in real-time on the embedded hardware. Figure 6.2 shows an example of data recorded by the acoustic goniometer along with keys for interpreting the data. Since showing the recorded text files would do little other than clutter this document and poorly convey the performance of the goniometer, another method for presenting the data was selected. For the analysis of system performance presented in this chapter, the DOA calculations recorded by the acoustic goniometer are compared to the expected DOA in each test determined based off the known location of each event source. These

comparisons provide a metric for determining the percent error for each test, which is then averaged with similar (repeated) tests and reported. The data file example shown in the figure is presented merely to illustrate how the acoustic goniometer provides a DOA measurement without the need for any further processing. Two types of information packets are recorded in the data file shown in Figure 6.2: identifiers and measurements.

(a) Excerpt from Data File

(b) Identifier String Example with Interpretation Key

(c) Measurement String Examples with Interpretation Key Figure 6.2 Acoustic Goniometer Recorded Data

With any sensor system, recording important information about the sensor is necessary. Figure 6.2 (b) shows an example of an acoustic goniometer sensor identifier. The identifier packet starts with a label (I) defining it as an identifier followed by a unit number for the sensor system (Unit ID) used to identify it in the event if forms part of a sensor network. The third field provides a three digit number (Sensor ID) used to associate the sensor’s measurements with its identifier. Using the three digit number as opposed to the sensor’s name and units on every measurement saves space in the log file and reduces the strain on wireless communication in the event data must be transmitted. The following fields include a time stamp for the creation of the identifier (T=), a description of the sensor type (G=), a sensor model number (P=), and the units in which the sensor records data (D=). As should be expected, the acoustic goniometer consists of the 2 sensors (S=369 and S=370) shown in Figure 6.2 (a): azimuth (G= Goniometer_AZ)

and elevation (G= Goniometer_EL). For every detected event, each of these sensors reports a value to provide a complete DOA measurement.

Similarly to the identifier packets, the measurement packets can be broken down into several distinct components as shown in Figure 6.2 (c). The “M” at the front of the packet identifies it as a measurement. This is followed by the unit and sensor IDs and a time stamp indicating when the measurement was taken. The “Raw Value” referred to in the key usually represents raw/unprocessed data for most other sensor types. In the case of the acoustic goniometer sensors, this value is not merely unprocessed data but a debug value used to analyze other aspects of the system’s performance depending on the test being run. For example, a raw value of 0 for both azimuth and elevation is indicative of a calculation error (thus providing a means of checking the validity of the data for a given DOA measurement). Finally, the last field gives the final calculated value for the sensor. In the case of the acoustic goniometer, this is an angle measurement in degrees with respect to the positive x-axis and positive y-axis for the azimuth and elevation, respectively.

6.2 Laboratory Tests