Not tested yet, but here are some images of the finished PCB!

Image 1 img_0002.JPG Image 3 Image 4

Over the past week I have had enough of the surface tension tests since I was getting nowhere. I redid the low surface tension (Ethylene Oxide) and the high surface tension (salt) tests to get some more resolute data. (I thought I might have just been either putting too much in at a time or something.) I found that when I reduced the surface tension this increased the amount of large bubbles being created and the amount that were sustained on the surface (surface bubbles for a long time). This meant that there were some semi-large bubble noise but some utterly huge signals when the large bubbles on the surface popped. Hence, not a good route to go down.

For the higher surface tension test with salt I found that the results were little better. What seems to happen here is that the production of many smaller bubbles is more apparent. Im assuming this is because the large bubbles that are created cannot withstand the pressure inside the water and break up into lots of small bubbles. This is quite good to watch, since the 1 large bubble that is created due to the drop seems to ‘blow up’ and scatter into many smaller bubbles; typically in a spherical arrangement. This also leads to quite a lot of small ‘foam’ on the surface. So the signals from the ‘exploding’ bubbles plus the signal from the drop hitting the foam is also pretty rubbish.

So I sat back and started thinking why oil works so well again. After a small conversation to Sergei we decided that the only other parameter to play with was viscosity. This reminded me of the idea that Kevin had that a change in viscosity may change the frequency of the escaping bubbles. So I thought I would give it a go; a double whammy if you will. Sergei pointed me to Glycerol, stating that it had good thickening properties, but it wasnt very good. Infact it was very similar to the ethylene oxide tried before. So I went back down my simplistic metal path and decided the easiest thing that I could get hold of to make things thicker was Jelly! At worst I would have a nice pudding for tea.

First attempt I didnt use enough jelly, but second attempt I got is spot on. (It is a bit annoying that I have to leave it overnight, but thats the price I pay!) With about a mixture of 3 parts water 1 part jelly-water (as mixed to the directions on the packet) I got a consistency very similar to oil. After a few data captures I knew I was onto a winner.

So, for once I think this almost categorically means that viscosity is the key when trying to minimise bubbles, not surface tension. A nice think liquid acts like a cushion not allowing a depression to form and also preventing the backlash of water that you get on the exit of the bubble.

The images below compare the oil results to the new jelly results. Note the similarity.
The jelly has 3 levels of zoom. The first is the normal 10 second data. The second is zooming in on the noise that you can see in the 10 second data. I think this is the actual oscillation of the liquid iteslf. I could quite easily test for this later. The third image is zoomed right in to the spike itself. The very quick oscillation you can see is reflections of the side walls. These tests are done in a 6×6″ bucket, and will be a lot less in real life. (So will the surface oscillation)

Just for future reference (because I always forget), using the naff double sided PCB, 3:30 exposure was enough, but by far and away the most important point was to remember to jam the acetate down to the exposure unit, to the point of stressing the joints. Too many times have I relied on the foam in the lid of the exposure unit only to find that the acetate has warped slightly so I get a blurring after developing. Argh! Never again!

On the preamp front, it died! I dont know why, but I know what could have happened. Today in the lab, I came back from cleaning the “drop chamber”, as I like to call it, plugged it back in and it didnt work. I think it was because there was a DC spike on the output of the hydrophone which then knocked out the amplifier input. Here is my reasoning. I washed the hydrophone in hot water, boiling hot, since its the best way of getting rid of all the contaminants. I think this cause a charge build up in the peizoelectric material (either that or it was still hot, hence a wierd DC value) which then discharged (or stayed the same if it was simply due to the heat) and wiped out the input with a fair amount of voltage.

So next PCB, remember the protection diodes! I didnt put them on this time because I couldnt be bothered, and I didnt think this would happen!

p.s. Also, dont forget to place some text so you know which way round the acetate is supposed to go!  Plus that the text that is to be on the bottom layer should be flipped! Elementary I know, but always forgotten!

After lots of testing, here is the brief version.  What I have found is that if you lower the surface tension, you increase the longevity and the size of bubbles under, and on top of the water.  If you increase the surface tension, the opposite happens.  You get lots of tiny bubbles.  Neither actually gets rid of bubbles.  (Disclaimer: This could be a coincidence)

Thinking what else could be making the oil work so well in preventing bubble formation is viscosity.  This is the only difference between oil and the rest of the tested liquids.  So I am in the process of making some scientific jelly, but I dont think I’m going to get it quite right to catagorically prove one thing or another (as usual).

The problem I have is the inability to change one single constant.  For example, all the chemicals that are specifically designed for decreasing the surface tension also tend to be quite viscous (although nowhere near oil, and a lot more expensive!) and very very foamy (if that’s a word).  Great for washing machine engineers, bad for scientists.

So in the end, I will still probably end up using oil and although it doesn’t mix,  it does provide good results and its cheap.

