That'll Learn Em... (Warning, contains extensive rantings)...

I've never been one to do things the easy way and I always get more enjoyment from finding my own solutions to problems than relying on what others have done. I once spent months trying to get somebody to machine parts for me with a lathe with no luck. So I made my own lathe. It wasn't the most accurate tool I have ever made, but it was more than adequate enough to build jet engine parts, after some practice. That's the trouble when something seems impossible, you only realise how hard it was when you have accomplished it. I still haven't had the sense of whats possible/impossible beaten out of me by the education system yet, I have known a few students who just give up or think something is too hard to do and never even make an attempt. There is a whole culture that has developed in academia where attempting something and failing is viewed as wrong especially with some of the tutors who will throw up their arms and roll their eyes should a student answer a question wrong in class. I can't count how many times I have tried a new approach and failed, but I'd pick up the bits and try again. When I say pick up the bits, a lot of the time this is literally what happens, usually accompanied with flames and some blood loss, but that's another story.

I may have said this before, but I was genuinely surprised when I started uni in that there seemed to be hardly anybody else who did any sort of engineering outside of the curriculum in their own time. I have naively thought that naturally everybody else would be like me and they were not. I have since found out over the next few years that I wasn't alone and there was a handful of other people, I never saw a degree as a simple stepping stone into a good career like a lot of students, I just wanted to learn and to use what I learned to improve my own projects, which in hindsight was also somewhat naive. How well you do in a degree in aerospace engineering seems to me to be how well you can remember vast chunks of information and jumping through the right hoops rather than any real understanding of the subjects.

As you may have noticed I have been messing about a lot with data acquisition devices, and for more years than I care to remember. Not just DAQ's but jet engines, rockets, model aircraft, pulsejets ect. I built my first large solid fuelled rocket motor when I was sixteen. A couple years later when I found out that I could measure thrust with a computer and not the Rube Goldberg type contraption I was using that consisted of a felt pen, a set of fishing scales, a Meccano motor and a few other things and I never looked back. So you can imagine more than ten years of using DAQ's later, how much I was looking forward to a module in year two of my degree called 'Instrumentation' which was to teach me about DAQ's, load cells, thermocouples, strain gauges, piezo-electric accelerometers and so on. That excitement soon faded due to a tutor who showed zero interest and would do nothing more than read from a book. His exam was based on a set of notes over 100 pages thick copied from an E book, with two pages of the book printed on each sheet, front and back. I scored 43% and almost failed the module. Others who have the capacity to remember vast chunks of information got higher marks, but not by much. Am I bitter, of course I am, it annoys me that I have feel as though I have an understanding of the subject but because I was unable to state a vague equation from one of the hundreds in the book or draw precisely one of the many DAQ logic circuits out of the many available, that I have to feel as though I have nearly failed.

I know I am moaning, but the education system in the UK is rubbish. The standardisation of the curriculum means that there is no capacity for children to show their full potential. Some will grasp subjects earlier than others but are then forced to carry on at the same boring pace. Others may not excel at academic subjects but might show flair for arts subjects, which are then usually ignored. How many arts teachers does the average high school have? How many music teachers? Mine had one of each, yet we had several French teachers, maths teachers, science teachers and three computer teachers, this was back in the day when we were still using BBC Microsoft computers with 5" floppy drives!. Why aren't we encouraging what children excel at, rather than making sure they all get the same education which just penalises the entire country. Churning out vast numbers of children who are either disillusioned with the system or have been ignored and do poorly in their exams, yet we wonder why there are many reports of school leavers having ever reducing standards of maths and literacy.

Every level of education from infant school, high school, A-level and degrees are treated in the same linear manner. Easy things are taught first and they progress in difficulty with each year. At first this seems a logical method of teaching, but looking at my experiences in maths and science education, then it starts to fall apart. I left school with a D in maths GCSE Now I have almost finished an aerospace engineering masters degree which is more or less a maths degree in disguise. Thinking back I was almost constantly bored, preferring to read anything I could get my hands on in the libraries to doing my homework on memorising Latin nouns. I could have easily handled more complex subjects but the copying of paragraphs from textbooks was what got you the marks not your knowledge on geology. So why can't you teach high school kids about calculus, why wait till they do A levels? Why at degree level do we still have to work through huge mathematical problems that give the same nice round answers as the tutors marking scheme in order to get the grades to go onto to potentially design aircraft? Real world problems never give nice round answers, nor would you be expected to work through a problem from first principles in the real world. If you truly understand a mathematical process then you should be able to write a program to solve it, computers do not remove an understanding of the theoretical methods despite what some people say. I think we are approaching a cross roads similar to what happened when calculators were introduced and those who held the slide rule and log tables as the only 'proper' methods also thought calculators took away the understanding. More and more kids are teaching themselves how to program, so hopefully the tide will turn and the long, tedious days of solving neat problems in the back of an exercise book will be over. Computers are great problem solving tools, let them do the hard work!

