In a research project, it is advantageous to have the possibility to change most of the conditioning and processing at any point, in order to test and measure different parameters and algorithms. Hard analog filtering with fixed response and ASICs, while offering good performance characteristics, make this difficult. FPGAs, on the other hand, offer a trade-off of power consumption and operating frequency for reconfigurability, while still being more efficient than DSPs and offering a more natural implementation of many algorithms. In the low-rate, bandwidth-limited environment of underwater acoustic communication, the added flexibility to try different techniques and tune the system is easily the deciding factor.

For our work, we’ll be using a GODIL FPGA board mounted on a custom analog front end receiver board, previously used for an underwater localisation project.¹ This board performs preliminary signal conditioning, using a processing chain composed of broadband pre-amplification and variable gain amplification stages, an anti-aliasing filter with 250 kHz cut-off, and a 12-bit ADC with up to 1 Msps sampling rate. The high cut-off frequency of the anti-aliasing filter allows some flexibility in transducers and carrier frequencies, at the cost of some added filtering inside the FPGA.²

For the transmitter, we will try to get an audio board made with a DAC, filtering, and a voltage amplifier. If that isn’t possible, we’ll use a simple square wave output, relying on the piezo transducers to bandpass the signal, which despite the sub-optimal coupling should be enough to get good results with moderate transmission power.

The transducers, the same ones used by the OceanSys group for their AUVs, are T257 models from Neptune Sonar, with an operating frequency range of 16 to 30 kHz. They are interfaced through a custom driver circuit, a model of which will be used in MATLAB simulation of the transmitter.

The GODIL board is based on a Xilinx Spartan-3E XC3S500E FPGA, with a minimal set of support peripherals. The FPGA will be used to implement the digital processor and protocol stack, as well as all data acquisition and external communication. The protocol stack will most likely be implemented using a soft microprocessor, such as a Picoblaze core, possibly with a simple FORTH on top. We’ll use external communication through a serial port to get real-time figures of merit and control the modem operation.

As for the development environment, as usual with Xilinx systems, we’ll be using the ISE Design Suite (System Edition) for synthesis and core generation, as well as the Mentor Graphics Questa Simulator for verification. We’ll use the Tcl scripting capabilities of ISE and Questa to automate the synthesis and as much of the verification as possible.

The project documentation will be written in Markdown and likely built using MkDocs or similar. Hopefully, seeing pretty output will help mitigate documentation inertia and help keep us sane.