Fingers on the pulse....

It's been a long time since I had any time to sit down and do anything else other than read about ship airwakes, plot ship airwake CFD data, then read more reports on bluff body aerodynamics. Progress on the dashboard has slowed considerably, to the point that hardly anything has happened since the last update other than I drilled some holes in a project box to fit the various electronic boards.

In other news since work on the dashboard has ground to a halt because I am stuck at uni during the week and at my girlfriends during the weekends I have been taking an interest in resuming work on pulse detonation engines or PDE's.  I amassed a fair bit of research on these engines with the idea of using a small two-stroke piston engine as a valve, somewhat similar to this patent, dated 2005 which is incidentally around the time when I was doing my research and struggling to use rubbish TurboCAD program to develop a some 3D models.

These engines are similar to pulse jets in the fact that combustion takes place intermittently and superficially they look alike but in the pulse detonation engine combustion takes place at high speeds. So high in fact that it produces a supersonic pressure wave that combusts the air/fuel charge almost instantaneously. Although in pulse jets and car engines the combustion process might seem to occur very quickly, it does in fact undergo a process called deflagration where fuel combustion propagates subsonically. Occasionally car engines and pulse jets can transition from deflagration to detonation and when this occurs a great deal of damage often occurs.

Anyway I abandoned the project quite early on, despite the relatively easy fabrication such an engine will require, the high precision required to control the engine made it a non-starter as I had no experience or understanding of control systems and the accompanying mathematics. Roll on nearly ten years and I find myself looking at another heap of reports and running some simple CFD simulations in between my PhD work and thinking this is a viable project. I should finish the Ardour dashboard too, but all my extra curricular activities will probably be on hold until I move house in a couple of months time... But I can still throw some time into designing the engine.

I've already decided that instead of using a valved PDE, my design will be valveless. I see point in going down the valved route as this requires high pressure fuel and oxidiser feeds, careful valve and ignition timing and would hardly make a lightweight, flight capable engine. The valveless route means I can use ambient air for the oxidiser, remove some complexity and reduce overall engine mass and cost, which is makes it attractive to a poor student like me. It's not all advantages though, it has a drawback. A big one. Without mechanical valves there is nothing preventing air or more specifically hot combustion gas from escaping from the engine without contributing to thrust. But all is not lost as you'll see soon enough, but more on that later, I still have to wait on some CFD results before I can move forward.

Focus Magazine makes a cock up...

Bought a copy of Focus from Tesco's earlier because I was bored and I don't mind reading a bit of pop science now and then.. Anyway trudging through the questions and answer sections and I came across this nugget of misinformation. A question about setting a firework off on the Moon,  I'm sure any GCSE student could answer. But no... An astrophysicist made a boo boo.