DAQ To Labview

I've noticed a lot of hits on my blog have been from a Google search trying to couple a DAQ with Labview. I have briefly alluded to how I did this a couple of weeks ago, so I thought I'd go over it again in a bit more depth. This vi should run for any DAQ that uses a serial port or runs through a virtual serial port, I'm not sure how many of the DAQ's out there that do it this way though. Of course the easy way to do this would be to buy a National Instruments DAQ, but this would require you to sell a kidney as they aren't cheap. There are several DAQ manufacturers who will provide Labview vi's for their equipment and it's always worth investigating prior to buying one.

I have actually downloaded a few beginners guides to programming in Python, I am quite proficient at Matlab scripts, so it wouldn't take long to learn the syntax. Depending on how I progress with Labview and whether it can actually do the things I want without dragging its heels, I may end up scrapping it all together and write a dashboard program from scratch in Python. Another student at uni is in the progress of building a flight simulator with several screens and a true to life aircraft cockpit, and has built several virtual aircraft gauges using C++, so that's another option. My first impressions of Labview were favourable, but the more I try to use it, the more 'clumsy' it seems. But we'll see, and I will persevre with it for now.

Anyway my vi for the µChameleon DAQ looks like this, it is very simple when compared to other DAQ vi's I have seen. I have no idea if that is a good thing or not. Since this particular DAQ has firmware which creates a virtual serial port, it is 'easy' work to get it to work with Labview. I'm sure there are much easier ways to do this, but I have had less than twenty hours time with Labview, so I will gradually improve things as I go. I have labelled the vi with as many comments as I can think of to help, rather than try to explain every last step because pictures really do say a thousand words! The vi is based on VISA, (virtual instrument software architecture), and will find any device connected to the serial port).

Within the vi you may notice a small block I have labelled as a sub vi. This was a small vi I 'borrowed' from somebody else's program, I forget who's because I have downloaded so many and picked each one apart to see how it worked, but whoever you were, thank you!! But I digress, here is what is contained within the sub vi. I will get around to putting up a download link for my vi when its done.

Update on Millivolt Signal Amplification

I have been run off my feet with uni work since coming back after the Easter break, along with sorting out my PhD applications but I have managed to squeeze some time into building the amplifier circuit for the five thermocouples. Here it is in all it's vero board glory along with the data bus, neatly labelled up as despite the colour co-ordinating I know I will end up connecting the wrong signal wire to the wrong DAQ channel.

I have noticed that the outputs in my Labview vi appeared to have some noise that would cause the gauges to 'bounce' slightly. Looking at the number string of the load cell channel coming out of DAQ in Labview it appeared to fluctuate randomly between 70 and 100 when no load was applied and rising to nearly 4000 with two 1 gallon water bottles hanging off it, again with a random noise of around 10 units either side of the steady state value . At first this meant nothing to me and I had to firstly find out what the DAQ actually outputs, in case I had  made a mistake with Labview and was reading some other signal. A quick skim read of the pdf manual provided by Starting Point Systems told me the DAQ gives an integer output between 0 and 4095 which corresponds to a 0 to 5v analogue signal. Ok, that seemed to fit with my measurements, but was the noise a problem with the Labview vi? Well a quick play with the µChameleon controller software showed the same noisy signal, so until I get my new oscilloscope there isn't much I can do except put up with it. Although I have said 'random noise' I don't think it is random but some sort of interference as putting a square wave through any one input channel on the DAQ will have a small effect on the outputs of the others. This effect seems to disappear once I have signals connected to those channels but I don't think it is. I have no idea if this means I need to shield all the signal lines or provide some better grounding for the DAQ.

I've also got my eyes on some Wren turbine parts on EBay, the seller has a spare outer engine case in the lot and that means I can take a drill to the engine for the temperature and pressure measurements without the potential of ruining an engine. I'm keeping my feelers crossed it doesn't go for a fortune!

Amplifying Millivolt Signals.

