At its core, a sub-bottom profiler functions in a relatively simple way: it generates a signal with specific length and frequency characteristics, emits it through a set of transducers at regular intervals (typically 4 to 16 times per second), and uses a hydrophone to receive the reflected signal from the underwater environment. The transducers are strategically placed just below the water’s surface and arranged to ensure that the emitted signal travels perpendicular to the seabed.
When the signal reaches the bottom, it experiences partial reflection and partial transmission. The transmitted portion penetrates deeper into the seabed, undergoing similar processes of partial reflection and transmission at each layer of varying density it encounters. This process allows the sub-bottom profiler to gather valuable information about the underlying layers of the seabed, including the geometry and terminations of reflectors, which can be used to infer details about depositional processes and environmental changes.
2.1. Hardware
Several models of SBP systems are available today, each fulfilling specific technical requirements based on the intended application (e.g., stratigraphy, archaeology, environmental studies). Each SBP system features a custom hardware design that includes the generation of an impulse or wavelet, which is sent to a power amplifier and transducer coupled with the water column.
While current technologies make the development of a sub-bottom profiler appear deceptively simple, there are real-world challenges to address:
Signal Quality and Power: The generated signal must be of high quality and have sufficient power to penetrate adequately beneath the seafloor.
Hydrophone Sensitivity: The hydrophone must be sensitive enough to accurately capture the weak reflected signal from the seafloor.
Noise Reduction: The hydrophone receives not only the reflected signal but also ambient acoustic noise; effective methods are needed to mitigate this interference.
Autonomous Operation: For use with autonomous vehicles, the instrument must be compact, low-power, and self-contained, capable of performing data acquisition without reliance on an external, powerful computer.
Addressing these challenges ensures the sub-bottom profiler’s effectiveness and reliability in real-world applications, particularly for autonomous underwater vehicles (AUVs).
To meet these technical specifications, we developed an all-in-one system incorporating as many open-hardware and open-source components as possible. The final system, described below, comprises an emitting system and an acquisition system. The acquisition system includes a compact computer that collects and stores data from the profiler in a standard format, geo-referenced with GPS-provided positions.
The
OpenCHIRP system is designed to be compatible with unmanned systems, such as autonomous surface vehicles like the
OpenSWAP vehicles [
21], allowing for complete programmatic control of its functions. By utilizing open-hardware and open-software components, we ensure flexibility, transparency, and ease of customization. The emitting system integrates smoothly with the acquisition system to facilitate accurate and reliable data collection.
A compact computer within the acquisition system is essential for managing and organizing the collected information, ensuring accessibility. Precise geo-referencing, facilitated by GPS integration, is critical for applications requiring spatial accuracy. Moreover, OpenCHIRP’s compatibility with autonomous systems represents a significant opportunity, particularly in environments where manual control is impractical or impossible. The ability to programmatically control all aspects of the system adds a layer of automation that enhances efficiency and reduces the need for human intervention.
Overall, this approach not only fosters innovation through the use of open technologies but also provides a robust and versatile solution for a wide range of applications.
The hardware blocks of the SBP system are displayed in
Figure 1.
2.1.1. Mainboard
By using open-hardware parts, maintenance is particularly straightforward in case of problems or failures. Open-hardware components are typically well-documented and widely supported by a community of developers and users. This accessibility ensures that replacements and repairs can be conducted efficiently and cost-effectively, minimizing downtime and enabling interventions even during operations in remote locations.
Additionally, the modularity and standardization inherent in open-hardware designs facilitate easy upgrades and modifications. If a particular component becomes obsolete or a new, improved version is released, it can often be swapped out without requiring a complete overhaul of the system. This flexibility provides a significant advantage over proprietary systems, which may require proprietary parts and specialized knowledge for maintenance.
As shown in the block diagram of
Figure 1, the system primarily consists of a Raspberry Pi connected to an Arduino-DUE microcontroller. The Arduino-DUE performs the following tasks:
Receives, via its primary USB port, the start and end frequencies, the pulse length of the signal to emit, and the emission rate of the pulses.
-Builds the waveform to emit based on user parameters.
-Emits the waveform at the specified rate through one of its DAC ports.
-Simultaneously receives the signal from the hydrophone and sends it to its secondary USB port.
The Raspberry Pi performs the following tasks:
-Instructs the Arduino-DUE on the signal to emit.
-Collects data sent by the Arduino-DUE.
-Acquires real-time position data from a GPS device.
-Saves the geo-referenced data in a standard format on a USB disk.
To properly manage the emitted and received signals, the microcontroller requires signal conditioning electronics for input and output amplification.
The Raspberry Pi, Arduino-DUE, necessary voltage-processing electronics, and additional features are all arranged on the
OpenCHIRP main board (
Figure 2), designed using the free ECAD software
Altium CircuitMaker.
The main features of this board are here briefly reported:
- fused power supply equipped for external input of 5 and 12V;
- Raspberry Pi and Arduino-DUE slot for easy access and maintenance;
- hydrophone signal processing: custom voltage adjustment and gain amplifier programmable in real-time by the Arduino-DUE;
- expansion ports for additional integrations.
The
OpenCHIRP main board schematic is reported in
Figure 2, and includes three sections:
i. A supply section (box A -
Figure 2), designed to accept both 5 and 12V on two separate rails and using a pre-crimped 4-pin connector. Decoupling and bypass capacitors are added, as well as interchangeable bottle fuse (default 3A) and an SMD led for power-on tracking. No reverse polarity protection is provided in this board release.
ii. A specific low-noise regulated voltage section (box B -
Figure 2), dedicated to the signal conditioning section (box C –
Figure 2, described in iii.). This section, along with the connected signal conditioning part (iii.), ensures that interferences and noise affecting the hydrophone signal are kept as low as possible, thus enhancing the signal quality. The circuit design, along with the selection of components and integrated circuits (ICs) has been made to receive a signal from the hydrophone in the [6±3] V range, and it can be easily reconfigured for different input signal ranges. Low-noise and low-dropout voltage regulators from LT technologies have been selected (for 5V – IC U1A and 3.3V – IC U3A) considering their market availability and their package (MSOP); the latter allows easy component swap and circuit reconfiguration. The IC U2 provides the -5V voltage necessary for the proper signal conditioning (iii.). Passive components (C, R, L) are here used following manufacturers’ suggestions to make the regulation circuit properly work. Service test points are included on the PCB layout to check the regulated voltages.
iii. A conditioning section for the hydrophone signal (box C –
Figure 2) that provides voltage adjustment and amplification of the input signal, labeled on the schematic as AN_IN, coming from a 2-pin pre-crimped connector. The hydrophone signal is first fed to IC U4, a single-channel operational amplifier (rail-to-rail and high voltage span, for potential system reconfiguration), used as a voltage buffer (for signal stabilization and impedance matching). It is connected to a first-order high-pass filter with a cutoff frequency of about 400 Hz. The filter and its capacitor block the DC offset, so the signal input to op-amp U5 is in the [0±3] V range. U5, in inverting configuration, provides the first hardware signal amplification according to the JP6 jumper position. R2 and R3 resistors define the amplification factor, by default 0.68x (via R2) and 10x (via R3). Then, software amplification, controlled by the Arduino DUE board, is applied through IC U6: a programmable gain inverting amplifier (LTC6910, gain 0÷64, selected via 3 digital signals). The signal is then shifted around 1.65V (op-amp U7A; U7 is a dual-channel, rail-to-rail, low-noise operational amplifier LTC6910) to ensure proper reading by the Arduino DUE Analog-to-Digital Converter. The shifted signal passes through a first-order low-pass filter (cutoff frequency about 52 kHz) and a voltage buffer (U7B) before being wired to the Arduino DUE at label A0_A2. Service test points are placed in section iii, as well as exposed ground pads to add a ground shield and reduce external interference. Bypass and decoupling capacitors are placed for all the ICs used.
iv. The Arduino DUE, Raspberry Pi, and additional connectors section (all parts not included in BOX A, B, and C –
Figure 2) includes headers for easy maintenance and substitution of the Arduino and Raspberry Pi, as well as multiple connectors for customization and feature expansion. The available expansion ports are: 1x RS232 port, 3x UART ports, 2x analog inputs (0-3.3V), and 2 TTL digital I/O. Status LEDs are connected to the digital I/O of the Raspberry Pi and Arduino to provide information about the proper system operation. An additional header connector is also placed on the PCB to ensure compatibility with previous
OpenSWAP hardware and for debugging purposes.
The components mounted primarily on the top of the board enable easy maintenance and part replacement, while the PCB form factor (Eurocard 10x16 cm with additional M3 mounting holes) provides numerous options for placing and securing the board.
This board will be released under an open-hardware license, and the routed PCB along with a 3D rendering of the board are shown in
Figure 3.
2.1.2. Seismic Reflection Signal Generation System
The system features a combined emitting and receiving electronic setup designed for generating and detecting seismic reflection signals from the sedimentary sequence. It operates using two different electronic configurations and types of transducers: one is a commercially available system, and the other is a custom-designed solution.
Commercial System: this configuration employs an off-the-shelf electronic driver paired with a standard underwater transducer. It is optimized for reliability and ease of integration, ensuring consistent signal output with minimal calibration needed.
Custom System: this second configuration consists of a specially designed electronic driver paired with a custom transducer. This system provides enhanced control over signal characteristics, such as frequency, pulse shape, and energy output, thereby optimizing performance for specific seismic exploration requirements.
Both systems are designed to produce controlled acoustic pulses that travel through the water and reflect off subsurface layers, allowing for high-resolution seismic imaging. The integration of commercial reliability with custom flexibility offers a versatile solution for underwater seismic studies.
All experiments utilized the same receiving unit, which consisted of a hydrophone and a preamplifier. However, two different emission units were employed, each comprising a transducer and an amplifier. The peripheral devices used in the tests are detailed in
Table 1.
Table 1 displays the peripheral devices that were tested, along with the interconnection scheme for both testing configurations. It emphasizes the differences in the emission units while keeping the receiving setup consistent.
Both, transmitter and receiver transducers were hosted in a hydrodynamic vessel designed for the purpose of mounting the
OpenCHIRP transducers onboard an Autonomous Surface Vehicle (
Figure 4)
2.2. Software
The software system consists of two primary components: the Arduino-DUE firmware, known as OpenCHIRP, and a Raspberry Pi program called CiapCiap. The firmware is developed in C++ and uploaded to the controller using the Arduino IDE, while CiapCiap is also written in C++ and operates on a Linux distribution, specifically Arch Linux, for the Raspberry Pi.
This paper does not provide a detailed analysis of the source code for these two programs but instead outlines their main features and usage. Readers can access the source code, as both programs are released under the GPL license.
Additionally, the software system includes the Arch Linux operating system running on the Raspberry Pi. It has been configured for unmanned operation, focusing on maximizing fault tolerance and enabling automatic shutdown and restart in the event of temporary malfunctions. This feature is especially important for deploying the instrument in autonomous vehicles.
2.2.1. The Firmware
This software operates within an Arduino DUE microcontroller. The Arduino DUE features two USB ports: one designated as the “Native port” and the other as the “Programming port.” The “Native port” is significantly faster and is therefore utilized for receiving the acquired data back. Meanwhile, the other USB port is employed for transmitting commands and parameters to the Arduino to configure the low-level acquisition process.
Figure 5 illustrates the block diagram of the program.
Two additional ports of the Arduino-DUE are utilized:
-The DAC0 (Digital Analog Converter) port for emitting the waveform towards the amplified transducers.
-The ADC (Analog Digital Converter) A0 port for sampling the signal received by the hydrophone.
Upon startup, the program flow enters an infinite loop, awaiting commands. Although the command set is small, it enables control over all necessary aspects to program the emission and acquisition processes. The commands and parameters are listed in
Table 2.
2.2.2. The CiapCiap Program
It is the main software used for acquisition and control, providing extensive management of the emission and acquisition processes through two configuration files that contain commands and parameters for the Arduino-DUE microcontroller. This program starts automatically during the Raspberry Pi’s boot sequence. It reads the two configuration files, “params” and “commands.chirp,” and then begins the acquisition process. The software’s block diagram is shown in
Figure 6.
The CiapCiap code is entirely configured through these two files, devoid of any graphical user interface. However, this absence of a GUI should not pose an issue, given that the program is intended for use in remote vehicles. Upon startup, the program searches for a file named “params” in the current directory, thereafter configuring all operations based on the contents of that file. Although the block diagram appears simple, the software itself is quite complex. It requires time to thoroughly explore the parameters in the configuration files and understand their functions. The full source code of the CiapCiap program is available at: https://gitlab.com/giuseppe.stanghellini/ciapciap
2.2.3. The “Params” File
This file is structured in a position-dependent manner, where each individual line is designated to specify a distinct parameter.
CiapCiap starts the reading process with the expectation that each line will consistently contain the correct parameter. Consequently, if there are any lines missing,
CiapCiap will encounter problems, resulting in the file not being interpreted correctly. To elaborate, each line is composed of values that are intended to be assigned to the parameter corresponding to that specific line. These values are followed by one or more spaces and, optionally, a ‘#’ character. Should this character be present, it serves as an indicator that any subsequent characters extending to the end of the line are to be disregarded and treated as non-executable comments by
CiapCiap. In
Appendix A, a line-by-line description of the parameters file is reported.
2.2.4. The Hosting Operating System
The Raspberry Pi running the acquisition jobs uses an Arch Linux distribution for ARM microprocessors. The installation is minimal, not requiring any desktop environments or graphical user interfaces. It is configured to auto-login as the root user and start all services and acquisition processes. System images are freely available for download.
The system is configured entirely by configuration files inside the /boot/OPENSWAP folder. This folder is mounted read-only to preserve it in case of unexpected reboot/freeze of the system. All file systems, except /DATA, are mounted read-only to preserve their integrity. To modify files on those file systems, a four-step sequence is required:
- 1)
Login by SSH to the OpenCHIRP.
- 2)
Execute RW.SH to make the folder writable.
- 3)
Edit the files for acquisition parameters.
- 4)
Kill ciapciap.
- 5)
Execute RO.SH to make the folder read-only again.
2.2.5. The Boot Process
When powered on, the Raspberry Pi automatically logs in as the root user, causing the profile file inside the /root folder to be executed by the bash shell. This file executes the /boot/OPENSWAP/autostart.sh script, which spawns several processes and runs the following shell scripts:
-prologue.sh: Prepares the execution environment, sets global environment variables, and checks existing file systems for consistency.
-start_net.sh: Starts the network and configures the access point.
-start_acq.sh: Starts the acquisition process.