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.