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.

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!

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.