 |
|
|
|
|
||||||||||||||||||
|
||||||||||||||||||||||
 |
||||||||||||||||||||||
|
Click to email me |
||||||||||||||||||||||
|
|
 |
|
|
||||||||||||||||||||
|
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
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
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 analogue 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 my 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 understanding 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 postgraduate 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, 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 shielding. I’ve ordered some ferrite cores and commercial inductors for bread-boarding a prototype. 23 July and I’ve completed initial bench prototyping of a new analog front end (Figure 53) using a direct conversion receiver design approach. The noise reduction and signal discrimination shows a significant improvement over my earlier ‘filter, gain and rectify’ approach. I still have some work to do to minimise the component count for the local oscillator, applying further gain, AGC, an active low pass filter and transmitter adjustments to optimise the transmission duty cycle for 329 Hz modulation. The most difficult of these problems is the local oscillator circuit reduction. In prototyping I have used a Pierce crystal oscillator which work fine on Veroboard and has minimal current consumption, but the component count and PCB real-estate are just too high. Figure 53. Direct Conversion Receiver Prototype
It’s the 2nd of August and bench testing is all but complete. I still have some work to do on the spectral purity of the local oscillator but I’m satisfied with the front end amplifier, the post-mixer filter and the overall gain. In fact I expect some improvement in circuit performance when I progress from bench tests to circuit boards. The bench prototype is essentially unresponsive to the electrical noise from eco-fluoresent lighting that plagued my earlier designs. However these lamps also generate 40 kHz microphonic noise which is picked up by the transducer. When I run an earlier detector in parallel with the prototype under florescent lighting the earlier version locks on signal and shows three LEDs while the bench prototype output is less than 20 mV (which is less than the least significant MCU ADC conversion). My current challenge is entirely focused on improvement of the the crystal controlled local oscillator amplitude stability and spectral purity. Time flies like an arrow, and thanks to my other commitments progress has been slow. It is now September and development is preceding steadily. I still have work to do on my local oscillator but bench tests have shown that my current design receives valid signals at ranges over 25 m in air (through apertures and reflections) with almost no perceivable background noise issues. Transient response on the the receiver needs optimisation but it is all coming together - just not fast enough for my liking. Here are some more signal images to give you an indication of progress. Figures 54 and 55 show where I am at today which should be compared with Figures 43 and 44 above (receive and transmitter in identical positions). The significant differences are the complete absence of high frequency components in the received signal and improved signal discrimination without an appreciable increase in the noise level. Current drain is 11.2 mA at 5 V which is acceptable and the component count has pretty much been minimized. Figure 54. Noise Measurement. Vert. 20 mV/div. Horz. 10 ms/div.
Figure 55. Signal Measurement. Vert. 50 mV/div. Horz. 10 ms/div.
The next stage is to make yet another printed circuit board, which is expected to result in a reduction in noise, and carry out further field trials. November 2009 already. Rather than spend a weekend making new circuit boards I have contracted a company in China to make them from my artwork. Their quality and turnaround time promises to be as good as I can get locally, their customer focus has made for a very pleasant experience, and even with courier costs, they are 1/5th the price of local companies. I also have a bunch of new bits that have arrived from Farnell ready for populating the circuit boards when they arrive. As an experiment I tuned the new electronics (and in the process reduced the current consumption by 2 mA), set up the bench prototype along side my previous design, and comparatively observed the performance of the analogue front ends at maximum test transmission range. Despite a significant decrease in design gain the new prototype has dramatically improved signal to noise and reduced the response to transients (see Figure 56). The DC baseline is rock solid at ground while in the previous design this tended to drift in proportional to average signal and noise amplitude. The difference in frequency response is quite evident from the Figure. This is promising because the lower gain means the device is less prone to saturation from strong signals and the signal detection and processing routines in the microcontroller can be significantly simplified. Figure 56. Comparative Design Performance. Vert. 50 mV/div. Horz. 20 ms/div.
My ‘standard’ transient test has been to click my fingers in front of the transducers. While this is hardly a controlled and scientifically repeatable test method the response of the current design is about 20 times less susceptible to transients than its predecessor. 7 December 2009 and the new printed circuit boards have arrived and the first has been populated and tested (Figure 57). All good. I’ve been thinking about the commercial case design and, while the current control button has worked reliably without leaks for more than a year, it requires two precision-machined stainless steel components, two O rings, a stainless steel spring and circlip. In order to simplify production, reduce cost and improve reliability I have decided to experiment with some sealed piezoelectric switches from Schurter. They are on order. This will necessitate a new prototype housing to get the appropriate clearances for the switch body. I’m literally on the case. Figure 57. New PCB (Waiting a New Case)
The new switches have arrived and my initial tests are really promising. They show minimal response to gradual changes in pressure so I expect that they will work fine at depth. On the down side they provide absolutely no tactile feedback and the switch body is 6 mm longer than I had expected. Life is full of tradeoffs and I’m sure that someone will have a switch that will better suit my case requirements. All I have to do is to find it! 16 December and I have designed a new prototype case in which to fit the new boards and switches. It is the same length as its predecessor but substantially thinner and lighter. I just need more weekends for construction. 20 December 2009 and the new cases are almost complete. They have a heap of void space because I am using an IC socket for the microprocessor (essential for development), a battery holder, and the mode-change switch length. Assembled, the case is approximately neutrally buoyant in fresh water. It is more comfortable to hold than its predecessor and the mode change button is in just the right position for thumb activation while watching the display. It’s interesting looking back over the case development since the start of this project. Figure 58 shows the gradual reduction in case size from the original light-saver concept through to a cardboard mockup of where I am headed (along with a cell phone for scale - but I assure you the cell phone will not work for long underwater). The commercial case will have a nicely rounded profile just like the cell phone. Figure 58. Case Development (and the Future)
22 December and I have decided to use brass inserts for the case screws which means some more machining is required. The advantages will be a stronger case through the use of smaller 2 mm diameter machine screws without the problems of taping fine threads in the Perspex, and a better seal through distributed fasteners. Santa has delivered me two nice new Buddy Locator cases. My next mission is to populate a second circuit board and fill the cases. All looking good so far. I have tweaked the software too, incorporating a 90 minute no activity power-down (sufficient time for lost diver procedures while minimizing the effects of battery discharge between dives if a Buddy Locator is inadvertently left on), changed the turn on sequence to require 3 button pushes at approximately 1 second intervals (to avoid inadvertent activation) and reconfigured the signal strength display based on in-air bench measurements and my earlier sub-aqua ranging experiments. The current major software revision is Version 37a. 27 December and the second circuit board is populated (but not yet tested or tuned). Hand soldering almost 100 components, many comparable in size to a grain of sand and all with at least 2 electrical connections, under an illuminated magnifying glass is a bit of a bind. It takes the best part of a day working steadily to populate a board. The current hardware Version is 14 so I’ve populated 32 boards to date (Buddy Locators come in pairs and I’ve made a few stuff-ups on the way). Version 15 of the hardware, hopefully the production prototype, is in development. A few problems have emerged during testing. 1. The 90 minute time-out works fine but restart following time-out shutdown isn’t a happening event. This is clearly a software problem that shouldn’t take too long to fix. 2. A critical oscillator on the second PCB is failing to start reliably during mode changes which has significant consequences for the receive circuit. The basic design is fine but clearly I have some more work to do on component values and tolerances. The oscillator needs to start reliably and fast (within 100 ms). I have begun my investigation. 3. More work is required on the receive DSP. Although noise rejection is good there is an inordinate 0.4 s delay associated with a peak signal averaging routine which is at best jolly annoying. More thought is required here. 4. The battery condition display isn’t telling me what I need to know. This is another software problem caused by changes in the hardware that should be relatively easy to fix. But all is not doom and gloom. The new piezoelectric switch is working well, the control button three-press start routine works just fine, and the 90 minute time-out is accurate to within 10 s. Further, everything fits nicely in the new cases and the water tight seals are working well although they have only been tested to turtle tank depth. After an evening of deliberation, trials and reading I think I have found and cured the oscillator problem (and uncovered and resolved a potential noise issue in the process). In my circuit simulations I had failed to account for op amp input offset voltage variations (up to 2.7 mV according to the manufacturer’s data sheet) which appear to have been the cause of the intermittent oscillator startup. A wee bit of negative feedback has resolved the problem and now the oscillator on the second board starts reliably under all anticipated voltage and temperature conditions. While not ideal, and certainly not for production, the extra component sits relatively unobtrusively on the PCB. You probably wouldn’t notice it unless you knew what you were looking for - unfortunately I notice it. The unexpected noise issue was caused by excessive RC power supply decoupling of a filter stage causing low frequency power supply ripple. Yuck Team! This was easily resolved by a change to one SMD resistor. Testing also revealed that over time I have managed to destroy one of my ultrasonic transducers. With nothing left to lose I disassembled it. The cause of failure will never be determined conclusively but corrosion on the connector PCB suggests water ingress through a poor case seal. Not really too surprising given that this particular transducer was first installed in hardware revision 1f and has been subject to all manner of abuse including a destroyed Lithium battery pack. The transducer construction is interesting. See Figure 59 which shows the transducer disassembled. The peizo element is bonded to the inner surface of the aluminium housing, which is packed by a felt washer, then a cork washer, topped with a thin terminal PCB connected to the transducer and the case by welded jumpers. The assembly was held in place and sealed with silicone rubber.
Figure 59. Transducer Assembly
30 December and I have resolved my earlier problems although I fully expect that ranging, gain and DSP will require further adjustment after field testing. I figure that I have at least four test dives to complete to confirm operation of the new control button, ensure that I have licked the marine noise issue, validate ranging and confirm the operation of the current DSP. Additionally I have two tests that I need to complete to ensure that the Buddy Locator will not cause a fire with a dead-short applied to a Lithium battery pack in air (worst case), and to observe the effects of ultrasonic transmissions on apex predators (read that to mean sharks). 3 January 2010 and I have completed the first of my test dives at Goat Island. The weather was fine with bright sunlight interrupted by the occasional cloud. The wind was a light northwesterly breeze. There was a slight swell with no appreciable wave action and a moderate northwesterly current. Visibility was about 12 m. There was plenty of marine life about - the ubiquitous Goat Island snapper, crabs, urchins, goat fish, cod, kelp fish... they were all there. There were also heaps of canoeists, snorkelers and swimmers enjoying the day. I undertook this dive with some trepidation. Was my new hardware going to resolve the background noise issues that I had experienced at this location in the past? Here are the results from my experiment. In the shallows (less than 1 m) I had no or one LED lit in receive in the presence of wave action. At a depth of approximately 6 m one LED was always lit with two LEDs lit about half of the time and a three LEDs peak about every second or so. LEDs four and five never lit. The direction of the Buddy Locator made no difference to the signal display. Up, down, towards the reef, towards open water, deeper, shallower, at specific objects: it made no difference. The noise was everywhere. Marine life seemed oblivious to the transmit signals from the Buddy Locator. They just carried on doing what they were doing with no perceived change in direction or movement. When I placed my hand over the transducer in receive mode the signal level dropped to zero. Clearly the noise that was being measured was external. Two additional issues arose. The smaller case needs finger profiling to assist with grip while wearing gloves. The LED brightness was a challenge in direct sunlight near the surface (particularly the green LEDs). The control button worked well with no water pressure influence and the case did not leak. The receive 5 minute time-out worked well - reminding me to check air and decompression. The ranging is at least as good as anything that I have built so far. Looking back at the noise measurements that I made at Goat Island on 6 October 2008 where the received signal varied between three and five LEDs (with the Automatic Gain Control minimised) there has been a huge improvement. I have gone through the maths and and the current noise discrimination is at least 2/3 improvement over my previous designs. However my current DSP is at best simplistic and there is significant scope for varying the receiver gain, amplifier transient response and taking full advantage of the transmit duty cycle. 5 January and I have spent much of today thinking about my earlier noise measurements from Leigh reef and Goat Island in comparison to valid signals looking for further solutions to marine noise. See Figure 60 (but note that these measurements are not absolute - they are subject to the variable gain and transient response of my version 12 hardware). I am loathe to reduce the gain although this would be an easy fix because I want to reliably achieve at least 100 m (330 ft.) ranging. Figure 60. Time Domain Signal Measurements from Leigh Reef and Goat Island. Top trace: Noise at Leigh Reef
There are two particular features of the the transmitted signal that have the potential to allow improvements in the DSP. The first is the transmitted pulse width. This is approximately 4 times the width of noise peaks. Unfortunately my current hardware makes this critical difference difficult to detect due to the Local Oscillator (LO) frequency that I had selected for the direct conversion receiver (I will be the first to admit that this was an unforeseen mistake in my earlier design). I can easily modify the LO but this results in hitting a wall with the speed limitations of the microprocessor ADC. The fix requires both hardware and software modifications. Unfazed I have computer-simulated the frequency, transient and steady state performance of the modified circuit and have rebuilt the bench-top receiver. The hardware is working well. The second potential DSP improvement is associated with transmitted pulse repetition which the current design does not use. I intend to apply a previously developed signal lock routine to improve confidence in validity of signal reception. 6 January and I have successfully recovered my pulse envelope at maximum range as shown in Figure 61. In looking at the ADC routines I have discovered another potential problem in the previous design. There is no sample and hold on the ADC input to the ST62XX series of microprocessors. The data sheet states explicitly: ‘The analog voltage to be measured should therefore be stable during the entire conversion process.’ The ADC routine takes about 112 us to complete which means the previous design had a potential measurement error, subject to received signal phase, of up to 20%. The frequency of the envelope modulation in Figure 61 is about 2,330 Hz (with a half cycle width of 214 us) which means that I cannot possibly use the ADC to directly measure the envelope carrier. Figure 61. The Pulse Envelope and Track-and-Sample
I am having to re-implement an early track and sample design (click here to see the details) for the ADC. This will provide a stable analog voltage for the ADC and allows peak detection in any designated period. Thankfully there is no significant hardware burden in implementing this. I have dusted off my old processor development board and started programming the test receive routine incorporating the track and sample drive. I’m off to Australia for a few days on my annual pilgrimage to take part in the Pier to Pub swim and Mountain to Surf run held in Lorne. This means a few days off from development. Back from Australia and after a day of intensive programming effort the bench test hardware is up and running. The track-and-sample works well and provides a stable input for the ADC. However it is difficult to discern if my efforts have made any appreciable difference because, as much as I click my fingers, I am struggling to produce the brief noise impulses that seems to be prevalent in the marine environment (see Figure 62). Figure 62. Comparative Noise Measurements Top Trace: Noise at Leigh Reef. The key difference between noise and signal is the pulse width and repetition.
The software absolutely discriminates between the narrow noise pulses and the wider signal pulse but this will only address the noise peaks. My next mission is to implement a noise floor measurement and to look at incorporating pulse repetition rate for signal validation in the DSP. The noise floor measurement was easily implemented at the beginning of receive mode with just a few lines of code. Signal validation will take a bit more effort due to the hardware limitations and instruction speed of the MCU - I may yet have to go to a new microprocessor. 16 January and I have been messing with the DSP in Excel using the noise and signal measurements that I made last year at Goat Island and Leigh Reef. I have made a system that performs admirably in real time but my current processor just doesn’t have the RAM or the speed for real time processing. Click here to go to the Maths Behind my current algorithm. Although I still have a lot to do everything is starting to come together. I have completed the draft users manual today (click on the link below to review) and have made steady progress with the new software DSP.
1 February and I have selected a new microprocessor and started on the hardware conversion. The work is progressing steadily but, as usual, not as fast as I would like. It is time-consuming becoming familiar with a new instruction set and the idiosyncrasies of a new microprocessor. The processor executes instructions about 100 times faster than the SG620X and includes sample and hold on the ADC. I figure I can get ADC readings at a rate of around 80,000 conversions per second which lets me do away with the track and sample hardware resulting in a reduced component count. To aid development I have decided to make a new PCB for bench testing. The board has been designed to integrate directly into the Buddy Locator but this will take a few more weeks to make and populate. While developing the software I have a distinct feeling of having been here before. My very first microprocessor project used a National Semiconductor SC/MP INS8050 processor in circuit published in Electronics Australia - circa 1975 (see Figure 63). Thinking back it was surprising what could be achieved with just 256 bytes of RAM painfully reloaded byte-by-byte after each power-down using a bank of address and data bus switches. Figure 61. My First Ever Micro - A National Semiconductor SC/MP INS8050
8 February and I have begun the laborious task of transplanting the new processor design into the previous analog circuitry. My new processors have arrived along with about half of the supporting passive components. It’s May 2010 and, because of my commitment to my part-time postgraduate studies, my diving and projects have all but ground to a halt - just like this time last year. My studies are progressing well, but at the sake of many of the things I would rather be doing. Click here to navigate to the Latest Update Page |
|
|
|
[Turtles are Here] [750Z Housing] [Construction] [A20 Housing] [Drawings] [Scuba Buddy Locator] [The Idea] [Proof of Concept] [Prototype] [Latest Update] [The Maths Behind] [Photo Galleries] [Galapagos] [Data Logger] [Making PCBs] [Links] [Contact Me] |