Automotive Compression Tester

Hi-

I have made a preliminary design for an automotive compression tester and would like to run the idea past the Arduino experts on the forum for any feedback that they'd care to share. I'll try to be brief.

I need to sense the pressure from the combustion chamber during a compression test (fuel and ignition disabled). I want to be able to have a few input parameters for the varying engines that my tester will be applicable, display the results, provide data and possibly offer a probable scenario for various failure conditions.

I've reviewed the online tutorials for Arduino and seen a few example programs. I've also searched this forum for similar projects, from which I have gleaned some good information. I am a software engineer by day (old school C/C++) so I've already written the "sketch", based on what I've learned about Arduino thus far.

Here is the basic design, laid out in a linear fashion beginning at the plug hole:

Adaptor -> Pressure transducer -> Connector -> Unit casing (no connector for the cable) -> Arduino Uno R3 with data logger shield and display shield

I'm considering creating the ability to connect a smart phone for viewing of the data with an app, but don't have much experience with that, so might not go down that road. If anyone has any input regarding making the data available to a smart phone, I'd like to hear from you. I saw the SD stuff, but don't think that would be the way I'd wanna go.

Anyway, opinions? Also, I've been researching pressure transducers. Looking at a Honeywell unit that is 0-200 psi, 0.5 - 4.5 V output and that is powered with +5V. Any opinions there?

Finally, the display. I've reviewed the 2-line RGB LCD displays and they advertise that they have directional buttons plus a select. Then there's the 1.8" TFT with the same 5 buttons (which they are calling a "joystick") and the 2.8" TFT touch screen. The latter claim that they use less pins and less memory on the Arduino but I am not certain how difficult they are to program. I read that there are libraries available to draw lines and such for the TFT devices, but it kinda seems like I'd be getting much more complicated with one of those options, and they may end up being a time sink. But I don't have any experience with any of them, so I thought I'd ask. The 2-line LCD seems like it'd be the easiest. Any feedback here?

Thanks so much!

Jerry

Hi,

av8or1:
Anyway, opinions? Also, I've been researching pressure transducers. Looking at a Honeywell unit that is 0-200 psi, 0.5 - 4.5 V output and that is powered with +5V. Any opinions there?

200/(4/5*1024) = ~0.25 PSI resolution. Good enough?

I have used the Honewell pressure transducers that you mention and i really like them. They are inexpensive and pretty accurate out of the box.
For just a pressure readout a 2 or 4 line LCD would be easy to set up and program (lcd library). I prefer the I2C interface for LCD as it takes only 3 pins and those same pins can control many other devices.

Hi,
Are you aiming this at multicylinder engines?? If so, my experience with this (writing data down in the notebook) is that you may want to take more than one reading per cylinder and average them, and then record the data for each cylinder. Then it might be nice to calculate the mean and min-max, which can give an indication of how worn the engine may be.

200/(4/5*1024) = ~0.25 PSI resolution. Good enough?

Yes, looking for variations like 2 to 4 PSI usually.

You can save that amount of data on Arduino and use some menu to display it on an LCD, say 4 by 20 characters. But you may really want to send it to a PC for archiving / printing?

Now the really cool thing would be a quick-connect adapter to go quickly into the plug holes, instead of the usual laborious screw-in-out or the maybe-not-so-accurate rubber adapter.

I'm just about to swap in a new 350 GM into my aged truck, and I SHOULD run a compression check on the old one to see what kind of shape it's really in..

But that will probably get scribbled down in my notebook like 1958 :slight_smile:

Let us know how this all works out...

Oh, info on LCDs here: http://arduino-info.wikispaces.com/LCD-Blue-I2C

DISCLAIMER: Mentioned stuff from my own shop...

If you can install one per cylinder and do all the tests together, that would simplify the testing a lot and eliminate a lot of the issues that occur when you're comparing cylinders. If you take this approach it would be good to collect all the data centrally and automate the analysis for cylinder-to-cylinder variation and the pressure versus cranking duration checks. For extra brownie points, figure out how to use the same hardware for a leakdown test.

figure out how to use the same hardware for a leakdown test.

That would be interesting!

A typical "2-way valve" could exhaust each cylinder's pressure to an "exhaust port". If that was a common port, one cylinder at a time could be pressurized for a leakdown test.