Thought I'd write piece on a simple circuit I have built to amplify the output from a thermocouple. I am using two types of type K thermocouple for my temperature measurements, I don't know the technical names for each type off the top of my head, and it is past 4:30 am so I can't be bothered to find out. I call the type in the first picture 'probe' and the inset picture 'bulb'. These thermocouples come in several 'Types' depending on the requirements and are in essence a bi-metal strip that produces a voltage change proportional to the change in temperature, and this voltage is generally in the millivolts scale. The Type K probes are found in all commercial micro-gas turbine engines to measure the exhaust gas temperatures and I will be using the same but I have limited space within the engine and will therefore use the bulb type. They also have a faster response time which will give better results when the engine is throttling away from steady state operation.

The circuit diagram shows the final layout circuit I will be using, it is based around the LM358N op-amp which I sourced on EBay as they were very cheap. I originally omitted the small ceramic capacitor but since I will be using several amplification circuits and thermocouples in parallel there may be some noise which this should help to minimise. At this point you should know I am relying on the electronics I have learned at uni, since my course is triple accredited, (or cursed depending on your viewpoint), we have to cover a certain number of mandatory electronic engineering modules. But I digress, anyway these circuits are pretty simple and if you have any suggestions for improvements please let me know...



I couldn't help but transfer the circuit onto a bread board for testing and it worked  flawlessly, I even hooked it up to a DAQ and used WINDAQ in oscilloscope mode to see how stable the output was and it was surprisingly well behaved. I can't wait till my oscilloscope arrives as it will save me a lot of time messing about with a DAQ everytime I need to see how a circuit behaves. Dunking the bulb thermocouple into hot water then into cold showed a good response time, (something I need to further investigate to see how accurate temperature measuring will be when the engine accelerates or decelerates). Swapping over to a probe and holding a flame underneath it gave similar results.




Just need to make up five of these circuits on some vero board and then I can carry on with the Labview dashboard program. The pressure transducers have also arrived so more fun things to come as I can't really do much with the RPM frequency to voltage converter yet as I really need the oscilloscope. I have also been thinking about buying one of the DIY PCB kits from Maplins and making my own PCB's. This would be a more elegant method than vero board. Hmm...

I Kissed a Girl, Didn't Like It... (She Tasted Like Bloody Lemsips)

My lovely Aerospace Girlfriend has been laid up in bed all week suffering from an acute case of the manflu, and no she didn't catch it from me. But while she wasn't well and nothing was on TV we have been living the life of an old couple by playing Scrabble. I have to say that winning two games out of at least twelve didn't do much for my confidence. She then went on to smash her way through the Sudoku and both the normal and cryptic crosswords in the Guardian. When she was really stuck, she'd ask for help. I'd assume a look of thoughtfully gazing into the air, but in reality I was stumped everytime.

I learned an important lesson the other day... I was making dinner while Aerospace Girlfriend was lay on the sofa and managed to convince her that it was foolish to let me cook a very complicated meal and talked her into letting me cook one I was familiar with. All was going well, cooking nicely, looking good...... Then she woke up and asked if I had used any vegetable stock, I laughed and retorted that I was a damn fine cook, this recipe had come down through the family and wait until you eat it. In fact so confident I was in how nice it would be, I laid a bet that if she didn't like it I'd buy her a vintage bangle that she had been lusting after. Out came the dinner from the oven, steaming and smelling delicious... My moneys safe..

While I was clearing up and dishing out my dinner, Aerospace Girlfriend was eating hers and pulling faces. I kept asking what was wrong, and she say it was fine and how lovely it was, nom nom ect... Strange. I sat down and began to eat my dinner, now I know that reading this you are imagining that I am going to say how horrible it was, and you'd be right. It was, more or less, just slices of potato and onion in hot water and she had beat me again.

Score Woman 1000

Score Man      0002

Bugger.

Measuring RPM with LabVIEW

There appears to be two ways of measuring the rotational speed with Labview, one of which is easier than the other. First things first let me explain how the rotational speed of a micro-gas turbine can be found as there are some important subtleties between each technique.