Fireworks are mixtures of combustible fuels mixed with an oxidiser, for example black powder, I have made this myself and is a mixture of potassium nitrate, sulphur and charcoal. I mean who hasn't it's so easy and it is still the fuel of choice for small model rocket and firework motors. The potassium nitrate is the oxidiser, while the charcoal is the fuel, the sulphur just helps the reaction along. But this mixture will burn in a vacuum, on the Moon, in my hand, under my backside, in a rocket motor, in a cannon, under water, (providing the powder doesn't get wet)... 

So much for 'The Experts' who answer questions...

PWM Servo Control

Another short blog post, but I have drank almost an entire bottle of wine and I have a stack of papers to read about CFD analysis on ship air wakes. Haven't started the PhD yet, and although PhD's don't officially start till October, I'm needed to start as soon as possible. So rather than spend the first week trying to play catch up, I have been reading everything and anything on the subject so that I can hit the ground running. In other news, I have also bitten the bullet and ordered a second µChameleon DAQ, so that means I have up to 16 analogue channels, which means I can add other sensors in time as I'd like to take more pressure readings, especially the combustion chamber pressure loss and the pressure drop across the turbine stage.

I have been playing with the µChameleon DAQ to try and control an RC servo by providing a PWM output. The µChameleon has two 5V outputs, allowing me to power the servo directly, while channels 9 to 12 are the PWM output channels. It didn't take as long as I expected. Some to the examples provided by Labview looked complex and where composed of lots of sub vi's. I have no doubt that these would work, but since I don't have access to an National Instruments DAQ I couldn't find out. So I played with the VISA functions and managed to get a simple PWM servo controller to work in about an hour. I only needed to mimic a PWM signal given by a radio control receiver from a full throttle input signal. Once again the trusty oscilloscope came in handy. The pulse width values I have used, (the two constants on the left in the diagram), corresponded to maximum and minimum values I found for one of my radio control system. This value doesn't really need to be specific as the gas turbine ECU can be adjusted to read the max/min values of any radio control system and set the throttle range accordingly. I then convert the range between the two values into a percentage and multiply that with the throttle input value. Although a hundred steps seems a bit coarse, the average radio control transmitter may only have twenty five steps, (if using a ratchet system on the stick), so a discrete range of a hundred steps should be more than adequate.

Most ECU's are also started by moving the throttle trim to max and cycling the throttle from idle to max and back to idle, once the ECU see's these throttle movements it initiates the start up procedure. I intend to replicate this by having the start button on the dashboard input a 10% throttle input into the ECU replicating the maximum trim position.

Success!!!

I have been formally offered a place on the PhD project I applied for, Ship Design Guidance for Aircraft Operations!

That is all.

Dashboard Update

Haven't been in the mood to do much today so I spent a couple of hours tidying up my dashboard. I changed to the 'old' style gauges to some sharper ones and now it looks a bit more slick. I have also rigged up a switch to start recording data which is sent to a text file. I can then open this in Excel for further analysis letting me analyse the results easily. Prior to this I'd have to calibrate all the channels I used on the DAQ then start the engine and perform the experiment, then find the chunks of data that relate to the experiment for channel 1 and so on.. This way I have all the channels I want to analyse exported as a chunk, and only for the time I want to capture.
I am nowhere near to finishing the block diagram yet, so when I do i will make that available too. I need to write some functions to calculate efficiencies and a lookup to find the air massflow rate. Think I will tackle the PWM throttle signal next as the turbine flowmeter I have been waiting for will not be in stock till November!! Nice of the company to keep that quiet after I had ordered and paid for it nearly three weeks ago and only told me after I had sent an email Asking me if I wanted to cancel or wait. Yes I think I will be cancelling that order! I'm not waiting five months I'll have to order a slightly more expensive one from EBay.

It's not rocket science... Oh wait, yes it is..

In other news, a friend from uni has expressed interest in starting a small experimental rocket team to get a micro-satellite into low earth orbit, so far there around five students who expressed interest but just the two of us who actually want to get anything done. It seems that once again that the engineering students I know are all too interested in a well paid career than having any kind of affinity for engineering. Anyway a task of this magnitude would take many years, but who's to say it will never happen, all big projects had to start somewhere and other teams like Ausroc, Aspire, dutch Sub-Orbitals, Starchaser and SpaceX all started with a few interested people and big ideas. We have planned out initial project aims of building a small scale version of the liquid fuelled rocket engine, on the order of 1000N, and to have reached an altitude of 5km by December. The highest I have been before was about 1.5Km and that was with a commercial solid fuel motor and rocket this is going to be something else entirely. We have begun to put out some tentative feelers about who and how to start applying for funding or sponsorship. I have enough equipment, instrumentation and materials from previous projects to build and test a fairly large proportion of this initial stage, but there's no way we can afford the rest on our own budgets. Let alone the further stages of the project should we actually meet the objectives.

 

Talking of funds, well it looks like my bank account is going to take another hit because I need to buy another DAQ... Luckily with the European economies they way they are, I will be able to shave a bit off the the price. I need it because I have ten analogue signals I need to measure and thought I could use both the µChameleon and a DATAQ DAQs, but this has proved to be messy and it conflicts with my desire for everything to be symmetrical... This will also help in that I can monitor the gas and fuel solenoids, starting motor and glow plug operations easier, than trying to read these through the digital I/O channels.

Everything is coming together well now, I am starting to think about the physical test bench. I have some plans I sketched out a couple of years ago that involved the test bench mounted on a trolley with the engine operating inside a fully enclosed 'box' with the exhaust ducted out the rear. Fuel and instrumentation would be housed in separate compartments. This has the benefits of reducing noise, I know it won't be much, but even a few decibels would enough to help reduce the annoyance to the neighbours. I only wear ear defenders for the full throttle runs because I love engine noise, even high pitched rasping two-stroke engines! Another plus for this isolated engine layout, is the fact I can easily inject CO2 from a fire extinguisher should the need arise and it has on many occasions. I have set fire to the shed, my parents shrubbery, myself, in fact anything can be burned has been burned over the course of my life. The shrubbery is a particularly sore point with my mother who brings it up with anybody and everybody more than ten years after the incident. To be fair I really didn't think the exhaust from a small jet engine, without an exhaust nozzle, would be hot enough at ten feet to cook an entire bush. But I was wrong, and to top it off a bearing failure at 80,000 RPM then left pools of burning kerosene on the new block paving. I got the feeling I wasn't her favourite person that week.

Currently the dashboard in Labview looks like this. I'm still not happy with the layout, but it's getting there. Apologies for the mixture of metric and English units, That's if you noticed the temperature meters were in degrees Centigrade rather than Kelvin. I will be using this to monitor the engine in real time and my brain works best in Centigrade, especially at the higher combustion temperatures, because its the unit I use most in daily life. I only work with Kelvin when mathematics are involved. It's a bad habit I know, but I don't want to run the risk of missing something going wrong a moment before all hell breaks loose because I was confused with subtracting 273 degrees. Despite having just done a maths degree in disguise, it seems I am hopeless at simple arithmetic. I've also christened the project Ardor which is Latin for flame, burning, heat..... according to my seventeen year old, high school Latin dictionary. After my track record in testing gas turbines, I think the name is justified. There's still some things that need to be added to the dashboard, but these are simple indicators to notify me when the ECU is cycling through various start up systems. The next big job is figuring out how to export a PWM signal and adding a second vi to control another DAQ.

Judging by the amount of blog traffic I get just from people looking how to measure RPM in Labview, there must be some interesting projects out there. If you're doing something interesting let me know! I love reading about what other people are up to!

Signal Conditioning

I have been having some issues with noisy outputs from the µChameleon DAQ so when running the dashboard to see how well my sensors and their associated circuitry performed. The voltages I'd measure on a multimeter were fine, however Labview would show wildly fluctuating signals which had the needles on the gauges jumping over very large values. If you look at my previous Labview vi's you might notice that I had tried to lessen the effects of this unknown noise using a simple mathematical method where I limited the number of decimal places of the number string. I had tried to do some fault finding a few weeks ago and didn't really get anywhere as I didn't yet have an oscilloscope, but it now seems I have fallen victim to the dreaded aliasing...

Looking at the RPM voltage signal on the oscilloscope showed not the linear voltage I was expecting, but a triangular waveform that had a mean voltage that was the same what I was seeing on the multimeter. The maximum to minimum voltage was in the region of 1.8V!!! Which, after figuring out the scale I'd used, corresponded to the magnitudes of the needle fluctuations I was seeing in my Labview gauges.

That was one mystery solved, but why was the DAQ giving me a signal that looked like random noise. Now when I bought the DAQ I noticed it had a sample rate that was more than sufficient, at 50KHz. Even if it only ever realised 60% of that claim it would be more than fast enough, can you see where this is going? It does indeed seem that you get what you pay for, and in my case that would be a measured sample rate of around 50HZ on my analogue channels which is only 0.1% of the claimed sample rate. Some digging on the products help forum showed similar results from other people, although it seems like the moderators don't keep on top of the spam robots which seem to have flooded the site when I checked it a couple of days ago. Putting this into context, at 50Hz the time step between each sample is 0.02 seconds, as you can see in the graph of the waveform above, the period of that signal is 0.0005 seconds. This means that the DAQ cannot capture the waveform and the result is a signal that looked noisy. Incidentally, if I had a sample rate of twice the measured frequency, Nyquist theorem, then I'd need a sample rate of 10KHz.

Putting this together it seems like the low sample rate and the noisy waveform was the source of my frustrations. Even if the DAQ had a higher sample rate and aliasing wasn't a problem, the values would still oscillate and I'd still have data which would be unusable. I looked at commercial signal conditioning, but after a few seconds the cost and complexity had me running for coffee and an easier solution. Digging out some of my uni notes from a third year module, I found that I might solve the problem using a filter, specifically a 'Low Pass filter', this comprises of a capacitor and a resistor. Couldn't be simpler, so literally a few minutes later I had found that a 1MΩ resistor and a 220nF capacitor reduced the magnitude of the noise from 1.8V to 0.3mV and the noisy behaviour of the Labview gauges had stopped. Finally!!

Now that I have sorted the noisy signal issues I have also been able to implement Labviews built in Thermocouple vi  to interpret the temperature from the thermocouple. This saves me from creating a large lookup table to locate the temperature value based on the voltage. Previously I have been using a quick and dirty method to estimate the temperature based on the product of a simple conversion factor and the voltage. I did a test where I dunked a couple of digital thermometers into a cup with one of my thermocouples and monitored how it performed by watching the temperature drop of boiling water and observing the values. I'm happy to say that the temperature my thermocouple was giving values within 1°K of the food grade thermometer than the thermometer that I use to monitor one of my aquariums. Looks like I won't be using that one in my reef tank anymore.

Still have to sort out my load cell, pressure transducers and flowmeter, but things are coming together quite quickly now. Stay tuned!

RPM In Labview Part 2.

Remember a few months ago I mentioned how I was planning on using Labview to display the engine speed by splitting the signal between the Hall sensor and ECU. Now I had tried to simulate and convert a square wave in Labview to represent the engine speed, and didn't really have much success. I had an idea whereby I converted the frequency of the signal into a voltage and treated it the same way as the other signals. Now after looking at trying to do this in Labview, which lead me to almost scrapping the idea of using Labview and instead toyed with the idea of writing the whole thing using Python which I gave up. The madness continued and I looked at writing some code in Matlab and trying to get Labview to utilise the code to analyse the signal and spit out the RPM... This was starting to get complicated, so I wondered if I could solve this with an analogue solution. A quick Google and one coffee later I had found an IC from National Instruments that would do this, and that was as far as I got.

Fast forward a few months and I have just finished a prototype circuit, tested it and it seems to be stable and working fine. I have yet to test it with the DAQ and Labview, but that's a mere formality. I apologise for the messy picture showing the prototype circuit, I will transfer this to Veroboard shortly and tidy it up a bit. Just incase you can't match the circuit diagram with the circuit on the right I have numbered the important features that might need highlighting because there is a lot of crocodile clips in there. My new oscilloscope and function generator have been invaluable in this mini-project, so much that I think I would have abandoned it long ago if I didn't have them.

The corresponding circuit diagram which is based on the prototype circuit looks like this, not too bad for something I knocked up in Microsoft Paint!

 

You might have noticed the addition of an adjustable voltage regulator, this is to modify the pulsed DC signal given by the Hall sensor into an AC signal that can be read by the LM-2917 chip. After getting the circuit performing nicely giving a 0V to 4.5V output for 0 to 3KHz, which is 180,000 RPM I started playing with the input square wave to approximate the signal that I'd actually need to measure instead of a sinusoidal wave. At this point I found out that this chip doesn't like pulsed DC signals. Here is some data I took from the Hall sensor, at 88Hz showing the signal. As you can see, the signal is offset and doesn't cross the zero volt axis. Therefore I just simply added any voltage between -0.5V and -4V to the input signal to ensure that it crosses the zero volt axis and therefore can be read by the NI chip. In the end I used -1.5V, produced by a voltage regulator that I got from Maplins for £0.85. The polarity of the voltage regulator doesn't matter, if you want to shift the wave below the axis you can either add a positive voltage to the ground side of the waveform signal or add a negative voltage to the positive side of the signal.

I'm sure there is an easier way to read the RPM in Labview, I did think about hacking the ECU itself to read the voltage from its frequency-voltage converter chip, assuming it has one but I don't want to risk introducing noise into the ECU that could lead to it destroying a turbine. These engines will self destruct in a very, very short time especially at high RPM's. Besides, I don't know about you, but sitting in front of this isn't a bad way to spend a few hours! 

Just a quick note on the oscilloscope, It's an Atten ADS1102CAL 100MHz and I got it off EBay for about £190 and it is very good value for money and has more than enough capability for what I need to do. After using CRT style oscilloscopes in the past, this is super light and compact and very unobtrusive in my small room.

Update:
Here is the finished circuit, just need to add a gauge on my Labview Dashboard which is the easy bit because I now have a nice linear 0 to 5v voltage output from 0 to 200,000RPM. A conservative estimate of the total cost of the parts used would be in the region of £4.00, not bad.

And now for something completly different....

I should apologise for the lack of posts over the last few weeks, I am in the middle of my fourth year exams and the last few weeks before the semester finished I was run off my feet with a never ending list of coursework and reports. One of the modules had me doing some interesting programming of the vortex sheet produced by a wing to investigate the wing tip vortices's to see if the wake interfered with the tailplane. So while I have a few days between exams thought I'd write up a bit on this because having researched this topic, I know how tricky it was to model. The code is written in Matlab and a link to the scripts will be given at the bottom of the page. The mathematics behind computation of the vortical wake produced by a wing is too long for me to delve into for this mid-exam blog post, if there is enough interest I am more than happy to cover this in a future blog, but for now I will just gloss over the details and show the pretty pictures. After the last few weeks of non-stop revision digging out my notes and writing what would amount to another small report is the last thing on my mind. Besides, the UK is in the grip of a heatwave at the moment, it is nearly 28`C outside which reduces my desire to write up my derivations even more! For those of you who are reading this from sunnier climates it might sound like an average day for you, but for us it is almost unheard of on this rain drenched island.

Here is the classic NASA video of an experiment to show the vortex produced by the wing of an aircraft. These wing vortices's can interact with the empannage of the aircraft producing unpleasant effects as well as interfering with the behaviour of other aircraft. This is a well known phenomenon among large aircraft and most people know there are separation limits that govern take off and landings for commercial aircraft, but this video shows that the vortex sheet produced by an microlight aircraft is enough to interfere with a second microlight.

Here are a couple of screen shots from the my wake code that predicts the wake produced by a small aerobatic trainer type, aircraft which myself and several of my classmates designed for one of our uni modules. After finding the wake, the Matlab code will also plot the wing, fin and tailplane geometries to see if the wake produced any undesirable effects on the tail surfaces. 

The two files at the end of this post are the script 'wingwake.m' and function file 'vortex.m' for the wing vortex model. You'll need to download both into the same destination folder but only the 'wingwake.m' file needs to be run, and you will also of course, need a copy of Matlab. I will one day modify the code to add in the effects of flap deployment and tidy it up with a GUI, but I don't have the time yet. I never have the time for anything these days least of all the interesting projects. I haven't touched my gas turbine dashboard for a while and I'm itching to get back to it. 

Talking of interesting projects, fingers crossed I will start a PhD in a few weeks looking at CFD of ships with a view to improving the design process with respect to the handling qualities of a helicopter during deck operations.. I can't wait!

WingWake.m
Vortex.m

Wild goose chase.

It is Tuesday night, three days ago, the night before an exam... This happens, true story..
My four year old niece decides she wants to play with the quails. I had bought my mother a pair as part of her suburban dream of starting some kind of farm in her garden. Anyway my niece inadvertently releases a quail into the garden which then takes an instant dislike to any efforts to catch it, and hops the eight foot high wall into the neighbours garden. My brother, father of the now crying child jumps the over the wall, meanwhile the quail finds his new garden is not suitable for its taste, probably a lack of storage and decides to fly, magnificently for a quail, the twenty feet over the alleyway into another garden which is perfect quail habitat. Four foot high weeds, brambles, nettles, grass, bricks and an outdoor toilet that would look good in trainspotting. Que an hour later after much careful poking, swearing, scratching, shaking twigs and false alarms, where I stalked and caught a dried up plant that looked suspiciously like a quail. Dammit.
All hope had faded until my brother poked the quail up its bum and it took off again, clearing another eight foot high brick wall and into another garden. I started to sense a pattern developing here that quails can fly and they can fly better than I can climb walls in my bare feet. Within seconds we are perched on top of the wall trying to see where it went, at which point the neighbours two dogs appear. They are mental, they are angry. So angry that my bottom hole relaxes slightly. Oh fiddlesticks, that's going to be one tasty quail sized snack for a dog.. Then a woman appeared and visions of having to explain myself to the police flashed through my mind. Surprisingly the woman who lived there didn't appear to be alarmed by one guy stood on her wall brandishing a children's rock pool net and another waving a broom and gibbering nonsensically with what only can be described as a gingery-brown afro, (I had washed my hair earlier that day, but didn't condition it, and now I'm paying for that with a beautiful, but inexplicable hairstyle, but I digress)... Two minutes later and the quail found himself in the back of the net and back in the run, the niece was suitably shouted at and I'm left with an arm full of scratches, an afro full of twigs and one pissed off quail...

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.