280Z28

I just looked at the graph (had a pic on the cell phone) and it's obvious I wrote down the wrong numbers for the exhaust. I'll get the right ones asap, sorry.

Doh lol. I hear the exhaust flow balances out with a wide duration split cam (like 15 degrees). Allows you to run a smaller intake duration which keeps the motor from getting too "grumpy." :dunno: The exhaust will improve a bit but those valves are such different sizes...

The heads are GM L92 heads with 2.16" intake and 1.59" exhaust valves. These are baseline numbers. Numbers after some work still to come. :wall: Test was done on a SuperFlow SF600 FlowBench using the same bore I'll be running in the car (4.125). Lift Int Exh 0.100 72 55 0.200 155 115 0.300 221 115 0.350 246 122 0.400 266 124 0.450 284 125 0.500 298 126 0.550 310 127 0.600 321 128

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.

I'm in Far West. I saw you at Chili's actually back in... like April or something? I didn't get to talk though; people were crowded around so I was just looking. I had my TA with me that night. My car's not out too often so you'll probably stay the only known V8Z in Austin.

Just got word from my builder that these just flowed 322@.600 out-of-the-box with stock GM valves. I'll have flow sheets later

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:

The plot one post up is from my scope

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:

Didn't 2000+ LS1s have a revised oil pump? Either way, this is the one I'd be taking care of for sure. Rod bolts aren't necessary unless he has a big cam. Edit: Obviously I mean aftermarket rod bolts

I have an 88 LSD (not from the special edition) plus CV shafts already turned for the early Z's plus all the install hardware (modern motorsports) plus regular and finned covers that might be going up for sale in a few months... I'm not sure it'll handle the power I'm pushing and I'd rather sell it than break it.

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.

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.

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).

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.

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.

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:

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

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.

Here's one example of a more advanced feature I'm researching: Current idle control systems often use a PD controller on the spark and a PID controller on the IAC valve. This provides rather mediocre control over big cams. I'm investigating a system that works somewhat like follows: 1. Monitor the value and first and second derivatives of the speed at 45* past TDC for each cylinder. That's 8 cylinders x 3 data points per cylinder, IE wayy too much to handle for an embedded system (an FPGA could do it but it'd take an unreasonable amount of gates). 2. Calculate the first principle component of the inputs affecting the desired speed with first and second derivatives 0 for each for of the 8 cylinders. 3. Optimize a single in, single out function for controlling spark on a cylinder-by-cylinder basis. The input is a linear combination of the measured inputs. The output would be trained in a special neural net (a simple one too...) and/or genetic algorithm. A lookup table can then be generated and put in the ram attached to the FPGA and applied rapidly by the output controller. 4. The function continuously trains with a low learning coefficient to keep it running optimally in various weather conditions, etc. The IAC valve will end up as a boring old controller because they work fine. The spark has a more immediate effect on the "jitter" you feel from a big cam motor though.

I don't have my R series yet so I can't test it, but this should work, at least in a form very similar to this. Note that the loop across the top of the first image is a single cycle timed loop. The loop runs a complete pass on the whole thing in 1 clock cycle at 40MHz. A complete fuel and spark update together will take around 10 clock cycles because each of the memory reads (sunglasses) takes a cycle, plus there are 2 parallel multiplies at 1 cycle for both (parallel), plus one clock cycle to run through the rest of the output, literally :faint: This thing is "only 40MHz" but the logic circuits run as fast or faster than a P4 3.0GHz in series and parallel paths run independently so it's like you have as many CPU cores as you want/can fit on the chip. At $17 for a Spartan core (for a release version; my dev kit is crazy expensive), I am REALLY digging this system Angle detection: http://www.280z28.org/images/z/ecu/engine_speed_angle_detect_1.png Handling updates to angle changes: http://www.280z28.org/images/z/ecu/fuel_spark_1.png Side note: 30" Dell =

Sweet I really never would have guessed how many people work with these things. I redesigned what I did above to fit all on one VI instead of calling all the sub-VIs. Now I can optimize the thing better and can use the sychronization and memory functions to control timing precisely. My injectors and coils are now updated every time the crank position engine detects movement (interpolated, degrees * 100). Fuel pump and cooling fans took up 747 out of 14336 SLICEs (logic blocks on the board). Adding an adjustable injector driver capable of bank, TBI, or sequential injection for any number 1-16 cylinders (easier than it sounds like) bumped that to 1125 used (not quite done here, need to do some boolean logic on the final output but that's minimal resources). I'm guessing there's some decent fixed overhead The injection block/loop is wayy more complicated.

Alright I know I made this thread asking for criticism of the FPGAs, and I definitely got that On a slightly different note, can you think of any reason why I'll be SOL trying to make a controller if I'm using an FPGA like I'm talking about in this thread?