Timing the pressure pulse on each cylinder should allow stopping rotation with both valves closed for each cylinder individually.

Adding a per cylinder "oil injector" could automate the "Is the leakage valves or rings?" test.

This could save me 1/2 an hours work every 5 years.... :slight_smile: But maybe financially worthwhile for a diagnostic center that can print up a nice report along with the bill...

Such resolution would be more than good enough, as Terry mentioned. That's taken from the perspective of a 10-bit data value from the A-to-D output and I'm not sure how noise (or other factors) would influence that value. Any thoughts or experience on that? Then there's the accuracy of the transducer itself. The Honeywell unit I am considering is quite accurate (+/- 0.25% to +/- 0.5%) and I admittedly haven't done the math yet, I don't know that I could get the 0.25 PSI kind of accuracy by the time the sketch saw the data, but hey, that's neither here nor there. A variance of +/- 1-3 PSI would be acceptable in this application scenario.

Which leads me to another question: how much noise can I expect from the built-in A-to-D converter anyway? Should I code up a simple R/C filter or something?

Thanks!

groundfungus:
I have used the Honewell pressure transducers that you mention and i really like them. They are inexpensive and pretty accurate out of the box.
For just a pressure readout a 2 or 4 line LCD would be easy to set up and program (lcd library). I prefer the I2C interface for LCD as it takes only 3 pins and those same pins can control many other devices.

The Honeywell transducer that I am considering using is model MLH200PSL01A. It is a sealed gage, amplified heavy duty pressure transducer with a 0 psi to 200 psi Pressure Range. The output is 0.5 to 4.5 VDC with a 1 m termination cable. It retails for about $135, but the reviews claim that it is an excellent transducer that has the qualities required in this application. Thoughts?

PeterH:
If you can install one per cylinder and do all the tests together, that would simplify the testing a lot and eliminate a lot of the issues that occur when you're comparing cylinders. If you take this approach it would be good to collect all the data centrally and automate the analysis for cylinder-to-cylinder variation and the pressure versus cranking duration checks. For extra brownie points, figure out how to use the same hardware for a leakdown test.

Thanks, but a leakdown test is a different animal, so I'll save that as a separate project/exercise. XD

Also, one of the application scenarios is for a rotary engine, where a leakdown test is not applicable. The compression test tells you everything you can and need to know, as there are no valves for air to leak past and blowby is detected with a low compression reading due to a failed side (typcially one low reading out of three) or apex seal (typically two low readings out of three).

terryking228:
Hi,
Are you aiming this at multicylinder engines?? If so, my experience with this (writing data down in the notebook) is that you may want to take more than one reading per cylinder and average them, and then record the data for each cylinder. Then it might be nice to calculate the mean and min-max, which can give an indication of how worn the engine may be.

Yeah I have been considering a few options regarding the data. With a run-of-the-mill compression test, more than one reading means separate crank events, which is something that I am considering delving into, but might avoid just to be able to deliver a product this century. And separate crank events would not apply to a rotary, where it would be impossible to keep track of which rotor face you're measuring between different crank events. However I am considering keeping track of values during a single crank event and offering an average, min, max and median. Some have suggested that the average would be required just to get an accurate value from the transducer, due to noise (primarily) and other factors. Not sure that I buy that, it seems to me that with the relatively slow input values from the transducer that the Arduino would more-than-easily keep pace (laughable to suggest otherwise really) and with the approach being to simply display a value until another one is read, then replacing it with the new value, the only limitation you'd have would be the speed at which you could update your display. With a display inside the unit, not a concern. If you were broadcasting the data through a WiFi/Bluetooth/whatever to a smart phone, that might be another story. Then again, probably not there either. But I digress...

terryking228:
You can save that amount of data on Arduino and use some menu to display it on an LCD, say 4 by 20 characters. But you may really want to send it to a PC for archiving / printing?

Well that is why I am considering employing the datalogger shield. The idea being to provide a more extensive amount of data to the user to be able to plot at their free will. I'd likely just generate a file with CSVs that they can import into Access and have at it. But the datalogger uses the SD cards and I don't know how practical that is in this application scenario (greasy, dirty hands needing to fiddle with a small card, etc.). You say that this amount of data can be stored on the Arduino itself? How much data roughly? Also, would there be a way to just emit the data through the USB port so that the user could grab it on the other end and do whatever with it? Of course, if I develop a simple smart phone app, that takes care of that problem really, just broadcast the data and let the app deal with it on the other end.