Quick update, I wanted to try the matlab vs c++ routines again, because from what I can remember, matlab was several orders of magnitude quicker than the c++ program. But I recently found a library in Qt called QVector, which claims to be very quick on the
whole memory front. So I went back and did the test again. (Because for some reason I didnt leave any trail of documentation like I normally do?)

Now notice my shock, suprise and glee when I rewrote the program for Qt 4, put it in release mode instead of debug and opened a large can of groinal kickers on matlab. See the results below.

Programs, settings, etc. __________________________________
Matlab V7.3 (2006b)
Qt V4.3.4 (release mode, default optimisations, single threading, pure c++ (no QVectors etc.)

MATLAB_____________________________________________

x = -0.5; y = -0.24; hydrophoneDepth = -0.3; SoS = 1482; hydrophoneSpacing = 0.5;
T = [1000000*sqrt( x^2 + (y-hydrophoneSpacing)^2 + hydrophoneDepth^2 )/SoS;
1000000*sqrt( (x-hydrophoneSpacing)^2 + y^2 + hydrophoneDepth^2 )/SoS;
1000000*sqrt( x^2 + (y+hydrophoneSpacing)^2 + hydrophoneDepth^2 )/SoS;
1000000*sqrt( (x+hydrophoneSpacing)^2 + y^2 + hydrophoneDepth^2 )/SoS];
tic
for(x = 1:1000000)
SolvePosition(T,hydrophoneSpacing,hydrophoneDepth,SoS);
end
toc
tic
for(x = 1:1000000)
SolvePosition(T,hydrophoneSpacing,hydrophoneDepth,SoS);
end
toc
tic
for(x = 1:1000000)
SolvePosition(T,hydrophoneSpacing,hydrophoneDepth,SoS);
end
toc
tic
for(x = 1:1000000)
SolvePosition(T,hydrophoneSpacing,hydrophoneDepth,SoS);
end
toc

Elapsed time is 18.844249 seconds.
Elapsed time is 18.670732 seconds.
Elapsed time is 18.662103 seconds.
Elapsed time is 18.620391 seconds.

c++_____________________________________________

Starting Test
___Position Solve Speed Test___
This routine tests the speed of c++ vs.
Matlab for our developed Multilateration Algorithm
7015

Starting Test
___Position Solve Speed Test___
This routine tests the speed of c++ vs.
Matlab for our developed Multilateration Algorithm
6985

Starting Test
___Position Solve Speed Test___
This routine tests the speed of c++ vs.
Matlab for our developed Multilateration Algorithm
6969

Starting Test
___Position Solve Speed Test___
This routine tests the speed of c++ vs.
Matlab for our developed Multilateration Algorithm
6984

Note that the c++ program is in ms. It is clear to see that there is a clear speed advantage, not a lot I know, but it is clear. There is also more scope for firstly optimising my code specifically for c++, using more aggressive optimisations in the compiler and also using the fast access libraries included in Qt.

Haven’t updated in a while. Cracking on with the PhD doing lots of experimental work. Lots of time has been put into experimenting with the new hardware setup, PC->NI DAQ->Single Hydrophone, playing with all sorts of different concoctions. Results have been adequate, but not astonishing. The expected amount of bubble noise is there, masking the instant verification that would have been so nice. The most interesting part is that the bubble creates quite a number of frequencies that span from almost-DC to 10’s of kilohertz’s which means that a simple kill-all-bubble noise filter is not as simple as we first thought. Ive attached images of a control test where droplets of about 2mm are dropped from a hight of approximately 3 meters into a tank of water. The first is a simple plot of the data, and the second is a spectrogram showing the different frequency components at different times.

Over the past couple of days I have started trying to filter out the bubbles in software, so I don’t have to put so much emphasis on reducing the bubbles at the source.  I have had some success convolving an average of 10 drop pulses and also using the fact that the drop pulse is very delta-like.  In the frequency domain this can be viewed as a broad spectrum, so taking an average of a FFT will produce a high result and others spurious signals give out a low.

I have thought of things like this in the past, and it looks like someone has taken the time to actually do it:
http://www.gizmag.com/go/7293/
I think that they have gone down the wrong road for the mouse part though…

[ I chose not to make the reasons why it is not appropriate and what can be done to remedy it to be private, since this is a bladdy good idea.  Anyone interested, please email me. ]

After months and days of searching I cant find any websites that are developing a hobby based phased array soultion for robots or whatever, so I am very very tempted to get to work on this straight away when I move in, rather than spending time on my robot like I had planned.  Also, another idea for today was to control stuff throught the pretty much redundant lifedrive we have, it is bluetooth and wifi enabled, so these could be utilised to form an advanced remot control?

Just for future reference Ive found some sites with a T610 LCD pinout and some code and stuff. Links:

• Forum Discussing the T610 LCD
  
• Pin Out from the manufacturer
• Another Big forum discussion

I could mount the IR and the IR rx on the top and bottom of the boards, then I wouldnt have to worry about them interfering with each other!  Cant believe I didnt think of that before! Might not fit with the wiskers on though?

Also, I could add some transistors to make the power output a bit more beefy.