Acoustic Location System


Hi Jim:

Transducer mounting looks great I’ll look forward to the results of the Tahoe tests. In the meantime I have been playing around with NTP and PTP to see if I can get clocks to synchronize across a network. I purchased a GPSDO from China that has both PPS 3.3 V square wave and 10 MHz sine wave outputs and interfaced it to an Arduino Micro and two Raspberry Pis. The 10 MHz output is divided by 2 in a D flip flop to have a 5 MHz clock for timing purposes and fed into pin 12 of the Arduino. Maximum external clock for the Arduino is 6.4 MHz (16/2.5 MHz) and the PPS signal is fed into Pin 4 (ICP input). The 10 MHz output is spot on at 5,000,000 counts/sec and varies by at most +/-1 count when the GPS is locked and TXCO is at temperature. That should work out to 5,000,000 x 100 /1500 = 333,333 counts for the 67 mS needed for sound to travel 100 meters. For NTP/PTP tests the GPS can be interfaced to the Raspberry Pis several different ways, either directly using the NMEA driver, or via the GPSD, which in turn passes the data to NTP using a SHM driver. In addition a separate driver is used for the PPS signal. On the master clock side I am running NMEA driver attached via USB to the Arduino so I only send the RMC sentence with the PPS driver and the PPS attached to a GPIO pin. The master runs NTPD and PTPD but the system clock is set by NTP (-t option on PTPD). On the client side the other system has NTP disabled and only PTPD is running and logs the difference between the master and slave clocks. Attached is a picture of the setup and the histogram of the differences between the clocks after running PTPD for about 6 hours. The attached results were a little disappointing, but I haven’t been about to see how much of the variance is due to the master clock drift. With expensive hardware clocks it is possible to get sub-micro second agreement, so more tweaking is definitely needed. These are just first look results but agreement to less than two microseconds on average isn’t bad (median -0.536) however the standard deviation of +/- 88 uS is probably too high so more work is needed. I assume it will be pretty easy to set up PTPD on the beagle bone if this approach is useful.

I’ll also try and develop a simple front end for the timing board and see if I can measure some acoustic pulse durations with the Arduino using the new transducers you made, and do a follow up post with how to set up the Pis and the Arduino code.


ptpd0509.pdf (39.2 KB)


Hi Bob

First off congratulations :thumbsup: on your progress it’s great to see what you and @Jim_Trezzo are doing

Just reading between the lines of your post and dumbing it down to what I can understand
you mentioned

So in “theory” this would represent 1 count per 0.3 mm so depending upon how “clean” you pick up the flip flop interface (my guess the main issues will be in the acoustics for how clean this is) this would give (round figures) at even ± 100 counts a ± inch accuracy in this part of the system

You also mention

So after 6 hours of operation the “drift” between the 2 systems was “less than two microseconds” thus for the 100m range 2/67 mS or over the 6 hours the drift was equivalent to about 3 meters

Mate if you can do anywhere near this I would be more than happy

Again thanks for the work you and Jim are doing (I just wish I had the skill to give you both a hand)



Hi Scott: I agree detecting the time the pulse is received and avoiding false triggering are likely to be issues but I like how Jim is approaching that problem. Also, if we can send a back channel electrical pulse down the tether when the acoustic pulse is generated at the surface, something sufficient to detect but not shut the ROV off and on, then the need for having the clocks synced would be less critical. We might even consider sending a 1 PPS signal or 5 PPS signal, and initiating the surface acoustic pulses on the leading edge of these pulses. That would allow ongoing calibration of whatever device is measuring the time of flight of the pulses on the ROV. As you observed the computers we are using are more than capable of counting to far greater resolution than is needed if we can provide a clean gating signal and have a known stable frequency to count. With 0.3 mm resolution a SBL system on the ROV might even be possible.