terryking228:
I'm just about to swap in a new 350 GM into my aged truck, and I SHOULD run a compression check on the old one to see what kind of shape it's really in..

But that will probably get scribbled down in my notebook like 1958 :slight_smile:

Let us know how this all works out...

Roger that, will do. Thank you for the feedback.

Jerry

av8or1:
separate crank events would not apply to a rotary, where it would be impossible to keep track of which rotor face you're measuring between different crank events

It would be possible to detect the compression cycles and you would know that every third one corresponded to the same lobe - if you maintained separate statistics for each lobe, wouldn't that enable you to detect variations between the lobes?

PeterH:
It would be possible to detect the compression cycles and you would know that every third one corresponded to the same lobe - if you maintained separate statistics for each lobe, wouldn't that enable you to detect variations between the lobes?

To answer your question, I first need to speak a little rotary here. Lobes refer to an elevated point, like the lobes on a camshaft. On a rotor, these are called the apexes. Each apex has a seal that is kept in place by an apex spring and it is that seal against the rotor housing - one on each side of each face - that gives you compression. The "side" of the rotor in between each apex seal is called the rotor face. So the statistics kept here correspond to each rotor face, not each "lobe."

In the end I think that this is a difference between theory and real-world, though I'm open to being proven incorrect. While what you are saying is theoretically correct, my suspicion is that the first compression event at the beginning of each crank cycle may not yield a reading good enough for the processor to know if it is a valid pressure or not. And if that was the case, then the first reading picked up by the sketch would be the next rotor face, thus you'd be off by one. That said, given that the sensor can read values from 0 - 200 PSI, the theoretical notion you expressed seems plausible. However after having done too many of these over the years, I am intuitively skeptical. When doing a rotary compression check, you usually ignore the first couple of pulses you see, favoring instead to only look at the readings after it's turned over a couple of times.

But it might be something to experiment with if I get some spare time during development. Thanks for the question.

av8or1:
That's taken from the perspective of a 10-bit data value from the A-to-D output...

Exactly.

...and I'm not sure how noise (or other factors) would influence that value. Any thoughts or experience on that?

Some. With ATtiny processors. As far as I know, the ADC is essentially the same for all AVR processors. The difference is in how they are connected to the world. For example, the ATmega328 has a separate power connection for the ADC side.

What I know...

• The 0.1uF [A]VCC / [A]GND bypass capacitors are important. Excluding them to save $0.01 is foolish.

• Some notes from Atmel...
http://www.atmel.com/Images/doc2521.pdf ...2.2 Analog supply

• Using an AREF bypass capacitor seems to reduce noise a bit.

• If the processor is otherwise idle, ADC Noise Reduction sleep mode eliminates all digital noise. With a processor like the ATtiny85 this can eliminate one or two bits of noise (very significant improvement).

• Keep pins / lines carrying a PWM signal as far away as possible from analog pins / lines.

• Keep communications clock and data lines as far away as possible from analog pins / lines (e.g. SCK, MISO, MOSI if you are doing SPI communications).

• Atmel has a recommended filter for AVCC ... I can't find it. Argh! No wonder I can't find it. It's in the obvious place: the processor's datasheet. Check the Analog Noise Canceling Techniques section for an good description of how to get the most out of the ADC.

• This looks useful: http://www.atmel.com/Images/doc8444.pdf ... 2.9 Best practices for improving accuracy

I wasn't trying to imply that your sensor could tell you which compression cycle corresponded to which rotor face, only that it could collect together a set of readings that related to the same one. Typically on a piston engine, variation between cylinders tells you more than any absolute reading. I imagine the same could apply to a rotary engine, but the mechanics of the engine would make it harder to separate out the three sets of readings. However, it would be possible with the sort of device you're describing, plus the right firmware.

If one set of readings is out, do you actually care which one it was? To fix it I expect you'd need to strip the whole engine anyway.

PeterH:
I wasn't trying to imply that your sensor could tell you which compression cycle corresponded to which rotor face, only that it could collect together a set of readings that related to the same one. Typically on a piston engine, variation between cylinders tells you more than any absolute reading. I imagine the same could apply to a rotary engine, but the mechanics of the engine would make it harder to separate out the three sets of readings. However, it would be possible with the sort of device you're describing, plus the right firmware.

