Acoustic Modems, Location, and Pingers

payloads

#1






There has been interest expressed in Acoustic Modems and Location by a number of people in the community so I thought it might be useful to share the design of simple acoustic modem I experimented with a couple of years ago, and some references for more advanced designs. I based my design on the same Steminc transducer used by Bridget Benson for her PhD Thesis at UCSD in her very elegantly designed acoustic modem. I don't think her design has been picked-up up commercially yet and is not available. My project used a much simpler modem based on some obsolete Exar modem chips (I didn't include the modem designs due to upload limits, but will add to another post if anyone is interested). I would think use of software designed modems in microprocessors is certainly the way to go rather than this approach, but perhaps the analog amplifier designs may be of some use to experimenters. The transmitter consists of an Exar 2206 driven by opto-isolated TTL serial data at 110 baud with the resulting FSK modulated signal (43KHz +/- 500Hz) fed into an amplifier driving the transducer through a 2.5 mH inductor. The receiver has a 40 dB gain preamplifier fed into a Sallen-Key High-Pass filter and decoded back into Serial Data using an XR2211 demodulator. The designs are taken directly from manufacturers datasheets and publications and modified as needed to fit what was in my junk box. Since my hand drawn schematics are so bad I can't follow them most of the time I just painted the correct components values in the original drawings for reference. Also included a picture of transmitter and receiver prototype. Both were designed to be powered off of two 9V batteries and packaged into small Otter cases good to around 100 ft. but I never completed the packaging and testing at greater distances than a few inches in my front room. My original application was for use in sending data in diving equipment.

I have been thinking about using the amplifier and receiver for location of a ROV. Since the vehicle is tethered it should be possible to generate an acoustic pulse and send the pulse both through the water acoustically and over the tether electrically along with the current depth. Comparing the arrival times should allow calculation of the distance over ground to the ROV since both the hypotenuse and one leg of a rt. triangle are known. Using a couple of transducers or heading information and a GPS fix on the boat location, Lat-Long coordinates could be assigned to the ROV. Probably do the same thing less elegantly by pulling the tether tight and noting the angle off the stern.

Following are the references I used for the design. They are also noted at the bottom of the pictures.

Bob

Bridget Benson's PhD Thesis (Do search for additional publications)
http://haduken.ucsd.edu/papers/phd-thesis-benson.pdf

Nathanial Garcia's Shark Tag Locator Thesis
http://digitalcommons.calpoly.edu/cgi/viewcontent.cgi?article=1011&context=cpesp

Transmit and Receive Transducer Used by Bridget Benson in her UCSD PhD Thesis
http://www.steminc.com/PZT/en/ceramic-cylinder-26x22x13mm-42-khz
New Part Number:
http://www.steminc.com/PZT/en/piezo-ceramic-cylinder-26x22x13mm-43-khz

Transmitter: XR2206 FSK Modulator Datasheet
http://www.mouser.com/ds/2/146/exar_xr2206-195595.pdf

Transmitter: Intersil CA3140 Datasheet with Transmitter Amplifier Circuit
http://www.intersil.com/content/dam/Intersil/documents/ca31/ca3140a.pdf
I used a NE 5532 in my modification of the design.

Receiver: Transducer Preamplifier Modified from this Analog Devices Presentation See Page 5.28
http://www.analog.com/static/imported-files/seminars_webcasts/371366216sscsect5.PDF
I used a TL084 amp from the junk box but using the recommended AD745 and the 100 Meg input
resistors would be likely be an improvement.

Reciever: I used a HPF instead of the MFB filters used by Garcia and Benson.
This is a good site for designing these filters and I'm sure their designs would be superior
to the simple one I used.
http://sim.okawa-denshi.jp/en/OPseikiHikeisan.htm

Receiver: FSK Decoder using XR2211 FSK Demodulator Datasheet as follows:
http://www.mouser.com/ds/2/146/XR2211Av104-49880.pdf


