I posted some pics of this in another thread and dont want to take over so I thought it is easier to post something here. Im not trying to sell anything, and at the moment nobody else has used it, but people might find it interesting.

Basically what I have done is made a little setup that will generate dyno graphs from input I read from the diagnostic port. The ideas I have used are not new, at the time I just couldn’t justify spending the $100 odd bucks others are asking for similar setups when these things sound so damm crazy. They work by recording information about the cars acceleration using tape recorders using hacked up timing lights for microphones. You later put these recordings into your computer and it gives you a dyno graph. As crazy as they sounds, the idea behind them is good though. You measure the rate of acceleration of a know mass (your cars weight) and work backwards to find out how much power is needed to do the same work. The power figure they are actually putting out is not how much power the engine puts out, but how much work was done to accelerate your ~1500kg hunk of steel from Xkph to Ykph in a certain time. If you know how much work was done, and your engine is the only thing doing it, then that’s how much power your engine has.

I did a few recordings and myself used Excel to do the calculations and got some graphs that looked amazingly similar to the dynos I was getting at the time. So I wrote a C++ app and made a little board to read data directly from the diagnostic board of e-series falcons into a laptop (very simple board).

Comparing what this software was putting out to my dyno’s at that time –





I did a fair bit of work with it and found it to be very accurate considering what it was. Doing back to back runs the results were never more than 2-3kw different at any point in the graph. I did some more work on the software so that I could graph a couple of runs at the same time and play around with settings. I stopped working on it about 6 months ago when I installed the MS2. After the install I was getting a lot of interference though the diagnostic port and it was really hard to get a run that worked (which was a real disappointment because I wanted to use it to help me tune the ECU). This is one of the early MS2 runs that did work.



Because of the way it works there are a few problems with it -

No atmospheric condition correction. I got hold of the formula dyno dynamics use for atmospheric conditions (so that dynos on hot days are comparable to dynos on cold days) but since I have now way of measuring barometric pressure, temperature and humidity i didnt bother coding it in.

Wheel spin kills it. If the wheels spin, or the clutch slips, the data is useless. This isnt reall a problem though as you would just pick a gear that you cant spin the wheels in for the run (for me thats 2nd).

Air resistance robs power. Get kind of complicated if you want to correct for air resistance so I dont bother. Since it is a constant, it doesnt really make any difference to me because I am more interested about how the graph changes after mods instead of doing dyno comps.

Wind is an issue, but can be worked around easy enough.

You need a REALLY precise RPM to do this. When I had trouble with the MS2 I just wrote a bit of extra code to use the MS2's datalogs to do the graphs but it is nowhere near accurate enough. You need an RPM source that will give you heaps of decimal places with no rounding for a good graph.

So there it is. In my opinion these sort of setups can be useful (as long as you dont take the results to seriously). There is a generic commercial product using this theory at http://www.charm.net/~mchaney/homedyno/homedyno.htm but it seems a bit old and clunky to me. If anybody has one or any experience with them let me know. It has to at least be as good as a gtech.

I'm looking at reading from the OBD II port to my car-puter for diagnostics / dyno etc.

How did you interface between the OBD port to your laptop??

Thanks,
Panda

Not in a way that will help you unfortunately - its just a voltage divider between the port and the laptops line-in. Works well for high frequency rpm pulses.

so you mean basically a DIY version of G-tech?

Yes - if gtechs used engine rpm instead of cheap accelerometers and gave you dyno graphs instead of a HP number

Love the idea of it and the work you've done so far is impressive, but I think it may be fairly difficult to get going in the real world. Half the idea of this is you don't need a equipment like a dyno, but you'd need something which can precisely pick up your engine's rpm - more equipment there. As far as I'm aware, only BA's onwards had an OBD port as well - does that mean they would be more difficult or easier to read data from then the E-series?

Also, when you say you got interference through the diagnostic port what exactly do you mean by that? Very good work though, nonetheless.

Significantly easier. I would think that Mark has used the tach output on the E-series diagnostic port?? Would be no different to hooking up an aftermarket tacho, except he's gone the extra mile and addressed some of the noise/interference issues.

I'm glad to see a seperate thread started for this mark, didnt get the credit it deserved in amoungst the ongoing dyno accuracy debate!

I'm assuming it could also time 400m runs - altho the limitations of wheelspin you have described could be an issue.

