Real-time Compression for Acoustic Array Time-Domain Data
From Navy 18.1 SBIR Solicitation
N181-067 TITLE: Real-time Compression for Acoustic Array Time-Domain Data
TECHNOLOGY AREA(S): Battlespace, Electronics, Sensors
ACQUISITION PROGRAM: PMS 485, Maritime Surveillance Systems Program Office
The technology within this topic is restricted under the International Traffic in Arms Regulation (ITAR), 22 CFR Parts 120-130, which controls the export and import of defense-related material and services, including export of sensitive technical data, or the Export Administration Regulation (EAR), 15 CFR Parts 730-774, which controls dual use items. Offerors must disclose any proposed use of foreign nationals (FNs), their country(ies) of origin, the type of visa or work permit possessed, and the statement of work (SOW) tasks intended for accomplishment by the FN(s) in accordance with section 5.4.c.(8) of the Announcement. Offerors are advised foreign nationals proposed to perform on this topic may be restricted due to the technical data under US Export Control Laws.
OBJECTIVE: Create innovative algorithms and software for commercial off-the-shelf (COTS) general-purpose computers and Digital Signal Processing (DSP) equipment capable of converting time-domain data from a passive acoustic array into a compressed data stream that can be transmitted via satellite communications (SATCOM) and rebuilt into a replica of the original data.
DESCRIPTION: The Navy is seeking solutions to enable data from acoustic arrays to be transmitted in real-time without degradation to shore facilities for processing by specialists. Such transmission solutions would reduce the need for installation of expensive data processing and display systems on ships and the requisite specially trained crewmembers on-board to perform real-time data analysis. Since the capability sought is expected to be fielded as software that can be integrated into the shipboard array processor system, the recurring cost to field the capability would be minimal.
Current surface Anti-Submarine Warfare (ASW) practice for Surveillance Towed Array Sensor System (SURTASS) ships requires installation of an expensive, custom-built data processing system on each ASW ship, because the data from the arrays is too large to be transmitted to shore in real-time via Navy satellite communications (SATCOM). The quantity of data expected to be created by next-generation arrays is even greater and available satellite data bandwidth is not expected to grow from its present size. Therefore, current and future ASW platforms need a lossless data compression capability that enables raw time-domain data from each element of the array (up to 256 channels simultaneously) to be transmitted to shore and reconstructed as an exact replica to enable accurate data processing and precise target localization.
A unique solution to acoustic data compression is required for this application. Unlike consumer audio applications in which psychoacoustic phenomena are leveraged and much of the inaudible data is selectively removed, the compression scheme must preserve the time-domain waveform precisely in both amplitude and time across all sensor channels in order for the array beamforming performance to be fully exploited by the DSP system. Additionally, unlike commercial audio applications, all sensor channels are receiving data from a common real-world physical source (e.g., there is not a guitar on one channel and a vocal on another); therefore, each channel is processing the same acoustic data, but with variations in amplitude and time among the channels. It may be assumed that the configuration of the sensors, including their spacing and bandwidth, is provided to the compression and decompression algorithm. Sampling rates may vary among sensor channels. It should be noted that ambient noise needs to be preserved in the compression, and electronically induced sensor noise can be assumed less than ambient noise (and therefore inconsequential).
The product for this effort is software source code that can be integrated into the Navy’s common processor system, which is based upon the Intel x86-64 platform and the Linux operating system. (Previously other SBIR-sponsored software projects have been integrated into this common processor system, and appropriate safeguards to protect the contributors’ intellectual property have been put in place.) A COTS DSP device may be used if required, but it will need to be integrated into the processor system. It is acceptable to leverage available open-source code. The objective ratio of compression is 80% compared to the raw array data stream with an input/output latency of less than one minute.
In summary, the capability includes the following characteristics that are not available in today’s lossless compression/de-coding schemes:
- Input has user-variable number of channels up to 256
- Output incorporates forward error correction (FEC) with automatic negotiation capable of supporting radio/satellite data links with a bit error rate of 0.01, end-to-end latency of two seconds, and data block outages of up to two seconds
- Including FEC, output is single data stream composed of 80% of the data volume compared to raw data
- Sample rates can be selected by the user in 1Hz intervals up to at least 96kHz
- Sample rates can vary among channels, but will be in integer multiples of each other
- After coding and de-coding, the time domain waveform shall be visually identical to the original with objective performance of true effective 16-bit resolution (96dB dynamic range), < 0.05% Total Harmonic Distortion (THD), frequency response accuracy +/- 0.1dB, and phase accuracy between channels of +/- 1 degree at 0.9*(Nyquist frequency/2)
- Coding and de-coding processing latency not to exceed one minute
Work produced in Phase II may become classified. Note: The prospective contractor(s) must be U.S. Owned and Operated with no Foreign Influence as defined by DOD 5220.22-M, National Industrial Security Program Operating Manual, unless acceptable mitigating procedures can and have been implemented and approved by the Defense Security Service (DSS). The selected contractor and/or subcontractor must be able to acquire and maintain a secret level facility and Personnel Security Clearances, in order to perform on advanced phases of this contract as set forth by DSS and NAVSEA in order to gain access to classified information pertaining to the national defense of the United States and its allies; this will be an inherent requirement. The selected company will be required to safeguard classified material IAW DoD 5220.22-M during the advance phases of this contract.
PHASE I: Develop a concept for real-time lossless compression for acoustic array time-domain data implementation and perform analysis, modeling, and/or a demonstration to support the technical recommendation. The Phase I Option, if awarded, will include the initial design specifications and capabilities description to build a prototype solution in Phase II. Develop a Phase II plan.
PHASE II: Using the requirements and concept of Phase I and the Phase II Statement of Work (SOW), develop and deliver a prototype for a complete implementation of the data compression and decoding capability. Demonstrate the prototype’s performance in a lab using real-life array data that will be supplied by the Navy. (Since this data is classified, this demonstration can be performed on accredited classified equipment in the performer’s facility or at a Navy facility.) Support a temporary installation of the compression capability aboard a Navy ship to demonstrate the performance of its design in an operational environment; support the installation of the decoding capability at a Navy shore site; and provide operational testing technical support and performance analysis. In preparation for a potential Phase III, provide an estimate of schedule, non-recurring cost, and product cost to support integration of the capability into the Navy processor system.
It is probable that the work under this effort will be classified under Phase II (see Description section for details).
PHASE III DUAL USE APPLICATIONS: Support the Navy in transitioning the technology to Navy use. Work with the Navy’s integrator to support the integration and testing of the capability into the Navy processing equipment on-board an operational SURTASS ship. Tasks may include software development, software quality assurance, cybersecurity support, development of documentation, and test support on shore and at-sea. Deliver future software/hardware builds of the processor system with the SBIR-developed integrated compression and de-coding capability.
Passive acoustic arrays are used in the oil industry and this data compression capability would have direct application for data storage or transmission via radio. As an example of a business case, this data compression capability could be used to decrease deployment costs significantly by enabling the use of a relatively inexpensive unmanned vessel to collect acoustic data rather than a ship with crew ($50k-100k/day).
1. Johnson, M., Partan, J., and Hurst, T. “Low Complexity Lossless Compression of Underwater Sound Recordings.” J. Acoust. Soc. Am., March 2013, Vol 133, No. 3, pp. 1387-1398. https://soundtags.st-andrews.ac.uk/files/2012/05/Johnson_etal_JASA2013.pdf
2. Liebchen, Tilman. “MPEG-4 ALS – The Standard for Lossless Audio Coding.” The Journal of the Acoustic Society of Korea, October 2009, vol. 28, no. 7. http://elvera.nue.tu-berlin.de/files/1216Liebchen2009.pdf
KEYWORDS: Audio; Lossless Compression; Acoustic Data Compression; Real-time Data Compression; Lossless Compression/De-coding Schemes; Data Compression; Communications in a Battlespace Environment
TPOC-1: Mandeep Nehra
TPOC-2: Mary Johnson
Submitted Proposal: A181-067-0655
Note: Formatting changed to suite web page layout, page title blocks, disclosure restriction blocks, and trade secret page, have been removed from text.
Volume Two: Technical Proposal for Phase I
1 Identification and Significance of the Problem or Opportunity
Acoustic Array Sensors simultaneously output a parallel set of data from each sensor detector for the sought sounds and ambient sounds being detected. Due to the close proximity, the similarity in detector operation, the similarity in digitization, and the post calibration processing whether included in the detector readout electronics or in the compression processing, the sought and ambient sounds all have a high degree of similarity but occurring at different time shifts depending on physical placement of the detectors and angles in which the detected sounds come in. Although there may be several sounds from different sources simultaneously being detected, these sounds all have a very high degree of correlation across the sensor array set which makes the data detected, highly compressible.
There is a need to compress the high volume of data from Acoustic Array Sensors with very little to no signal data degradation to allow it to be sent over a limited bandwidth SATCOM communications in real-time to a data processing center for detailed signal processing analysis and expert evaluation by specialists. This could greatly reduce the deployed sensor system usage cost compared to having the sensor processing equipment and sensor specialist on board to perform the analysis. The operation could then be with lower cost unmanned vessels, less costly operation with smaller crews, or deployment where the vessel operation is primarily for other work and toeing an Acoustic Array Sensor system is not a big inconvenience and has value.
Note: Through conversation with the topic authors, it has been acknowledged that non-acoustic noise is a moderate component that cannot be mathematically compressed, and that the target compression system is not expected to have lossless binary data compression to achieve the target compression range. The data compression is not expected to be a "Lossless Data Compression" (which has specific meaning), as stated in the Request for Proposal.
2 Phase I Technical Objectives.
The Phase I objectives are:
- Create a base compression program architecture for a IA x86 COTS Linux server for doing realtime compressing of blocks of varying length of samples for parallel channels of Acoustic Array Sensor that support multiple types of compression and decompression algorithms and new algorithms can be easily added. Some code components such as the post compression data management will be simplified preliminary components in Phase I. It is expected the overall compression system, software components, compression algorithms, and compression performance, will evolve over the 3 project phases.
- Create a decompression program matched to each version of compression program for IA x86 COTS Linux server that decompresses the data blocks. The compressor internally has a matched decompressor for each compression algorithm to keep a running difference of data to determine the binary data difference and determine when compression is done. This program just breaks out that decompressor portion of the compressor into a separate decompression program.
- Create an Acoustics Sensor Array Data Simulator including the ability to mix or feed real Acoustics Sensor Array data into the data which feeds the compression program. Would prefer having real unclassified Acoustics Sensor Array data, ideally from the target sensor, however, can be from a similar sensor array, as soon as possible, for compressor noise analysis, algorithm development, and ambient noise analysis, modeling, and compression. The Acoustics Sensor Array Data Simulator will also be used to feed precise data into various compression algorithms for algorithm development and testing.
- Create a document with detailed descriptions of the software architecture, software components (or modules), and analysis and compression algorithms in detail. Covers the preliminary compression algorithms and some performance measurement metrics. Invent, research, and document other possible compression algorithms and methods.
- There is no question that a full compression framework to support multiple methods can be created and some compression can be done. The only question is: Can the desired compression performance be achieved by end of Phase II work?
The overall Phase I objective is to create a preliminary real-time Acoustic Array Sensor compression and decompression program for a Linux server with a preliminary compression capability where multiple and different compression operations can be iteratively applied to the data blocks. It is expected that the Phase I algorithms used in the initial coding will not meet the compression rate goals for all possible data types, and that the algorithms and real-time code will be iteratively improved, and new compression with decompression algorithms will be added and improved as work progresses through the Phase I Option and Phase II, and possibly in the future phase III work.
3 Phase I Statement of WorkThe work for Phase I and Phase I Option are each 6 Months in length and will be conducted at Lightning Fast Data Technology Inc. Headquarters (3419 NE 166th Ave, Vancouver, WA 98682). However, some of the non-classified work might be done while in The Dalles, OR.
3.1 Overview of Realtime Acoustics Array Compression System
Shown in Figure 1: Real-Time Acoustics Array Compression System is the preliminary overall simplified diagram from the Acoustics Sensor Array to the SATCOM communications system. The compression program will be executing in an IA X86_64 COTS type system(s) running recent Linux. External to the server are some boxes for an overall operation discussion.
Figure 1: Real-Time Acoustics Array Compression System
3.2 High Level Compressed Data Block Format
The preliminary compressed data block has a format shown in Figure 2: Compress Data Block Format. This format allows locating the beginning and verification of a valid block intermixed with bad blocks, which might occur in SATCOM communications with such high error rates. All data is in little-endian format which is the native format of the x86 processor.
Figure 2: Compress Data Block Format
In addition to the compressed data blocks, some data set related blocks, such as general information about data, compression calibration data, channel information, etc. will be sent at beginning of data. In the end, the system will know the required blocks in a data set and can ask for them through COMSAT request feedback if they are lost due to transmission errors.
3.3 Data Center Receive Processing
Shown in Figure 3: Data Center Compressed Acoustics Array Receive System is a preliminary simplified diagram of a IA X86-64 COTS based system to receive, manage, decompress, and output the acoustics data into the data processing system at real-time rates.
Figure 3: Data Center Compressed Acoustics Array Receive System
3.4 Real-Time Acoustic Array Compression Process
The preliminary diagram in Figure 4: Real-Time Acoustics Sensor Array Compression Process is expanded from Real-Time Acoustics Sensor Array Compression Process box shown in Figure 1: Real-Time Acoustics Array Compression System. This is a multi-threaded process that does the multi-channel data compression processing and is the primary focus of this contract.
Figure 4: Real-Time Acoustics Sensor Array Compression Process
To decompress the data later, the a decompression algorithms for each compression block is executed to get a result and added to the other decompressed blocks to get the near original data block minus the uncompressible detector readout noise. Decompressing the difference block and adding it to the decompressed block gets back to the original binary data or the post calibrated sensor data, depending on what was saved in the difference data block.
Compression and decompression algorithms can incrementally evolve and new compression and decompression algorithms sets can be added as analysis and algorithm refinement work is done.
3.1 Noise Considerations
Non- sound detected sample data components, such as internal detector generated noise, electronic circuit noise, cross talk noise, A/D converter electronic and quantization noise, noise of any preprocessing and result rounding noise, and any other noise contained in the data not generated from sound stimulation, will just be grouped into Detector Readout Noise. Detector Readout Noise is predominately random, but probably with some colorization from averaging effects. True random data is not compressible, which makes Detector Readout Noise not compressible. This Detector Readout Noise forms a noise floor is which limits the accuracy of data and does not need to be sent if SATCOM communications bandwidth cannot support it.
3.2 Basis of Initial Compression Algorithm
Frequency analysis in the 5 data sets (closest to center, 4 outermost edges) will be used to find the primary data signals, incoming directions, and phase relationships. For wavelength frequency less than the spacing of the 5 data sensor positions, the number of cycle changes for the signal between the positions will need to be measured to determine accurate incoming angle(s). The data's frequency and phase angle will give a much more accurate waveform position than trying to do a mechanical sample by sample waveform curve match, even for impulse matching. However, some algorithms might use curve overlay matching and impulse data might be represented as a curve. Careful data set evaluations will determine the best methods.
Starting from largest to smallest, a model of the data segment for frequency, amplitude, direction, starting phase, and some other symbols to categorize bulk characteristics of how the waveform changes through the block, will be used in the compression blocks. The compressed block, removes the data for each waveform compressed. After the series of accurately compressed data is removed, the residual data should be fairly small. The residual is separated where the estimated Detector Readout Noise number of bits is sliced off the bottom, and the remaining residual representing detected data is compressed by a bit algorithm and becomes the last block compressed. The series of bulk waveforms and residual makes up the compressed data.
Isn't this cheating since this is what the end system is trying to measure and these measurements will bias the measurement results? Not at all, since the data blocks are short and measurement parameters are recalculated and restarted at the beginning of each compressed block. The residual data helps remove remaining compression error of the data block. Full data measurements at the data processing center will be across a larger block of data formed from a series of data blocks and estimation errors will become less significant. This is a method to isolate and compress the bulk data characteristics as fast as possible.
The theoretical shortest block would be 1 sample frame thick. For example, 20 bits could be used to represent 1 of a million possible symbols (data patterns) of the characteristics of data across data block, and with scale and rotation, this could encode data very efficiently. A frame might be made of 1 or more symbols. The symbol characteristics is static and known by both compressor and decompressor. This could work since there is always some form of relationship of the detected data across the sensor array, but no relation for the non-signal generated noise. Symbols can also be multiple samples thick, however matching to a large number of seemingly random symbols can be very difficult. An algorithm generated and matched algorithm might work. I suspect that a symbol compression method might be difficult to do. Symbol compression might be explored as an additional method after bulk signal compression has been developed. If there is a pattern of residual signal error across the data set, a basic symbol could represent this pattern. For example, the residual data starts small and increases toward the end of the data block, a symbol representing a cone shape could be used to compress the residual where it starts with compressing the residual with one bit, which goes to 2 bits in the center and 3 bits at the end. Another pattern might be an hour glass shape where residual is minimum at the center. Overall there is a multitude of possible ways to compress data. More methods can be found through thought experiments of the characteristics of particular data in hand (which is why processing and analysis of real data is important) and document research of digging through multitude of documents and books to find better methods that has already been done, or a method applied differently than before to create a new method.
3.3 DSP vs COTs IA x86
The IA x86 Xeon has a DSP instructions set, a Vector instruction set (multiple instructions at the same time), huge cache memories, can use 1 Gigabyte page memory (reducing data access overhead for virtual system) for efficient data memory access, and can do mathematics very fast, with the main problem of keeping the data available (memory reads are slow). Plucking of data across the memory will cause single data point per memory cache line reads, and would be slow. Ordering the data and processing so that most data is in the cache, when needed, can make a big difference. DSPs have the same problems and often without the resources. The ordering of data for DSPs to make them fast, also works with an x86. At 0.3 ns per complex instruction or math calculation, it difficult to find a cost effective DSP system that can outperform the Xeon with its multiple and parallel execution units in each core. Expecting many dedicated IA x86 CPU cores available for processing and not planning to use a DSP system for this project.
3.4 Phase I Tasks
3.4.1 Task 1: Research Acoustics Sensor Array Data Sequence Variability
The array can have up to 256 sensor channels running simultaneously, with sample rate selectable in 1 Hz intervals up to 96kHz. Sample rates can be different on some channels, but will be an integer multiple of one another. A thorough understanding of the possible data sequences and data rates and a plan on how a compression system could handle all of these variations has to be determined. It is also assumed that there is a small number of simultaneous data rates, and cases where every data channel has a different data rate, will never occur.
3.4.2 Task 2: Create the Base Compression Program
Using the preliminary block diagram in the COTS system portion shown in Figure 1: Real-Time Acoustics Array Compression System and the preliminary compression architecture in Figure 4: Real-Time Acoustics Sensor Array Compression Process create the base program to run in a Linux system. This program is with very basic operation and will be refined during the development process as needed. Some things like the SATCOM formatter and complex Data Storage and Management will be left to Phase II work. All coding work will be on an evolutionary path which will be iteratively improved through expended time rather than exact definition and exact delivery time. A much higher quality product can be evolved than can be guaranteed at the start, due to the learning and organization that occurs during the process.
3.4.3 Task 3: Create a Decompression Program
The compression and decompression algorithms are a matched set. The compression program contains both and this program breaks the decompression portion out. This Linux program will decompress a data file which contains a series of Compressed Data Blocks. If a difference data block follows the Compressed Data Block, both blocks will be used to reconstruct the original data block back to the original binary data. Tests will be ran with a sensor data set through the compression and decompression programs and compare with original data for errors and generate other data such as compression efficiencies, average block sizes, etc.
3.4.4 Task 4: Create an Acoustics Sensor Array Data Simulator
This program generates simulated acoustics sensor array data to feed the compression system. This will be used to generate some specific data with which allows testing and evaluation of the mathematical operations in the compression algorithms. May also generate some simulated environmental sound data and detector readout noise data for general signal processing tests. This will allow some modeling, demonstrate operation, and allow compression performance analysis. However, this program will have limitations, since it is just a stimulation tool for the data generated, and will not be generating data of a fully modeled acoustics sensor array.
In real-time mode, the simulator will generate data rates consistent with the acoustics arrays and to simulate the 16 bit multi-channel (up to 256 channels) digital sample feed rate at whatever data rates up to 96K samples per second, with the start of the set accurately timed by using the CPU internal 64 bit running clock counter as a reference. This data can then be used to show that the compression algorithms can keep up with the input data rates. Data is generated with the modeled data frequency content consistent with the set output sample rate. The sample rate is just a component of frequency wave generation that can be changed as needed.
This program will be able to feed stored sensor data at either real-time or non realtime rates. For real-time operation, it may require fast disk(s) like in the Data Store System discussed earlier.
3.4.5 Task 5: Research & Development Compression Algorithmsr
Search for and study articles and books related to audio compression methods, acoustics sensor array data processing, and general data compression methods. Do signal processing and compression of real acoustics sensor array data (if sensor data is available), look for compression issues, determine what the problems are, ponder ways to solve the problems and create algorithms to improve processing.
3.4.6 Task 6: Detailed Project and Algorithm Documentr
Document the software architecture, components and libraries. Document sensor data organization and buffering to support the organization since data organization and how it is directly used can greatly affect the signal processing performance. Document the waveform analysis methods providing data to the compression system, and it's good and poor properties. Document each compression algorithm used in the compression engine, test results, estimated compression performance (varies depending on data), and the good and poor properties of each.
3.4.7 Task 7: Test and Data Display Programr
A windows utility, testing, and GUI display program which connects to the compression program through a TCP/IP to monitor internal operations, plot data, and help develop the code and algorithms. Programs are coded to build and run on Linux, but due to the far superior debugger in the windows development environment, will probably build the most of code as a library and do some of the code debugging linked into in a Windows program where it is easy to set breakpoints and step through and closely examine and evaluate the program's code.
Can easily write windows display code to display data however it's needed. A possibility of a 3 dimensional plot that will graphically show progress from sensor or difference data to the next difference data that visually shows how the compression performed and how the residual data is spread across the data block. This may allow visualization of data compression mismatches that would be more difficult to see by than just looking at numbers. This is a development and convince tool, to help develop and evaluate some of the algorithms, and is added to as needed, rather than as a predefined program.
3.4.8 Task 8: Project Management
General project support and management. Work scheduling, planning, and progress tracking and review. SBIR, government contracting compliance review and planning.
3.4.9 Task 9: Phase I Monthly Status and Progress Reports
Status and Progress Reports document the status of overall project, the projects objectives for the month, the progress of each task, results obtained, and any concerns. Provided within 15 days after the completion of each month, but excludes the last month which is included in the Final Report.
3.4.10 Task 10: Preparation of Material for Meetings
Compile material for algorithms reports, data, and status into documents, Power Point presentations, and laptop demonstrations to present at the Sponsoring SYSCOM Facility.
3.4.11 Task 11: Meeting at SYSCOM Facility
For kickoff, mid-contract, and end of contract meetings, travel to contact officer selected facility for meetings to discuss presentations, program related information, and laptop demonstrations.
3.4.12 Task 12: Phase I Final Report
Contains detailed information for project objectives, work performed, results obtained, and estimates of technical feasibility. Provided within 30 days of Phase I completion.
3.5 Phase I Option Tasks
3.5.1 Option Task 1: Continue Improving Compression Program
The base program will be created quickly in Phase I, however the data analysis and compression program will be an ongoing effort that will take considerable time to improve the algorithms, create new compression algorithms, and improve pre-compression data analysis. Improvement will be an ongoing effort across the Phase I Option and Phase II programs.
3.5.2 Option Task 2: Continue Improving Decompression Program
Polishing of the decompression program to be used as a real-time decompression program as shown in Figure 3: Data Center Compressed Acoustics Array Receive System. And, the decompression software is a linkable library component used to create a simple command line, file set in with file out, decompression program that can be used by script files to do general decompression of the compressed files located on a general purpose Linux IA x86 computer. Improvement will be an ongoing effort across the Phase I Option and Phase II programs.
3.5.3 Option Task 3: Continue Improving Acoustics Sensor Array Data Simulator
As algorithms are refined, testing and simulated input data types and sets will need to be refined and be added to support more algorithms types and better sensor data simulation, and continue to be an ongoing effort across the Phase I Option and Phase II programs.
3.5.4 Option Task 4: Continue Research & Development of Compression Algorithms
Algorithm and methodology searches and study will continue. Analysis of the results of signal processing, studying the related data issues, thinking of how to solve the issues and forming new solutions to improve and create new algorithms will be an ongoing effort across the Phase I Option and Phase II programs.
3.5.5 Option Task 5: Continue Adding to the Project and Algorithm Document
As coding evolves, software architecture, components and code library documents will be updated. Continue documenting the new compression algorithms and improvements to the compression algorithms as the project progresses.
3.5.6 Option Task 6: Continue Improving the Test and Data Display Program
The Test and Data Display program will continue evolving as needed in support of the compression system development.
3.5.7 Option Task 7: Project Management
General project support and management. Work scheduling, planning, and progress tracking and review. SBIR, government contracting compliance review and planning.
3.5.8 Option Task 8: Initial Design Specification and Capabilities Description
Information from this proposal, diagrams, research and development, data, and initial test results will be used to create the Initial Design Specification and Capabilities Description document as called out in the request for proposal, which describes the prototype solution for Phase II.
3.5.9 Option Task 9: Create Phase II Proposal
Write the Phase II Proposal for "Real-time Compression for Acoustics Array Time-Domain Data".
3.5.10 Option Task 10: Phase I Option Monthly Status and Progress Reports
Same as described in Phase I, but for the Phase I Option time period.
3.5.11 Option Task 11: Preparation of Material for Phase I Option Meeting
Same as described in Phase I, but for the Phase I Option material.
3.5.12 Option Task 12: Phase I Option Meeting at Sponsoring SYSCOM Facility
The kickoff for Phase I Option will be done at same time as Phase I end of contract meeting. The Phase I Option mid-contract, and end of contract meetings, is to travel to contact officer selected facility for meeting to discuss presentations, program related information, and demonstrations.
3.5.13 Option Task 13: Phase I Option Final Report
Contains detailed information for project objectives, work performed, results obtained, and estimates of technical feasibility. Provided within 30 days of Phase I Option completion.
3.6 Schedule of Major Events
ww (work week) 2: Phase I kick-off meeting at SYSCOM facility.
ww6, ww11, ww15, ww20, ww24: Phase I Monthly Status and Progress Reports.
ww15: Phase I mid-project meeting at SYSCOM facility.
ww25: Phase I end of contract and Phase I Option kick-off meeting at SYSCOM facility.
ww26: Phase I deliverables: Phase I: Compression Program, Decompression Program, Acoustics Sensor Array Data Simulator, Test and Display Program, Detailed Project and Algorithm Document, and Program User's Manuals.
ww29: Phase I Final Report.
ww32, ww37, ww41, ww46, ww50: Phase I Option Monthly Status and Progress Reports.
ww35: Phase II Proposal, Initial Design Specification and Capabilities Description document.
ww40: Phase I Option mid-project meeting at SYSCOM facility.
ww51: Phase I Option end of contract meeting at SYSCOM facility.
ww52: Phase I Option deliverables: Phase I Option: Compression Program, Decompression Program, Acoustics Sensor Array Data Simulator, Test and Display Program, Detailed Project and Algorithm Document, and Program User's Manuals. ww58: Phase I Option Final Report.
Applies to Phase I and separate set for Phase I Option if the Phase I Option is exercised.
- Monthly Status and Progress Reports: May contain proprietary information, unless otherwise requested or 2 versions with and without proprietary information.
- Final Report(s): May contain proprietary information, unless otherwise requested, or 2 reports with and without proprietary information at contract officer's earlier request.
- Compression Program: Buildable program on Linux system. As Git repositories.
- Decompression Program: Buildable program on Linux system. As Git repositories.
- Acoustics Sensor Array Data Simulator: Buildable program on Linux system. As Git repositories.
- Test and Display Program: Buildable program on Window's system but also need to build code libraries for Window's from the Linux repositories. As Git repositories.
- Detailed Project and Algorithm Document: R&D Document of Project.
- Program User's Manuals: Documentation on how to build and general use of programs.
- Technical Meeting Presentation Documents: For meetings for discussion of technical algorithms and data, status, progress and ongoing contract plans. May contain proprietary information. Could also deliver versions with the proprietary information removed.
- Phase II Proposal: If Phase I Option exercised, the proposal for Phase II.
- Initial Design Specification and Capabilities Description Document, if Phase I Option exercised.
3.4 Technical Data Rights Assertions
|Technical Data for Restrictions||Basis of Assertion||Asserted Rights||Name of Person|
|Signal Power Measurement Algorithms||Contains proprietary trade secret algorithms developed at private expense. In process of applying for a patent.||Restricted (License)||Mike Polehn|
|Linux, Libs, DPDK, Components||Open Source Software||GPL, BSD Licenses||Open Source Community|
The high quality trade secret method (discussed later) that will be used in this project, also has use in general Array Sensor Signal Processing. These algorithms are Licensed only for this compression project through Phase III including licensed for the deployed system. This gives no rights to disclose elsewhere or to be used elsewhere. Other agreements and/or contracts are required for other uses. Standard SBIR data rights applies to all other parts of the contract.
4 Related Work.
Note: Acoustic Signal Processing has the same exact meaning as Audio Signal Processing. Different audio processing algorithms area used for different types of end results but does not separate acoustic and audio meaning. Digital Acoustic Signal Processing is a sub-category of Digital Signal Processing where Signal Processing is much more encompassing and represents the mathematics and methods of processing of real world data which usually includes noise data. (This being provided sense the evaluators of a different SBIR, didn't understand these relations.)
4.1 Sensor Signal Processing and Algorithm Development
Sensor Signal Processing R&D for 7 years at Boeing Aerospace. This included sensor signal processing algorithm development, sensor simulations, noise analysis, data measurement, sensor signal processing R&D reports, presentations, and designed, manufactured, tested, and delivered high performance pipeline digital signal processor hardware prototypes, along with a sensor emulator to the missile defense center in Huntsville, AL. Lead Engineer for creation of an improved sensor digital signal processing hardware prototype. The R&D work included an algorithm using correlation methods to do a 6 to 1 data compression while maintaining high data content integrity.
As an expert electrical optical engineer (from the Boeing experience) consultant for Northrop Grumman, L-3 Communications, and Sensors Unlimited in support of the infrared camera in the U2 “military asset”. Created a signal processing analysis program to analyze the camera data, improved the deployed sensor performance, and improved the camera testing program. Lead development engineer for creation of new sensor chip test program, which made testing easier, did better data measurements, and generated high-quality test reports. The camera system used correlation techniques to achieve a 12 to 1 data compression to reduce data rates for radio based communications to the ground based data analysis system. John Ueng-McHale, 609-649-5400. Mike Caro, 609-524-0341. 2003 to 2009, part time to 2014.
4.2 High Performance Real-Time Processing using COTS x86-64 Xeon
To help increase markets for Intel x86 Xeon processors, work used IA X86 Linux servers to run real-time packet processing, which is also directly applicable to doing real-time signal processing. On a single server, simultaneously achieved input/output data rates > 380 gigabit/sec with 20 10 GbE interfaces, did basic packet processing of > 180 million packets/sec, while utilizing 20 CPU cores executing real-time code in 10 VM (Virtual Machines). These were 60 second, 0 loss tests, but could have sustained operation and performance level indefinitely. Work included expert code and algorithm optimization. Intel, Trevor Cooper, (503)-696-2096, 2015.
Additional information can be found at http://www.lightningfastdata.com/info/flow_log.html.
4.3 Acoustic Data Signal Processing for Signal Frequency Measurement
A trade secret proprietary frequency analysis algorithm has been developed that that will be very useful for signal analysis in this project (and maybe future Navy acoustic data processing projects). This algorithm allows high-quality frequency analysis at any chosen frequencies between 0 and Nyquist frequency. This has some very important qualities that is not available with the standard frequency analysis methods.
This secret proprietary frequency analysis algorithm will be used in the detailed processing of the 5 data channels to find the primary contents and in some of the compression algorithms to find the location and starting phase of these primary content sounds in the remaining channels. These algorithms will be used in the initial target compression algorithms discussed above and some of the future compression algorithms, but some of the compression algorithms might not use them. The compression algorithms to try first, and order that the algorithms will be tried, will be based on the initial detailed processing of the 5 data channels.
An acoustic processing program is under development based on this algorithm. Due to expert knowledge of optimization, signal processing, and utilizing x86 CPU to do signal processing: On a laptop (8th gen i7, 4 core, 8 threads, 15 watt) the program can sustain a real-time processing rate of around 465 million 64 bit floating point operations per second on a single computer core. In addition to the math, the single core is also converting 16 bit data to 64 bit floats for each input data access, doing loop processing, getting and saving intermediate and result data, processing data buffers, sending data buffers to the sound system, getting the done buffers from the sound system, comparing minimum and maximum data results, clearing and scaling and plotting data up to 40 times/sec (the plotting also uses considerable CPU resources), and doing interactive Window's processing for the program, all while maintaining real time operation (the sound does not breakup), and the Window's program remains fully interactive. All together this is a very substantial amount of processing being executed on 1 CPU core. The preliminary acoustics program will be used to evaluate real sensor data and the plots will help visualize the frequency content, but is not part of this project. It is available for your evaluation as a prototype.
Additional information can be found at http://www.lightningfastdata.com/freq/freq_anal.html.
Currently a patent application is being prepared for the frequency analysis algorithm. The current convolution, FFT, and Goertzel algorithms are the current methods for frequency analysis.
Figure 5: Comparison of Convolution and Goertzel Response
Plots created for the patent's current methods in Figure 5: Comparison of Convolution and Goertzel Response shows that a point by point sine and cosine wave convolution, which gets the same input sine wave data, produces the same exact response as the Goertzel Algorithm; (even though the base mathimatics are completely different). Note, the FFT is based on the sine and cosine convolution, so it is covered. A 500 Hz center frequncy analyisis with at 600 Hz input is used. These 200 points match to 13 digits, and the same frequncy analysis with input data at the center frequncy, matches to 14 digits. These responses, by going up and back down to 0, show that the frequncy response has a zero frequency width, which is undesirable when measuring real data that usally has frequencies that are not at the measurement center frequencies. This off frequency measurement response is different (non-linear), as you move across the curve in time, and the particular stopping point on the curve for data further off frequency, is just noise, making acurrate high-quality data measurements difficult.
[Note: 1 page of Trade Secret information removed]
5 Relationship with Future Research or Research and Development.
(a) Anticipated Phase I results: 1): Sensor Array simulator that can produce simulated sensor array outputs for well-defined uniform high-signal amplitude inputs at various angles and mono frequencies and readout noise simulation of uniform random and-or white noise. 2): Acoustics sensor array compression system as outlined in the discussion, that can analyze and measure the input data waveforms and noise floor and produce compression and difference blocks for various sample length block sizes. High compression of simulated signals is expected. 3): R&D of algorithms, environmental noise, and (hopefully get) real array sensor data for analysis that will provide data for determining more complex data and noise environments for compression. Overall this development and R&D work will provide very good data for the technical feasibility of the proposed compression architecture and the initial proposed compression methods.
Anticipated Phase I Option results: 1): Get real-time multi-threaded operation running; (most development work will be done in non real-time mode). 2): Improved simulation models. 3) Evaluation of real data, (if available), through the compression process. 4): Additional and improved compression algorithms for environmental sounds and more complex sound environments. 6): Additional R&D learning and documentation. 5): Prepared for Phase II.
(b) The significance of the Phase I objective is to provide a Phase II foundation for evaluating real sensor data, and creating and improving compression algorithms. It is anticipated as the data becomes more complex, the difficulty in compression will correspondingly become more complex, where some complex data blocks may have poor compressibility. Poor compressibility of some blocks is OK if other data blocks have good compressibility since it is the overall average compressibility that is important. As work proceeds, it is anticipated that there will be diminishing returns on work quantity to improve algorithms and compression capability.
(c): Regarding clearances, certifications, and approvals: Fully US owned business, the principle investigator and owner, Mike Polehn, has had secret clearance in the past and has no anticipation of any issues for obtaining a new clearance. Have received "Military Critical Technical Data Agreement" before and should be able to get one for this project. Have had ITAR DDTC registration in the past, when needing it, and should be able to obtain it again, when needed for this project. The business is located in a private home, however, review of the facility clearance documents gives the impression that getting a secret facility clearance should not be an issue. The project will start out with 1 person, the principle investigator Mike Polehn. Coordinate with the contact officer to get clearances, certifications, and approvals as needed, and make appropriate adjustments to the project cost structure to support these.
6 Commercialization Strategy.
The compression of large channel count Acoustic Sensor Arrays data for communications over a SATCOM communications is a high value component for the Navy. The sale of Phase II and Phase III contacts to the Navy to accomplish the development of the compression and decompression software through deployment, is the primary focus and revenue for this work. There is also some value in accomplishment to help obtain future Navy and DoD contracts.
After Phase III deployment, the acoustic array compression will be marketed to other businesses like the oil industry which also use Acoustic Array Sensors. This highly specialized product has no use outside the Acoustic Array Sensor data compression. Overall, non-DoD delivery count is expected to be very small.
7 Key Personnel.
PRINCIPLE INVESTIGATOR: Mike Polehn
Oregon State University, BS in Computer and Electrical Engineering, 1983
Many years of R&D experience for digital signal processing systems. Did sensor evaluations, did signal processing algorithm development, did extensive simulations and processing performance evaluations, designed and delivered high performance pipeline signal processors to internal and DoD facilities. Extensive test and evaluation of infrared sensor camera, performance and data, test program improvement, extensive analysis computer programs, operational and test issues resolution, algorithm development, and operational performance improvement. Also did audio-acoustics signal processing, optimization and compression for Intel and modem companies.
Information and resume can be found at http://www.lightningfastdata.com/mike/mike_info.html.
8 Foreign Citizens.
No foreign nationals or foreign citizens or individuals holding dual citizenship working as a direct employee, contractor, or consultant will be working on or have access to this Phase I or Phase I Option projects.
The physical facilities to carry out Phase I is only office space, since this will be programming, documenting, and compression analysis work. Currently have several fast i7 development systems, with one of these is a very recent fast i7 running CentOS 7 with 32 Gigabyte of DDR4 which runs as fast as a server. Also have some i5 Linux systems. Overall no new systems are needed for phase I work. Can create a new unconnected network for classified data processing.
The COTS equipment to do work is low cost, is provided by Lightning Fast Data Technology Inc., and a local area network island (not connected to any other networks), is easy to create. All classified data will be kept on encrypted disks and only decrypted during dynamic use with all result files being encrypted. Access of decryption keys will be password encrypted and kept on a separate flash drive, which will be kept in a safe, when not being used. When not running overnight, long running, or weekend compression tests, equipment will be shut down during non-working hours to clear any residual unencrypted data in memory. When classified data is no longer needed, it will be destroyed or returned to the contract officer as requested.
The facilities meets all environmental laws and regulations of Federal, Washington State, and local Governments for, but not limited to, the following groupings: airborne emissions, waterborne effluents, external radiation levels, outdoor noise, solid and bulk waste disposal practices, and handling and storage of toxic and hazardous materials.
No Subcontractor or Consultants are required for Phase I and Phase I Option.
11 Prior, Current or Pending Support of Similar Proposals or Awards.
No prior, current, or pending support for proposed work.
12 Discretionary Technical Assistance.
No Discretionary Technical Assistance (DTA) required for Phase I and Phase I Option.
Proposal Evaluation Criteria
From section 4.1 of the 18.1 DoD SBIR Program BAA:
a. The technical approach has a reasonable chance of meeting the topic objective,
b. This approach is innovative, not routine, with potential for commercialization and
c. The proposing firm has the capability to implement the technical approach, i.e., has or can obtain people and equipment suitable to the task.
It is unknown if this is the exact criteria in the debrief since the exact criteria is not listed on the debrief, however criteria b and c might be swapped relative to the list in the debrief.
Note: Debrief text information was copied and pasted, however the formatting was changed to adapt to the html type document.
Proposal Evaluation Debrief
Proposal Evaluation Debrief
Thursday, May 10, 2018
Proposal Evaluation Debrief N181-067-0655
|Proposal Number:||N181-067-0655||Topic Number:||N181-067|
|Title:||Real-time Compression for Acoustic Array Time-Domain Data|
|Firm:||Lightning Fast Data Technology Inc.|
The vendor has proposed a framework in which each block of data is evaluated for frequency/waveform components iteratively, the content being removed at each step, until it has sufficiently low energy that all content has been recovered and all that remains is noise. The algorithm expects this noise to be small and will compress it as a final step in the block compression.
The proposal outlines not only the compression approach, but all of the framework surrounding it from array to SATCOM ready data.
At the heart of the approach is the vendor’s trade secret Signal Power Measurement Algorithms.
This company understands how to configure a computer system for fast processing and operation, which would support the real-time aspects of this task.
The ocean acoustic noise is fairly random and the contacts of interest are very low in SNR, making this approach challenging. While identifying and peeling off the signal components as waveforms is intellectually appealing and attractive for eventual use in classification, it is likely that the final compression step for the block will overwhelm the data compression budget. If, in Phase I, the vendor focuses solely on his own data simulation, he is likely to misjudge the importance of the ocean background noise, flow noise, etc.
This proposal focuses on the data manipulation and methods for gathering the data from the array and transmitting it to the shore station more than on the actual compression. It merely says that “a multitude of compression and decompression algorithms” can be used and evolved.
Their emphasis is on the engineering of the data storage and processing hardware architecture.
They mention that a significant portion of their development work will involve building a sensor array simulator and then evaluating their compression approach using simulated data. It is likely that their simulated data will not be completely representative of actual data, and thus provide false characterization of their compression scheme, especially without having significant prior underwater acoustic array experience. A significant amount of work would be required to essentially develop all of the compression components from scratch; in fact, the proposal includes time dedicated to researching existing compression techniques.
The PI has many years of experience developing and implementing high performance digital signal processing systems, including audio/acoustics signal processing and compression.
The PI has held a clearance in the past.
PI has performed work for the DoD in the past. He has held a secret clearance previously, and expects to issues in obtaing one.
The PI has no experience with underwater acoustics and has made some incorrect assumptions.
This is a one-employee company with very limited acoustic data experience. The PI has an emphasis on computing and processing capabilities, and there is no one else at the company to assist with the acoustics aspect of the project. The PI does not seem to have experience specifically with compression techniques either. There would be a lot of effort spent learning the relevant background information. The required clearance for working with classified data are not currently in place.
|Strength:||The vendor expects to market to the Navy and to the oil and gas industry.|
There is little information in the commercialization statement and no detailed plan.
Lightning does not perceive any market for the developed technology outside of the applications specifically involving acoustic array data compression and therefore does not emphasize marketing to non-DoD businesses. They do point to the oil industry as a possible market, however.
Post Proposal Comments
Attempted an Award Protest, which I had a week. Putting together a discussion of the weakness and inaccuracies in the evaluation, resulted in a paper that was longer (30 pages of discussions about the debrief information) than the proposal. Realizing that this was probably a big waste of time and time would better be used for other things, I terminated writing, did some formatting, added a section from a DARPA proposal that discussed my very successful IR sensor and IR FPA chip test programs which totaled at 183,480 lines that would require 5 1/4, 500 page reams of paper just to print (70 line/page, single side), to show that I could write a very substantial program, by myself, if I need to. Could have stood polishing, but needed to put it behind me, and forget about adding all the information that came to mind. The program manager never responded to the Award Protest.