The 'old school' method way back when I first started building jet engines was to use the case pressure of the engine and a compressor characteristic performance map. These performance maps are readily available from turbocharger manufacturers and since most micro-gas turbines are built around a turbocharger compressor this would seem to give a good approximation. But, as with all things to do with jet engines, the simplicity of this idea isn't as simple when you need to use it. Looking at the Wren MW54 which uses a turbocharger compressor from Garrett, (Part number 446335-9), which is also is used on the GT2854R turbocharger. Although the compressor may be identical the second stage of the compressor is different. The MW54 uses a series of wedges for the stator blades of the compressor stage, while the turbocharger uses a bladeless spiral volute. The reason for this is to provide greater efficiency over a wide range of rotational speeds required for a pistion engine, but the increased size, area and weight means that this is a no-no for small model aircraft gas turbines. This means that the compressor map wont truly represent the behaviour of the compressor, and in my experience with the vast amount of experimentation and modelling of these small engines I can say that the average turbocharger compressor map is at best within + 6% of the performance of the compressor used in a gas turbine engine. Now 6% does not sound like much, but if your engine has a mechanical limit of 100K RPM then I will let you figure out how big that error is, and the value of 6% is based entirely on the MW54 engine. Other engines showed as much as 10% deviation from the predicted performance shown on the compressor map. Of course if you have modified a turbocharger into a gas turbine then you wont have this problem.

A typical compressor map looks like the chart shown on the right. It is actually a plot of four non-dimensional values and if you're handy with non dimensional analysis then list all the variables for all the fluid properties that a compressor will experience and you will derive four equations. These are known as corrected massflow, corrected rotational speed, a pressure ratio across the compressor and the isentropic efficiency of the compressor. All the work I have previously seen with amateur gas turbines and in the model gas turbine book by Thomas Kamps, (good general book for beginners but I think a lot of the mathematics was lost in translation from German to English), simply states that you can use the values as given, but the corrected speed and massflow need to be modified with the equations below, before you can use them.

So why am I telling you this, well simply knowing the pressure is not enough to find the corresponding rotational speed or massflow. You will need at least three known values before you can locate the operating point on the compressor map. This is a complex problem and requires complicated computational models to solve them, something that has put years of wrinkles on my face from lack of sleep. But you can take several pressure and temperature measurements at various throttle settings and take a best guess at a 'steady state operating line' shown in dashed red in the picture above. This will give you a line which you get approximate RPM, massflow and effiency values from a known pressure ratio.

The second method was to use some some of frequency counting to measure the rotational speed of the engine. This was commonly done by using infra-red LED's and has now moved onto Hall sensors. The infra-red method works by passing an infra-red beam through a hole in the compressor nut, while the Hall sensor works by detecting the pulse generated from a passing magnet embedded within the compressor nut. Both methods generate a signal that can be approximated to a square wave signal, and the frequency is the rotational speed of the engine.

Now Labview has the necessary functions in which to find the frequency of a signal and in fact I came up with at least four methods which worked with any number of simulated signals, with noise over any frequency from around 10Hz to 2500Hz. Seems ok, but that equates to RPM values of 600 to 150000, not good since I want to measure the RPM from zero up to at least 165000. When I came to test the tachometer with both a signal generator and an actual RPM signal from the engine it didn't work, no matter what much I tried. Labview has what they call an oscilloscope function that you can use to analyse the behaviour of a signal while the program is running and this showed I had a valid signal, and in fact using a premade Tachometer function block which opens up into a nice GUI showing a speed over time graph and a waveform of the signal but it would not output anything!

Hmm, I think I  need much, much, much more experience with Labview but time is short and I have already decided to go another route. Rather than measuring the signals frequency I will convert the frequency into a linear analogue voltage signal using a National Instruments LM2917 chip. The data sheet accompanying this chip and a trawl through Google showed that most people use this chip to build car tachometers measuring low RPM's with multiple pulses per rotation. After a coffee and sitting down to read the data sheet properly resulted in the page of maths in the picture on the right and an order for several bags of capacitors and other bits and pieces. The circuit is based on a maximum frequency of 3500Hz which is 210000 RPM, which should help to keep the results in the linear region of the chips output. The output is also designed to be between 0 and 5V, which is line with all my other analogue voltage signals. This may work, it may not, time will tell once I get my new oscilloscope I will be able to investigate this method better and see if it actually works. Stay tuned!

Edit: The NI LM2917 ic can be found on EBay for £1.40 so cheap enough to experiment with.

Inporting Data Into LabVIEW

My initial attempts at getting Labview to communicate with a DAQ were based on two methods. The first was an old pdf document from DATAQ and the second was from ultimaserial.com, without these two informative guides I would have been lost. Once I had a working virtual instrument in Labview, vi, I resort to what I did when I was learning to model in Matlab Simulink by playing with various things to see what effect they have. This is my most efficient way to learn new software like this, because by discovering for myself what something does means I can better understand how to use the tools to my advantage. There are of course hundreds of examples available in Labview for you to play with, so it looks like my summer is going to be busy playing with them too....

