My FPGA/DSP/PC custom ECU worklog

[280Z28]

My other thread was mostly asking for criticism, so I'm making this one where I can just tell what I've done on it and not get so much criticism (hopefully)

 

This is just my worklog, so whenever I make progress (forward or reverse) I'll post about it here. I'll make some posts concerning things I faced in the past as well, for anyone who might be interested. I'll probably be working on this for a few years so expect to see some back from the grave going on from time to time.

[280Z28]

What led me to do this.

 

The project started when I decided to try and write a program to process my log files and program my Holley Commander 950 better than I could do by hand. I finally made that my senior design project (finishing up my BS EE degree).

 

The project was actually somewhat successful. The math involved was insane but I enjoyed it (and obsessed over it) because of where I wanted it to take me. I never got a clean process down for it though. Sections were just hacked together it order to get an answer (it spit out tables that I could type in to the Holley software). I'll go ahead and include a copy of my final report, but I'm not sure anyone wants to take the time to read that whole thing.

 

http://www.280z28.org/downloads/2005-05-05-EE464K-Final-Paper.pdf

 

After the semester ended, I worked on the project off and on for the next 6 months. I finally decided that IF I was going to ever get somewhere (really get somewhere), I would have to stop trying to work with the [quite limited] Holley system. And so began the search for a custom hardware solution.

 

Keep in mind that I am a programmer. I love to code, and I love making math work in code. I don't really like making the hardware as much because I didn't take as many classes in it and am not extremely comfortable in the idea that I could make an optimal solution.

 

I actually didn't take many classes in programming either, but I started with a Learn C++ in 21 Days and learn Game Programming with DirectX in 3rd or 4th grade (seriously...because I wanted to; no one else in my family is a programmer). I'm pretty comfortable in my skills with that at this point

[280Z28]

Trying to find hardware.

 

This was a while back, but I'm trying to keep this in order so this is going to be my placeholder if I remember my initial searches and their results. :hmm:

[280Z28]

Hardware attempt number 1.

 

The first hardware I purchased was one of each of these products:

 

NI USB-6008

NI USB-6009

NI USB-6501

 

Some of my thoughts when I was ordering:

 

1) Obviously things like throttle, MAP, MAT, Coolant Temp, O2 Voltage, fuel pressure, and others DON'T require sampling rates above 10KHz. I saved money by going with the 6008 for those inputs.

2) My particular interest in acoustics led me to get a 6009 as well with its 48KHz sampling rate that's more suited to acoustic sensors.

3) The 6501 was cheap and gave me more I/O for whatever I needed it for, so I ordered it at the same time so it would be there if I needed it.

 

Initial success

 

When the boards arrived, I went downstairs, grabbed the TB off the Z and brought it up to my desk. I installed the NI-DAQmx drivers and software for the boards and opened up the NI test panels. It took under 10 minutes to get the TB hooked up to the boards and reading the position voltage. That was easy, on to the next part.

 

Then I opened up Visual Studio to write my own copy of the functionality I needed. In literally 10 minutes I had the boards reading the throttle position accurately. I set the start and stop voltages (closed it all the way and set that to min, opened it and set the max). My readout for the position in % was smooth and flawless. Sam was a very happy camper at this point.

 

First problem

 

Unstable drivers. Half the time when I did an unclean shutdown of the software (hit Stop in the Visual Studio), the computer would end up blue screening... The drivers expected an explicit "I am shutting down the ports now" command or they freaked the F out.

 

Other problems

 

I'm not completely sure what order these happened in, but I know a lot of the actual problems and how I felt as I faced them.

 

#1 CRAPPY support for digital inputs. You'd expect at least 10KHz since "on or off" is so much easier than 12/14bit ADC inputs. No, try 500Hz MAX summed across all inputs you're reading (2 inputs = 250Hz each). This applies to ALL THREE boards I got, including the dedicated digital one. Seriously, what was I supposed to do with that?

 