Definately one of the coolest 'gizmos' i've seen here on fordmods.

I know Im gonna sound like a party pooper, but the later Gtechs do a graph, and they do pick up RPM. (The use the noise from the alternator Im pretty sure).


But good work stock standard...

Also a thought, you're running an MS2, you could build that code into it, to spit out a power reading at any one point, and get MT to log it.
RPM is pretty good, and also barometric correction can be used aswell.

Just a thought.


Good work!

Yeah its easier on e-series because you just get the tacho pulses and do the rest in software.



I think its just the way i wired the coil up, but I didnt look into it so I cant be sure. If you look at the pulses coming out of the port they are nice and clean (easy to process). After the MS2 install, the pulses are messy, some dont even reach 1/2 the peak the used to and new pulses are appearing. Basically its just a very dirty signal now. The software has a hard time working out the rpm because the pulses are not a regular shape. I played around with all sorts of filters and tried to interpolate missing pulses but I had to tweak the software so much in the end i couldnt be bothered.



Yeah ive seen those, but not sure what they are like for accuracy. The new gtechs also have more accelerometers which should be them a lot better than the old ones. I would like to try one against my little hack to see how close I got to a commercial product (or how close they got to me ).



Yeah. I always though it would be cool to do something like that. I was thinking about integrating the MS2 with the trip computer (Think you said you were going to do this which would be cool ) and adding an extra mode for it to display engine power. Im just to busy to work on it though (must.... finish.... thesis....).

Yes, and this is something I have been thinking about and might try. I would log the VSS instead of tacho. Wheelspin is a problem, but you can work around it in software. When you graph the output of the sensor, wheelspin looks like a big spike. You can work out where the car got traction again and then interpolate values back to 0. Not perfect, and the more wheelspin you get the more innaccuracy you introduce, but it will work.

Would be nice little addition, give it a flog and you get a timeslip.

Another way to do it would be to log one of the front ABS sensors. Then you only have to worry about lifting the front wheels of the ground (I can always weld up some wheelie bars if that becomes a problem). Only thing is My POV pack doesnt have ABS.

If you ever need a gtech to play around with (old one), just sing out. I still need to solder a new cigarette lighter plug on but apart from that, works fine.

I've got a GTech Pro RR, it has all the new wiz bang features - 3 accelerometers, RPM pickup from the cig lighter, which doesn't work to well, maybe because I'm running a multi spark ignition.


The software gives you loads more too. But that's just a quick shot. Pulling 16s with a busted BTR auto in the boot.

Thats really cool. Same sort of thing as what I was planning on doing.

Its just the accelerometers that put me off the gtechs. We do a lot of stuff with accelerometers at work and found we have to spend over $2000 to get ones with acceptable accuracy so I am a bit sceptical when they market these for a couple of hundred.

I also dont like them because mine tells me my car is only good for a 15.5, yet my younger brothers R33 will pull low 14's and Grants XR8 is good for low 12's.

What's your's actually run then? (and the same for the skyrine and XR8)

Ran a 14.8 first time out, so about .7s off the average time I got with the gtech and .5 off my fastest. The skyline and the xr8 havent been run but sound about right. The other thing I found with the pro is that there is considerable inconsistancy in the results. I would get anywhere from 15.4's to 17's over 10 or so passes. Just reading about the gtech pro rr's, definately a big step forward over the pro's. It was interesting reading on their site:



Which is pretty much exactly what I found when trying to use the serial output of the MS2 - Just a couple of rounded rpm values being outputted every second and the graphs come out looking like crap.

Using the tacho and laptop I record a few 100,000 samples, which I use to calculate a table of each rpm and the time it took to get there. This tells me how long it takes to get from Xrpm to Yrpm to a 0.00002 second resolution. After playing around with it all though, I can say the number of samples doesnt have a big impact on the quality of the graph, but the resolution does. The raw arrays I calculate usually have 4000-4500 rpm/time values, but I subsample this to 50 before I do the power calculations because any more just wastes processing time and doesnt contribute to the graph. Any rounding of the values in the array results in a massive difference in the graph though.

So I have to disagree with the gtech website about sample rate being such an important factor. From what I have worked out, it doesnt really matter if the sample frequency is 5Hz or 4kHz, its the accuracy of the reading that determines the choppyness of the graph. What they are saying as far as OBD2 not being suitable is still right though.