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 finished rewriting all the subroutines now and I have manage to increase the speed even more. When rewriting, I got rid of any grossly underperforming code and now at 100mm/h it runs through in just under a second.

But once again, the errors are still plaguing the system. At this rainfall rate there are quite a few ghost drops and therefore still quite a lot of missed drops. The one I have just done is at 9% and I can clearly see at least 2 ghost drops. Have to investigate this further.

However, I think its about time I stopped for Christmas, so I don’t think I will be doing much except maybe showing a few people what I have done over the holidays.

Merry Christmas all!

Update
Just a quick update, I continued tarting up the code, and it now reports all ghost drops and all missing drops and why they were missed (ghosting/verification/etc.). Ive just done a beefy test at 100mm/h over 1 second:

run(’..\..\Create Samples\V0_7\V0_7′); V0_9;
7966 Drops Generated
Elapsed time is 143.394716 seconds.
12.7% Error

Thats without all the warning and debug messages. As a results Ive found that the thresholding/peak detection routine does not always find all the pulses. In fact, it only finds them at very slow rain rates. As a consequence I have had to pad the data so they are all the same length. So I am definitely going to have to look into that.

The graph also now shows the errors so it makes them easier to pick out. So just for formality, here are a few screenshots and program outputs:

run(’..\..\Create Samples\V0_7\V0_7′); V0_9;
79 Drops Generated
Elapsed time is 1.486008 seconds.
Ghost Detected at: (0.2093440.1,-0.3657250.1) Due to Pulses: 3774,3492,3380,3705
Ghost Detected at: (0.3033100.1,-0.0157940.1) Due to Pulses: 3619,3407,3602,3758
Ghost Detected at: (-0.0449920.1,0.3495790.1) Due to Pulses: 3481,3749,3880,3702
Ghost Detected at: (0.0771620.1,-0.4683740.1) Due to Pulses: 4014,3790,3505,3864
Ghost Detected at: (0.3148400.1,0.0721700.1) Due to Pulses: 4199,4023,4276,4384
Drop Missed: Number 6. The data did not pass varification tests.
Drop Missed: Number 30. The data was eaten by Ghosts!
Drop Missed: Number 31. The data was eaten by Ghosts!
Drop Missed: Number 32. The data was eaten by Ghosts!
Drop Missed: Number 33. The data did not pass varification tests.
Drop Missed: Number 36. The data was eaten by Ghosts!
Drop Missed: Number 37. The data was eaten by Ghosts!
Drop Missed: Number 38. The data was eaten by Ghosts!
Drop Missed: Number 39. The data was eaten by Ghosts!
Drop Missed: Number 40. The data was eaten by Ghosts!
Drop Missed: Number 41. The data was eaten by Ghosts!
Drop Missed: Number 56. The data did not pass varification tests.
79 drops originally, we have found 67
15.2% Error

And Some output Screenshots:

After a knock in the right direction from Kevin, I found a slight error in the Multilateration routines.  When simplifying U, we chose points on the edge of the tank to solve for.  The point which is at the top right of the tank was wrong.  I was solving for x^2+y^2 = 1.  I should have been solving for x^2 + y^2 = d^2.  Fixed that, and now the results are a lot more accurate.  No more inaccuracies around the outsides of the tank.  Somewhere near +/-0.2mm.  Too small to measure.

Still the largest problem is the number of false detects.  I have started rewriting the code, but because of this silly error today, I have not had any time to continue rewriting the rest of the code.

Well here it is. A good couple of months worth of work summed up in a single image. Says a lot doesnt it…

I have confirmed that the source of the errors in the newest program is definatly because there is a chance that a random combination of pulses could produce a valid output. So I think the only way to mitigate this is to also check the value and add that to the error.

Plus there are also times where the actual input data has some pulses missing off the end.  This is simply because I have not made the array big enough in the original creation.  A simple fix.

I think I have finally chosen all the things I need to get cracking with the real software. No more of this nancy Matlab.

Ive chosen C++, mainly because it will be more beneficial to me in the future.  Companies really need you to know c++, and I can learn C# on top of that if I need.  Plus I will get a slight speed increase due to less overheads.

Ive chosen Qt because its free, looks pretty neat, has a good reputation and doesnt have all the nasty Microsoft related overheads/complications.

Finally Ive chosen an IDE called HaiQ because it was one of the only compilers I could get to work, and it looks pretty slick.

So now I just have to get learning! (again!)

As I thought, by changing the code to copy the good records rather than trying to delete the bad ones is a million times faster.  The 20 second code from yesterday is now down to 8 seconds.  Now the real possible combination sorting isnt even on the profiler any more, its that fast.  The slowest part of the code now is the check combination routine, and only because its called 125984 times!  Cant be bothered to change any of that since its pretty good anyway.  At 10mm/h its now down to about 0.3 seconds.  This is all for 0.01 seconds of data mind you.

For 1 second of data it takes about 8-9 seconds.  So still roughly an order of 10 behind at 10mm/h.

Ha! And at 1mm/h it takes about 0.95 seconds.  So we are just real time at that point.

Found something very interesting with the profiler. In the file “Find_Best_Combination.m”, line 56, there is the code:
Possible_Combinations(Temp_Index,:) = [];

Line 56: Possible_Combinations(Temp_Index,:) = []; 220223 Calls, 7.095 s

So basically it takes for ever to delete a record that is in the middle of a set of data. Maybe instead of deleting a record, I should move correct ones to a new array, and then delete the first record. I have heard that deleting records either at the start or the end is quicker.

The only other sources of delay are the “Generate_Possible_Combinations.m” and “Check_Order.m” routines. This is purely due to the fact that they are called so many times. I think they are fairly well optimised already.
What i could try is to remove the redundant order check part of the code and let the “SolvePosition.m” routine take all the working…

Ok forget about that! I just did the above, and not only did it take 140 seconds, there was a 95% error. Probably something wrong with the error, but I’m not about to check when it took that long. It should take something around 20 seconds.

Thats about it for today, so I am waiting a reply from kevin about his thoughts on the accuracy of the “SolvePosition.m” routine, but I’m just about done. So…

Todo:

• I think I should check where these errors are actually happening to make sure that I can’t do anything about it.
• Then after that I should finish the whole thing and present a graph of the found drops and data. Then thats about it!
• Then onto the c++. I think I have decided c++ because it will give me a better stead in the long run. Companies are really looking for c++ rather than c#, but c# is only a simple step away. I could probably learn c# in my spare time if I have a good c++ background.