Fortunately the signal output by the Darlington transistor pair on the receiver is a pretty clean digital signal.  At full power it ranges from (a little above) 0 V to (a little below) 3.3 V.  As the transmitter gets farther away the digital signal remains but the low voltage increases beyond the UART receiver’s ability to read a 0.  For example, at a large distance the UART signal might range from 2.5 V (logical 0) to 3.3 V (logical 1).

There are several options I’ve considered:

The handy old Schmitt trigger is the most straightforward, but it’s touchy to design and it will add a bunch of parts (an op-amp and a bundle of resistors).  I tried using a comparator chip, which is like the Schmitt trigger but simpler, but I found that it had a big limitation.  It worked, but the inputs can’t exceed Vcc – 1.5 V (the “common mode input voltage range” on the datasheet).  It can’t read a digital signal ranging between 1.8 (or more) and 3.3 V, so it would provide some amplification but not a lot.  I’m targeting 90% of Vcc as my threshold, so it should read anything below 3.0 V as low.  I also considered using another PNP transistor to amplify the difference between Vcc and the input voltage, but: that much amplification is risky noisewise, an extra transistor reduces the bandwidth too much, and the PNP transistor will produce a logically inverted signal.

Another option is to amplify the signal using crazy op-amp magic, but aaaaaaah no.

So I tried thinking like I’m supposed to for once, and I’m going to try a software solution.  AVR processors include an analog comparator, which I can (hopefully) use to amplify the digital signal coming from the infrared optotransistor.  The downside to doing it this way is that it bypasses the UART module, which means that the application needs to receive data manually (I can still use UART to transmit the signal).  Receiving data will tie up the processor, but as long as there’s enough time to run the receiver code it should be okay, I don’t foresee much data traffic.  Here’s a potential flow chart for the receive procedure:

Software receiver flow chart.

Some notes:

• The wait process is a euphemism for “disable the timer, store the data, blah blah blah, then go back to the program until the next start bit.”  This process takes place during the stop bit, so if there’s another byte incoming then it should finish in time to receive the next start bit.
• Kevin Rosenberg’s awesome tool AVRCalc calculates that the 8-bit timer running at 8 MHz can be used to generate a 57554 Hz interrupt rate using an OCR value of 0x8A.
• I might need to mess around with the timing so that the AC reads the right bit, but probably not.  There should be plenty of interrupt overhead delay, and the sampling rate is a little slow and will drift toward the end of the bit.
• I’m not sure how long the analog comparator takes to produce a result but I’m guessing it’s pretty fast because it doesn’t have to do much.  The AVR datasheet doesn’t have much information on it.  I also don’t know if the comparator has a large common mode input range.

Failing that, I can look for an external comparator with a large common mode input range, or just suck it up and use an op-amp.

• Acoustic modem
• Motor control
• Depth control (buoyancy control and pressure sensing)
• Master controller

Rather than wiring everything together, I plan to give each module its own power supply and use an optical communication protocol to connect the modules to the master controller.  The inside of the hull will be cleaner and more solid than if everything was wired together, and waterproofing will be easier.  Here’s how it works:

I’m thinking about the depth controller at the moment, so take that as an example.  The master controller wants to send a depth set point to the depth controller.  In my current design, such as it is, the master controller sends a signal to a high-power infrared emitter via a transistor.  This could be e.g. a UART signal (inverted to be active high).  The infrared emitter lights up the inside of the hull with the signal sent by the master controller.  Everything receives this signal, so the frame will be addressed to the depth controller.  The infrared signal is transduced back to a TTL UART signal using an optical transistor and a pull-up resistor or filter, and the UART signal is fed to the depth controller’s UART receiver.  The depth controller transmits its detected depth back to the controller in a similar manner.  This is a very simple non-modulated (baseband) infrared communication protocol.

I can foresee several issues that demand exploration:

• The emitter isn’t strong enough: I hope this won’t be an issue in a small, enclosed, dark sphere, but I might be able to arrange all the modules so that the IR components have line of sight.
• Infrared absorption and reflection: the module casings will need to be transparent to infrared.  I currently plan to have most or all of the casings be made out of clear acrylic, and I will need to test the infrared transmission through air, acrylic and water.
• Data rate: the two kinds of optotransistors I bought have rise/fall times of 10 and 15 microseconds, leading to a theoretical maximum throughput of 33 to 50 kbps.  I don’t need high-bandwidth communications though, so the data rate can be lowered easily to reduce interference.
• Grim shadows: I am not designing the AUV to be sea-worthy, in part so I don’t have to deal with crud building up and blocking the optical signal.  The module casings should stay clean, and with only a couple wires inside the hull this is unlikely to be a problem.
• Collisions: The master controller will initiate all communications, and all communications will be synchronous.  This is effectively a one-wire bus protocol, kind of like I²C with an asynchronous clock.
• Other UART errors: Specifically framing errors.  Likely each module will have a crystal.  Even without a crystal, so few data will be transmitted at a time that framing errors should not be a problem, but I will probably keep a sanity check on the UART’s frame error detect bit just in case.

My original idea associated each module with a colour instead of an address, so a module would only receive data transmitted on the correct wavelength.  As a friend once said to me, “Rube Goldberg would be proud.”

I also came across some really cheap waterproof transducers that may be suitable.  Unfortunately they both have high directivity, whereas I’d like at least an omnidirectional transmitter.  Another possible issue is that they’re made for outdoor applications, not underwater applications.  How waterproof is “waterproof”?

This guy has a super-cool post on driving the little waterproof transducers.  Instead of using a step-up transformer, he uses an inductor and a MOSFET.  The inductor gets charged from a 9 V battery through the MOSFET.  When the MOSFET is opened the magnetic field collapses and it sends about 300 mA of current through a diode to power the transmitter.  This is called the inductive flyback method.  Awesome!

One final note: I found what look like the transducers that are on the ranger modules I’m using.  Less than US$3 per pair.

Transmitter (top) and receiver (bottom) circuits.

I’ve previously described the power supply and transmitter for my acoustic modem.

The receiver circuit completes the modem’s hardware design.  It is simply a two-stage amplifier that gives a total gain of about 2000, in series with a band-pass filter.

The acoustic transducer produces a beautiful sine wave with nearly no noise.  I found that I could apply a huge gain to its output and the amplifier’s output would still be clean: the raw (unfiltered) output has a 5 V offset, and the signal fits into the 5 V above the offset.  In other words, the output is at -5 V when idle and peaks at around 0 V when the receiver receives a signal.

The goal is for the receiver to output a signal that is around -10 V when idle and peaks at -5 V when it receives a signal.  These voltages correspond respectively to logic low and high on the microcontroller.

The band-pass filter serves two functions: a blocking capacitor (the simplest kind of high-pass filter) removes the 5 V DC component, and a low-pass filter removes the 40 kHz carrier wave.  The filter also has a side-effect of attenuating the signal, so that the filter’s output peaks at 1 V instead of 5 V (this is bad).  The attenuation problem can probably be avoided, either by tuning the filter better (I’m not sure how), or by replacing the DC blocking capacitor with a diode or something that drops 5 V, or by subtracting 5 V from the output with a difference amplifier.  From now on I discuss the output of the filter, not the raw unfiltered amplifier output.

The receiver's output (0.5 V/div vertical and 500 μs/div horizontal)

You can see the receiver’s output in the photo above.  Unfortunately my screen capture technology is unsophisticated.  The output peaks at just over 1 V (due to the filter attenuation), and lasts for about 3 ms (recall that the 40 kHz carrier signal is filtered out, so it’s just one big chunk of signal).  The waveform corresponds to a very strong input into the receiver: I held a piece of paper about a foot above the modem and transmitted an acoustic ping with the transmitter.  The waveform looks somewhat different when the received signal is weaker:

The receiver output for a somewhat weaker signal (0.5 V/div vertical and 500 μs/div horizontal).

This corresponds to the piece of paper being held a metre or so away from the transmitter.  There is a dip in the middle of the signal, and a lone tertiary peak a little more than 0.5 ms after the original wave ends.  As the acoustic signal gets weaker, this dip gets more pronounced.  This is caused by ringing in the receiver transducer’s piezoelectric sensor.

As I mentioned in my post on the transmitter component, the transmitter encodes a 1 bit of data as eight acoustic pulses at 40 kHz (a 0 bit is simply encoded as no signal).  The total duration of the acoustic signal is 200 μs; clearly this is much less than the 3 ms output observed at the receiver.  What happens is that when the acoustic signal is received, the receiver starts to resonate, like a guitar string.

It takes 8 pulses for the receiver’s piezoelectric crystal to reach full resonance.  Once the acoustic signal stops, the crystal continues to resonate, until after 3 ms the energy finally dissipates and the crystal goes quiet.  I’m not totally sure what’s going on, but I think the dips are caused when the resonance somehow interferes with itself; you can observe this phenomenon in many resonance effects.  Eventually the resonance gets back into phase with itself (or whatever) and reinforces itself for a while.

Anyway, the good news is that even at large distances (>10 metres) the acoustic receiver can pick up the transmitted signal effectively, and the receiver’s output includes a strong peak that fits reliably in a 3 ms window.  This means that for data transmission, one bit can be sent every 3 ms, for a total bit rate of 333 bits per second.  This is a low data rate, but not so much lower than that of commercial modems.  I’ll write more about data transmission later.

Acoustic transmitter circuit.

Above you can see the transmitter part of my acoustic modem.  From left to right, the components are: the power supply, the acoustic transducer, the amplifier, and the microcontroller.

The problem: I need to send a 40 kHz, 20 V peak-to-peak square wave to the transducer.  The circuit has two outputs, + and -, that are connected to the two transducer pins.  In other words, each output needs to switch from +10 V to -10 V  and back once every 25 microseconds.

As always, there are a few decent solutions, and as always I didn’t implement the best one.

Solution: Transformer

I think the best solution, or at least the awesomest, is to use a step-up transformer.  I don’t need a transformer because the transducer I’m using is pretty low-voltage, so I can use it with a reasonable power supply.  A higher voltage transducer such as the Meas-Spec US40KT-01 [PDF], which operates at up to 300 V peak-to-peak, would definitely need a transformer.  The main downside of using a transformer is that I don’t know very much about using transformers, and also I suspect the circuitry will be more expensive (I do have room in my budget).  The upside is that it will produce a  high voltage signal and should be a simpler circuit once I figure it out.

Solution: Amplifier

I have a little microcontroller generating a 0 V to 5 V square wave at 40 kHz.  Originally I had some kind of vague notion that I would use an amplifer to bump the micro’s output up to 0 V to 20 V.

My stumbling block is that the microcontroller is grounded to the -10 V rail, so according to the op-amp, the micro’s outputs are actually from -10 V to -5 V.  How do you amplify that to a signal that goes from -10 V to +10 V?  I’m sure there’s a slick way of doing it by mucking around with virtual ground, but I gave up pretty quickly.

Solution: Schmitt Trigger

Suddenly it’s clear why I wrote a log entry about the Schmitt trigger!  Another reason: I was too busy to make a long log entry about something more complicated.

Originally I learned about the Schmitt trigger trying to figure out how to turn the receiver’s analog output into a digital signal.  It transforms a signal of arbitrary amplitude into a digital signal flipping back and forth between the op-amp’s two power rails.  I was going to turn the ±10 V output into a 0-5 V output by adding a diode to block the -10 V signal and a voltage divider to turn the +10 V signal into +5 V.