Let me do a bit more work with NTP and PTP before determining whether this system is a viable alternative. What I think the data is telling me is I know the offset of the clocks with a somewhat wider range, maybe 0.3 - 0.4 mS with an acoustic signal that is 67 mS or less. Given this is only one source of potential errors it would be nice to have greater confidence in the offset. There is suppose to be a way to log the timestamps of the PPS signal of the Master Clock in NTP, but I haven’t figured it out yet. I think that data might be revealing also. I’m still at the beginning of the learning curve on all this.


Here are some additional graphs of the PTP testing. I piped the ppstest output to a file which gave me timestamps of the PPS signal from the GPS attached to time server (master clock). I did a fresh build on the client side so it is the current Raspbian OS updated and upgraded with the ptpd that is available using sudo apt-get. The attached plots show the PPS signal gets timestamped within a few microseconds of the seconds boundary, with some upward bias for noisy stamps presumably when the OS is busy with other tasks and can’t service the interrupt. On the client side, ntp was stopped as soon as the system was booted up, and ptpd was started with a log file. The client start-up graph shows the time difference between the server and client rapidly goes to near 0 in under 5 minutes. I ran the system for a few days and plotted 32K sample points to examine for bias and variability. The server client differences are much more variable than the PPS signal on the server side. The impact this would have on using the clock’s time for measurement would depend, I would think, on filtering and statistical algorithms used within PTPD to set the clock which I haven’t gotten into yet. It looks like some time might be required to get the on board clock properly disciplined to the Server attached to the GPS.

Overall, given we can get to within a few microseconds or less if we have a PPS signal, my inclination would be to see if there is some easy way to send the 1 PPS signal down the tether without shutting off the ROV or messing up the two-wire Ethernet, and recovering it in the vehicle. By initiating acoustic pulses from the surface at known offsets from the PPS signal, the time of flight could accurately determined against an on-board oscillator (like the processor clock), and that in turn is calibrated to the PPS signal as often as necessary given to quality of that oscillator.

If that is not possible, then more work on PTP or using an onboard processor with an Ethernet chip that does hardware time stamps might be worth testing out.


NTP_PTPD.pdf (1.2 MB)
Histogram.pdf (352.7 KB)


Hi Bob

Just thinking about you comment

The Tenda home plug was system was originally designed to transmit data over an AC system but is also suitable for DC systems (such as we have) as a thought if we had a step (say 5VDC to say 4.5VDC for argument) and maintained that for 1 second then stepped back to 5VDC etc at your 1PPS (1 pulse per second). Is that not much more than a “switch” and a “dropping resistor” (the speed of this change - or at least its leading edge may be an issue)

As long as the step if below the threshold to turn the unit on/off (at a guess to turn it on off is more a voltage / no voltage situation) it should be fine


First test of acoustic signal to on-board ROV transducer/amplifier:

I had hoped to get this working for our Tahoe trip, but there was too much soldering and integration with the ROV electronics. So here is a video of the results in the test tank in Berkeley at OpenROV HQ. The receiver circuit is powered via regulated 5V from J4-15

of the controller board - we only draw 80ma. The transducer is mounted on the top of the ROV and signal-in wires come in through the end cap to the DB-25 connector. That goes to the receiver circuit and for now the analog output goes back out the end cap to a second 100M tether to instruments on the surface. The signal from the surface is generated with a function generator sending a 40KHz sine wave to a piezo transducer also in the test tank.

Next step is to test with pulses and get timing data and signal characteristics at various depths/distances. I still need to work out which approach to use for signal data acquisition inside the ROV - Teensy 3.1 micro-controller interfaced to BBB via serial or using BBB ADC (if I can make it run fast enough).



Ah yes ok ignore my previous post ha!


End to end testing through on board transducer

Here are the first results from sending short 40KHz acoustic pulse (yellow trace) through a piezo transducer to one on-board the ROV and into an on-board analog amplifier. The output of the amp was routed back out the DB-25 cable to a second tether up to the surface where I first used the oscilloscope (red trace) and later the Teensy 3.1 microcontroller to sample 500 points at 250Ksps.

