Click to email me

Click here for the Latest Update

Don’t you hate it when, 15 minutes into your dive, you and your buddy become separated and, because we are all safety conscious, after two minutes of unsuccessfully looking around for bubble streams or a patch of a yellow cylinder in the haze, you head reluctantly for the surface.  I’ve had this experience on a number of dives.  One recent event is worth recounting.

It was a boat dive in open water to a reef at 15 m.  The visibility was about 5 m. The surface current was strong and my buddy (a dive instructor) and I descended rapidly to the reef below and set off just west of North into the current looking for crayfish and that photo opportunity of a lifetime.  We’d being progressing steadily when I noticed a Blue Maomao behaving very peculiarly, rubbing itself on a kelp stem. I moved in for the photo.  On closer investigation the beastie had been foul hooked and the nylon filament had entangled in the kelp.  Prior to the dive we’d been fishing to kill deco time.  A couple of the lads had lost their lines following strikes and this was clearly the result of one of those incidents.  My buddy and I set about freeing the fish and with no thanks it darted off to live another day. Photo opportunity gone we set off again on our bearing, buddy leading. I’d covered about 5 m when I was pulled up short by a fin. The nylon filament had tangled around my left foot (and as it transpired, also my dive knife and a clip on my BCD).  Darn! I deflated my BCD, settled on the reef, and set about untangling the line.  My buddy, oblivious to my peril, had disappeared. After about five minutes I’d identified and cleared all the snags. But my buddy was nowhere to be seen. I like to dive by the book so I figured I had about two minutes to link up or head to the surface. I set off with purpose on our original course and after about two minutes aborted the dive.  During my accent the current carried me back just to the stern of the dive boat.  They noted my presence and left me to drift with another diver, picking us both up some ten minutes later.

If only I’d been able to locate my dive buddy. He’d continued on the designated heading and, having decided that I had been distracted by a photo opportunity, completed the planned dive alone.

Some weeks earlier I had been diving with Ivar (he features in the Great Barrier photo gallery – check him out). Ivar had a nifty sonar gadget for finding the boat. It comprised two devices housed in clear plastic cases, each turned on by a magnetic reed switch. One unit was a sonar transmitter hung from the boat. The other device was a receiver carried by the diver to locate and home in on the transmitter signal. It had a couple of LEDs for direction finding. I don’t know if Ivar had to extend his mortgage to buy the gizmo but he did say that it wasn’t cheap.

Navigation has never been an issue for me in my limited diving experience. Sometimes I have been slightly embarrassed by the current but I am usually not too far off the mark and I’ve never felt totally lost in inner-space. But linking up with a lost buddy is another matter.

Hence my current project: a sonar buddy locator. The concept is a cheap, unobtrusive, neutrally buoyant sonar transceiver rated to a depth of at least 40 m for each diver.  It would allow either diver to locate the other should they loose visual contact.  The device might also be useful on night dives.

This application cries out for a microcontroller (MCU).  I chose an SGS-Thomson ST6201 because I have a development kit, a number of EPROM ICs for prototyping, a general purpose development board that I made some time back (Figure 1), and familiarity with the instruction set/hardware. The MCU has an on-chip analog to digital converter and lots of I/O.  However there are lots of other micros that would be equally or better suited to the task including Atmel, PIC and TI.

Figure 1.  Development Board