If one set of readings is out, do you actually care which one it was? To fix it I expect you'd need to strip the whole engine anyway.

I think we're tripping over slight misunderstandings here. First, no: you wouldn't care which seal was bad because you would indeed need to rebuild the engine to correct it. That's why precise measurements to 0.25 PSI aren't critical in this application. However, I thought you were indeed attempting to keep the data correct to the corresponding rotor faces between crank events. You would need to do that if you were to save the data and then attempt to plot it later. The data that I plan to provide would enable a user to plot the results from each face separately. You wouldn't want to get them confused or else you'd see inconsistent results. And it is exactly the strong likelihood of an inability to ensure consistency between crank events that causes me to avoid going down this path.

Finally, the variance between cylinder readings that is important in a piston engine is an axiom that doesn't apply to a rotary. Understand that all three faces ultimately share the same rotor housing, which is roughly equivalent to a cylinder in a piston engine, so if there's a problem with the housing, you'll see it in all three readings. Thus it is not really possible to see a variation between readings of the different rotor faces without the seals being the problem. If an apex seal is bad, then one face will produce a good reading, while the two faces that have the failed apex seal in common will both produce failed results. If a side seal is bad, then just the face that has the failed seal will produce a bad reading, while the other two faces will produce good readings. Again, since you don't have separate cylinders you won't see values like 180 - 179 - 180 - 130 (4 cylinder). Instead you'd see:

105 - 54 - 58 -> Failed apex
107 - 104 - 60 -> Failed side

And other similar variants. A variance of a couple of PSI between good faces can be attributed to several things but isn't generally a concern. Not yet anyway, because there's no way to know if it's a seal that is starting to go or just excessive carbon buildup on one face versus another.

But anyway, I am off the subject here. I'll keep the focus on development in future posts...

Thanks again.

Hope this helps.

Thanks to Coding Badly for the ADC information. I'll investigate and see what I come up with. Initially I was thinking that I would need to worry much because I don't need 0.25 PSI precision. The plan was just to read a value and display it. Then when the next value is read, replace that value with the new one. Then I started thinking of R/C filters to condition the signal. Now this stuff. Yikes! :slight_smile:

Coding Badly: I found this thread:

http://arduino.cc/forum/index.php/topic,86516.0.html

That seems to address the key elements of the ADC issues. Would you agree?

Thanks!

Ok so I'll admit that it's late on a Friday, I had a long week and I'm having doubts about what's going on upstairs right now. That said, I cannot seem to come up with a good way to convert the 10 bit analog value to the corresponding transducer equivalent. In this project my transducer will read pressures from 0 - 200 PSI, but the output is radiometric and will come in a voltage range from 0.5V to 4.5V. So that offset and total range need to be taken into account it seems. I found code in the forum that seems to do that by first calculating the voltage like this:

 int reading = analogRead(0);  
 float voltage = (reading * 5) / 1024.0;
 float temperatureC = (voltage-0.5) * 100;

This was a temperature sensor. However I cannot derive something similiar, which is why I'm thinking that my cognitive skills have really deteriorated tonight. :blush: Obviously a simple call to map() would do the trick, but it doesn't seem like it would factor in the offset. But the offset also doesn't appear to be necessary because in the end the way I found to make this work was to do this:

   int reading = analogRead(0);
   float voltage = ( reading * 4 ) / 1024;
   float PSI = voltage * 50;

So let's say that the value coming in from A0 was 768. That's .75 of 1024, so the PSI should be 150, which is .75 of 200:

768 * 4 = 3072 /1024 = 3 * 50 = 150 PSI

Am I out to lunch on this one? What am I missing?

Boy but it must be late...

av8or1:
...but the output is radiometric...

Radiometric? Are you sure that's the correct word?

Radiometric Definition & Meaning - Merriam-Webster
Definition of RADIOMETRIC
1 : relating to, using, or measured by a radiometer
2 : of or relating to the measurement of geologic time by means of the rate of disintegration of radioactive elements

av8or1:
That seems to address the key elements of the ADC issues. Would you agree?

Yes. (Sorry about the late reply.)