Here is a screenshot of my block diagram for the DATAQ 148 DAQ in case anybody ever needs that extra bit of help with their models, if anybody needs the entire vi for this DAQ then get in touch. This vi has an extra bit tacked in to it so I could see how well it was working when using a load cell which I use to measure thrust.

The next picture shows the vi I used to import data from the µChameleon, this is still in the development phase and requires some tweaking. This time there is a signal generator and an RPM measurement block to investigate how to build a reliable tachometer. More on this later. This time the vi was assembled from scratch based on trawling through many, many forums and help topics.

The front panel, the bit that will be the user interface once complete looks like this, the calibration dial is used to set the thrust gauge to zero before use, as strain gauges are very sensitive to small changes in temperature and even switching the power supply on and off can result in a small deviation from the previously zeroed condition. A careful look at the block diagrams will show that the output from the DAQ is multiplied by a small value to convert the signal to Newtons, the dial then subtracts a small value from this signal, which is then passed through a block which ensures that the output is always positive. Therefore by moving the dial, the needle will approach zero, and if the dial exceeds the zero value, the needle will bounce back up, preventing false calibrations.

Labview To A Thrill....

The basis of my latest project is the design of a real time data acquisition program using LabVIEW, this is a program which allows you to build programs visually without having to write code. My programming knowledge is based on Matlab but I have built several complex models using a program within Matlab known as Simulink, which is simply a graphical representation of Matlab coding. This is a very powerful way of implementing dynamic systems quickly, especially for engineers as we tend to see the world in a visual way, rather than trying to implement many lines of code. The picture below shows a Simulink model that governs fuel flow rate into a gas turbine. This model is one of many subsystems that make up the entire simulation, I wont go into details but it should be easy to see that building up a model this way has its advantages.

Now LabVIEW has very similar approach to Simulink, but that is were the similarity ends. I have only been using it for a week but I'm slowly getting to grips with it. Although it is designed to receive data through a a digital to analogue converter or DAQ, it seems like the good people at National Instruments have decided to make it really easy to use LabView their own brand of DAQ's. Use another brand of DAQ and you either have to rely on the DAQ manufacturers releasing some code, help from forums or just ploughing away and figuring it out yourself. Trust me, if you are new to this kind of thing, I would seriously consider paying a fortune for a National Instruments DAQ, it will save you hundreds of hours of work on a very steep learning curve.

I currently own several DAQ's, one is a kit from Maplins, I have two from DATAQ which are very good and come with some good free software, and the fourth is from Starting Point Systems. The latter is an excellent piece of kit called µChameleon and also comes with a piece of nice software with a really simple but interesting programming language. For my jet engine test bench I needed ten analogue and four digital inputs to measure the following:

• RPM
• Thrust
• Fuel Flow Rate
• Pressure Ratio (differential)
• Case Pressure (gauge)
• Freestream Temperature
• Intake Temperature
• Compressor Temperature
• Turbine Inlet Temperature
• Exhaust Gas Temperature
• Fuel/Gas Solenoid Operation (digital)
• Starter Motor Operation (digital)
• Glow Plug Operation (digital)

So this means I have to use two DAQ's, specifically the µChameleon, which has eight analogue input channels and the DATAQ 148 DAQ which has a further four analogue channels. They both also have several further digital I/O channels, counter channels, analogue outputs etc. But this also means I have to use LabVIEW to read two instruments simultaneously which may or may not work. I hope it works or I have to lose two measurements most likely the pressure measurements.

