What sort of specs should i look for when choosing the most appropriate transducer? In other words is there a way to see it's sensitivity for receiving? I assume that if it can operate from 5+-200 kHz then it should be able to receive those frequencies?
dc42,
The transducer you mentioned has an transmission angle of 20 degrees. in which case i would need to rotate it 360 degree's to insure reception. in this case 20 goes into 360 18 times, therefore i would want to broadcast the same signal at least 36 times. If it was rotating every 2 seconds then that would mean 18 transmissions every second. Will this be a problem since the goal is to transmit as slow as possible for reception purposes? According to Crossroads my bit rate would be 352bps if the transducers were aligned. However in the rotating situation the Bit rate would have to be bumped to 6336bps.
I think you will find there are very few undedwater ultrasonic transducers generally available so you may have to accept whatever you can find. A narrow beam transducer will have greater range and less sensitivity to multipath interference than an omni directional one and these should more than compensate for the increased bit rate needed. If the water is shallow then you could try pointing the transmitter straight down and picking up the reflection from the bottom.
Will the PLL filter out the multipath interference that i assume is inevitable?
At the moment i am drawing up a schematic for the receiver on Cadsoft. I see from the transducer that there are three wires coming out of it. I assume on the receiving end i will only us one of the three?
What values should I be using for Rf and Cf in the schematic below?
What is the use of the Vh and Vl terminals?
I would choose the non-inverting configuration and use a single +5V supply, see attached schematic. I've designed it for a gain of 100, and I'm assuming that there isn't a lot of other ultrasonic noise to filter out (if there is then you could use a twin-T network in the feedback loop to reduce the bandwidth. The 1K input resistor limits the input current to 30mA (as per the datasheet) when transmitting if you use the same transducer to transmit as well.
The Vl and Vh terminals of the OPA699 are for limiting the output voltage. You can leave then disconnected.
The PLL will help filter out most sorts of interference, however your best defence against multipath interference is to use as low a bit rate as possible, and select the PLL response time to reject modulation frequencies higher than the bit rate.
You should include some sort of error detection and/or correction in your data protocol so that you can detect errors in the received data.
Do i use my carrier frequency (200 kHz) as the zero value for the binary? if so how far off should the second frequency be? i assume the second frequency would be best as an octave of the center frequency?
If i need to use a center frequency and two additional frequencies what should i set the three frequencies to?
Depending on the encoding scheme you use, you need either 2 or 3 frequencies. Ultrasonic transducers have a fairly narrow bandwidth. The 200KHz ones I found have a bandwidth of 25KHz.
If you program timer/counter 2 to take its clock input directly from the system clock and toggle the output pin on a compare match, then on a 16MHz Arduino you can get output frequencies of 8/(1+x) where x is the value you program into OCR2A. See page 152 of the full datasheet. So you can get frequencies of 190.5, 195.1, 200, 205.1 and 210.5 kHz, which should be suitable. As the centre frequency has a tolerance of +/-10KHz, it is probably best not to use the outer two of those.
Hi.
Real interesting subject. I have been building RoV's and underwater vehicles for a few years now and as far as I am aware of no one has done this with any success.
U.S. navy have spent a lot of time and cash developing any sort of communications for its subs.
Any depth in sea water will kill any frequency. Yes the lower the frequency the better.
U.S subs use a drift aerial approx a mile long to get any signal in or out.
I am interested on this subject and will watch your devepment on the forums.
I remember reading a defence paper about a proposal to use green lasers to transmit data to submarines at higher datarates than the ULF systems normally used.
The devices in question were mounted on satellites, which may limit their practicality for amateur use, but the principle remains.
AWOL:
I remember reading a defence paper about a proposal to use green lasers to transmit data to submarines at higher datarates than the ULF systems normally used.
The devices in question were mounted on satellites, which may limit their practicality for amateur use, but the principle remains.
How would the satellite laser know the exact location to point the beam to a submerged sub? Doesn't sound like a practical method to replace the ULF system that allows the sub's location at any time to remain secret even to our side but still able to receive launch instructions.
If you're a member of the IEEE, the paper is available online; I read a digest in Jane's.
There are other articles online from later in the 1980s.
Not a member. But it just doesn't sound like a workable system even if green or other color high power laser can penetrate water to some workable depth, one still would need to know where the target was located for a narrow beam to reach them? And a sub on nuclear patrol duty never purposely gives it's present location to anyone.
Below is the schematic for the receiver that i have come up with, i still need to adjust the LPF and set the center frequency for the PLL. However overall does this look correct? I have a FT232R for communicating with the computer via USB. The compared binary from the comparator will be fed to the RX terminal as seen below. I assume there is no need to attach anything to the TX since the receiver is only talking to the computer.
Values of C4 C5 R6 are wrong, see my original sketch (100 by itself means 100 ohms, and nF means nanoFarads)
The + input of the comparator needs to be biased to half VCC, so you need to add a 10K resistor between it and ground.
You only want a sufficient frequency capture rang to cover the transmission frequencies (e.g. 185KHz to 215KHz), so you should add a resistor (or resistor + pot in series, so you can trim the centre frequency) between pin 12 of the PLL and ground. Then recalculate R9 C9. See page 15 of http://www.ti.com/lit/an/scha002a/scha002a.pdf.
R13 is probably too large, you may need a lower value for better noise immunity, especially as reducing the frequency range of the VCO will increase the PLL demod output signal.
Also, what baud rate are you planning to use? The lower the baud rate, the less you will be affected by multipath interference. But the FTDI chip only goes down to 183 baud according to the datasheet I found, and I don't know whether the virtual COM port driver for the PC can even go that low. If you find that you need to use a lower baud rate, you will need to use an Arduino or something else to receive and retransmit the signal.
Do you have an oscilloscope? I wouldn't want to try getting this to work without one.
I have started working on the Transmitter circuit. You mentioned using a mosfet driver chip. what about a regular mosfet transistor (data sheet below)? The mosfet, i assume, will connect to a Tank circuit before feeding to the transducer?
What about using a VCO attached to an amplifier? I searched for VCO's and found some but they operated in frequencies above 200 kHz. If i went this direction, could i use a PLL and drive it with PWM voltages connected directly to the VCO?
I am considering a 1200 baud rate. I will have a total of 6336 bits to transmit and so considering transmitting at ruffly 6 bits per baud. Would this make sense? Hopefully this baud rate will not result in to much multipath interference
bigolbug:
I have started working on the Transmitter circuit. You mentioned using a mosfet driver chip. what about a regular mosfet transistor (data sheet below)? The mosfet, i assume, will connect to a Tank circuit before feeding to the transducer?
No, driving the transducer using a single mosfet would be very inefficient. I suggest you a mosfet driver such as TC4420 or TC4429. Use an SMD adapter board if you find it difficult to solder. You don't need a tank circuit, the transducer behaves like one already. I would use a series capacitor and inductor between the mosfet driver and the transducer, tuned to 200KHz. Ths capacitor avoids putting DC across the transducer and the inductor suppresses the harmonics. Put a 10K resistor in parallel with the transducer for the capacitor to charge through.
As an easy alternative to the mosfet driver, you could drive the transducer direct from an Arduino pin through a 100 ohm series resistor and capacitor, but the transmitted signal will be lower. Using the mosfet driver, you can drive the transducer with a higher amplitude such as 12V p-p if you have a 12V supply available.
bigolbug:
What about using a VCO attached to an amplifier? I searched for VCO's and found some but they operated in frequencies above 200 kHz. If i went this direction, could i use a PLL and drive it with PWM voltages connected directly to the VCO?
What's the point? As I pointed out, you can get the frequencies you need from the mcu anyway, and they will be more stable than you would get from a VCO.
bigolbug:
I am considering a 1200 baud rate. I will have a total of 6336 bits to transmit and so considering transmitting at ruffly 6 bits per baud. Would this make sense? Hopefully this baud rate will not result in to much multipath interference
Using 1200 baud rate with 1 start and 1 stop bit, you will get 1200 * (8/10) bits per second, so it will take 6.6 seconds to transmit all the data. Have you considered whether you can represent the data using fewer bits?
Unfortunately i have not written any code regarding data to bit conversion so i do not know what is possible at this point. However if the arduino is only transmitting numbers i assume i should easily be able to do so in fewer bits. For the transducer to rotate and transmit i will need to send sets of data (pressure, temperature, orientation...) in 1/18 of a second. Would it be good to separate sets of data with a third frequency to avoid misappropriation on the receivers part? Something like 190.5 kHz, 200 kHz, and 210.5 kHz with 190.5 as the error check frequency?
bigolbug:
I am considering a 1200 baud rate. I will have a total of 6336 bits to transmit and so considering transmitting at ruffly 6 bits per baud.
You haven't mentioned much that I can see about your proposed modulation method. Are you thinking of an PSK or FSK type arrangement? 6 bits per baud is probably pretty ambitious. If it were me, I would start with some sort of simple binary keying -- On-Off Keying or a 2-frequency shift -- and then use a known robust encoding, like the one used by VirtualWire. This would yield something like 0.3 to 0.5 bits/baud, but with some built-in error checking.