Anyway, the Schmitt trigger produces a ±10 V signal and hey, that’s exactly what I want, so I just made a Schmitt trigger with threshold levels between -10 V and -5 V (that being, again, the microcontroller’s output from the op-amp’s perspective).

It works okay.  The ±10 V waveform is more trapezoidal than square.  Square waves are always are kind of trapezoidal, but this one is really trapezoidal.  But it’s square enough and the acoustic signal it produces is fine.  The raw output of a receiver module receiving my signal is indistinguishable from that of the SRF04 I’m trying to copy, except my signal is marginally more powerful (since I’m sending the transducer a slightly higher voltage).

So that’s what I’m using as a transmitter for now.  The plan is to upgrade the transducer and switch to a transformer amplifier at some point down the line.  This transmitter functions as a proof-of-concept that works well in air (how to get it working underwater is TBD).

Output

Visualization of the output waveform.

The modem encodes data in acoustic pulses, as shown above.  The image is a representation of a single 1 bit, encoded as eight consecutive pulses at 40 kHz.  I will discuss this more later.

The puzzle I’m working on right now is how best to actuate the transducer to generate a 40 kHz pulse.  The SRF04 does it using a chip that’s intended to convert 5 V logic signals into the ±12 V signals used for the RS-232 serial protocol.  Unfortunately most RS-232 converter chips aren’t made to power an acoustic transducer, and they aren’t able to provide enough current to generate a strong signal.

I bought a couple ADM208EANZ RS-232 converters, which seem like they should be able to provide up to 40 mA.  I didn’t read the datasheet carefully enough and failed to notice that it needs a bunch of 0.1 μF polarized (i.e. aluminum electrolytic) capacitors.  I have 0.1 μF ceramic caps, and I have various electrolytic caps, but I don’t have 0.1 μF electrolytic caps.  The chip will generate +9 V with a 10 μF cap, but it won’t generate the -9 V rail.  I have no idea why some circuits require capacitors with polarity, but if the diagram has a plus sign next to a capacitor you really need to pay attention.  Ceramic capacitors, which don’t have polarity, might not work.

(Most RS-232 converter chips generate ±9 V instead of ±12 V, presumably because ±9 V is easier.  The input is 5 V, then they put that through a voltage doubler to generate 10 V and put that through an inverter to generate -10 V.  Then I guess they put both through something that drops 1 V (a regulator or something to stabilize the output) and you end up with ±9 V.)

If the ADM208EANZ can power the transducer, I think it will be the best solution.  I see three downsides to using an RS-232 converter:

1. You’re limited to an 18 V swing (or perhaps even less) instead of the full 20 V.  This isn’t a major problem because the transducer output is roughly a logarithmic function of the voltage input, so the output difference between 18 V and 20 V isn’t very high.  But if you want to upgrade your transducer to something like the Maxbotix MaxSonar-UT transducer, which takes up to 60 V, then you’re stuck at 20 V.
2. The receiver’s amplifier is a little more complex because you have to operate it on a single rail (i.e. 0 V to 5 V instead of -10 V to +10 V).  This downside is overwhelmed by the upside of not having to generate a  ±10 V power supply.
3. The SRF04 documentation notes that they had to turn the RS-232 chip off while receiving to reduce noise.  The noise is probably from the step-up converter and inverter that generate the positive and negative voltages.  This is pretty annoying, and now that I mention it I recall that the ADM208EANZ doesn’t have a disable feature.  I might be able to filter the noise.

The upside is that the RS-232 converter can be powered from the same 5V supply as the rest of the electronics.  It doesn’t need a complicated battery assembly or external step-up converter, or a bunch of regulators to generate reliable voltage rails.  It just needs a battery and one 5 V regulator, which is more power efficient and space efficient.

One final comment: ADM208EANZ looks like Adam 20 Beanz.