Underwater positioning GPS by triangulation?
#2

Thanks

I had been reading through several of the same papers (although you are obviously well in front of me) on the same base hardware. I would also recommend people viewing the project" home" and also read the low cost modem paper

My thoughts had been towards adding a GPS to the surface unit to transmit it location with an aim to Virtual Long Baseline VLBL Navigation (as used in many of the REMUS units) pinger

But as always it is vital to develop the base hardware first (and thanks to you is pushed a long way forward) and the more complex applications of it will come in time

Excellent well done and thanks for the ideas

Scott


#3

Nice writeup Bob.

My thoughts are to start with a simple system that can be expanded into a more general one.

Since the ROV is tethered and we have good depth data using the pressure sensor, a ping with timing info from one or more known locations (GPS synched) could give us what we need with only a hydrophone (plus decoding logic/sw) on the ROV. We would have a GPS on the launch vessel at a minimum and be in communications with the ROV with socket.io or some protocol.

The ping would contain an encoded message containing; time, an id from the sender (since we may want another sender from a different location) and location (use GPS unit for location and time). Since we are connected with a tether, the clocks can be synched over tcp/ip. The ROV only needs a receiver initially plus a decoder. The message is short, so simple FSK would be fine.

Hydrophone shouldn't be that hard to implement since we already have the BeagleBone on board. Assuming the A/D can sample fast enough.

The older modem ICs should be fine for now, later we can look at FPGAs for higher data rates and more complex encoding. The analog sections should be the same in any case.

I have a pair of the 40KHz ceramic transducer mentioned in the acoustic modem paper. Could also use a mic for the receiver and get a broader range of sound (sea creatures as well).

I saw an interesting mic and app note (below) indicating it could be used up to 100KHz. Might be able to read the mic output from the BBB A/D. Don't know how fast that could be done (need 2x the desired frequency at a minimum). May also need a pre-amp in front of the BB A/D.

$14.11 mic from Knowles (they have a broad product line)

http://www.mouser.com/ProductDetail/Knowles/EK-26899-P03/?qs=%2fha2pyFadugbmZFkT%2f0T3nCkJLGjL3ikoMLbmvdnOS0xxLTjx%252bJnLg%3d%3d

App note - http://www.digikey.com/Web%20Export/Supplier%20Content/Knowles_423/pdf/knowles-ultrasonic-application-note.pdf

I will look over your circuits and try to replicate at shallow depths initially.

Jim


#4

Hi

Don't know if You guys have seen this, but interresting stuff

http://www.mbtelectronics.com/side-scan-sonar.php


#5

Yes I had seen it a while back and have it tucked away when we look at Sonar. He has done a nice job of documenting all the basics and how to build one. It would be nice to do a digital make-over of this project. I wonder if anyone has done a derived work like that.

If adapted to an ROV, the tow-fish part goes away and all the signaling would come into the BeagleBone. The chart display now would be digital.

Jim


#6

Yes , but that sw part some guru have to Work out :D

I allready struggle with the Arduino part on a color module I'm working on...


#7

Bob,

If you can somehow get your acoustic modem to calculate distance only, I'm sure it would be possible to come up with a Long-Baseline (LBL) system. I think an accuate USBL system is a bit out of our reach with the technology at hand for DIYers.

My idea is to have a series (3-4) of buoys moored around the work area. Inside a waterproof on each of the buoys is an Arduino with a GPS (to know where the bouy is) and Wi-fi shield (for communications) stacked on-top. If we can interface your transducer modem for range only, we can use a method called trilateration to determine the position of the ROV underwater. The distances between all the buoys is sent to a BeagleBone on the support vessel/dock for calculation and then fed into Google Earth that will show the location of the buoys and the location of the ROV in realtime. This method is a lot easier than trying to use triangulation and figure out angles and is what GPS and radar navigation systems use.