In the first test, I taped the two transducers together with the top surfaces in contact out of the water. This resulted in a strong signal with almost no delay.

In the second test (OpenROV’s fresh water test tank) I was able to keep the transmitter at one end of the tank and submerged the ROV with a total distance of approx. 1.2 meters. This delayed the signal about 880usec.

I am pretty excited to see these results and will move on to a larger tank to get more distant readings. I also will work on collecting the points data from the on-board BBB if I can make it run fast enough without disturbing the operation of the ROV.

I have also included the output of the Python points analysis program. The first trace is the raw points data plotted. The second is after a band-pass DSP filter which also eliminated DC bias. The third trace is after an absolute value is calculated and the final is the envelope that results from a moving average calculation. This will be used to detect the time of arrival of the first pulse at the ROV. Later navigation equations will be developed to determine position using a combination of ping delay times from multiple sources, depth info and IMU data.



So using speed of sound in water of 1500m/sec and a delay of 880usec to see the pulse hey presto distance between the unit 1.32 meters

Looking really good Jim I love the work you are doing



Good meeting you this weekend Jim, exciting stuff you’re working on! I’ve cloned the repo and am going to see what I can do with the data collected thus far. Can’t wait to see the project evolve.


HI Jim:

That looks really promising. It looks like you will be able to resolve the signals to times in the 10s of microseconds or better. I’m not sure my timing experiments are keeping up with your technology. I have been playing around with an inexpensive clock chip, the DS3231 on a ChronoDot board. This timing chip is a major improvement over the DS1307 in that it has a temperature compensated crystal on the chip, and in addition has a register that you can manually fine tune the oscillator. It produces a 1 PPS output and a 32768 clock output. By measuring the 1PPS output against my GPSDO 10 MHz signal (divided by 2 so it works with the Arduino) I was able to get the chip to produce a quite stable (within +/1 count) 1 PPS output. This also produces a stable 32768 Hz output. A picture of the 5 MHz and 32768 Hz signals gated with the 1 PPS signal is attached. I have been a bit vexed trying to initialize the DS3231 in a manner that would match up the 1 PPS signal from the chip with the GPS 1PPS signal rather than just measuring the difference and including the offset in the measurement, but I’m still working on that problem. Ideally I would like to discipline the DS3231 to the GPS and use the 1 PPS signal onboard without resorting to a timing signal from the surface. I don’t know yet if it will really have the stability for that purpose for the time needed for a mission, but if so it will be a really cheap solution for onboard timing. So far PTP client server, send 1PPS down the tether, and a stable on board clock seem like possibilities, but too early to tell except for the middle option (1PPS backchannel down the tether). Bob


I have been working on an iPython notebook to evaluate different DSP filters and techniques. So far, I’ve written a function that helps evaluate filters. It takes the transfer function of a digital filter and plots its frequency response, the result of the filter on an example signal, and the FFT of the filtered example.

The entire notebook can be viewed here:

Here is the frequency response of the FIR filter used in file on GitHub.

Here is the frequency response of a Type II Chebyshev Filter that I designed in the iPython notebook.


Hi Jim,

I only joined the forum late last year but I’ve been following with interest your experiments with the acoustic location device, which are really encouraging. As a matter of interest, did you manage to carry out any frequency response tests on the transducers you built ? If so, how well do they work outside of your filter range ?

Although I run a small electronics design company in the UK, I’ve been looking into how I might personally be able to contribute on the development of a low-cost UW modem design. One key factor being the transducer’s performance.




I have been traveling up and down the west coast of the US most of July and haven’t had a chance to get back to you. I should be home for a while and will have more time to resume working on the OpenROV projects.