#2 Misleading support for analog inputs. The board only hits 10KHz (or 48KHz for the 6009) if you set it to aquire/buffer multiple samples. You can't do a read/save/read/save style operation or you'll be down to under 1KHz. As is the case with all NI DAQ boards other than the S series, the 10KHz is a scanning rate, so the rate per input channel is limited to 10KHz / number of sampled channels.

 

#3 Crank position hopeless. It was obvious at this point that the crank position couldn't be sampled fast enough on the digital inputs to be worth anything at all. Ignition outputs and fuel injectors fell in the same category.

 

I spent a total of 2 months working with these products trying to figure out what I was doing wrong before determining (with confirmation from NI) that the boards were completely unsuited for my application. The NI return period is 30 days. Sam was a very sad camper at this point. :( One of the major problems they noted is the USB (and USB2) bus is inherently limited to a latency of around 1.5ms. Transfer rates are fast but the "ping time" so to say is way WAY too slow for a control application.

[280Z28]

Tool number 1

 

Fluke 88 V/A Automotive Multimeter. Bought it new off eBay for ~350.

 

There is not a single doubt in my mind that that was money WELL spent. It owns...

 

Pulse width, RPM, and duty cycle measurements are sure to come in handy. Of course I can say that now way after the fact.

[proxlamus©]

someone please explain to me.. what is FPGA ??

[280Z28]

Hardware attempt number 2

 

I finally decided that the NI PCIe-6259 was the board that was most likely to be suitable for my application. Variable VERY high speed rates for analog data acquisition, and timed digital acquisition up to something like 10MHz (wayy above what I require). I got an agreement from NI to return my previous boards for a refund if I ordered an M series board. That made things slightly easier for me.

 

More success

 

Analog inputs are more than adequate for my needs. Don't think that's in question. Digital outputs look good and the period detection provided rock solid engine speed measurements. The board latency is also much lower since it's directly connected via a very fast PCI Express bus. Once again, things are looking really good.

 

More problems

 

I had an VERY accurate measurement for engine speed, but engine position was baffling me. I tried several things (at least 3 completely different methods) without success, which was very dismal to me because I had to re-write the entire output algorithm to make the pretty major changes between an idea failing and coming up with another idea. That took at least a day, up to 2 weeks to come up with a new idea and write the code for it.

 

More success

 

I finally settled on placing 90 output samples in the digital out buffer of a channel. I used a start trigger from the crank wheel to trigger the output start. I needed to then set the output rate such that (based on the measured engine speed) 1 sample would be written every degree of rotation. Unfortunately I was using 1 of the 2 available counters for measuring the engine speed, and the other was outputting my simulated crank trigger pulses. The digital output bus needs a clock that can vary in rate, and those are the ones that can do it. After talking with NI again, they directed me to a document on using the analog output clock to trigger digital output samples. So I moved the constant rate crank trigger simulator to an analog line and freed up the 2nd counter for generating the variable rate pulses. I used the pulse width and RPM measurement features of the Fluke and verified that the output was exactly what I intended. This was definitely a viable solution for at least the fuel injection tasks. I still had to verify that the pulse was stopping at the correct angles though.

 

I finally decided that I could do a two-edge time measurement to measure the time between the spark output time and the next crank trigger. Given the position of the crank trigger and the fact that I had a verified speed measurement for the engine, I would be able to calculate the amount of actual advance from this time. In my time of being glad for such an idea, I forgot that I moved the simulated crank trigger to the analog bus and the counter output was now being used for a different required task. So I thought I could go get a frequency generator and hook up a square wave to the board to free up a counter (afterall, the crank trigger doesn't take board resources in a live application). The first time I went to Fry's, then ended up selling me a frequency counter by mistake (it was the same price as the generator and placed right below the display unit). Oops. The next day I picked up a frequency generator (it was the demo unit because they were out).

 

To my dismay when I got home, I realized that I had moved the simulated trigger to a different bus so I didn't free up a counter at all (stupid me). At this point, I came up with the idea of creating the simulated pulse as one like the ignition trigger, only it fell at the beginning of each 90 degree section. So that did free up a counter by moving my single degree pulse trigger to the analog output, and using that to drive the digital outputs. (The digital outputs on this board don't have an internal clock, but you can use the clock from another bus on the board or an external clock).

 

After setting up the two edge separation task, I found that my output samples were in fact timed correctly (the ignition timing advance was accurate).

 

More problems

 

The engine speed changes. Uh oh.

 

I needed a way to actively change the output frequency of the digital out task based on the engine speed to keep the outputs coming at one sample every degree of rotation. The normal function for setting the output frequency of the analog output bus stops the output task then restarts it, with a delay of about 0.5ms of having no output pulses... That kinda messed up my digital out timing... a lot.

 

After talking with NI yet again, I found another method of changing the analog output rate "live." Another glimpse of light!

 

I knew going into this implementation that I would run into timing "skew" problems. The analog output speed wouldn't be precisely lined up with the time when the engine changed speeds because it only updated when I got a crank pulse. My idea was to actively correct the 90 sample digital output buffer as a circular buffer, and adjust the start position to correct the error I was measuring via the two edge separation task. I spent a couple days coding this part with the hope that the updates could correct the measurement fast enough to keep up with engine speed changes. The first day was putting it directly in code to complete failure... the timing was way WAY off (spastic all over the place). It turned out I wasn't waiting for propagation delays between measuring a timing error, updating the output clock rate, and then waiting for a new timing error measurement after the new wait. So my timing errors were being multiply corrected for even more error. I found I had to place a delay of 125ms in the two edge separation task to stabilize the self updating loop.

 

On to testing the ability to correct timing as the engine speed changes. This time the frequency generator actually came in handy. I set up one of my "fancy digital computer gauges" to display the amount of measured error that was being corrected.

 

The good: the loop WAS updating the output correctly to keep the timing accurate at different engine speeds.

The bad: the amount of error corrected under a speed change of 300 rpm/sec (way slower than you actually face) was 5+ degrees of timing error, and it went up from there as the change rate increased. This meant that while the engine was changing speeds, the timing was monstrously inaccurate.

 

One of the NI application engineers suggested I look into adding an encoder to the crankshaft to measure the crank position, and use THAT output signal directly to drive the digital out task on the board with perfect precision. Theoretically, that would still work. I never tried it though due to:

 

1) It's expensive. $500++ for a precision optical encoder like I would need for the job.