PM me if your interested. I can build and field-test anything you come up with. I *think* I can program something to geo-locate a buoy, but I'm not sure how to use an acoustic modem with it.

Kevin


#8

A few different things running concurrently (although all somewhat related -they all have sound being produced and listened too - maybe separate payload posts on the forum?)

Yes, I think everyone considers some sort of location pinger a great concept and useful in a "towards autonomy" concept (as well as great many other uses) and that this modem is a strong start towards that hardware payload platform. Although in the real world Bob is just at the breadboard stage and no doubt is likely to go through several revisions and his post then allow all us and all our group knowledge to be used to improve the base unit - exactly the benefit of open source

My take on a sidescan system for the ROV would be to start with a "standard" sounder payload module built up from say a 200kHz transducer (say based upon the transducer from this), with some custom circuitry (this thread is worth a read) and then into a Arduino and then feed up though the chain to software on the surface.

Such a system can be developed or built upon over time adding to the base such as

  • Just depth - Time of flight from the transducer to the returned signal
  • Bottom type - Related to the retuned intensity
  • Doppler shift - Frequency change from the sent to returned signal
  • Time varying gain more gain add for longer time of flight
  • Multiple array transducers

This also then allows other payloads to be developed from simplistic forward looking for collision detection to more complex (once Doppler shift is refined) production of DVL and sidescan (look at the Burton unit which is just a standard depth and bottom type sounder)

My thoughts on the transducers used for sidescan as this is a tethered unit is the SSS range is only required to be say 20-30m each side so putting it firmly in the 455KHz or 800kHz frequency range (eg Lowrance Lss-2 Hd Skimmer Transducer) which much greater resolution than the 25-40kHz piezo units where for SSS is just too low a frequency (great for coarse multi km swaths or longer distance modem communication) to be useful for such a small ROV

Realistically this is all somewhat a tangent to Bob's original post on an extraordinary step forward on an open source underwater modem where hopefully someone here can assist in its development

Scott

(PS you can check out what I have been doing with our SSS here)


#9

if we can interface your transducer modem for range only, we can use a method called trilateration to determine the position of the ROV underwater

How about a simplistic first approach where the surface bouy is connected to the surface laptop that the ROV is connected to, so that the ping can be logged when it is sent and then when it is received at the ROV and time difference determined


#10

Sounds like a good first start to me. I guess I was about 8 steps ahead.

Scott, do you think the lag might be too long/unpredictable if we use the ROV tether to track the pings? Would it be better to keep the transmitter and receiver separate? Some of the research projects I've been looking at utilizing some sort of "indoor localization" or ultrasonic positioning have the transmitter completely separate from the timing circuits of the receivers.


#11

My understanding of the commercial units is that they are set up as a call and response with a dead time to allow for processing at each end. For an autonomous unit they are typically initiated from the bottom unit and follow the structure below.

  • The bottom unit pings and then the surface unit detects the ping and adds a known lag (to account for its processing speed) and then responds to the bottom unit and the bottom unit detects the return (and reads the string) and with the known lag subtracts this from the overall return time and given the speed of sound (around 1500m/sec) has twice the distance between the 2 units (forward and back)

Given our potential scenario if the surface piezo ping starts the timing (or is triggered at a predefined CUP timing) I'm not sure if the time is best measured down on the ROV at the Arduino level, or at the BBB, or back up at the surface laptop. But I would assume there is a dead time for processing no matter what and I would assume at this stage any higher level LBL would be a on the surface (post processing? as a first attempt??).

Some of the research projects I've been looking at utilizing some sort of "indoor localization" or ultrasonic positioning have the transmitter completely separate from the timing circuits of the receivers

This is basically an unreferenced or local view geodetic system which is also cool and most likely a good simpler starting place (as this can also tie back to the IMU and tie one point to the next and then work out how to tie it back to the real world). I have been playing with post processed SfM (like this or this) which also similarly has a localised camera position system (eg relative to the last) that has potential in this scenario

