Acoustic Location System


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


Eagle files for ultrasonic transmitter and receiver boards now in Github ( See Hardware folder. Carey has corrected the wiring error on the original version of the receiver - see “40khz_ultrasonic_receiver_0.1.brd”.

I am still using the hand wired receiver for my testing, along with the three transmitters based on the Eagle files.

A quick update on our approach: Project is going well. I spent a few days with Frikk when he visited SF/OpenROV HQ and we worked to simplify the approach used in a paper on time difference of arrival for uw sensors (see reference). A key gain is that no time sync is needed with the transmitter as with ToA. If we use three separate frequencies (seems to work so far) then we can transmit all three at the same time (independent channels if separation is OK) and filter things out to get TDoA. Each individual transmitter is identified by it’s frequency and we know it’s location. Since we have the depth sensor on the ROV, it becomes a 2D problem followed by a 3D projection using the depth data.

Another simplification is to have the three transmitters in a fixed orientation (two sides of a
vessel plus the stern). Location relative to the transmitters would be calculated and if GPS/heading of one of the transmitters are known, location can be transformed to lat/long.
We are developing the algorithms in Matlab and will convert to C code that can run on the ARM Cortex M4 (Teensy 3.1 at the moment). We think the critical DSP filters which separate the frequencies and give us TDoA data will be able to run on the ARM micro-controller during the time between transmissions (every second or so), but this needs to be verified.

I have collected some data signals in the OpenROV test tank that we will run through our algorithms and software to verify. Once working I will test with more realistic deployments at greater distances.

I will give a more detailed update (possibly a paper) on this once we get the math and DSP calculations worked out. For reference look at this paper (Silent Positioning in UnderwaterAcoustic Sensor Networks - IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL. 57, NO. 3, MAY 2008). It lays out a much more complex scenario that we were able to simplify for our purposes.

Note that I will be away on holiday in Argentina until the end of October - my wife and I are celebrating our anniversary. So limited e-mail for a while.



Thanks for the update @Jim_Trezzo fantastic to hear how well it’s going

Enjoy the holiday and congratulations on the anniversary


Any update on this project @Jim_Trezzo ? I am very interested in finding a way to localize my openRov from a fixed position such as a deck. If we can use a fixed position, wouldn’t it be simple if we placed 2 transmitters appart on the deck and triangulate using an algorithm to find the 2D position of the ROV?

thanks a lot


I am fairly new to the ROV scene and was wondering if anyone has information regarding if shielding is required when using a transducer so it won’t affect video or other electronics in the ROV. I am building from scratch, using a cast fiberglass enclosed body housing a ptz camera, arduino mega 2560, esc’s and lighting. I would also like to use an externally mounted commercial transducer(fish finder) unit to locate objects prior to diving to narrow my search area. I will be in inland fresh water lakes and rivers with depths no greater than 100 ft. Also, my power supply(2-18ah agm motorcycle batteries) are enclosed in the hull. I plan to use a logitech wingman pro 3d extreme digital joystick to control most functions, including ballast air, servos, lighting, camera and thrusters(4). The transducer cable will be separate(except power) using cat6e, as will video feed and data communications. I have designed for shielded cat6e(23awg) tether cables hoping it would be enough if there is any interference from the transducer.


I have been waiting for a next significant milestone before I posted an update, but it has been a while since my last posting in October. So I will outline current progress for the community.

I am still staying with the TDoA approach I described in October and am hand building enclosures for the electronics that will drive the three surface transducers. Each of the three boxes will have a BNC connector to attach a transducer using an RG-58 coax cable. Input to the enclosure will be for a DC power source (9-18V, less than 900ma max) and a signal pair for a logic input that can sync transmission of the pulses. I might add an indicator LED as well.

The onboard electronics will be the ultrasonic transmitter board that has been developed (see Eagle files in Github repo - along with a small micro-controller board like the teensy. I will also experiment with one or two of the micro-controllers that have a radio (Bluetooth LE or WiFi) and use that for synch. Other potential add-ons include a real-time clock and a GPS. I will start with a fixed geometry with a triangle orientation and 1-2 Meter long sides. This can be set up on a small to medium sized vessel or even an inflatable. Placing an enclosure on Port and Starboard with the other either on the Bow or Stern will provide the triangle.

Each transmitter will be on it’s own frequency between 30-40 KHz. I am experimenting with the DSP software to see how much separation is required between the frequencies so the digital filter software can detect the pulse arrivals of each and calculate the time difference of arrival. If the frequencies are too close, more complex digital filters are required and may be too much to process on the ARM Cortex M4 processor that will be on board the ROV. The transducer and receiver on board the ROV (again see Github repo above for receiver circuitry) will sample the signal at around 250 SPS using a micro controller with an on-board ADC. The micro-controller will do the DSP filtering and pulse detection and return the TDoA data to the surface laptop (via the BBB and the socket-io event stream). The surface laptop will know the orientation of the transmitters and run the TDoA calculations to determine the location (relative to the transmitters) of the ROV. This can be mapped to Lat/Long when GPS info on the transmitters is available.

Much of the work ahead will be with the TDoA software and DSP filters. I have most of it now in Python in a first cut form that allows me to experiment once the electronics enclosures are completed. The DSP software that goes on the ROV will need to be converted to C, but libraries are available to support this.

I hope this update is clear enough, but feel free to ask about any clarifications, etc.

In parallel with my work, there have been a few folks working with the transducers that I have built and even some of the electronics. One project in the UK has been working on a OFDM modem and another at U of Pennsylvania is building an USBL array to track a diver with a transducer on board from an ROV.

I am hoping both of these projects will be successful and share results. I will keep folks posted if I hear anything.

Regarding the question on shielding requirements for the transducer, I don’t have any specific data to share. In my case, the on-board transducer is only listening for now, so I am not transmitting any power to the transducer. I am more concerned with electrical interference from the motors. My receiver does have an analog filter to pass only ultrasonic signals in the desired range.


Exploring bottom structure 300-500m depth

Thank you for the update Jim. I am very impressed with your work so far. I appreciate your response to my question as well. If through further research I come upon any data that is applicable I shall post. Thank you again.



This past quarter I have been working with UCSD student group to progress the project. Basically start to convert the ADC and DSP work to run on an STMicroelectronics Nucleo microcontroller board (STM32F446). An ARM Cortex M4 with 128KB running at 180MHz. James Smith, Luis Sanchez and Jason Shen have put together a short video report outlining their work for Prof. Ryan Kastner’s CSE class at UCSD.

Will keep you all posted as we get closer to a working POC.



Hi @Jim_Trezzo Great to hear you are getting close to a proof of concept system

As a thought would the surface pingers have an inbuilt GPS to define their locations (sort of like the trident surface float) for the long base line trigonometry or would they have to be measured as offsets from a central datum point? (or I may be getting a bit too far ahead of where you are up to)



Initially the surface pingers would have a fixed geometry (no independent gps of their own). For a boat launch from a vessel with gps and a compass, you would know absolute location of pingers from their position on the vessel using ship GPS and heading info.

Later the pingers could be on GPS intelligent buoys that drift around. Many of the components that the Trident wi-fi/GPS float will have could be used for a GPS buoy.



Thanks @Jim_Trezzo

Have you had any feedback on how the Tritech MicronNav - USBL Tracking System went on the SS Tahoe?



I am very interested in the work you are doing on this subject.

My background is in subsea positioning in the offshore industry and have a very strong understanding of this subject using current commercially available equipment.

I am a software developer as well and currently completing a Thesis at Curtin University.
3D reconstruction in the ocean environment combining photography with subsea postioning sensors.

I haven’t read your blog in great detail but I would suggest a couple of ideas.

  1. Having two cameras separated with a known baseline may enable realtime relative positioning using photogrammetry processing.
    i.e. DVL’s (Doppler velocity logs) are used for determining velocity in real time. Potentially real time processing that tracked objects in imagery along with a known baseline between cameras could be exploited to determine velocity and potentially angular changes in trajectory

2, Acoustic positioning is the classical method for tracking objects back to a surface position.

  • A two way transmit and and receive time is measured to determined a range between transmitter and receiver,
  • Other systems transmit a code in the acoustic signal that contains a time of transmit message (similar to GPS). This is a passive system that only requires a listening beacon on one end and distance is resolved by multiplying the time difference by the speed of sound.
    This would be the approach I would look at because you could have the passive receiver on the ROV which would be a smaller payload than one that had to transmit a return signal,
  • A baseline (two or more acoustic transmitters) could be established on the tracking vessel that would enable computation of a 3D position. This would be done using a least squares solution combining other sensors and possibly utilizing a kalman filter to minimize noise.

Keep up the good work




I only found this forum and I am quite excited with what you are doing !

I think a combined acoustic SFM and acoustic approach may be able to be developed for tracking the ROV.

  1. In shallow water you could potentially have an upward facing camera that could track the vessel.
  2. Even a single acoustic range back to the tracking vessel could be sufficient for tracking purposes.
  • The ROV could remain stationary and the ROV is boxed-in as part of the pre-dive initialization (that is a series of ranges are taken with the vessel at four quadrants around the ROV.
  1. Once initialized the SFM would provide the positioning. The occasional acoustic range could be injected into the SFM to provide some redundancy.

Any just a few hair brained ideas I thought I could add.

If I could get hold of some real data I would be more that happy to process and see what results can be obtained.





I want to build a receiver circuit like yours. Could you please confirm the value of Cb that you used. The diagram says that Cb should equal Cs, I take this as meaning that Cb should have the same capacitive value as the piezo element, is that right?

I have measured the capacitance of my piezo element (same type as yours) as 5394pF.

Many thanks in anticipation and keep up the good work.



Attached is both the circuit and BOM for the components that I am using. The value of C2 (Cb in the hand drawn diagram) that I am using is 10nF (.01uF). It seems to work as expected. I have not done any precise measurements of the transducers capacitance using a bridge. You can try different values if you like.

There is a pc board layout for the receiver that you can order from OSH Park or use the eagle files.

40khz_ultrasonic_receiver_0.1.pdf (100.3 KB)
ReceiverAmpComponents.pdf (24.5 KB)

Good luck,




     We have **Acoustic Positioning System Market 2016** reports.Global [Acoustic Positioning System](http://) Industry Report 2016 is a professional and deep research report in this field. For overview analysis, the report introduces Acoustic Positioning System basic information including definition, classification, application, industry chain structure, industry overview, policy analysis, and news analysis, etc.

Acoustic Positioning System Market available @


I have been working away on the acoustic location system, but have not been posting updates since much of the work has been low-level micro-controller work and DSP learning curve for me. I want to give an update on recent work to create a software plug-in (a term used in the OpenROV software stack for a component).

I am using an independent micro-controller (ARM Cortrex-M4) to capture and eventually do the signal processing of the acoustic signal that the transducer hears. This data will need to be passed along to the OpenROV software system as follows.

My sensor system is an independent sub-system with it’s own micro-controller and a serial connection to the node server on the BBB (or Raspberry Pi on the Trident). For the Trident the serial connection will be over wi-fi since the unit is sealed, but the plug-in should be very similar. I think this pattern of a serial-link to a plug-in will be a common form of integration for OpenROV, it is worth while to develop a documented sample that can be adopted and re-used by others.

I am using my plug-in as a development tool at the moment to get raw sensor data from the transducer to the OpenROV stack. I will use that data to develop the signal processing software that will eventually run on the micro-controller. So for now I have some communications (tell the sensor system to collect data points and send it as JSON messages to the plug-in) that will save the data as tagged files on the BBB/linux system. I will need some UI/web components to control this remotely when the ROV is in the water. I also need to capture some of the status data from the ROV message buss so I know what the depth/temp and time was when the data was captured. I will need to capture data-sets from many locations to refine/develop location based algorithms for ROV positioning.

I have just put the “analogsensor” plug-in code (which is still underdevelopment/not finished) into my Github repo ( for those interested in taking a look. Warning - not very much documentation exists at the moment for how plug-ins work, so I expect this code will be hard to follow.

I will also post the software running on the micro-controller when I have a chance. This software will also be a bit more complex that a typical Arduino program. To get the sample rates fast enough I have to use more sophisticated techniques such as DMA (Direct Memory Access) transfers between the internal parts of the micro-controller (a timer drives the ADC and the results are moved into memory by the DMA peripheral).



Thanks for the update @Jim_Trezzo

Have you seen what they are doing over at bluerobotics?

Still looks early on but starting to get some inwater trials (by the look of it at close ranges (say up to 30m)



Thanks Scott,

yes I have seen this new product from Water Linked that Blue Robotics will be distributing in mid-June. While I have only seen the video and looked at data sheets (documentation not on web sites so far) it seems at least conceptually similar to what I have been working towards. It looks like the cost of an analog system would be around $4,300 from what I can tell. I will try to produce a set of components that would be a bit less and would be based on an open-source approach. There may be common ground with my efforts if they have an open approach. Maybe their transducers could be used by the electronics and software I am working on. Also possibility that some integration or higher level software could work with their system/APIs.

When I have a chance I will reach out to folks from either/both companies to explore.