The first mission was finding some affordable ultrasonic transducers.  Jaycar Electronics sells an AU5550 40 kHz transducer in a waterproof aluminium housing with a transmitting pressure level of at least 105 dB and a receiving sensitivity of at least -74 dB for just a few dollars (http://www.jaycar.co.nz/). A few calculations on sound pressure attenuation in water promised a range of at least 250 m for a point-to-point communication channel within the half power beam width of the transducers with a receiver gain of about 50 (34 dB). The transducers require a transmit signal of 140V ppk for peak power transmission at 40 kHz for 0.4 ms every 10 ms.  The data sheet for National Semiconductor’s LM 1812 Ultrasonic Transceiver IC provides a design basis for a battery powered transducer drive and receive circuit. There is also a lot of information on the web associated with robot ultrasonics. Figure 2 shows the concept hardware block diagram.

Figure 2.  Hardware Block Diagram

Ultrasonic transducers are narrow bandwidth resonant devices.  This should eliminate the requirement for selective filtering of the received signal, simplifying the hardware. I settled on the use of a single ultrasonic transducer for receive and transmit to reduce the size of the device. The limiter is to prevent destruction of the receive amplifier when transmitting.  Having selected an MCU and transducer, the MCU oscillator frequency was set to drive the transducer at 40 kHz. The ST62001 divides the master oscillator by 13 for each instruction cycle.  The best off-the-shelf crystal I could find was 4.1943 MHz giving eight MCU instruction cycles every 40.3 kHz. This is well within the +/- 1 kHz tolerance of the transducer.

An ultrasonic signal channel transmission in the ocean at recreational dive depths may not actually be line of sight and I have no idea of the effects of sea water on the transmission characteristics of the AU5550. Additionally there are numerous potential sources of sound reflection including the surface, the bottom, obstacles (including divers) and thermoclines.  Refraction due to changes in temperature and salinity may also cause signal paths to bend. Where several signal paths exist from a transmitter to a receiver signal reinforcement or cancellation can occur. I figure that these issues will need to be evaluated in sea trials.

The 60 degree beam width (-3 dB) of the transducer could also be a problem.  I expect that an errant buddy will usually be heading away from me, so provided that their transducer is leg or tank mounted and facing their fins, the transceiver alignment should be close enough.  Sound reflections from the surface and seabed are likely to be helpful. If no signal is received then the receiving diver should move away from any immediate obstacles, try the points of the compass at different inclinations, ascend a few metres and try again.

My initial concept was to have transceivers on each diver in a buddy pair, both transceivers normally transmitting.  When either diver recognized that they couldn’t see their buddy they would initiate receive mode and use the received signal strength to locate their buddy.  I drew up a flowchart and wrote the code in assembly language over a few week nights to prove the concept.

For maximum range the transmitters would need to be operated at their maximum power, but having them on all the time was not a good idea due to the battery power supply. The peak transmit current was estimated to be several amps.  Although the average transmit power was only about 0.8 W the repetitive peak current would quickly deplete the batteries. Alkaline AA batteries have a rated capacity of about 2.7 A/hrs to 2/3 rated cell voltage.  The unrealistic alternative was to strap a car battery to each diver or provide a long extension cord.

Plan B meant each device would normally be in receive mode with relatively low power consumption.  When a diver realized he/she was lost they would push a button on their unit, transmitting a short signal that would cause other diver’s unit to transmit continuously for a couple of minutes provided they were within range.  The local unit would then show received signal strength and signal peak, allowing the receiving diver to locate the transmitting buddy.  I figured that if a unit was transmitting then another diver had initiated the transmission and help was on its way.  Therefore if your device had been placed in transmit by another diver there should be no need for you to initiate a transmit cycle on another diver’s device, and you could tell that help was on its way.  If the devices were out of range then, after a minute or two pointing the receiving device in different directions, it was time to head to the surface anyway.

What would happen if there were a bunch of divers, all with gizmos?  If someone initiated transmit on the other divers then there was the potential for all of the devices to be eventually locked into transmit mode. I decided that after a device had gone into transmit for a few minutes, it would go to receive until there was no signal. Only then could it be triggered into transmit again. This way if there were multiple divers within range then the device should still allow a lost dude to find the nearest diver.

The unit could also be used to locate a boat just like Ivar’s. Excellent!

The practice of drawing flow charts for software development seems to have gone out of fashion.  I have worked at various times with ‘brilliant’ programmers that set about programming tasks by immediately writing code, done in the belief that modern languages are largely self-documenting and force structure. I don’t subscribe to this approach at all. I start with a flow chart (see Figure 3).  Then I break each task into smaller elements eventually ending up with blocks that can be written in 10 instructions or so.  Common code segments can be placed in subroutines.  The blocks are relatively easy to test and debug. I have a book somewhere that describes this approach as 90% perspiration and 10% divine inspiration, but it does produce structured programs that work.

Figure 3.  Top Level System Flow Chart

The software was written and tested on the development board in a couple of evenings and in less than 300 bytes of non-optimized code.  With a power supply of 4.4 V the gizmo drew 1 ma in the idle receive state, 4 ma in transmit, and a maximum of 20 ma with all seven signal strength LEDs and the transmit LED on.  The 16 transmit pulses were measured at 40.328 kHz with a repetition period of 10 us, and very little jitter – perfect.

The next step was to decide on a power supply to enable the design of the ultrasonic transducer drive amplifier. The MCU was rated to operate between 3.5 V and 6 V at a frequency of 4.2 MHz.  The supply would not include a regulator but it was essential to include reverse-voltage protection using a Shottky diode, and Zener over-voltage protection would be a nice-to-have.  The supply voltage should therefore be between 3.8 V and 6.8 V. Four standard alkaline cells provide a series voltage of 6 V with rated loads to three quarters voltage – ideal.

Now to develop a transducer drive circuit.

There is some Internet correspondence that suggests that the AU5550 ultrasonic transducer isn’t much chop. I suspect (on the basis of the data sheet from Jaycar Electronics) that the problem that others have experienced is due to inadequate drive. Inductive drive is certainly the easiest to implement to get a 140 V peak across the transducer but at somewhat less than the rated maximum transducer power.  In my spare time I pretend to be an electronics engineer but resonant magnetic drives are not my strong point. (I’ve made a few mains transformers in my time, pottered with Tesla coils, and designed some MOSFET high-side gate drives, but the current task would require some thought and experimentation.) I suspect that I need a resonant 40 kHz transformer for this task.

Figure 4.  Transformer Development

Progress.  After a few days playing with a calculator I wound a development transformer on an 18 mm external diameter L8 ferrite toroidal core. The primary consisted of a bifilar winding of 28 turns of 0.4 mm diameter enameled copper wire.  The secondary consisted of 160 turns of 0.2 mm diameter enameled copper wire.  I bread-boarded a drive circuit using an LM555 and some CMOS logic to make a pulse-train driving two BUZ71 MOSFETS (selected because I had some). The primary windings were switched on opposite half cycles of 40 kHz to a 5 V rail.  The output pulse was 50 V ppk retained the basic rectangular shape with a slight slope on the rising and falling edges. An aligned, unloaded receiving transducer provided an output of somewhat less than 15 mV ppk at distance of 1 m in air.

A significant problem with this prototype design was that I failed to take account of the static capacitance of the transducer (measured at 1.75 nF and 1.6 nF for each transducer).  I needed to tune this out with the inductance of the transformer windings at 40 kHz.  I remade the transformer with 80 turns of 0.31 mm diameter enameled wire on the secondary and five bifilar turns of 0.5 mm diameter enameled wire on the primary. The math’s behind this design are here.

The transformer worked nicely producing a clean 140 V ppk square wave across the transducer, followed by a few damped resonant cycles (see upper trace in Figure 5). The transducer was certainly active – the vibration from the pulse modulation could be readily felt by placing a finger on transducer housing.

I looked for off-peak resonances by connecting a signal generator across the in-circuit transducer and (with the power off) scanned from 100 Hz to about 1 MHz.  The only resonance I could detect was at about 41 kHz.  Excellent – I had effectively tuned out the static transducer capacitance.

Using the second transducer and a similar toroidal transformer I measured the received signal at a distance of 1 m in air at 15 mV ppk (see lower trace in Figure 5).  How does this compare with the transducer receive/transmit specifications? There is an excellent reference at http:\\www.senscomp.com/specs/piezo%20application%20note.pdf that discusses this calculation.  The received signal was slightly better than the math’s predicted (see the math’s here).

Figure 5.  Transducer Drive
(Upper Trace:  Transmit 50 V/div, Lower Trace: Receive 5 mV/div. Time Base 10 us/div)

As an experiment I placed the drive transducer in a glass of salty water.  After all, the transducers will not be operating in air.  The resonant pulse decay was markedly damped and there was an extended period of low voltage 40 kHz ringing. The water appeared to have dampened the transducer housing resonance but the ultrasonic waves were reflecting around the inside of the glass. I put a second receiver transducer in contact with the water.  Wow!  The received waveform was almost identical to the transmitted pulse (140 V ppk). I placed a tuned load across the receiver. The voltage across the transmit transducer reduced due to the power absorbed by the receiver transducer.  See Figure 6.

 Figure 6. Salt Water. 
(Upper Trace: Transmit 50 V/div, Lower Trace: Receive 50 V/div Time Base 10 us/div)

The average power supply current was 52 mA in air, 35 mA in the glass of salt water with no load, and 52 mA in the glass of salt water with the tuned receiver.  The peak primary transformer current was a 1.7 A spike at the start of the transmission pulse, with subsequent spikes at approximately 0.7 A at each consecutive pulse.

With the transducer transmitting successfully it was time to think about the receiver amplifier and detector.

Christmas has arrived (almost) and at last I can make some progress on this project. The receiver amplifier was initially designed as two state-variable bandpass filters using two TL072 dual operational amplifiers (op amps). The TL072 was chosen because it was cheap, readily available, gave me two op amps in an 8 pin DIL package, promised no latch-up, and had a relatively wide unity gain bandwidth (3.0 MHz).  Because almost all of the development to date has been in air I decided to increase the amplifier gain to about 500. The bandpass filter was selected because of my concerns about the potential effects of noise.

Most of my circuit development is carried out by an iterative process of design idea/requirement, literature research, some maths, circuit simulation (Intusoft ICAP/4 Spice), and finally breadboard prototyping. Often times the theory doesn’t agree with the simulation, the simulation doesn’t agree with the breadboard, or the breadboard doesn’t work at all.

In my formative years I had the privilege to train under the guidance of Laurie Morton (ZL2AUT) at the electronics workshop of the Physical Chemistry Department of Victoria University of Wellington. Laurie was a gentleman of infinite patience, generosity, honesty and integrity and he had an incredible aptitude for electronics and instrumentation. I learnt a great deal from Laurie for which I am forever in his debt. At the breadboard stage I am often reminded of one of Laurie’s sayings:  ‘My amplifiers oscillate, and my oscillators don’t.’

Having successfully prototyped the bandpass filter I decide to compare its performance with a simple AC coupled amplifier comprising two inverting op amps.  The simple ‘no filter’ approach worked fine.  Its current consumption was a meager 3.5 mA (c.f. 8.4 mA for the state variable filter design), the device had no instability issues due to phase shift, there was only a hint of low frequency noise, and it promised a significantly reduced printed circuit board area. The bandpass filter design was now redundant.

One issue that arose through the use of the TL072 op amp was the need for a negative 5V rail.  The option of providing a low impedance 2.5 V tap from the 5 V supply was rejected because a 5 V rail significantly reduced the available output voltage swing and was less than the minimum power supply requirements for the IC.  There are numerous alternatives and many ways of providing a -5 volt rail but I settled on a charge pump IC (LM 7660) because these devices are cheap, small, very efficient, and I had some in stock.

The next part of the design was the detector.  The onset of clipping at the output op amp was measured at just over 7 V ppk. A simple diode and filter capacitor design was elected using a Shottky diode to minimize the diode voltage drop.

Finally I needed a limiter on the front end of the amplifier to prevent the transducer 140 V ppk transmit drive from destroying the front-end op amp.  I used two back-to-back silicon diodes at the inverting input of the op amp to limit the input voltage to 1.2V ppk about ground.  The 5K6 ohm resistor in series with the 0.01 uF capacitor provides DC blocking and limits the clipping diode current to about 12 mA.  The limiter was constructed and connected across a transmitting transducer to make sure it would have no adverse effects on the transmit cycle. The transducer drive current increased by about 12 mA as expected, and some of the resonance was dampened, but the drive remained stable at 140 V ppk.

The completed prototype receiver circuit has an overall gain of 460 at 40 kHz with a DC output of between 0 V and 3.8 V DC, and with a discharge time constant of 0.1 sec. It draws approximately 3.8 mA from the + 5V rail.  The circuit schematic is shown in Figure 5.

Figure 5.  Schematic

Time to build the stages on something a little more permanent than breadboard, evict the turtles (I suspect that ultrasonic radiation might have nasty effects on them) and test the device sub-aqua.

For circuit board layouts I have been using EAGLE which is available as a limited functionality free-be off the internet.  The process is described in detail here.  I print the board graphic directly onto overhead transparency using a 1200 pdi laser printer and transfer this to presensitized PCB using a UV light box. The PCB resist is developed with aged sodium hydroxide solution at about 20°C, and the copper is etched using ferric chloride or ammonium persulphate.. To ease soldering of SMD devices I tin plated the board using a proprietary tin plate solution available from RS Electronics, but this additional step is not essential.

The board design was hand-routed to minimize board size and optimize power supply and signal routing (see Figure 6). I settled on a single sided PCB using surface mount devices where possible to minimize hole-drilling and board size. The dual in line (DIL) packages of the op-amp, MCU and the charge pump ICs ended up being the limiting factor in determining the board size.  With judicious use of leaded components no wire jumpers were required.  During the board design I changed the output MOSFETS from BUZ71’s to an SOT-08 SMD MOSFET to save real estate.

Figure 6.  PCB

During assembly there was only one significant problem.  The 1 A Shottky diodes from Jaycar Electronics did not come in the advertised SOD 08 package. Sod!  (Pun intended.) With careful positioning I made the SMD diodes fit.

The finished boards measured 30 mm x 63.25 mm (1.18” x 2.5”) and were well within the plan area of four AA batteries laid two end-to-end and side-by-side. See Figures 7 and 8. The populated board height was 19 mm (0.75”) due to the MCU crystal, the use of an IC socket for the MCU, and the mode push button.  The MCU crystal would need to be changed to a lower profile package as it would interfere with the battery pack. The LED display and the mode-change push button were mounted on the track side of the board to permit a clear view of the display with the single control on the same side.

Figure 7. Populated Board - SMD Side

The circuit was assembled and tested in stages.  First I mounted all of the passive SMD devices, diodes and the LEDs and checked these individually with a multi-meter to ensure continuity and no shorts.  I populated the leaded devices starting with the charge pump IC, followed by testing; then the op amp followed by more testing; and finally the MCU.  The MCU had been reprogrammed for lamp test followed by receive-only with LED display to allow some static tests in air.  The circuit received fine in air with a receive range of at least 12 m (~40’).  Promising!  I needed another weekend to assemble the other PCB.

Figure 8. Populated Board - Leaded Component Side

With the second circuit assembled and tested a design flaw with the MCU reset circuit was discovered.  The simple reset circuit was only active on power-up. If the power supply was cycled before the power supply decoupling capacitors had fully discharged then the MCU would latch with its outputs at mid-rail voltage.  This is sufficient to turn on the MOSFETS which draw several amps through the primaries of the pulse transformer, and get rather hot in the process.  The next design would incorporate a more comprehensive hardware reset. SGS Thomson’s Application Note ‘Simple Reset Circuits for the ST62’ by T. Castagnet, J. Nicolai and L. Perier has the answer. In the meantime I use the lamp test to make sure that the devices power up properly. If they don’t, I immediately disconnect the power supply, ground the reset pin of the MCU, and reapplied power.

With the turtles safely evicted and the two devices Sellotaped to the tank lid the received signal strength was measured at all LEDS on. The devices were both sensitive to radiated noise and would readily go into transmit when the boards or transducers were handled.  The amplifier gain may need to be reduced.

With the turtles safely back in their tank it was off to the pool. The received signal strength was still all LEDs on with transmission path across the 1.2 m deep 7.75 m long oval shaped pool with the transducers placed at each end of the pool aimed vertically downward. The sensitivity noted in the turtle tank test was still a problem. Another issue that arose was that once a device was in transmit mode it would stick there. The cause was put down to transmission echoes bouncing around the pool.  When transmission times-out after 100 seconds a device is forced into receive mode until it detects no signal at which time it switches to the default idle receive mode. The device was getting to idle receive mode, then receiving its own delayed transmission echo and going straight back into transmit. This would be less of a problem in open water, but it could be counteracted by increasing the delay between transmit and receive, or by requiring a no-signal condition over several seconds before going to idle receive mode.

The amplifier gain was reduced to about 470 by changing the feedback resistor on the first op amp from 150K to 100K, and the software was modified to require a number of repetitive zero and signal detect readings before changing mode.  The units are shown operating in Figure 9. Time to make a water proof package and do some field trials.

Figure 9.  Left Gizmo in Receive, Right in Transmit

I set about making two cylindrical cases for the electronics and batteries.

The housing was more of a hassle than I had envisaged. The initial concept was a cylindrical Perspex tube with threaded end-caps and watertight O ring seals.  The transducer would be located in an end-cap, fixed and sealed by silicone rubber to prevent any problems with the effects of rigid mounting. The plastics shop (Universal Plastics) had some 30 mm internal diameter tube with 5 mm wall thickness that would fit the quad AA battery pack and the gizmo nicely. The device would be neutrally buoyant (within 20 g) and, although far from my envisioned size, would enable me to test the device underwater.

Figure 10. Prototype Case

I drew up the housing and made the tube, end-caps and PCB supports.  See Figures 10 and 11.  So far so good – they were a bit larger than anticipated, looking somewhat like a Light Saver from Star Wars, but hey, this was a prototype.  I decided to dispense with an on/off switch as a nice-to-have, at least until the prototype had been proven.

Figure 11. PCB Supports

The hassle was going to be activating the mode switch which I had located off the PCB centre to minimize the board area. While I could make a single O ring seal control button operating the switch at an angle of 40 degrees this was far from ideal. A lever or arm on the end of the control button was discounted because the control buttons were free to rotate, potentially missing the switch or obscuring the LED display. I decided to use a double O ring sleeved control seal, a concept that I had played with during the development of my camera housing.  See Figure 12.  This had the advantages of dual O ring seals with an internal return spring internal (and therefore not subject to salt water corrosion). I trialed drilling the off-centre hole and fitting the control button sleeve into a Perspex tube off-cut using cyanoacrylate adhesive and then Acrifix 192. The cyanoacrylate did not form an airtight seal first up (measured using the uncalibrated suck test) and, with the use of a press, I was able to free the sleeve by cracking the adhesive. However the Acrifix 192 worked wonderfully.  It formed an airtight seal to the brass sleeve and the only way I could release it was to fracture the Perspex with an engineer’s hammer.

Figure 12. Mode Switch Pushbutton Controls

Drilling accurate off-centre holes in tube is difficult at the best of times and more-so when working with a soft material like Perspex. The trick is to first mill a flat for the centre so that the drill will not wander off down the tube wall, ruining the work in the process. Then use a centre drill (which will not flex appreciably) to locate the hole centre and finally drill out to the desired diameter.

Rather than instantly ruin the tubes I tested the concept on a short length of scrap.  Darn - the application of the glue caused instant stress cracking of the off-centre holes in the Perspex.  Although these passed the suck test I was concerned about their integrity. I did some more trials with an extended period of annealing the machined tube at 80° C for one hour. This reduced the cracking but did not eliminate it.

I set about machining the control button holes in the tubes. Fine so far. Then I applied adhesive to the outside of the sleeves and gently pressed them into place with a drill press. After UV curing stress cracking was still evident but a good seal was achieved. See Figure 13. However a significant problem was encountered when I tried to assemble the electronics in the case.  The dimensions of the tube bore were all-over-the-place preventing a running-fit for the PCB supports.  This made alignment of the mode buttons with the control button sleeve all but impossible. It was time for plan B, a rectangular section case with a different control button arrangement.

Figure 13. Control Button Fitted and Glued. Note Stress Cracks.

Plan B involved the design of a new 12 mm diameter control button with a rubber membrane providing a watertight seal and return spring action.  See Figure 14.

Figure 14. Surface Mount Control Button

The case was made from Perspex with a 10 mm thick front plate for mounting the transducer, 6 mm thick side-walls and a 3 mm thick top and bottom. I still haven’t incorporated an on/off switch in the prototype.  Access for battery replacement was via the bottom plate held in place by 8 machine screws and an EDM rubber gasket (the same approach that I’d used on my camera housing). I had to increase the thickness of the bottom plate to 6 mm to ensure a good gasket seal between mounting screws (the 3 mm Perspex was just too flexible).

The transducers were glued in place into running fit recesses using nonacid cure RTV silicon.  This should give a good watertight seal while avoiding the problems that rigid mounts can cause with transducers.

The PCB was mounted on Perspex spacers glued to the case and held in place by four 2 mm diameter brass screws. The spacers were machined to provide 0.5 mm clearance from the top of the mode control button to the inside of the case.

The overall weight (with batteries) of each unit was 272 g with overall case dimensions (excluding the mode control button and front of the transducer) of 125 mm long with a 42 mm square section (about 5” long x 1.5” square section). This makes for a negligible 50 g negatively buoyant in sea water.

Figure 15. Prototypes Cased and Ready for Sea Trials

The finished units (Figure 15) were tested to confirm operation, closed up and put in the turtle tank to confirm water tightness.  Now all I need is a dive or two for field testing.

While I have been messing around with the case I have also been having a rethink about the front end electronics.  I have redesigned the front end several times to eliminate the need for a negative rail, reducing the board size, reducing the component count (and cost), and reducing the power consumption.  The primary change has been to replace the existing op amp with a low power single rail SMD device. The circuit simulates fine but I have yet to prototype the new design. The other changes that I have previously mentioned are also to be incorporated.  The new PCB will include a little more thought on mounting which should make future case designs easier to construct and assemble.

First Field Trials

The first field trials were completed at the Poor Knights on 11 February 2007. I have some refining to do but I am satisfied with the proof on concept.

The prototype housings didn’t leak.  Maximum depth for the dive was just over 30 m with the majority of the testing completed at 15 m. The devices were negatively buoyant.

Figure 16. Wrasse Assisting with Development (One LED Lit)

Underwater is not as quiet as it seems to the average diver. The background noise at 40 kHz forced the buddy locators into the transmit cycle, followed by the receive cycle waiting for no noise to return to idle mode – an event that simply did not happen.  The signal strength usually remained at one LED on, but this was punctuated with periods of increased noise and sustained periods of medium strength pulses with a period of about 1 second. I carried out some tests to see if this was due to diver interference. With one device handheld and the other 5 m away on a conveniently shaped sponge, and with skip breathing, both units received the same extraneous signals and showed identical signal strength. I couldn’t ask the neighbours to turn down their stereo! This was a jolly nuisance because it stuffed up my planned test program which was based of placing one unit in a static location and inducing it to transmit from increased ranges and angles.  Thankfully pressing the mode button forced transmission so I could still get some useful information from the dive.

Directionality was good (what does good mean?) Placing ones fat neoprene-clad body between the transmitter and receiver attenuated the received signal appreciably.  Pointing the transmitter out to blue water (90 degrees to the receiver) prevented any increase in received signal at the other unit, above the background noise. The devices would definitely allow direction location.

The transmitter seemed to have no adverse effects on the local inhabitants.  An inquisitive Wrasse seemed oblivious to close exposure to transmit, and a hungry Leatherjacket was more interested in the taste of the silver transducers, going from one device to the other and nibbling at the exposed aluminium housings.

Figure 17. A Conveniently Shaped Sponge (All LEDs Lit)

Echoes off objects were a happening thing. Forcing one unit into transmit and aiming it at objects perpendicular to the receiver resulted in a good received signal strength over distances of about 20 m to the object (40 m signal path).  There was a noticeable delay in reception of the received signal as one might expect – sound takes time to propagate.

The noise-induced permanent receive mode limited range testing to the maximum distance over which I could observe the LED display on the remote receive unit.  Unfortunately my original test program didn’t include using echoes off objects to test the range and I didn’t think of this on the dive.  Thankfully visibility was between 25 to 30 m on the day.  At 15 m distance with the transmitter orientated at 90 degrees to the receiver (the only alignment which allowed me to see the receiver display from a distance) I had five or six receive LEDs lit.  At about 25 m I had all red LEDs lit and some green ones, but I couldn’t discern how many.

Finally the new control button design was watertight but quite susceptible to over-pressure activation.  On one unit the control button stuck on at about 5 m depth.  The other unit worked fine at 15 m but not at 20 m.

So what needs to happen from here?

1. The transducer and receiver circuit work fine, and it anything, the gain was too high.

2. To eliminate the background noise:

a. reduce the amplifier gain, and/or

b. modify the software to increase the zero signal threshold, and/or

c. add some intelligence to differentiate the transmit signal from the background noise.

3. The control buttons should be redesigned to overcome pressure susceptibility.

4. Add a power on/off control (the magnetic bistable reed switches are on order from a company in India) to ease further testing.

5. The basic case design is watertight. It will always need to be smaller, but it would be improved with a method of attachment to ones BCD.

6. Make a transmit-only device and a receive only device (software changes to existing prototypes) to complete range and directionality testing.

Had I fully comprehended the above problems during the initial design then the prototype may have performed better during my initial trial, but I seem to be delving into a realm where published data is scant, and there is no single document that gives solutions to the problems that I have found. This is what prototyping is all about and part of the challenge of the design cycle.

Another diver on the trip suggested sizing the device to fit into a spare weight belt pocket.  While smaller is definitely better (I hate having a plethora of stuff hanging off me on any dive) sticking things in spare weight pockets isn’t always a great idea. I recall seeing a diver a few weeks back with his safety sausage conveniently stowed in his weight belt. Problem is that, should he complete an emergency buoyant assent or otherwise have cause to ditch his weights, he won’t have his safety sausage.  Before you stick something in, or attach it to your weight belt maybe you should ask, ‘will I need this on the surface?’

Another weekend and two more dives logged. The first was to Leigh Reef. Visibility was a lousy 6 m with a strong Southerly current and surge. Maximum depth was to 36 m with the majority of the dive spent at around 24 m.  I used the entire dive testing the buddy locator with one unit programmed for transmit and the other unit in receive.

The hardware had been modified to allow envelope detection of the 0.4 ms pulse and the receiver had been programmed with a new algorithm. The new algorithm takes a large number of consecutive signal readings and records the peak received value in the period. The displayed signal strength was the peak received signal minus the average received signal and a threshold value. I have played with digital signal processing techniques over the past few weeks to try and find a better way of detecting a transmit signal from the background noise. The limited memory and speed of the SG6201 micro, the shape of the transmit pulse waveform, and the filtering inherent in the transducers have been substantial limitations to the effective implementation of digital signal processing.

My initial hassle was fixing the transmitter to something. I ended up jamming it into a crevice on the top of the reef. This was far from ideal because of the kelp, which I figured was a better wall than a window for signal transmission.

Brief background noise peaks were still evident and the received signal display was somewhat less sensitive than my earlier trials (possibly because of the threshold value being too large).  With the limited visibility it was difficult to determine range but I estimated this was about 30 m (undoubtedly restricted by the location of the transmitter).

I was able to drift off from the transmitter, well beyond the visibility limits, and after a time, relocate it without reference to the terrain. Strong noise signals were easily discriminated because of their intermittent nature.

Body blocking was a happening thing. When I placed my fat bod between the receiver and the transmitter the displayed signal strength dropped to zero.  Similarly pointing the receiver into blue water perpendicular to the transmitter significantly reduced the signal strength (zero or one LED lit).

The second dive was on North Reef to about 24 m, still with limited visibility but with only a moderate current and limited surge. This time I suspended the transmitter in a catch bag from the anchor rope about 2 m above the bottom.  Again I was able to swim away from the transmitter, well beyond the limits of visibility, and find my way back without reference to the terrain.

The maximum signal strength was displayed at all points of the compass before I could see the transmitter (about 6 m vis.) which implies that I need to adjust the display routine.

THOUGHT. With the existing algorithm the problem that I am faced with is reliably detecting a transmit signal above the background noise.  This could be easily overcome if the gizmos were normally in transmit mode. The first diver to notice that their buddy was lost could go to receive and, given that they were still in range, find their missing buddy. Similarly if a diver had not surfaced at the end of a dive then the boat could locate the diver, even if they were not conscious (dread the thought). If a buddy pair needed to locate the boat then, provided that the boat also had a transmitter, they could both switch to receive and search it out. Finally, using body blocking (a proven method of attenuating signals) a diver could locate the nearest transmission device, even if there were many buddy pairs working in the area.  My earlier rejection of this mode of operation was because of limited battery life in transmit mode.  However with an average transmit current of just 65 mA, a gizmo would be operational for approximately 20 hours. This should allow at least twenty dives or ten days at two dives per day operating on four AAA batteries. A month of diving on both days of each weekend at the cost of four AAA batteries did not seem excessive. Maybe this was the way to go?

With the receiver reprogrammed and armed with a 50 m string line it was time for field trials at the Poor Knights on 7 April 2007.  Visibility was about 12 m.  The device work well up to 40 m line-of-sight, with the LED display showing good linearity with distance (6 LEDs on at less than 5 m, 5 LEDs on at less than 10 m, 4 LEDs on at less than 15 m, 3 LEDs on at less than 20 m, 2 LEDs on at less than 25 m, and 1 LED on at less than 40 m.

The revised receive algorithm had improved the signal strength sensitivity.  Background noise was still evident but its intermittent nature was easily discernible from the transmit signal. I have had some more thoughts about the receiver front end amplifier. Analysis of the signal properties indicates that improved signal discrimination from noise can be achieved by using appropriate bandwidth filtering. This requires another redesign and more prototyping. It looks like my original design incorporating bandwidth filtering was not such a dumb idea.

It’s May already and time for an update. I have redesigned the receiver front end, incorporating an active band-pass filter and a precision rectifier, and modified the transmitter. This has increased the signal to noise ratio, improved the low signal sensitivity and increased the received signal strength substantially.  Now all I need is a few weeks to finish the reworked prototype, incorporating all of the modifications that I have identified over the past few months so I can get my ideas under water.

Figure 18. Comparison of New Font End with Old
(both traces on same V/cm equidistant from the transmitter).

Thankfully it’s still May and I have prototyped Version 1.1 of the Buddy Locator.  The improvement in the received signal strength has been a factor of more than ten (see Figure 18) with a significant reduction in signal to noise. The increased transmit pulse width has enabled me to incorporate an improved receive algorithm that does a much better job of discriminating the transmit signal from background noise.  How this will function under water will require more field tests. My current mission is to finish the new Printed Circuit Board (PCB) layout using a single sided board while following good signal routing practices and keeping the board size below a quad AA battery pack outline. This weekend I have another dive planed with my good buddies at PK Dive. Time constraints will prevent me taking Version 1.1 underwater for at least two weeks.

Its August now, and I seem to have a million and one things to do. I have made the new circuit boards but have yet to populate them.  This month I’m off to Fiji to complete my PADI Rescue Diver course in warm clear water, so my spare time has been entirely occupied with First Aid training, making a new camera housing for my Pentax A20, and my data logger.

On return from a fantastic trip to Fiji I have picked up this project from where I left off. The Rescue Diver Course included several exercises for searching for a missing diver. The 30 m + visibility in the water off Tokoriki made spotting an errant diver somewhat less of a challenge than in New Zealand waters, but the potential benefits of a Buddy Locator were still apparent.

On re-examination of the circuit board I found that I’d left off a critical track in the front end amplifier.  Darn, but at least I hadn’t populated the boards before I discovered my error! I’m going to have to remake the PCBs.  The new boards were made over a weekend (it is easier to make and test them in pairs) and the analog section populated and tested. Double darn - I had made two 42 kHz oscillators! Turns out that I had also inadvertently returned the active filter negative feedback path to the wrong input of the front-end amplifier.  With SMD components the chances of reworking a stuff-up like this are remote so it was time for another PCB.  In rerouting the board I decided to make the active filter tuning resistors leaded to aid adjustment, incorporate some test points, and in the process removed two wire jumpers from the design. Desoldering multi-legged SMD components is a real chore but I persevered (mainly because I needed to reuse the op amps) and ended up with a fully functional analog section that showed all of the promise of the breadboard prototype: a gain of more than 10 over the previous design, decreased noise susceptibility, improved low signal threshold, reduced current consumption, magnetic on/off switch, ...  Time to populate the MCU end and complete the devices for field trials.

Figure 19. The New PCB’s Assembled and Tested (Less MPU, Control Button and Transducer)

9 September 2007 and the new PCB’s have been made, assembled and tested. I had decided to fit them into the cases that had housed the earlier model using double-sided adhesive tape. The existing mounting blocks would have to be replaced because the new boards are 12 mm longer the earlier model and include mounting holes.  I planned on gluing up the superfluous holes in the case from the redundant top control button. Unfortunately I had used Acrifix adhesive on the mounting blocks and they would not budge. As a last resort I decided to try a sharp, well-aimed blow with a hammer and drift.  Regrettably the Perspex case failed before the glue joint. It looks like I’m making two new cases this week!

17 September 2007 and the new cases are almost completed but I need to purchase a new M3 plug tap to finish the job. Because the new boards have a magnetic reed on/off switch there is no need to be constantly opening the case and remove the batteries. This has prompted me to think again about the rear gasket seal for the prototype.  An idea from Florin Gheorghiu has prompted me to try using Silicon RTV instead of  EDM rubber gaskets. Florin has been making beautiful custom rubber gaskets using mold Silicon.  Unfortunately I can’t find a local supplier for mold Silicon, but marine seal RTV is readily available. The mode change button will be based upon my latest camera seals for my A20 camera, actuating a push button glued to a small Perspex mount.

Following my Rescue Diver Course I have decided that the units should revert from receive to transmit after five minutes (or so). This way a unit accidentally placed in receive mode should revert to transmit which is essential if a diver is somehow incapacitated and cannot change the mode themselves. Five minutes is sufficient time for about 20 slow pirouettes, allowing a searcher sufficient time to locate a transmitter direction.  It can be reasonably assumed that a searching diver that has deliberately initiated receive will be looking at the range/direction display, and so be able to reinstate receive mode should their device time out and start transmitting.  This warrants a new flow chart. See Figure 20.

Figure 20. New Flowchart

Another weekend of no diving due to inclement weather. This has allowed me to make some more progress with the Buddy Locator. The new cases are finished, leak tested to 1.8 m, the software has been rewritten, the electronics have been installed (see Figure 21), and functional testing has been completed in air. The tests and measurements are summarized as follows.

Receive current: 8.7 mA + 4.5 mA per LED.

Transmit Current:  40 mA average (1.4 A peak during 1.6 us transmit pulses).

Weight:  230 g (0.5 lb) with alkaline batteries, 200 g with lithium.

Case Size: 123 mm x 42 mm x 35 mm (4.8” x 1.6” x 1.4”).

Buoyancy:  45 g (0.1 lb) negatively buoyant with alkaline batteries, 15 g with lithium.

Range (in air):  Linear display to ~ 14 m.

Figure 21. Ready for More Field Trials

I have also incorporated battery voltage measurement and push button test routines on power-up, after the lamp test. Now all I need is some more dive time for a further set of field trials. I have another dive booked with PK Dive this weekend.  Hopefully the Met. will be favorable

A Learning Experience (or perhaps that should read Disaster).

I’ve just got back from my latest dive adventure with two seriously dead buddy locators. They were fitted with new lithium battery packs and the cases were sealed with Silicon two days before the dive. They were tested on the morning of the dive above sea level – no problems. But on the first dive something went horribly wrong with one unit before I descended.  When I changed from transmit to receive it latched in the display mode. No sign of any leaks – it just latched and wouldn’t respond to the mode button. Rather than risk a problem down-under I threw both units on board and set off on the dive. My first thought was that the software had a problem. After the dive one of the units seemed unusually warm. I power reset both units with my trusty magnet. Power on reset seemed to have fixed the problem. Both units came up with the lamp test, showed 100% on the battery, and went into transmit.

On the next dive I powered them back on and mode switched them into transmit.  I toggled the mode buttons on the surface and again, one unit latched. This time I decided to continue with the dive. At 25 m the latched unit remained latched and the other unit would not work at all no matter how many times I pressed the mode buttons.  I put them back in my BCD pocket and set out to enjoy the rest of the dive.

It was only when I back on board and had started to disassemble my gear away that I noticed that both units had taken on water! Lithium batteries do not like salt water immersion and had exuded a particularly corrosive gel over the PCBs.  The cases were both warm – too warm. Back I dry land and I removed the case screws. The silicon gasket had failed on the back plate, midway between the screws.

So what had gone so terribly wrong?  Back at home I examined the dead PCB’s, the failed devices and a photo of one device during the testing at 25 m, and thought about my observations.

Figure 22. Dead at 25 m.

Figure 23. Corroded PCB

Both case seals had failed midway between the mounting screws and had taken on water.  The earlier model case had a thicker bottom plate on a rubber gasket with eight retaining screws. It was therefore less susceptible to deflection.

One board had been severely corroded.  Some of the copper tracks and the SMD leads had been etched entirely away! (Figure 23.) This wasn’t due to sea water alone.  The battery contents were to blame.

On one board an electrolytic capacitor had been damaged by overheating.

Both boards had one dead MOSFET. One was shorted between source and drain and the other (the more severely corroded one) was open circuit - probably following a short circuit condition. This reminds me of a fundamental rule of circuit protection - semiconductors will always fail to protect the fuse.

The photo at 25 m showed that one unit already had a damaged MOSFET and there was condensation in the case.  (Look for the pimple in the top right hand corner of the top right right hand SMD package in Figure 22 above.)

There was no sign of moisture ingress around the control seals.

The cases were warm immediately after the dive, yet the water temperature was a chilly 14°C.

The MOSFETs are rated to handle 66 A pulses to maximum junction temperature, but their rated current drops to about 8 A continuous at 25°C.  . Either salt water ingress, an intermittent hardware condition, or the software had caused the MOSFETs to stay on for an extended period of time. Extended on-time would result in an almost dead short across the batteries causing failure of the MOSFET and the battery pack.  This would also explain the heating.

The inductance of the pulse transformers and the ‘normal’ on time of the MOSFETS limits the peak current to about 1.4 A (remember V = L di/dt and confirmed by measurements).  The only way the MOSFETs could fail was due to excessive on-time.

The Silicon case seals were good, at least prior to the failure. The Silicon had remained attached to the case, but had come away from the lid. The lids had failed midway between the mounting screws.  This suggests over-pressure inside the case – likely due to the batteries being shorted.

I re-examined the software looking for anything that could possibly cause the MOSFETs to stay on for an extended period. I found three potential problems.

1. On power up the I/O ports are configured as inputs with a 100K active pull-up. Could the active pull-ups be switching on the MOSFETs?  I had incorporated a 10K resistor between each MOSFET gate and source.  Therefore the gate voltage on initialization was at most 0.6 V. Although this is unlikely to cause the MOSFETs to turn on I decided to decrease the gate-source resistors to about 1K just to be safe.

2. The MOSFETs are only switched on in a short section of code in the transmit routine. Could the MCU get out of this section of code with one of the MOSFETs still on?  I had disabled any interrupts at the start of the code segment to avoid this and to ensure that the pulse timing would be accurate.  I think I’ve found the problem - the mode switch uses a hardware non-maskable interrupt!  The solution to this potential problem was to add a single instruction at the start of the non-maskable interrupt to turn off the MOSFET drive ports.

3. Power-down only turns off the MCU because the magnetic reed switch cannot handle the peak currents through the MOSFET.  When powering down during the transmit cycle it is possible that a MOSFET I/O port can be high (on) when the MCU clock stops at about 3 V.  I had previously experienced latch-up of the MCU early in the development that caused the MOSFETs to get hot. Some quick calculations indicate that the MOSFET could be on for up to 2.5 ms during power-down. (MCU filter capacitor is 10 uF, the no-signal current drawn by the MCU and analog circuitry is about 8 mA, the minimum turn on voltage of the MOSFET is 1 V; and using V.C/i = t)   This is long enough to cause MOSFET failure due to excessive power dissipation.  It is time to implement an active hardware reset on power-down.

Why hadn’t this happened earlier?  In the first instance I had been using alkaline batteries.  They have a greater internal resistance than lithium batteries. This could reasonably be expected to limit the short circuit current to tolerable levels for the MOSFET, at least for a short while.  Secondly the duty cycle in transmit mode is about 1 in 25, and therefore latching on power-up/down or mode change becomes a random event. The failure would not be expected to occur every time. And finally in the first prototype I had no delay in the interrupt servicing routine so the offending MOSFETs would not have been inadvertently turned on for very long.

The likely sequence of events is as follows. During the power-up, changing mode, or power down a MOSFET remained on too long, overheated and shorted.  The battery pack heated under the short circuit condition and ruptured – resulting in overheating and over pressurization of the case. This caused the silicon seal to fail at the weakest point (midway between the mount screws). The shorted batteries exuded corrosive gunk which corroded the PCBs.

The software fix was easy. Just one single instruction at the start of the interrupt routine. Seeing I had to remake the PCBs I incorporated an active power on/off reset (which will also ensure that the unit behaves sensibly if the battery voltage gets too low), hardware debounced the mode switch, and improved the layout to further ease tuning of the active filter.

With the bare PCBs remade it was time to salvage as many of the components as possible from the old ones.  I managed to save half the LEDs, three of the op amps, the two serviceable MOSFETs, the microprocessors, crystals, and a couple of the passive components.  The rest has been consigned to the rubbish bin due to corrosion.

7 October 2007 and the first PCB is fully populated, ready for tuning, bench testing and mounting in the case (see Figures 24 and 25).

Figure 24. New Board Topside

Figure 25. New Board SMD and Display

8 October 2007 and the both boards have been populated, tuned, tested and mounted in their cases.  In testing I’ve toggled the mode switch and turned the units on and off several hundred times to ensure that there are no problems.  All good so far.  I’ve reused the old cases and repositioned the mode switch, filling the old holes with Acrifix adhesive. The cases are far from pristine but functional. For the moment I’ll stick with the Silicon adhesive gasket approach as I’m sure this will be successful if the units don’t overheat.  Now all I need is opportunity to go diving and carry out some more field trials.

Figure 26. Ready for Field Trials

13 October - field trials.

The first dive was to 31 m on the sand beside the wreck of the Waikato.  The devices did not overheat and did not take on water. I positioned one device beside the hull in transmit and headed due south for about 2 minutes, stopping occasionally to check the signal strength and directionality.  The signal strength was too high close in, preventing me from locating the direction within about 20 m (10 m visibility).

Figure 27. Alive and Well at 31 m

I recovered the transmitter and set both units down in receive to observe the level of background noise. Brief one or two LED pulses were received every couple of seconds.  Click on the image below to link to a movie sequence showing the background noise reception.

Running close to decompression limits I headed to the upper deck, took a few photos of some very placid snapper, placed a transmitter on the helicopter hanger superstructure and headed off down the hull turning every now and again to see what the received signal strength was and to confirm body blocking. Again the unit was too sensitive close in – the signal was coming from everywhere at 5 or 6 LEDs.  I need to adjust the thresholds in the display routines.

The water temperature was 14°C and I was starting to feel the cold.  I set about a leisurely accent.

Dive number two was on a coastal reef a little north of Tutukaka Heads.  First and foremost this was a cray mission, but to spice it up I placed a transmitter in my catch bag, loaned it to Martin and advised that I’d try and track him down during the dive. This left me with a tiny mesh bag (purchased some piece of dive gear in) to carry my Buddy Locator and any spiny crawly things that I might find.  I found Martin immediately on entering the water, but this was too easy, he was less than 30 m away.  I gave Martin a head start and set off to find some crays. Heading NE I found a couple of nests, and spent a good while catching and trying to put crays into my too-small makeshift catch bag.  With three crayfish in the bag it had become next to impossible to use the Buddy Locator. Operating the receiver through the bag I tried to find Martin but without success. There were no consistent receive signals in any direction either at the bottom or several meters up. At this stage I decided to abandon the experiment and head back to Shadowfax (the boat).

Martin was the last diver up.  It was not surprising that I hadn’t been able to locate him.  He was 100 m + SW of the boat while I had been working 50 m + NE in rocky terrain. Given that Martin’s locator was also in a catch bag with a cray, and given that the alignment of the transmitter and receiver were unlikely to be optimal this result was not too disappointing.

With Martin at the surface and about 50 m off Jamie tried the receiver at the back of the boat.  He reported one LED on in Martin’s direction.  Again the direction of Martin’s transmitter was not optimal and it was operating inside a catch bag.  I need to conduct some more trials but preferably in 12 to 15 m so I can extend the dive time to test ranging and directionality. Warmer water would help too.

More Field Trials

27 October 2007 and I set off on a solo dive to Matheson’s Bay (Figure 28) armed with a 50 m string line, a slate, my camera and the Buddy Locators.  The planned experiments were ranging and orientation tests. Water depth was 3 to 4 m and visibility was 5 to 8 m, reducing sharply when the bottom was disturbed (a great opportunity for me to practice buoyancy control).  The water temperature was 15°C with a slight SE breeze, little current and essentially flat on the surface.  My selected dive site was a few hundred metres swim from the shore.  The bottom was undulating sand and mud with a patches of seaweed and few small rocks. Not a lot of marine life - some spotties, barnacles, the occasional urchin and a solitary jewel nudibranch.

Figure 28. Matheson’s Bay Test Site

The test program was to run out and anchor my line, place a transmitter on the bottom at the dive buoy end in different orientations, traverse the line recording the range at changes in signal strength, and finally attach the transmitter to the buoy (at the surface) and repeat the exercise.

Figure 29. Testing at the 5 m Mark

The units didn’t leak, the control buttons worked, the 5 minute time-out to transmit function worked, and nothing got hot. The background noise was negligible; just an occasional one or two LED pulse.

My first discovery was that the units had lost a lot of the directionality of the earlier model. This had nothing to do with the software.  In trying to minimise the case size I had allowed the transducer to protrude about 8 mm from the end of the case. In the earlier model the protrusion was about 4 mm. This meant that the transducer on the new case presented an appreciable plan-area to the transmitter source when positioned perpendicular to it. See Figure 28. The problem was confirmed by using my hand to block signals impinging on the side of the transducer.  The solution is to make some sleeves for the end of the new case.  The down side of this is that in making the receiver more unidirectional is likely to have the same effect on the transmitter. This will necessitate another set of field trials.

Figure 30. Transducer Protrusion

The ranging results were interesting.  See Figure 31.  The display linearity is not quite right but this is an easy software fix.  The basic curve shapes are similar which is to be expected.  With the transmitter and the receiver pointing in opposite directions the maximum detection range was 10 m.  The limited range with this orientation is fine because the receiver will eventually point at the transmitter during search and locate. With the units aligned and facing one another the range extended out to more than 55 m (the limit of my string line). It is likely to be greater than this due to bottom effects.  The purpose of the vertical transmitter test was to determine if this would be a good mounting option to avoid obscuration by a diver. The intention was that the transmit beam width and surface reflections would make for omnidirectional unobstructed beacon. I suspect that the value of this experiment was lost because of the protruding transceiver (discussed above). The final experiment that I was hoping to carry out was with the transmitter at the surface pointing down, but after more than a hour at 15°C I was cold and it was time to call it a day.

On reflection I also need to add a test with both units pointing in the same direction (<- <-) and improve the transmitter mounting so that it is off the bottom. I suspect that, weather permitting, I will be back at Matheson’s Bay next weekend.

Figure 31. Ranging Experiment

I machined up some Perspex sleeves and glued these in place with Silicone Rubber (see Figure 32).

Figure 32. New Sleeves in Place

And Still More Field Trials

3 November 2007 and another dive at Matheson’s Bay for more field trials.  Visibility was 5 m with a slight chop from a NW breeze.  I taped the transmitter to a 500 mm length of 10 mm diameter wooden dowl and dug it firmly into the bottom, anchored the gear with some handy rocks, ran out the string line and started my measurements.

Figure 33. Transmitter Setup at 5.2 m

Working my way from 50 m back to the transmitter I recorded the the LEDs every 5 m.  At 25 m from the transmitter the readings suddenly dropped below the readings at 30 m.  What was going on?  I headed back to the transmitter expecting to see that it had fallen over. When I arrived it was nowhere to be seen.  Darn! The dowel had worked loose and, with the dowel attached, the transmitter was positively buoyant.  It had taken off to the surface and was at the mercy of the wind and the tide.  What chance did I have of finding it?  A skinny, short stick with a transparent bit of plastic attached floating out there somewhere, and likely getting further away by the second.  I surfaced and looked around, Double Darn!  With nothing further to loose it was time to test the buddy locator for real.  I descended to 2 m and headed off in the strongest 1 LED direction. Then I had two LEDs, then three.  At six LEDs I surfaced and there it was.  Wow!  I looked back to my ‘diver below’ buoy. It was at least 100 m away, possibly more. I swam back to the buoy, descended, repositioned the transmitter, tied the dowel to the string line (to prevent another search and recovery mission) and set about finishing the trial.  The ‘transmitter pointing to the surface test’ was abandoned when the transmitter again dislodged,  but at least this time it didn’t take off into the Ulu. After two hours in the 15°C water I was getting cold.  It was time to head for the shore.  I hadn’t been able to test the transmitter at the surface, but the day had been useful and the device had worked in anger. Back at home it was time to analyse the results.

Working in the horizontal plane there was no signal received with transducers opposed. The signal strength with the devices aligned was one or two LEDs stronger than when the devices were perpendicular, so the new sleeves had worked.  The range with aligned devices was at least 50 m with 2 LEDs showing, but as a result of the search and recover mission showed that 100 m + was achievable.  Background noise on the day was negligible - one LED intermittent with an occasional two LED peak.

The display routine was still not linear with distance (similar to the previous field trial).  This requires some software tweaks in the display routine.

10 November 2007 and, thanks to a frightful cold and a couple of days off work, I have rewritten the receiver software.  The new flow chart is at Figure 34.

Figure 34. Revised Flowchart

The new code looks for the strongest received signal in 0.5 ms windows over a 40 ms period, calculates the delay to the next anticipated occurrence of a strong pulse, and measures that too. It then measures the average noise in a non-pulse period and calculates the received signal strength based on the two 40 ms spaced peaks and the noise level. I have also reduced the least significant bit truncation errors to improve weak signal discrimination, linearised the display (based on the last set of field readings), and changed the battery condition measurement routine.  I have changed from software coded time delays to hardware using the ST6201 on-chip timer counter. The new code is 856 bytes (617 lines of source code) which is somewhat shorter than the previous version. Re-coding has significantly decreased the time between successive receive analogue to digital conversions from to 0.5 ms to 0.14 ms! With the new brains inserted the devices showed a huge improvement in noise discrimination.  The old units would flicker up to 5 LEDs in response to a finger click in air while the new units did not recognize this noise at all. Range tests in air showed an improved signal detection range from approximately 14 m to about 20 m.  We are getting somewhere! Weather (and heath) permitting I will complete another set of field trials tomorrow.

Sunday morning arrived and I arose early with the prospect of getting into the Briney. I set about collecting my gear together in the hope that my headache and sore throat would somehow vanish on their own accord.  Wrong - maybe next weekend. While sorting out my gear I noticed that a couple of my Pentax A20 camera housing controls were sticky.  As much as I would have loved to get wet I ended up sorting this problem out instead.  Click here for the story.

Sunday 18 November 2007 I completed another set of field trials at Matheson’s Bay. The weather is getting better. The water was 16°C with a moderate swell and chop in a moderate NE breeze on a cloudy day. Visibility was about 6 m.  Maximum depth was 5.8 m during an 88 minute set of experiments.  The new camera seals worked well - no sticking at all and they had a better feel than the earlier unsleeved model.  The Buddy Locator cases remained water tight and, thanks to a sturdy steel fence standard, nothing floated away.  I completed nine sets of readings out to 50 m from the transmitter on the dive.

Back at home I set about analyzing the results.  Firstly the background noise had been noticeably decreased, but I was surprised to find that there had been no appreciable improvement in the ranging despite the improved discrimination and gain achieved through software modifications. What on earth (or more accurately under-the-sea) was going on? I decided to dust of the oscilloscope and take some readings on dry land from the output of the analog electronics.  The results were both interesting and insightful.  (For those that have bothered to read this far and are about to view the video waveforms my apologies for the quality. The persistence on my analog oscilloscope means that I have had to video the waveforms and I cannot find my tripod so the footage is hand-held.)

Close to the transmitter (say less than 13 m - call this near field) the received signal was entirely dominated by a strong peak causing the amplifier output to clip, but otherwise the received signal was very similar in shape and highly correlated in frequency with the transmitted signal. There was no discernible noise. Click on the Thumb at  Figure 35 to see the video clip.

Figure 35. Click on Thumb to see Video of Near Field Signal
Horz: 10 ms/div. Vert: 1 V/ div

With no transmit signal the background noise was intermittent peaks barely exceeding the threshold of the analog to digital converter resolution, with an 0.5 mV DC offset.  Click on the Thumb at Figure 36 to see the video clip.

Figure 36. Click on Thumb to see Video of Background Noise
Horz: 10 ms/div. Vert: 10 mV/ div

Now the interesting bit. With a remote transmitter (greater than 13 m - call this far field) the received signal was spread in time across the 40 ms pulse width.  There was still a distinct 40 ms period to the received waveform but the difference between the peak received signal and the numerous other peaks in the interval was minimal. The overall signal amplitude was still significantly greater than the 0.5 mV no-signal DC offset. In the far field multiple transmission paths are causing the transmitted pulse to blur out over the 40 ms pulse period. Click on the Thumb at Figure 37 to see the video clip.

Figure 37. Click on Thumb to see Video of Far Field Signal
Horz: 10 ms/div. Vert: 10 mV/ div

Why is this significant? My noise measurement routine takes place between the consecutive maximum pulses occurring at 40 ms intervals.  In the near field this is not a problem because the received peaks are literally hundreds of times stronger than the background noise.  But in the far field the received signal is distributed across the 40 ms transmit interval. This means that the background noise calculation routine incorporates a significant amount of valid signal during far field measurements.  The signal strength algorithm subtracts the background noise measurement from the peak signal. In the far field this effectively means that the current version of the software will not effectively calculate a true measure of the received signal. What’s more this is independent of the amplifier gain!

I need to rethink my signal strength calculation algorithm, perhaps looking at the area under the received curve as a measure of signal strength, perhaps dropping the noise subtraction routine in favour of using peak periodicy as means of validating signals from noise.  Alternatively I need to utilize two routines, one for near field and one for far field. I’ve also decided to increase the front end gain by 6 dB - a simple resistor change.

What would be helpful is to actually measure the received signals sub-aqua.  So much of development thus far has been based upon assumptions about signal propagation. If my next field trials don’t show a dramatic improvement in performance maybe I should switch priorities to my data logger so I can better understand what is going on.

25 November 2007 already and I didn’t get into the water this weekend for more field trials due to a strong SW breeze. Instead I headed for the back yard.  The recent modifications have gained a few more metres in line of sight measurements in air and have further reduced the effects of noise, but the overall ranging is still well short of the target I have set. In thinking about the problem I was reminded of a low cost ultrasonic transceiver IC by Pro-Wave Electronics Limited, the PW0268, (full credit to Warren Blair). The IC has some interesting features including a Time Controlled Gain (TCG) amplifier connected to a time base. Because it is looking for echoes the IC ramps up the gain in 32 steps from the the time of a transmission until the next transmit pulse. This ensures that as the received signal weakens through increased transmission path length, the amplifier gain is increased. The overall gain of the IC’s amplifier stages (subject to the specific design) can vary from about 150 to 8,000 (43 dB to 78 dB) and is good for reflective ranging applications in air up to a distance of approximately 20 m (40 m reflected path length).

The Buddy Locator doesn’t have the luxury of knowing exactly when and at what range a transmit signal occurred so the TCG amplifier approach is not directly applicable, but some form of Automatic Gain Control (AGC) along with a further gain stage might improve the current design.  I have previously thought about using AGC but there is a dilemma (or more precisely a tri-lemma).  The Buddy Locator needs to differentiate between between strong signals and weak signals to indicate direction, but AGC adjusts the gain to compensate for differences in signal strength making strong and weak signals look alike. The Buddy Locator is also intended to indicate range based on signal strength, but if the amplifier gain increases when the signal is weak then range information will be reduced (remember we don’t know when a transmit pulse was actually sent). And the third issue is background noise which I have still not quantified. As the gain increases so does the amplification of background noise. There is a point where the signal of interest is below the noise floor, and without serious Digital Signal Processing (DSP), cannot be recovered.  If the gain is cranked too high the noise will eventually start to look like valid signal reception.  Gee, we can receive signals from the Mars Rovers (Spirit and Opportunity) so these minor problems are surely surmountable!

However if AGC is only applied during very weak signals, (say one LED lit) and if the AGC time constant is long relative to the received signal and search motion of the Buddy Locator (say 10’s of seconds) then both ranging and direction finding should still be possible. At long range (1 LED lit) the Buddy locator will indicate direction only. At close range (less than 40 m) it will indicate range and direction. Hmmmm.

30 December 2007 and after some interesting diving at the Galapagos Islands I’ve made some time to do some more work on the Buddy Locator.  I designed the AGC, incorporated it in the existing design, and built a prototype PCB.  The AGC worked wonderfully but the increased gain, with an active band pass filter at the input, was a complete and utter disaster.  Even low levels of noise in the pass band became problematic at the output. After some thought, literature searching and experimentation I decided to dispense with the active low pass filter at the output of the analog signal stage (freeing up an op amp for a further gain stage), incorporate passive low pass filters between gain stages, and make the active band pass filter the second to last module in the signal path (ahead of the precision rectifier). I decided to incorporate gain in the precision rectifier in order to make maximum use of the microprocessor ADC.

The circuit worked perfectly in the simulator but the breadboard prototype burst into oscillation as the gain was increased via the AGC. Then it stopped working all-together.  I was not convinced that the circuit design was the problem.  Bread-boarding makes for fast prototyping but is somewhat susceptible to lousy  (and lossy) connections, inadvertent feedback (and consequential oscillation) and excessive signal paths. A more reliable, but somewhat more time consuming, prototyping method is VeroBoard. I rebuilt the prototype on VeroBoard and the results were impressively successful to say the least (see Figure 38).

Figure 38  VeroBoard Prototype

The output noise with no signal was nominally 10 mV at maximum gain. The gain was AGC variable between 750 to 10,000. Signal detection range in air had improved substantially although this could not be quantified because the receiver circuitry was tethered to my oscilloscope and power supply.  The circuit was completely stable under all load, power supply voltage and input signal conditions, including amplifier saturation.

This is all good news because the existing software does an excellent job of discriminating underwater noise from active signals and my field trials have shown that  sub-aqua range is at least three times as great as it is in air.

The circuit redesign requires considerable modification of the PCB.  While I’m about it I have decided to dispense with the magnetic switch at the expense of one of the signal strength LEDs. This has the advantage of reduced power supply consumption because the software can turn off the analog electronics in transmit mode, reduces the circuit cost and size and, with suitable programming, makes everything controllable with the single mode push-button. I have also decided that it is time for a double sided PCB.  The extra effort in fabrication will be offset with improved noise reduction through a ground plane, all SMD technology (with the exception of the MCU and the crystal), minimal track lengths, and a further reduction in circuit board size.

I have made a start on the PCB but this will take a day or so to complete.

9 January 2008.  I have finished the new PCB, updated the software, and installed the hardware in a case.  The AGC provides variable gain of between about 700 and 9,000 with a time constant of about 10 seconds. There is no discernible noise (in air) at maximum gain. The operating current has been reduced by about 8 mA in transmit and is about 2 uA in the off state. In receive mode the device reverts to transmit after approximately 5 minutes, requiring a further press of the mode button to resume in receive. More importantly the ranging has increased significantly.  The Buddy locator can detect an unaligned transmitter at more than 35 m in air (at which time I ran out of backyard).  The reduction of display from six to five LEDs has been less of a bother than I had envisaged, enabling me to dispense with the magnetic switch.  The device is turned off by pressing the mode button three times at approximately 1 second intervals.  I have added an LED ‘turning off’ Cylon display to provide visual feedback that the device is about to shut down (see the AVI movie at Figure 39 - the mode button cycles from off, through the lamp test to the battery condition display, to transmit, to receive, and with three presses back to off). The new populated double-sided PCB is narrower, shorter and thinner than the previous one, permitting a reduction in case dimensions to 125 mm long x 35 mm wide x 30 mm deep (c.f. 125 mm long x 47 mm wide x 37 mm deep) and with an overall assembled weight of just under 200 g.

As a final proof of concept test I asked Phillipa (my partner in crime) to play hide and seek with the Buddy Locator in the house. After about 20 seconds instruction she was able to locate a hidden transmitter located 20 m away down a hall with no line of sight. A second test at a range of about 25 m was equally successful.

Figure 39. Going Through the Modes
(Click on Thumb to View Video)

Now all I need is some more time underwater to confirm the effects of noise and measure the ranging with the new AGC.

13 January and I have completed another set of dives at the Poor Knights with PK Dive off Shadowfax. The first dive provided an opportunity for further tests with the Buddy Locator.   The new device showed a significant improvement in ranging to the extent that I couldn’t extend the range to the limit for fear of loosing the transmitter.  This was expected due to the increased AGC gain.

Perhaps more interesting was that the background noise which had been  insignificant during my Matheson’s Bay tests was again problematic. Brief (one to two second) peaks of maximum signal strength were displayed periodically on both the new and old Buddy Locators.  Further, the new unit indicated brief noise peaks between these more significant pulses.  There are a couple of conclusions I can draw from this.  The first is that there is something, probably biological, at the Poor Knights that is making the noise that is not present at Matheson’s Bay.  Man-made noise is expected to be far more regular than the observed signals.  The second is that the noise is probably a sustained burst of 40 kHz sound, as opposed to a modulated signal.

The signal processing routines currently look for 40 ms periodicy in peak signal reception, ignoring the period between transmit pulses. So it will be fooled into detecting a valid signal by a sustained burst of 40 kHz noise  from another source.  I have decided to further enhance the receive software to ensure that the signal level between peaks is somewhat less than the maximum measured value, thus making use of both the peak signal value, the periodicy, and the lower level signal that should exist between pulses.

Another valuable lesson from the dive was don’t leave the prototypes lying around in the sun and the wet.  Both case seals failed sometime between the end of my first dive and getting home. As with previous leaks the results were catastrophic.  The lithium batteries got very hot, failed, and oozed gunk that rapidly corroded the electronics.  On subsequent investigation all of the electronics check out fine (no MOSFET failure this time) and with careful cleaning I was able to salvage the cases, the transducers, the MCU’s, the LEDs, the op amps, the crystals, and a few of the capacitors.  I have  rewound the transducer transformers and remade, populated and tuned the PCBs, removing a few components in the process and reducing the board size to just 25.4 mm x 68 mm (1” x 2.7”),    The new boards have an overall gain of between 625 and approximately 9,000, subject to AGC, at 40.3 kHz. They draw about 2 uA when off, 7 mA + 4.2 mA per LED during receive, and an average of 17 ma during transmit.  On the test bench the noise with inputs shorted was less than 5 mV at the output at minimum gain and 100 mV +/- 50 mV at maximum gain.

The software has again been revised (I’m up to revision 23 already) to incorporate a background noise measurement routine to further reduce interference from noise bursts and to differentiate noise from signal at high gain.  I have remeasured the hardware timing delays between consecutive pulse measurements, programed the MCU’s and reassemble the cases.

During testing I managed to short circuit the one of the MCU rails, destroying a MOSFET and a power protection diode in the process. Noise (in air) at maximum gain is a problem. Measurements are not helped by energy efficient fluorescent lighting in our house and cooling fan noise in some of my instrumentation. The software looks for a number of consecutive 40 ms peaks that are at least 1.5 times the mid-pulse noise, but the noise is significant (at least 100 mV) at maximum AGC gain. I have gone back to the drawing board to eliminate any DC offset at the output due to noise, reduce resistance throughout the amplifier stages to reduce thermal noise, and refine the numerous high and low pass filter stages to clean up the signal.  Unfortunately this means a new PCB and a slight increase in receive current but the result should offer a signal gain of at least 10,000 with reduced noise, and AGC to permit increased range.

It’s the 15 March and the new PCB has been assembled and tested in air.  The new double-sided board is smaller than its predecessor (25 mm wide x 65 mm long x 10 mm thick - including socketed MCU) and the improvements in the electronics have reduced the effects of noise significantly. Software refinements have also improve signal discrimination from noise and increased the sensitivity to low level signals.  Direction finding and noise susceptibility has been tested successfully in air. Ranging needs software adjustments that will have to wait until I can get the Buddy Locator back under water.

Power consumption is approximately 2 uA in off, an average of 17 mA in transmit, and between 11 mA and 25 mA in receive (depending on how many LEDs are lit).  In air direction finding and ranging extend well past 30 m and the device shows no discernible response to noise. The cased weight is 236 g with alkaline batteries, making the assembled unit approximately 44 g negatively buoyant.

Subject to field trial confirmation and adjustment of the ranging parameters I believe the device meets my original design specification for range. Now all I need is a couple of fine weekends so I can get back in the water.

23 March and I’ve just got back from my old testing ground, Matheson’s Bay.  Conditions were terrible - just 4 m visibility and a strong surge - ideal for buddy locator testing!  The dive was to a maximum depth of 3.7 m in bright sunlight for just on 90 minutes (Figure 40). The water was a wonderful 21°C.

The good news was nothing leaked (including the camera).

Figure 40. Test Rig on 23 March 2008

The key results were as follows. Ranging was 5 LEDs on at 30 m and 3 to 4 LEDs on at 50 m.  Ranging was therefore not effective over the limit of my string line.  Direction finding and body blocking were not ideal with just a 1 or 2 LED difference between an aligned and opposed transmitter/receiver. This was mainly because of background noise - brief 2 and 3 LED pulses every few seconds - with the AGC clearly active.    There are   a few refinements needed including increased LED brightness (particularly for the green LEDS) improvement in the ranging calculation, and further reductions in noise.  I’m working on it!

I’ve spent some time thinking about the latest test results these past few days. The analog hardware has been been designed to limit the received signal bandwidth using an active bandpass filter to maximize the signal to noise ratio with little thought to the transient response of the circuit. A highly selective band pass filter (one with a relatively high Quality Factor, Q) degrades the envelope of the received signal by extending brief pulses with an exponential decay. This is the same phenomena that you will have heard from a bell or tuning fork after it has been struck. The ultrasonic transducers also have a relatively high Q that combines with the filter response, making brief transients look like extended signals.   This is not conducive to discriminating real signals from transient noise. I have set about to optimize the balance between maximizing received signal power and rejecting transient noise. This might take some time.

This gives rise to another thought that might reduce the transmit cycle current and free up some MCU Read Only Memory (ROM). The transducers are high Q devices although they are somewhat dampened in water (See Figures 4 and 5 above). Maybe I can drive them on alternate cycles and use their resonance to fill in the gaps (in the same way that a percussionist strikes a symbol or drum at a multiples of the resonant frequency to obtain maximum noise)?

Another thought  is to finish each transmit cycle with a some anti-phase drive to reduce ringing.  I understand that this technique is used effectively in ultrasonic imaging to obtain clean transmission pulses.

6 April 2008 and I have just completed the hardware redesign.  I have reduced the Q (increased the damping) of the active filter stage making it easier to tune and removing the problems that I have been experiencing with transient response. I have refined the gain, modified the AGC and replaced the precision detector and low-pass filter with a software controlled peak detector.  This last change comes at the cost of another signal display LED but should result in greatly improved signal measurements by the MCU. In reviewing the damping of the transmit signal in water I have decided to put my resonant transmitter drive thoughts on hold for a while.

The new PCB is smaller than its predecessor (just 55 mm x 25 mm), the component count has been reduced by 15% and the receive current has also been reduced by an estimated 4 mA.  In constructing the double sided board I have gone to using 0.4 mm internal diameter copper rivets in place of plated holes or wire links. Rather than peen the rivets I am soldering them on both sides of the board (because I cannot justify the cost of the peening dies). For more information on this system visit Mega Electronics at http://www.megauk.com/through_hole_rivets.php.

14 April 2008 and I have spent a good portion of the weekend remaking and populating the PCB after missing a critical via. A positive from this rework is that I have developed a better technique for establishing registration between the PCB layers.  In the past I have used registration marks on the top and bottom artwork and drilled 0.5 mm holes transferred from one of these to establish the alignment references. A better technique is to align the registration marks on the artwork, Sellotape these together onto the unexposed pre-coated PCB, and drill the reference holes at diametrically opposed corners of the board directly through the artwork and the PCB.    Then align the drilled holes in each layer of the artwork to the holes in the unexposed circuit board before exposing to UV light. My first effort has improved registration to within 0.05 mm (.002”). which is somewhat more precise than I can drill using my Dremil (see Figure 41). See my PCB page for details of the process.

Figure 41  PCB Registration (Hole is 0.8 mm diameter)

The software has been rewritten to support the new board which is now ready for bench-testing. It will take another week to complete the bench tests, tuning, in-air testing and assembly into a case.

15 April 2008 and the new design does not perform well!  The front end amplifier, filters, and AGC work beautifully with an overall gain at 40.3kHz of 10,000 (AGC disabled) and no more than 50 mV of noise, but my new detector is a complete disaster.  I suspect that the cause is the offset voltage at the non-inverting input to the precision detector which causes the output to go high when the sampling capacitor is discharged. This causes the capacitor to over-charge when tracking is enabled. This certainly wasn’t apparent in the circuit simulation!  Time for a rethink on the detector.

The difficulties that I have experienced with the brute force gain/filter/detect methods used thus far tempt me to consider direct conversion radio receiver design techniques. This would mean more analog circuitry and I have pretty much exhausted the IO and software capabilities of the SG6201 MCU. Many of the IO pins are already performing several tasks and the relatively slow instruction time and RAM limitations have curtailed the amount of digital signal processing that I am able to perform.  I suspect that this will take a lot more thought (and maths) to develop a practical design.

20 April 2008 and I have had some success on the test bench with the detector. I now have a sample and track-up detector that works reliably with minimal current drain, no appreciable DC offset, better than 95% accuracy over an input signal range of 20 mV to 2.5 V and only one additional component (two components added, one deleted).  See Figure 42.  This will result in increased ADC accuracy and eliminate noise pulse stretching due to the decay time inherent in an RC detector circuit.  This also means a new PCB which will take a week or so to design, make and populate.  This gives me an opportunity to think further about noise reduction, particularly at high (> 40 kHz) frequencies.  I want a gain of at least 10,000 (80 dB) with less than 20 mV of noise (less than one significant bit of the ADC).

Figure 42. New Sample and Track Up Detector.  (Horz. 1 mS/div. Vert. 50 mV/div
Bottom Trace: Input. Top Trace: Output)

22 April 2008 and I am getting to the bottom of the noise issues.  The first gain stage (preamplifier) has a noise figure of about 17 nV/SQRT(Hz) at 1 kHz dropping to 10 nV at 100 kHz (referenced to the input).  Testing has shown that this is a significant contribution to the output noise.  The solution is to use a low noise op amp at the front end. The LMH6622 is a device ideal for ultrasonic pre-amplification with a noise figure of less than 1 nV/SQRT(Hz) but they are relatively expensive, operate with a minimum 5 V rail, and consume 11 mA per channel. I have ordered a slightly lower spec. device with a noise figure of about 3 nV/SQRT(Hz) at 1 kHz, 2 mA per channel and an operating voltage range better suited to this application. I fully expect that the new op amp will allow me to double the existing gain while maintaining noise below the ADC 1 bit threshold.  This should result in increased ranging and less software overheads to discriminate between noise and valid signal.

As an aside, I have been using grounded metal enclosures to encase the electronics while making my noise test  measurements.  I suspect that the conductivity of sea water, the grounded transducer case (which is exposed to the sea) and the damping effect of water in contact with the transducer will provide even better attenuation of RF and other man-made noise sources. I’m banking that I can discriminate the noise from marine critters and wave action through the software.

4 May 2008 and I have replaced the front end preamplifier and completed some further noise measurements. The results have been instructive.  The op amp now contributes less than 10 mV of noise, but the 10K current limiting input resistor contributes about 50 mV of noise and the transducer about 30 mV. The noise output with a 10K resistor and the transducer is about 80 mV (with brief peaks to 100 mV). Unfortunately some form of current limiting is essential because under transmit the peak to peak voltage across the transducer is 140V and, without current limiting, this would destroy the ESD protection diodes in the first op amp.

19 May already!  I have been pretty busy getting ready for a change in employment and trying to complete my PADI Divemaster course these past few weeks.  But I’ve spent a few moments working on the Buddy Locator.

In order to reduce the noise I need to tighten up the bandwidth of the amplifier chain, reduce the value of all noise contributing resistors in the preamplifier (preferably replacing these with reactive components that will have minimal thermal noise contributions) and, if necessary, reduce the overall gain so that the noise is less than 1 significant ADC bit at maximum gain.  I think that the best solution is a capacitively coupled bandpass filter or ladder network on the input (similar to a pre-selector ahead of the first gain stage on a radio). Unfortunately the maths required to take account of even the lumped reactive components involves S to the power of four, and optimising the transient response while maintaining at least 10K Ohms (reactive) into the input while accounting for stray resistances and reactances is taxing to say the least.  I detest the practice of plugging components into circuits until a combination of values is reached that works.  I shall persist with the maths for a few more weeks, before resorting to iterative optimisation using circuit simulation.

30 May 2008. An auspicious day. Today was was my last day in my current job and, after several weeks of thinking about the dilemma of signal-to-noise ratios and current limiting, I have hit on the solution.  The trick that I have employed is a diode-bridge transmit/receive switch combined with a critically damped LCR filter at the input to the preamplifier.  The results have been impressive to say the least. At a gain of 10,000 I have managed to reduce the background noise to less than 20 mV RMS at the output of the gain stages. Signal strength for a reflected and aperture-limited transmit signal at a distance of approximately 16 m was 120 mV ppk - clearly distinguishable from the noise.  The following two photos and video show the results.

Figure 43. Noise Measurement. Vert. 20 mV/div.  Horz. 10 ms/div.

Figure 44. Signal Measurement.  Vert. 20 mV/div.  Horz. 10 ms/div.

Figure 45. Path from Receiver to Transmitter. Click on Thumb to play Movie.

2 June 2008 and I have redesigned the PCB to incorporate the front-end changes and ordered some more components for the tuned circuits.  Everything going to plan I should have two new Buddy Locators by the weekend. I’ve also played with logic reduction to increase the number of signal strength display LEDs from four back up to five.  Karnaugh Mapping shows that I can do this with just four additional diodes, a resistor and the additional display LED but PCB real-estate is tight, and many of the MCU IO pins are already performing two or more functions, so I’ve settled on four LEDS for now.

4 June and the new PCBs are made and almost populated (awaiting some SMD inductors and diodes) and I’ve tweaked the software to match a couple of hardware changes.  Still looking good for the weekend.

13 June (Black Friday) and the diodes have arrived and been fitted but I am still waiting on the inductors.  At least I can get on and bench test the devices. Both devices are now tuned and gain-adjusted to 10,000 at 40.3 kHz (no AGC). AGC action and power supply switching have been confirmed.  With no MCU the receive section draws 10 mA.  The signal results are very similar to those shown in Figure 45. I burnt a couple of MCU’s and set about testing the new ADC function and operation sequencing.  Darn! the ADC has the same problem that I experienced on 15 April (see above).  How can this be?  I have built the device and tested it.  The only difference between the breadboard and the PCB was the presence of the MCU. The MCU is supposed to present a high impedance input. What on earth is going on? I completed some experiments and found that the ADC hardware works fine when disconnected from the MCU, and that the MCU ADC input pin is sourcing about 50 uA.  That’s interesting - the MCU pull-up transistors source about 50 uA.  After re-reading the limitations of IO bit switching with the SG6201 I think I have found the problem. The ADC reset routine is inadvertently changing the ADC input to an input with a MOS transistor pull-up.  Thankfully I can solve this with software - but this also means that I can significantly reduce the ADC hardware back to the design that I had on 15 April.  With the ADC working properly I have identified another problem.  The switching transients of the ADC sample circuit (caused by discharging the sample capacitor to ground through a low impedance in 7 microseconds) are generating 50 mV of noise at the output that is masking low level signals.  I am going to rethink the AGC circuit!

After some chasing up I have been informed that the wait for my inductors will be infinite!  Apparently this new stock item is no longer available.  The frustration is not just the two week delay - I have two almost completely populated PCBs that aren’t even heavy enough for paper weights, and most of the SMD components cannot be recovered.

I have selected a new inductor, been assured it is in stock, and redesigned the PCB. This has taken some effort because the new device is axial and I am cognizant of the need to minimize magnetic coupling between the output pulse transformer and the input stage. It also has a somewhat larger footprint that its predecessor requiring a larger PCB to preserve ground plane separation between gain stages.  I have also rethought the ADC switching issue and have reverted to a non-switching design, and in the process salvaged an additional IO port for the LED display. Yes, I have simulated and bread-boarded the prototype and it works fine. The reason for a switching ADC was noise but I have overcome this problem with an improved front-end amplifier design and the diode transmit/receive switch.  The new layout will require further software changes as I have swapped some of the IO port functions to reduce track lengths on the PCB.  Although all these changes might seem annoying this is what iterative design is all about.  Its been good to be free from work these past two weeks so I can dedicate some time to this project. Far from being despondent I believe that at last I have some hardware (and software) that will meet my design objectives.

Once bitten, twice shy - I shall hold off making the new PCBs until the inductors arrive (hopefully tomorrow).

It is timely to reflect on where this project began well over a year ago.  Figure 46 shows the latest hardware block diagram.  For those that have persevered thus far you might like to compare it with the original hardware concept at Figure 2. Clearly the MCU IO is much busier than originally envisaged. However I am quite confident that I’m fully utilizing every IO pin and almost every ounce of the processing capability.  The current software (Version 29) is over 850 lines of source code. The program has been developed with the overriding considerations of reliability and power consumption followed by the need for processing speed during receive and and timing precision during transmit.  Although hardly elegant I believe (with final ranging and detection refinement still to be completed) the current code is efficient for the task at hand.

Figure 46. Hardware Block Diagram

The inductors have arrived at last. I have made the new boards, salvaged as much as I could off the old ones, and set about soldering everything in place.

22 June 2008 and my new circuit boards are oscillating (both of them). Double darn! The basic amplifier design is sound, the detector is sound, the input limiting and transmit/receive switch are sound; but in combination I have a wonderful 40 kHz oscillator.  This is not good because firstly the circuit doesn’t work, and secondly the design must be unconditionally stable.  I will set about trying to resolve what is going on today. In general oscillation means that there is signal coupling and phase shift from the output back to the input. The feed back path is likely to be either either through the power supply and the transmit/receive switch, or through magnetic coupling to inductive filter elements at the amplifier front end. Contributing causes are likely to be excessive gain of the overall circuit and transients at the detector.

I have resolved the oscillation problem caused by phase shift and feedback with some minor changes to the hardware - decoupling the transmit/receive switch from the power supply (the primary cause of the problem) , removing the inductor at the input, reducing transient current in the detector and reducing the circuit gain. Thankfully, with a little surgery,  the current PCB is still usable as a prototype. I have modified the design to account for the changes that I have implemented. The analog performance is a gain of about 11,600 at 40.3 kHz (with no AGC), less than 20 mV of noise at the output, good tracking of the detector, a functional transmit/receive switch and AGC, and a current drain of approximately 9.5 mA.   Now I need to reprogram an MCU and make sure that the processor has no unplanned effects on the gain stages.

A question that you might ask is why wasn’t this oscillation apparent during simulation and bread-boarding?  As good as modern circuit simulation packages are, they only represent a model of the circuit using lumped non-coupling ideal components. So a voltage source has zero impedance, adjacent wiring and inductors do not couple, and capacitors have no resistance.  Although non-ideal components can be modeled the simulation rapidly becomes incredibly complex. In this case the feedback through the power supply and the inductor simply did not exist in the model.  Models are only valid where their performance is verified by experimental results. My breadboard experiments have been on single stages so interactions between stages is not apparent.  In the case of the inductor my breadboard used a toroidal inductor where the magnetic field is almost entirely contained within the ferrite ring.  The prototype has an axial inductor which is more susceptible to coupling of external magnetic fields.  With complicated circuits breadboarding many stages has its own problems because of inordinate track lengths, poor connections and less than ideal layout.

24 June (somewhat late in the evening) and I have tested Version 12 of the hardware with Version 31 of the software and everything is working well in air. I will need to adjust the software detection thresholds for the LED display for ranging linearity and maybe adjust the valid signal detection to account for all the marine noise that has has been a bother in past field trials, but I am at last satisfied that the hardware is performing to specification and the current version of the software is functional.

26 June 2008 and, after examining the display and signals from the hardware I have modified the receive software to incorporate two routines - signal acquire and signal lock (a software version of a phase lock loop). The previous software completed a signal acquire routine on every receive cycle requiring at least 120 ms of processing time ignoring the fact that a potentially valid signal had already been detected, and causing brief (but annoying) blanking of the signal strength display every second or so.  The new routine has identified a software problem with the original code. The receive software had not been adequately synchronized with the transmit routine resulting in ‘signal slide’.  In plain English this means that the receive software takes slightly too long between transmit pulses to process the received signal so that the every second or so the receive signal is lost.  The solution is to firstly optimize the receive software so that all processing paths take the same time, and secondly to adjust the timing delays so that any error between expected and actual peak pulse time is corrected. I am on the case!

29 June already and after several days of intensive effort I seem to be no closer to resolving the software lock routine.  The hardware continues to work beautifully, the transmission software is rock solid, as are mode changes and time-outs.  The signal acquisition software works well too, but the phase lock loop refuses to lock which is most perturbing.  I have double-checked the software timing on the simulator but in practice the receive lock slides through the valid signal until it falls out of lock and re-aquires.  My initial thoughts were that this was due in part to AGC action but this has proven not to be the problem. This will take more time to solve.

Independence Day (4 July) and I have set about to rewrite the software lock routine to improve time discrimination of the peak detection. The flow chart was easy but the software implementation is taking some effort to minimize processing time and ensure that all possible paths through this section of the software take the same processing time. Hopefully come Sunday I will have a lock routine that actually locks.

12 July and I think I have found the cause of the lock problem.  A critical loop in the lock software was terminated by the status of the processor carry flag, but the preceding decrement instruction did not have any influence on its status. Darn!  I have solved the immediate problem but as a consequence I need to adjust a number of delay routines. This will take a day or so because the rather antiquated ST6 simulator clock frequency setting only has three significant digits and the clock speed division for the timer and the processor are 12 cycles and 13 cycles respectively.

14 July and I have come down with a hideous ‘man flue’.  While battling with copious quantities of green snot , a pounding headache, a runny nose and general lethargy there will be no progress on the Buddy Locator.

18 July 2008 and I have struggled on with my software problems.  With the timing routines optimised on the simulator the hardware was still failing to achieve signal lock. I programmed an output port to toggle high for the duration of the ADC reads and hooked up the oscilloscope to see what was really going on.  The ADC routines are taking far longer than the simulator would have me believe; 5.57 ms in real time while the simulator calculates 3.88 ms.  The unexpected delay in the ADC measurement is significant because it is more than the transmit pulse time (measured at 1.57 ms) so the receive software routine will always be late to the next pulse - resulting in failure to lock.  And to top it all off the increased ADC time was causing another problem with the background noise measurement routine.

The signal lock problems have been resolved! The signal display aquires quickly and is rock steady on lock, even for very weak signals.  Both boards are fully functional, in the same modification state, and ready to be installed in the cases for sea trials.  Now I just need to get rid of this cold so I can go diving. The lock routine is so good that I’m confident I can provide for a number of Buddy Locators to operate in the same space on different pulse modulation schemes. The current program is sufficiently modular that the code modification shouldn’t be too much drama. With the boards installed in the cases they are detecting reflected and aperture limited signals at more than 30 m in air (transmitter and receiver aligned).  Signal discrimination over noise is excellent!

We had a (non-technical) guest over for dinner so it was time for another find-and-seek test.  After about 10 seconds of instruction she was able to turn the Buddy Locator on, and within a minute had located the other transmitter at range of about 25 m, avoiding three alternative paths.  (The transmitter was hidden in a shoe by the front door.) Wow!

Although I haven’t completed my next set of field trials yet, the in-air test results have been really promising so I have started contemplating turning the prototype into a commercial reality. The only potential field test problems that I envisage are ranging linearity and background noise The former is readily resolvable with software refinements.  The noise issue may take some further work because I still don’t really know the nature of the noise that I am trying to combat. The current software should cope with low level broad band noise and intermittent peaks.

One of my initial goals was to make an affordable device so I have set about estimating the component, manufacture, tuning, testing, assembly, patent, warranty and legal costs. The biggest up-front cost will be a custom made translucent case that will remain water tight at 40 m.  I have designed an aesthetically pleasing and ergonomically practical casing (left and right handed - one hand operation complete with tether) allowing for easy battery replacement, acceptable power supply duration and minimizing size while having due regard for the anticipated pressure.  I have submitted the design to a number of injection molding companies and await the advice and estimates from the experts.

I have contemplated using rechargeable batteries and a sealed mode switch in a permanently sealed case.  While this has the potential to make for a smaller device, with a reduced risk of water ingress and a reduction in case cost, it makes the device unserviceable and would require battery management hardware and software, a charger and two battery connections. Better to have a slightly larger (but still comfortably hand-held) low-cost device with low-cost, readily available disposable or rechargeable batteries.

28 July 2008 and I am continuing to source the components that I need to make the Buddy Locator and I have started on the manual.  Figure 47 shows a scaled artist’s rendition of the assembled device to give you a feel for size and function. Note that this is the right-hand version but I have some strange left-handed characteristics (like using a knife and fork and wearing my wrist watch).

Figure 47. Scaled Artist’s Rendition of the Buddy Locator

6 October 2008 and I’ve had the Buddy Locator back in the water these past few weeks.  The dives have been training dives with open water students around Goat Island with so testing has been a secondary mission.    Essentially I’ve been measuring background noise performance.  The results aren’t good.  Three to five LEDs were lit almost all the time!  When I cover the transducer with my hand signal levels dropped to zero so the observed effects are clearly related to background noise. With the number of LED’s lit, the AGC would have minimized the gain, but excessive gain might still be a problem.

Goat Island is a marine reserve and consequently an ideal testing ground because it is teeming with marine life. It also has variable terrain with kelp forests on undulating rock and the occasional patch of sand.  If I can get reliable performance in this environment then I figure that the Buddy Locator will work anywhere.

A secondary concern was display visibility in the clear water under a cloudless sky but this is easily fixed by increased LED current and/or a filter over the LEDs.

I really need to understand exactly what the background noise characteristics are so I can adjust the hardware, transmission pulse modulation and receive software to optimize the Buddy Locator’s noise performance. I know there are a lot of potential noise sources that I need to deal with – waves, bubbles, sea urchins, crustaceans, fish, ….  Interestingly in my earlier experiments at Matheson’s Bay (essentially a sandy bottom devoid of marine life) I didn’t have too many problems with background noise. However when there are lots of sea critters, all making individual dins, and they’re additive, I’m guessing this makes for a cacophony of noise.

Unfortunately I still don’t have the equipment to measure the noise so I’m going to have to spend some time making it.

There are essentially two techniques for sound recording open to me. The first is to use a fast recorder operating at about 100K samples per second to capture the full spectrum of sound in the band of interest. While this provides the most complete data for analysis it requires high speed precision electronics, mass storage, money and time.

My preferred option is to use elements of the existing design and a homodyne down-converter to capture the modulation envelope at 40 kHz.  This should preserve the amplitude and frequency information of interest, and limit the data collection requirements (speed and capacity). It also means that I can focus on exactly the signals and noise that I am trying to process from the transducer.

I have spent some time these past few weeks modeling a homodyne receiver and data recorder.  The modeling has been very promising and my earlier idea of applying radio reception techniques has been validated. I can get much better noise rejection but this will require some additional hardware development.

While this has been going on I have also been working on production prospects. I have sourced all of the components for the current design and the electronics is within budget. But production of the case is proving to be a real challenge.  The majority of companies that I have contacted aren’t interested in making the production quantities that I envisage and most won’t produce a few tens of prototypes, essential before committing to a substantial order.  Others are hell bent on redesigning the case with no concept of the requirements of the hardware and life at 40 m and all of this is wasting time and adding expense.  I will persevere!

13 October 2008 and for a brief moment I thought I’d solved half of the data recording exercise by using an Olympus DS-330 digital voice recorder for recording the Buddy Locator output. The native .DSS files produced by the recorder can readily be converted into .WAV files which contain a header and a sequential file of digital samples. Unfortunately the idea crashed and burned due to the bandwidth of the recorder: 300 Hz to 5 kHz in standard play mode.  The upper frequency is fine but the lower frequency prevents reception of noise in the band that my current pulse modulation scheme is working in. Darn, there just doesn’t seem to be a simple solution and I have wasted another weekend getting my head around file formats that will not be useful after all.

I have also been busy on getting my data logger up to speed to enable readings of the analogue output of the Buddy Locator to get my head around the noise problems. The ADC conversion rate is about 20 kHz at 10 bit resolution which will permit detection of noise from DC up to just under 10 kHz.  Getting the readings is easy but storing them in a Windows compatible fire format on the SD card is proving to be a bit more difficult.  My earlier FAT16 implementation is too slow so I’ve abandoned this for now and also dispensed with the Microsoft Excel compatible file format.  If there isn’t enough going on I have enrolled on a PADI Instructor Development Course (IDC) in November, and this is not too far off.

It’s the 4 December 2008 and the data logger is now working, I’ve completed my PADI IDC and the Instructor Exams and it’s almost time to complete some Buddy Locator noise readings in the field.  This weekend I’m planning on installing the data logger in a water resistant case and attaching some cable and a drive circuit to one of the Buddy Locators so I can get some field measurements.

18 December 2008 and I still haven’t installed the data logger in a water proof case (boy am I slack)! After thinking about the data logger I’ve come to the conclusion that there should be no time impediment to making the stored files on the SD card Windows compatible.  I’ve spent the last two weeks modifying the data logger software to meet this requirement but, as usual, I’ve had to contend with numerous glitches on the way. The first of these has been a problem caused with Windows long file names which had me completely flummoxed for a week.  I won’t bore you with an equivalent long file name story, but I’m on the case.

28 December 2008 and the data logger is now doing everything I had originally desired. I have set about taking my first Buddy Locator readings (above water for now) to try and better understand the problems that I have experienced with undersea noise.  The following three Figures show graphs of the time domain signal, the frequency spectrum and the frequency-over-time for each of three signal strengths; one LED, three LEDs, and five LEDs (top to bottom).  The analysis was completed using Mat Lab

Figure 48. Time Domain of 1 LED, 3 LED and 5 LED Signals
X = Sample Number, Y = ADC Value (Note the vertical axis is not the same for each graph)

Figure 49. Power Spectral Density of 1 LED, 3 LED and 5 LED Signals

Figure 50. Frequency over Time of 1 LED, 3 LED and 5 LED Signals

This is all very interesting (well at least I’m interested). The time domain signals show echoes after the peak pulse, particularly for the 3 LED signal (due at least in part to my lest-than-idea test environment). The noise power is significantly attenuated above about 2.5 kHz (good, my  filters are working). The maximum signal power is at 25 Hz, corresponding to the 40 ms pulse repetition rate - just as the maths predicts.  The frequency-over-time plot looks pretty, but also shows the relative spectral content of the different signal levels.  Looking at the 5 LED bottom plot, the pulses occur at the first yellow vertical band on the right hand edge of the red ‘beehives’. These are followed by a band with hardly any signal, a second yellow band caused by a sharp echo peak. This is followed by the beehives which I believe are the combined multi-path echoes.

Now all I need is some noise measurements from the ocean. 

18 January 2009 and I’ve just got back from Leigh Reef with my first set of under water noise measurements. The conditions weren’t ideal with a south easterly wind, tidal swells and a 1 m chop which drenched everything in spray.  The visibility (down-under) was about 7 m.  My equipment (data logger, power supply and buddy locator) stood up to the conditions well. Even though this dive spot is probably not as noisy as Goat Island or the Poor Knights I can see immediately why my valid-signal detection algorithm is having such a hard time with the background noise at low signal levels.  I made 20 five second measurements at a depth of approximately 5 m in 12 m of water with no transmitted signal. The measurements show frequent spikes, some with considerable power.  The good news is that the noise spikes are very brief and appear to be quite random. See Figure 50 and compare this to Figure 48 above. I have no processing power left in the current microprocessor so I’m considering my options. Three that come to mind are to change the microprocessor (I need RAM and speed for Digital Signal Processing),  improve the analogue electronics, or increase the base band signal strength.  Before I tackle the problem I have some more measurements to take. I also need to fully analyze my data, and I’d like to get back to Goat Island or the Poor Knights where noise has been particularly challenging in the past.  I can see that 2009 is going to be a busy year!

Figure 51. One Second of Noise Measurement on Leigh Reef

I have started on the noise analysis and have concluded that my current transmission modulation scheme distributes too much power across the frequency spectrum for reception of weak signals in a noisy environment.  Ideally the modulation envelope would be a continuous square wave but this has repercussions for power consumption (read that battery life) and/or the power rating of my existing transducer.

31 January 2009 and I’ve completed some noise and transmission/reception measurements at Goat Island Marine Reserve. As expected, the noise was more significant at this site compared with the previous measurements taken at Leigh Reef, but similar in amplitude and consisting of random impulses.

The transmission experiments were rather imprecise as I could not get the transmitter more than about 10 m away from the receiver (due to the size of the boat and the depth) and I could not fix or monitor the alignment between the transmitter and receiver.  The Buddy Locators were simply tethered to lines, dropped over the side and left to the mercy of the current. However the qualitative results are insightful.  See Figure 51.  The noise issue is clearly only a problem when the receiver is operating at high gain.  At short transmitter test ranges the AGC is off and the signal amplitude is an order of magnitude above the peak noise.  The observed low frequency peak amplitude variations are almost certainly due to changes in the orientation of the transmitter and receiver. After each peak there are secondary peaks decaying over about 30 ms. These are due to echoes because they show the same repetition rate as the primary pulses and their shapes are similar for adjacent pulses.

Analysis of the noise echoes gives insight into signal strength at distance. The main echo peak occurs approximately 6 ms after the leading edge of the transmit pulse so the echo peak is traveling about 8 m further than the point to point signal (the actual range is 7.2 m to 9.0 m). This explanation sits nicely with the test configuration and depth.  I initially expected to see a direct correlation between the amplitudes of the peak signal and the noise, but after some thought I’ve decided that this is unlikely because the improved transmitter to receiver alignment, which results in increased peak signal, does not necessarily mean increased signal propagation to the bottom or improved reflection.  In fact the opposite might be reasonably expected.  Mathematical analysis showed little correlation between the amplitude of the peak signal and peak echo.

The echoes observed after the primary pulse leading edge show reception of reflected signal travel distances up to approximately 60 m.  As expected the signal amplitude decreases with increasing travel distance due to at least one reflection, dispersion and attenuation.  The amplitude of these longer ranging echoes are of the same order of magnitude as the background noise.

Figure 52. Signal Reception at Goat Island

Time for some more thinking and theorizing to determine the best course to proceed on from here.

I was interested to see a new device that has appeared recently in New Zealand branded the BuddyCall.  While I don’t own one, the sales literature indicates that it is based on transmission of an audio signal with remote reception by ear.  The package looks tidy and the inventor has clearly invested some time and effort into making a device that is relatively low cost, is available now and clearly fills a need in the market.  Does this spell the end of the Buddy Locator? No, for the following reasons:

The range of the BuddyCall is listed as 30 m (provided that you are not wearing a hood - read the literature).

It’s really hard to discern the direction of audio signals underwater. Having heard a call you have about 2,800 sq m (slightly more than half a football field - ignoring the depth dimension) to search with no indication of where to start.

The BuddyCall is listed for use in good visibility.  Where I dive the visibility seldom extends to 30 m and good visibility is anything more than 8 m (read the BuddyCall literature).

The BuddyCall relies on both divers being alert and mobile (a bit difficult if you’re unconscious or trapped).

The BuddyCall won’t help you find the boat.

Don’t get me wrong.  I have no intention of knocking a product that folks seem to have found really useful (based on web-published testimonials). And let’s face it, if you are more than 5 m from your buddy  (yet alone 30) then you’re not really buddy diving anyway. The Buddy Locator is not yet a reality and when it is, it will also have its limitations.  But I’ll be continuing with my project, and I’d continue with it even if an equivalent commercial device appears, just for the learning and self-satisfaction of seeing the project through to completion.

April (2009) is here already and I’ve really struggled to make time to work on the Buddy Locator, or for that matter to go diving. In addition to earning a wage I’ve started a Master’s program at Canterbury University on top of all of the usual rigors of life.  I’m enjoying being back at school and in February I spent a few minutes talking over the issues that I’ve been experiencing with noise with a professor from my earlier studies who has an active interest in underwater acoustics and electronics.

The outcomes of this discussion were that a possible (and indeed probable) cause of the impulse noise is snapping shrimp and that I need to rethink my signal detection hardware to eliminate broad band noise. Extensive digital signal processing is probably not the best approach for this real time application. The issue of the suitability of my transducers was also a potential issue.

As a result of the discussion I have been looking again at homodyne (and synchrodyne) receivers. My recent sets of noise measurements have been at the end of the analog electronics so what I’m seeing is the amplified and filtered noise envelope. It is difficult to work backwards from these measurements to the actual signal at the transducer in part because of the AGC and in part because of the transient response of the active filter networks. Although my logger works fine it is simply not fast enough for processing 40 kHz signals.  There are some commercially available balanced mixer and mixer/oscillator circuits available which should be fine for completing my noise measurements but power consumption and rail voltages mean these are hopeless for final application.  For now it’s back to the circuit simulator for design and optimization. At least I now have an understanding of the noise issues that I am up against even if this is incomplete.

Easter is rolling around and, weather permitting, I hope to spend a day or two diving without tangles of coaxial cable, batteries and instruments, enjoy the experience and maybe get a few photos.  The circuit simulation is progressing well - I’ve designed a direct conversion receiver that (in theory) solves the noise issues.

I’m almost embarrassed to post today’s date - 1 July 2009! Progress has been incredibly slow this year due to my post-graduate studies. In the semester break I’ve taken my field noise measurements and applied them through Spice (my circuit simulation package) to the new design and compared the output with my previous prototype.  There is a significant  reduction in noise, an improvement in the signal to noise ratio, better transient rejection and a significant easing of the requirement for specific tuning; all with a minimal increase in circuit complexity.  This is all good news!  However the new design uses inductors and transformers which are (relatively) physically large due to the low frequencies and will take some effort to construct. I am also concerned that these components, and a local oscillator, may present inter-stage coupling issues that will require metallic sheilding.  I’ve ordered some ferrite cores and commercial inductors for bread-boarding the prototype.

More to follow...

[Turtles are Here] [750Z Housing] [Construction] [A20 Housing] [Drawings] [Buddy Locator] [The Maths Behind] [Photo Galleries] [Galapagos] [Data Logger] [Making PCBs] [Links] [Contact Me]