I see this as all part of the development of the hardware and the rest can/will come


#12

I purchased a Garmin GPS 18x5Hz which has a 5 Hz PPS output the leading edge of which is suppose to be accurate to within 1 microsecond with a good fix, and have been reviewing the literature on GPS disciplined Master Clocks and Network Time Protocol. Adafruit has a GPS with 10Hz PPD. Off the shelf Master Clocks are expensive, but people have hooked GPS's with PPD up to the Raspberry Pi and BeagleBone to make a Statum 1 Time Server. It sounds like the acoustic modems Scott describes are using an underwater variant of NTP to send packets back and forth, noting the times and delays, and the compensating the clocks accordingly. All this becomes important if there is a long baseline and multiple surface bouy's or pingers are set around the worksite in order to make sure all of the pieces are working off the same clock. I would think the synching problems rapidly mount and the accuracy rapidly goes down moving from a wired situation to a wireless situation to a situation where he pieces are only connected acoustically.

That is why I think having an ability to send an electrical signal either over IP if the connection is not too busy with video and control signals for the ROV, or with some back channel method that doesn't interfere with the IP over Homewire protocol would be easier. That way you know when the ping was sent and received, Assuming 1 ns per 6 inches (15 cm) of wire delay, the electrical pulse will arrive in under 1 microsecond vs about 70 ms for the acoustic pulse if the ROV is 100 meters away. This doesn't seem like a really demanding timing problem if you assume you don't need to know the location of the ROV to the nearest mm. The timing issue is more difficult for the baseline on two or more sensors to get the heading information. If we used the Steminc tranduscer operating at 43KHz and know the distance between the acoustic detectors if on the surface, something as simple as a zero crossing detector that takes into account that distance ( each cycle

I bought a 1000 foot spool of 24 gauge Cross Connect Wire which is basically one twisted pair of an Ethernet cable and tested to see if the Tenda adapters could drive 1000 ft and connected and got a picture OK with ROV, but didn't extensively test it. If would be interesting to know if anyone has determined how long a tether is possible to see what the upper bound of the


#13

I purchased a Garmin GPS 18x5Hz which has a 5 Hz PPS output the leading edge of which is suppose to be accurate to within 1 microsecond with a good fix, and have been reviewing the literature on GPS disciplined Master Clocks and Network Time Protocol. Adafruit has a GPS with 10Hz PPD. Off the shelf Master Clocks are expensive, but people have hooked GPS's with PPD up to the Raspberry Pi and BeagleBone to make a Statum 1 Time Server. It sounds like the acoustic modems Scott describes are using an underwater variant of NTP to send packets back and forth, noting the times and delays, and the compensating the clocks accordingly. All this becomes important if there is a long baseline and multiple surface bouy's or pingers are set around the worksite in order to make sure all of the pieces are working off the same clock. I would think the synching problems rapidly mount and the accuracy rapidly goes down moving from a wired situation to a wireless situation to a situation where he pieces are only connected acoustically.

That is why I think having an ability to send an electrical signal either over IP if the connection is not too busy with video and control signals for the ROV, or with some back channel method that doesn't interfere with the IP over Homewire protocol would be easier. That way you know when the ping was sent and received, Assuming 1 ns per 6 inches (15 cm) of wire delay, the electrical pulse will arrive in under 1 microsecond vs about 70 ms for the acoustic pulse if the ROV is 100 meters away. This doesn't seem like a really demanding timing problem if you assume you don't need to know the location of the ROV to the nearest mm. The timing issue is more difficult for the baseline on two or more sensors to get the heading information. If we used the Steminc tranduscer operating at 43KHz and know the distance between the acoustic detectors if on the surface, something as simple as a zero crossing detector that takes into account that distance ( each cycle

I bought a 1000 foot spool of 24 gauge Cross Connect Wire which is basically one twisted pair of an Ethernet cable and tested to see if the Tenda adapters could drive 1000 ft and connected and got a picture OK with ROV, but didn't extensively test it. If would be interesting to know if anyone has determined how long a tether is possible to see what the upper bound of the