You asked about the characteristics of the transducer. I have mostly tested it around the resonance frequency (around 40KHz) and it works well from 30-60KHz. The design is based on the one in Dr. Bridget Benson’s thesis ( ). Bridget does have results from her characterization work in the document (see chapter 5). Since my initial needs are narrow-band, I haven’t tried to replicate her work just yet. I do have an EE student at UCSD that is interning in Scripps UW acoustic lab and will try to characterize the transducers. I just provided her with two transducers this past week, so it may be a while before Virginia has results.

I also had a summer intern (Carey, another EE) turn my schematics into PCB designs. I should have the initial boards back in about 10 days. If they work, I can share the Eagle files that we used (both transmitter and receiver). The filters are narrow band (30-50KHz if I recall), but you can change the resistor values for the active filters if you want a greater range.

If you want to get involved, I would welcome your help. We put together a short term task list and if you see anything you like, you can help out. See my github for the latest info ( ).

We have a few others that are involved including a recent MSEE grad from Norway – Frikk Solberg – who specialized in signal processing and now has an ROV.

Todo list:

PCB of transmitter and receiver – review boards, add components and test

Impedance matching/power maximization for transmitter

Measure attenuation/noise at distances up to 100m

May need more power and variable gain stage on receiver

Frequency sweep transmitter/receiver

Further characterization in water – acoustic power delivered vs. RMS in and receiver sensitivity as well

Transmitter pulse sync -when to start data acquisition over tether

BeagleBone data acquisition program (250Ksps)

DSP software to detect travel time of pulse using samples from DAQ program.

Alternative signals - chirp, m-sequence

Test chirp from square wave into transmitter

There can also be work on improving the transducer design – different shapes for down-facing unit, non-resonant material on inside of cylinder, etc.

There are many applications for these components to try beyond the initial location pinging. You can certainly begin testing two-way modem communications with the electronics. I think micro-controllers will be fast enough for FSK encoding and possibly more advanced encodings as well (OFDM, etc.).

Let me know your contact info if you don’t mind.




Always love to hear what you are up to @Jim_Trezzo

A question about the boards you are producing how accommodating are they to other frequencies rather than just the 40kHz your currently running. Can the same boards be used at say 200 or 455kHz as a simplified depth sounder with just a different transducer? If they can’t is it a simple 1 or 2 elements on the board or a whole new redesign?



The boards on order are without components at the moment. To change the frequency characteristics, only the gain resistors need to change. There are two stages of op amps in both the receiver and transmitter. One concern would be the op amp gain at higher frequencies such as 455KHz. The TL072CP may not have enough gain (unity gain up to 3MHz). The good news is that the pin configurations are common with several op amp families. I have been using the NE5532 for the transmitter and it has unity gain to 10MHz. This part has the same pinout and could go in the receiver. While the input impedance is not as good as the JFET based TL072CP, it should be good enough for this application.

After I get the boards in and test them, I can see if they can handle the higher frequency use case and let you know.


Thanks Jim looking forward to hearing how it goes


Testing PCBs for transmitter (piezo driver).

I finally got to solder components on the PCB that Carey McCachern laid out using Eagle ( ). We used OSH Park ( to fabricate the boards and they look real sharp. I have attached a few pictures and will also post the schematic and board files and the component BOM.

I was able to get 27v p-p without clipping and a gain of 17.3 at 40KHz using a sine wave as input from my function generator (also part of the NI VirtualBench product). The transmitter’s band pass filter will shape a square wave input signal well enough to be used with the acoustic transducer. I have been generating a series of square wave pulses using the GPIO output from a microcontroller (Arduino or equivalent) for the input signal during acoustic testing. I could generate other signals as well (ex. chirp).

The receiver had a design error, but I think I can salvage the boards for testing after I cut a few traces and add a couple of external wires. Once that tests out, I will publish results and corrected Eagle files as well.



Jim this is absolutely fantastic. I just got into using Eagle as well and am pretty amped about it. I can’t wait until you publish the new schematics. I have some research ideas that I’d love to implement you kit into.


Looks Nice Neat and well laid out well to both @Jim_Trezzo and @Carey_McCachern