In between playing with LabVIEW I had to go back to address an old problem I had before in measuring the the RPM signal. The engine has an ECU that controls the fuel flow rate while also monitoring the RPM and exhaust temperatures. In a nutshell, should these deviate from limiting values the ECU will correct the fuel flow rate to bring them back into line or even shut the engine down. The RPM is measured by using a hall sensor and small magnet embedded within the nut that holds the compressor onto the shaft. This signal is a 0 to 4V pulsed signal and at the engines maximum speed of 160K RPM, this signal will have a frequency of around 2.7K Hz. This signal also has some noise embedded within it and is particularly noisy at very low speeds, the picture below shows the signal measured during five pseudo start attempts where the engine is spun from 0 to 5000 RPM over several seconds.

 I did play around with this signal in LabVIEW but even though I managed to get a reliable RPM reading using a generated signal mimicking the hall sensor, complete with random noise of a similar amplitude, I could not get it to work with the real signal. Although using the oscilloscope function within LabVIEW I did see that I had what appeared to be a valid signal. I also didn't like seeing the way the on screen gauge would behave at zero or very low RPMs. So I made the decision to convert the hall sensor output from a pulsed dc signal to an analogue voltage which I had already cracked with LabVIEW and was having great results with. See the short video below, this was literally two days after losing my LabVIEW virginity so excuse the simple layout, and I have since moved on and improved the response from the load cell to remove a lot of the noise that caused the gauge to 'bounce' between values. Also note that I took the video at 4:00am so there is no sound bar some rustling and the light is dark, but you get the idea.

Now before I get into details on how I plan to do this I think I should cover how I linked my DAQ's with LabVIEW.

View to A Lab...

It's been a long while since I last posted and many things have happened. Don't worry I promise not to bore you to death. Well that's a blatant lie, I will try my hardest to bore you.... Lately it seems my favourite topics of conversation revolve around jet engines, no pun intended.

Anyway I have managed to winkle some spare time into my incredibly busy life that the fourth year of an aerospace engineering degree demands. So what did I do with the few days I had off over Easter break? Did I watch TV? Go flying? Run about in the garden, splashing a water from a hose in slow motion like those sentimental flashbacks to childhood? Nope. I spent the time working on something. It is a philosophy that Aerospace Girlfriend doesn't understand, but I don't see it as work. In fact over the looooong summer months between each year at uni I start to go mad with the shear boredom. Usually by the end of the summer I have no money left to carry on with my projects, the weather is usually terrible and I resort to spending the evenings moaning about the lack of Dr Alice Roberts on television these days. Ah Dr Alice Roberts, now she does make me want to run around the garden with a hose.

So what have I been doing, well I have been building a jet engine data acquisition program which would let me control a jet engine through a computer and see the performance of the engine in real time. The problem is I have to couple many, many, many different sensors to the computer. This is the easy bit and I have been doing this for years using a DAQ, but now I want to build a neat virtual dashboard and have the on screen instruments display the data from the sensors using Labview. Sounds easy, but trying to use Labview is very much like trying to herd badgers into a laundry basket with a plastic spoon. I'm getting there though and will post details soon.

In other news I won the NorthWest Aeropace Alliance 'Sir Frank Whittle Award' in February with my work on the steady state and transient performance of micro-gas turbine engines. I have a problem accepting praise for my work, especially the project that won me the award and this annoys Aerospace Girlfriend. The project wasn't done to win awards, simply as a way of me getting to spend vast amounts of time working on something that I enjoy doing while getting some much needed uni credits out of it. Sir Frank Whittle is a personal hero of mine, and it was due to a documentary about his achievements, that sparked my interest in jet engines when I was a child. So winning an award set up in his honour, in the field of gas turbines was very cool.

I also won a £1000 as part of the award and it was only right to invest a small amount into buying a bunch of pressure transducers, thermocouples and other assorted goodies towards the jet engine testing bench. Here is the obligatory picture, I had drunk many glasses of champagne and wine by this point, combined with my unphotogenic 'bulb head', I have no idea how the photographer managed to get a half decent picture. My dad took some pictures, but the less said about those the better.... 

I will be graduating in a few short weeks and the thought of being released into the world as a real live boy engineer is quite scary. I will still be building mad contraptions in the garden shed, except this time I am a certified rocket scientist. Let's hope this means less failures and more success? Turbines spewing flames, running pulsejets late at night and small explosions as a rocket motor decides to commit suicide, these don't go down too well with the general public. I need to win the lottery then I can become a mad scientist, free to tinker at leisure, although that's as far as the dream goes. I haven't yet decided if I want to be a Doc Brown kind of mad scientist or a Professor Frink. Time will tell, but I think my future lies with Doc Brown, (again no pun intended)... 

Now that I have mentioned Doc Brown, I think I should also mention his closest living parallel, Clifford Stoll. Watch this because if every child had the experience of having a teacher like him the world would be a far better place. I remember my science classes at school being dull and boring, well most of school for me was dull and boring. I remember having the fun of mathematics beaten out of me quite early on. and of course I couldn't be bothered to do any homework preferring to spend time reading books on geology, rockets and whatever else I could get my hands on.