2) I had no way of mounting it.

3) Encoders don't like being exposed to "the elements". I think I could place the encoder inside a modified distributor since I won't be using the distributor with my direct fire ignition system (8 individual coils from the late model GM engines). Unfortunately that won't be an option with the LS1 I'm getting in a few months. They don't have a distributor.

 

So at this point I'm out a cost of around $2000 for the NI hardware plus a HUGE amount of time spent and I have nothing. Giving up is tempting, but it's not what I want and IMO this project WILL be a success even if it takes me 10 years to finish. (Pete ) But now I'm going to need new hardware (again).

[280Z28]

Hardware attempt number 3

 

The big momma of the National Instruments R series (Reconfigurable I/O) - the NI PCI-7833R. This thing has it all - almost. It has a limited amount of analog inputs on it, but the ones it has are fast, accurate, and don't slow down when more than one channel is being read. You can even read each channel at different rates without a hiccup. The main feature is a 3 million gate FPGA core. (Field programmable gate array for those that don't know). The way it works is my special program loads onto the chip and becomes actually part of the hardware. I'm not running intructions in a processor. This IS the processor, and it's capable of rock solid reliable timing resolutions down to 25ns. FPGA programs aren't affected by multiple things going on at once either. I can set up each spark plug and each injector to be its own operation and they all maintain the 25ns precision.

 

Over the past week, I spent time actually writing large sections of the program I'll eventually use. I needed to make darn well sure that I wasn't going to run out of space on the FPGA. At $4200, I can't afford another. I don't want to afford the first one, but like I said, I will finish this project, and [someday] it will be the best.

 

The NI hardware is WAY more expensive than a lot of other boards, but it offers a rapid development environment, easy (native support) and extremely fast communication with the host computer. When I get ready to bring a product to market I can worry about putting the FPGA on a cheap board with its own suitable DSP for much lower cost. The NI support services are the best I've ever dealt with. Plus they're Austin based.

 