#14

Sorry my comment below got sent before it was finished, continuing on the second paragraph: each cycle is about 0.034 meters apart) might allow for calculation of the relative bearing of the ROV off the baseline. The acoustic signals are a bit messy and could easily present different issues for shorter vs longer baslines I would think.

Continuing on the second paragraph: of the distance the ROV can be tethered using the Homeplug system is. It is rated to 100 meters, but might be stretched much longer.

A lot of good ideas below. Sorry for the fat fingers.

Bob


#15

Here is an easy way to generate the 43 KHz signal that I got from the arduino forums. I haven't checked if the bigger processor used in the ROV would work the same way or if the timer and output pin are otherwise in use, but I assume the code be adapted and used to drive the amplifier circuit above. There is an extra op amp on the NE5532 that could be used as a low pass filter if the square wave harmonics interfere and it would need to be gated in software or hardware to produce the ping signal to drive the transducer.

//http://forum.arduino.cc/index.php?topic=122065.0

#define myOutputPin 9

void setup ()
{
pinMode (myOutputPin, OUTPUT);
TCCR1A = 0;
TCCR1B = 0;
TCNT1 = 0;
OCR1A = 185; // toggle after counting to 8
//184 = 43123 Hz
//185 = 42980 Hz
//186 = 42752 Hz
// Note My Arduino Uno Clock Is a bit Slow
// 7 = 999278 Hz
// 0 = 7994045 - 7993948 Hz
// Freq Measured with HiZ input Radio Shack 22-306 Counter
// 1.000037 Khz Calibrator = 999 - 1000 Hz Measured
TCCR1A |= (1 << COM1A0); // Toggle OC1A on Compare Match.
TCCR1B |= (1 << WGM12); // CTC mode
TCCR1B |= (1 << CS10); // clock on, no pre-scaler
}
void loop () { }


#16

Handy piece of code Bob. Got compilation errors when I tried it. Can you check if this was your running code?

problems with:

TCCR1A |= (1 COM1A0); // Toggle OC1A on Compare Match.
TCCR1B |= (1 WGM12); // CTC mode
TCCR1B |= (1 CS10); // clock on, no pre-scaler

should that be:

TCCR1A |= (1 << COM1A0); // Toggle OC1A on Compare Match.
TCCR1B |= (1 << WGM12); // CTC mode
TCCR1B |= (1 << CS10); // clock on, no pre-scaler

Jim


#17

cut and paste issue:

meant

TCCR1A |= (1 << COM1A0); // Toggle OC1A on Compare Match.
TCCR1B |= (1 << WGM12); // CTC mode
TCCR1B |= (1 << CS10); // clock on, no pre-scaler


#18

I see the problem - the less than symbols are being dropped in the forum comments!


#19

After changing the code to look like the example you cited,

//http://forum.arduino.cc/index.php?topic=122065.0

I ran it on my Arduino Uno and using my National Instruments Lab View gear (low end USB based DAQ system). I saw a rough square wave at 42.96KHz (just bare wire no probes), 5Vp-p. The Digital Signal Analysis SW indicated +6dbVrms at the center frequency with peaks less than -5db at 31KHz and 55KHz. Since the transducer sensitivity is so peaky around it's resonance frequency (see Bridget's Thesis - graph on frequency response of the piezo-ceramic transducer - Figs. 5.2-3) we many not need to filter the square wave.

Jim


#20

Jim / Bob et al

Just as a small adder (remember my electronics is not great I can sort of read the circuits and half understand what they are doing) I would look at a large capacitor (Super Capacitor??) in the transmit circuit acting as a storage bank (so not limited by the battery draws) to give a high peak to peak voltage output so that you can push more energy into the water (the more the better). Range as you know would know is based upon both frequency and power output