Phoenix_

Hi!

Thought I'd introduce myself first; I'm a new RX8 owner from Finland. Car is pretty rare here, people mostly drive them only during summertime. I'm using mine as a daily driver. Before shelling out the cash for the car, I took the it for a spin and shut it down an fired her up again a few times, no issues. Maybe a couple of seconds to start when warm, but as I knew of no better, I thought this was OK. The idle was also a bit rough, but I though this was normal. Apparently not. After driving it 600 km to where I live, it failed to start after fueling.

This brings us to this thread. I called the local dealer and made an appointment to get my car compression tested. When the time came, they were first an hour late, and then tried to use an ancient tester. Then they spent over an hour searching for the Mazda tool, but couldn't find it. I was pretty pissed after losing three and a half hours of working time. Of course the charged me nothing, but couldn't provide a new time for the test since the tool was missing. Haven't heard of them since, and this was over a week ago. Price for the check would have been 100 € (about $130).

Now I'm thinking of building my own tester. I could probably do it cheaper than the dealer would have done the single check. The plan is to use Arduino Uno, since I already have one laying around. I'm just ordering a sensor (Honeywell Trustability) with an I2C-connection. The sensor is a gauge-type with the range going from 0 to 150 psi. 16x4 LCD screen with I2C is already coming.

I'm probably going to gut an old compression tester, cut the fled hose, and just use a jubilee to connect the sensor to the hose. Sensor will have a small enclosure, and since I2C only need three wires, I'm planning on using normal 3.5mm stereo plug to connect the sensor to the main enclosure where the Arduino board and the LCD will be located. Power will be taken from the cigarette socket, and the enclosure will have an on-off switch.

I have no idea how the RPM sensing is done on existing applications like the TR-01, but I was thinking of using compression pulses to calculate it. The tricky part will be the code. Arduino has only 2K of SRAM, and I don't know how big of an array I can squeeze in there to hold measurements. There has to be some kind of filtering to get rid of possible spikes.

I was thinking about taking a few measurement to a smaller array, taking the average, and writing this to the bigger array, and then calculating the readings for separate sides of the rotor based on the RPM.

You're more than welcome to chip in with any suggestions.

Phoenix_

Decided on SSCDANN150PG2A5. Honeywell TruStability, Gauge-type, I2C, 0-150 PSI, total error +/- 2%. Ordered from Mouser, total was about 60 € incl. shipping.

oltmann

Cool project, and I look forward to seeing the github

Good luck with the car as well, and I hope you can put off a rebuild for quite some time.

RIWWP

iTrader: (2)

Cool project! I know that difficulty of getting compression checks, and other RX-8 specific parts/tools in Finland is a big problem of ownership up there. You could easily find a small market for it.

Yup, I'd take this method too. 2k isn't a lot of memory, but you aren't trying to store a huge array anyway. I'd probably ignore the first 3-6 pulses as the engine is still accelerating up to speed, then just index the pulses into their own arrays. 3 arrays, each pulse stores in the next one, just loops through the 3. You could probably store 30-60 pulses for 1 rotor without a problem, and that would be enough for the average you need.

It would probably get more difficult if you wanted to be able to output a wave-form chart of the compression, but that would mean hooking to a printer and that interface. I doubt you are interested in dealing with that.

I'm guessing just an LED numeric display for the values?


(Moved to Tech garage for you to get more exposure)

xexok

Good luck, I hope you can get it working. I wish the dealers out here only charged $130 for a compression check, mine wants $220.

ken-x8

Hmmm.... Never thought about this, but if I have access to a data acquisition system and a pressure transducer, all I need to do is cannibalize the fitting and hose from a regular compression tester and I'd be in business.

Not entirely sure if I could sneak our DAQ out of the lab, but it's nice to think about.

Ken

anoble1

Great Idea. Let us know what you come up with. You could use some old school Nixie tubes for the display. LED would be awesome.

Phoenix_

Tracking showed that they tried to deliver the sensor to my home address, called them and going to pick it up after work. Don't have the LCD yet so I have to use my laptop and serial monitor to play around.

I tried to do some coding on the holidays, but I'm still sure how to handle things.

First thing I have to check is the Arduino/sensor rate if it's enough for what I'm planning to do.

I'll probably have three steps in the main program:
1. Wait for three pulses
2. Take measurements
3. Calculate avg. compression and RPM and print to LCD

Step 1 would keep monitoring for the pressure to cross a certain threshold (maybe 2 bar) and after that look for three falling edges (and discard these).

Step 2 would run a timer and use interrupts to take measurements to fill the big array. From this step I would call a function that takes five measurements as fast as possible, and discards the highest and lowest one, and takes the average from the three middle ones. This function would be called every 5 ms. This should be enough to get a nice curve for each compression cycle.

Step 3 would then look for falling edges. I could maybe take the sum of three measurements and compare that to the sum of three measurements before those, and if the sum is higher, the falling edge is found. Any better ideas to look for these? The reason behind looking for falling edges is that I could then take the previous measurement before the edge and this would be the max point. These max points would be summed (every third one to a different variable), and taking the amount of edges found, I could calculate the average compression. As I know the time between each measurement is 5 ms, the RPM could be easily calculated.

From step 3 I would jump back to step 2 as long as edges are found.

Phoenix_

Do you guys know what is the max RPM during crancking? I was using 0.2 seconds per compression cycle as the worst case scenario (as this requires the fastest read rate).

This of course affects the length of step 2, as I need at least a couple of pulses per each rotor face to get any "average" compression.

The problem here is that if step 3 takes too long to finish, I would lose pulses and this would make keeping track of compression of different rotor faces really difficult. Maybe I should just keep taking readings all the time and sorting these to three different variables, and use, say, the last five pulses to take the average that would then be printed?

RIWWP

iTrader: (2)

The highest cranking RPM I've seen reported was something like 315rpm. That's at the e-shaft. Lowest of around 170rpm

1.3_LittersOfFurry

iTrader: (4)

329 crpms, new battery, new starter.

FF to 3:45.