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.