 |
|
|
|
|
|
|
||||||||||||
|
||||||||||||||||||
 |
||||||||||||||||||
|
Click to email me |
||||||||||||||||||
 |
||||||||||||||||||
|
|
 |
|
|
|
Click here for the Latest Update |
|
|
|||||||||||||||||||||||||||||
|
Time for a New Project 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 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 was 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 ST62001 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) and 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
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.
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. 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. 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
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 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 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 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 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 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 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 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 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 I have 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
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
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
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 |