Anyway, I finally finished verifying yesterday that the code will fit with room to spare on the FPGA (fits on the 3M gates board using 41% right now and almost done without spending too much time on optimization). Since lots of my processing will involve both my M series board and my host computer (for the AI software that I'm specializing in in school), I am confident that will meet my needs at the expense of only my pocketbook (or VISA card ). I ordered it this morning.

 

I hope to have the code ready to start testing by the time it gets here in an estimated 15 days.

[Jolane]

Sam, a couple comments that I hope you don't mind in this thread.

 

First, it seems that you really need a digital scope for this project. I used mine to measure the crankshaft speed directly from crankshaft sensor while the engine was running. I did this while the engine was running stock, so my system wasn't controlling it. This helped verify that my measurements were good enough. The crankshaft sensor I was using, along with a 4 position trigger wheel, provided excellent positional repeatability. I then had to find the accuracy and introduce an offset bias to correct for any machining errors (not a big deal). My uController had no problem keeping up with the input.

 

Have you looked at or modeled the scheme for controlling the coils? This is a big deal on a V8 compared to a single cylinder. I provided my scheme in my paper. It was harder than I had expected though. You have to provide enough time for the coil to charge, and also advance the firing when the RPM goes up. This becomes more difficult as the RPM increases. I was using a waste-fire scheme, so I only had to control 4 coils. With 8 coils, the problem will be worse because you will want to charge 2 or more coils at the same time. I would recommend modeling this if you haven't already, and understand this better.

 

The beauty of an engine is that it doesn't require the absolute best in timing accuracy, cinluding EFI. The system is actually rather slow compared to many other systems in the world. Building a great control system shouldn't be too difficult. The EFI should be the easy part because it doesn't require accurate timing at all (when I say accurate, I am talking nS). You probably would never see the difference in engine performance if your timing was off by even 1/2 a degree. Besides, the more precise the system, the better it must be tuned and calibrated, otherwise it is just extra information going to waste. In effect, ask yourself what you going to do with it, and why is it important?

 

Does NI offer a student discount? It seems like you are set on using an NI board. I would strongly suggest looking at a uController, perhaps in parallel. They are used for applications like this daily.

 

I am not trying to be a critic at all. I am very interested in your project actually. Please keep the updates coming. Hopefully this post doesn't come off differently. One thing engineers need to learn is what is good enough? Anything more usually costs more time, money, reliability, support, etc... Figure out the problem, what it requires, then solve it.

 

Good Luck,

Joshua

 

EDIT: I meant to add that these sorts of project are VERY time consuming. They also eat a lot of money. My project ended up costing me ~$5K+ including a scope and a few iterations of the hardware. This was for the ignition only, and didn't include donated parts/materials/etc...

[280Z28]

The NI boards I have now should work great as scopes. I used them to make sure the outputs from my frequency gen were proper square waves.

 

One thing that's nice is when I have the R series running in simulation mode (frequency generator for crank), I can watch all 16 outputs (ignition and fuel) at the same time as well as another for the frequency generator. Combined with the fluke that gives instance frequency/period measurements, it'll be easy to see how everything lines up in time. The M series board can do 32 digital channel synchronous sampling at over 1MHz, so it should be great for seeing everything.

 

My student discount is 10% off hardware, free software.

 

Regarding the timing: I wasn't really looking for that level of precision. But with the R series, I do have it so it's available if I find a way to make use of it.

 

I have already verified that the coil charge time is precise (exactly matches however many msec I tell it to) and the drop is at the right time.

 

For a microcontroller, right now I have my computer. Although once it's programmed, I haven't thought of any critical tasks yet that the FPGA couldn't handle by itself.

[280Z28]

I used my M series board to log the output of the R series board with a frequency generator simulating the crank pulses. After some debugging, I finally got the output I was looking for:

 

[randy 77zt]

20+ years ago i got an as (2 year) degree in electronics but didnt stay with it because i wasnt big on writing software.went into auto repair because thats how i paid my way through college and i always had work.i would say you need a good full size lab scope for this project .the fluke is a very good field test instrument but its easier with a big picture.if you need any ideas on oem junk yard sensors pm me.on my ms install i used a cherry industrial hall effect sensor and magnets in my flywheel.good luck and keep trying.

[280Z28]

20+ years ago i got an as (2 year) degree in electronics but didnt stay with it because i wasnt big on writing software.went into auto repair because thats how i paid my way through college and i always had work.i would say you need a good full size lab scope for this project .the fluke is a very good field test instrument but its easier with a big picture.if you need any ideas on oem junk yard sensors pm me.on my ms install i used a cherry industrial hall effect sensor and magnets in my flywheel.good luck and keep trying.

 

The plot one post up is from my scope

[280Z28]

I think I figured out what driver circuits I'm going to use for my injectors and coils.

 

For the injectors, I'll use the typical application here:

 

http://www.national.com/ds/LM/LM1949.pdf

 

For the coils, I'm using the GM LS1 coil packs so the driver is built in. I'm checking here about whether or not I can just use this simple circuit to drive it:

 

[Jolane]

I used a chip (hex driver?) to isolate my processor I/O from the driver chips. This also allowed me to "step-up" the signal voltage from 3.3V (uP) to the 5V required for the coil driver. I assume that the driver in the LS1 coils requires a TTL level input, which I believe is spec'd at higher than 3.3V. The interface chip I used was very inexpensive and easy to use. The opto-isolator was also serendipitous in that I needed to invert my signals during start-up to avoid firing all the coils initially (uP initialized with all pins high state).

 

Joshua

[280Z28]

WoW! Classes are hardcore this semester. Project is making "slow progress." I haven't done much work on it directly but my classes are strongly related to where I want to take this thing. Should be interesting to see the progress I make on it ~christmas break ~next summer.

[280Z28]

I've gone with a 90mm electronic throttle body so I'll have nice smooth control over throttle response and easy cruise control. I'm also going to find a way to get a couple sets of these:

 

Fiber optic in-cylinder pressure measurement plugs :yum:

[Tony D]

Wow those plugs make hooking up the kenescope easy!

On large industrial engines, there are kenetic taps on the head for reading actual BMEP Trace on the scope, and we had specialty plugs to hook up the the smaller (er, that is a relative term) engine without the taps for the peizo pressure sensors used on the larger units.

 

That plug would be very very interesting, taking a screen shot would make calculating BMEP and watching for detonation a piece of pie. You could read detonation clear as day with a sensor on that plug---for dyno tuning or realtime correction of mixture and spark advance it would RULE!

 

omigod! I've been pulled into the project intellectually. You bastard!

 

[280Z28]

Wow those plugs make hooking up the kenescope easy!

On large industrial engines, there are kenetic taps on the head for reading actual BMEP Trace on the scope, and we had specialty plugs to hook up the the smaller (er, that is a relative term) engine without the taps for the peizo pressure sensors used on the larger units.

 

That plug would be very very interesting, taking a screen shot would make calculating BMEP and watching for detonation a piece of pie. You could read detonation clear as day with a sensor on that plug---for dyno tuning or realtime correction of mixture and spark advance it would RULE!

 

omigod! I've been pulled into the project intellectually. You bastard!

 

 

The other sensors have been great in many applications, but one of the goals of my project is to be as non-intrusive as possible into the actual mechanics. When I saw these plugs are available I was like :woot: :drool:

 

On my car they'll be part of the live system. This summer I plan to use them for tuning peoples' cars in the Austin area. I have enough extra analog channels in the stuff going in my Z to sample the plugs for all 8 cylinders at 44.1kHz for semi-real-time processing (real time is responses from 0.05-100us, where these will provide control feedback on probably a 0.25s scale). By next summer, Intel's quad-core procs will be shipping (Core2Quad?), so I'll probably pick one of those up for extra analysis ability until I learn enough from the system to narrow down and optimize the algorithms.

 

Next summer the hardcore focus is gas mileage and drivability. I want 30mpg and (relatively) smooth driving from this thing...

[280Z28]

Holy hell those spark plugs are expensive...

 

$1200-1500 (each) to modify a self-provided plug. :faint: