Roman

I think MAF is the answer - if you can quantify the amount of air coming in then you can quantify the fuel, even if its not a traditional ratio I guess. But yeah god knows how you'd tell anything from a wideband. Maybe EGT would earn its keep here.

Yes the lean burn 7afe was right till mid 90s i think? One of them used a combustion pressure sensor in the block which is cool. Butttt not stratified so much as a homogenous lean mixture... which is why they ditched it because emissions were awful. Unlike stratified which is more like a pocket of rich mixture and extra air around the perimiter that i dont think contributes to combustion/emissions in the same way. Tuning stratified injection with just a lambda sensor sounds like a ball ache!

Steatified injection is one of the wizard magic things of direct injection? Not sure if thats possibly to rerofit even if wanted to. What kind of cross hatch will i need on the bore to sute PLA pistons?

So as per arduino thread I've been building a tuning box thingy where I can adjust some knobs to optimise fuel, ign timing, vvti, and injector timing (or whatever else) One thing I have been considering though is that I've currently got a goal AFR in the lean areas of around 15.2:1, I cant remember my rationale for this but it was probably because I was too chicken to run it leaner for starters, and this was as far as I migrated from 14.7:1 at low load before getting distracted by something else. So, I might try lean it out further from here. One issue that I have considered though, is that when you run a really lean goal AFR the burn speed slows down a lot so you need more ignition timing. So that's great, except for if you now get a momentary rich region for whatever reason you're now possibly into knock territory. So what I have been thinking is that I will set a goal AFR in a few key cells in the cruising region with a 14.7:1 (or maybe slightly richer) goal AFR and optimise the ignition timing. Then I will do the same again at a 16.2:1 goal AFR. This will need a lot more ignition timing. Then I will compare the differences to build an ignition trim overlay map that has AFR reading as one of the axes. So if the car ends up running richer, it pulls the timing back out towards whatever my 14.7:1 value was, so its always safely running the optimum torque from the engine. Will be interesting to see how much timing change the car wants over this span, I might push out the extremities a bit further and use 13.5 or something like that.

Thanks Ned that sounds fun. With some more persistence and masochism I got the bloody thing working last night though! So happy about that. Got the baud rate working at 200,000 as well. Hopefully this weekend or next week I'll have it working for its intended task. The refresh rate on the screen is great once it's going.

This screen has so far been one of the most infuriating fucken things I've done in a long time hahaha. Shitty things about it: 1. In the example programs it has the baud rate set to 200,000 yet it doesnt want to communicate at anything above 9600. Yes, that took fucken ages to figure out. 2. To update the code on the screen, you need to take out the micro SD from the back, put that into an SD card embigginer and plug it into the laptop. Then undo the fucking RIBBON CABLE to the screen and plug it into the USB adaptor to communicate to PC instead. Then compile the program, put SD card back in, and swap the worlds fiddliest god damn ribbon cable back over. To just fuck you off that little bit more, you cant upload any arduino code while the shield is on either. You have to take it off every time. When your code isnt writing to the screen for reasons unknown you can imagine how cumbersome this process gets. God damn I was ready to take a sledge hammer to this bloody thing today. Ocean swim calmed me down and I came back and figured out baud rate seems to be the issue after a few more hours of fucking around. It's one of the most user unfriendly processes I have experienced in a long time, i hope the end result will be worth all the swear words!

Almost have the housing finished. It was annoying having the take the shield off every time I wanted to communicate to PC with the arduino (they both use serial port) So bent some pins out of the way and ran some leads to one of the other serial ports for it. Should make it much easier as now I'll be able to use the serial monitor for checking code as it goes and it'll be much simpler to upload fixes to the code if needed. my GUI is still a work in progress, want to get a bit of an 80s digidash sort of vibe going on.

Oh yeah I've been hesitant to post a product link here until I've been fairly certain that it's not garbage, but seems decent enough so far. Using this arduino shield: http://www.4dsystems.com.au/product/4D_Arduino_Adaptor_Shield_II/ and then one of the Gen 4 HMI Display Modules, need the starter kit so you get the right cables etc http://www.4dsystems.com.au/products Keep in mind that although they sell stuff under "arduino kits" some of these use the older screens which are shittier. So better to buy the shield and screen seperately from the "Gen 4 HMI Display Modules" section to be sure you're getting the best... thing. Disclaimer: I've not actually managed to send any data from the Arduino to the screen successfully yet, so I'll edit this post if it turns out that one or both of the above end up being shitty.

Hey thanks for the tip, I'll keep that in mind! Initial impressions of the screen are that it's pretty sweet! could not be any easier to use, and the contrast rediculously good and viewing angles are great. It's just drag and drop everything, compile it, then plug into arduino. Then get the arduino to spit the values for the gauges etc to the screen via the shield. So worth the $$$ if it saves me many hours of ball ache trying to render basic items. It's funny though, its a bit ghetto when it compiles. All of the gauges etc, it draws the dial in every possible angle and saves this as an image, then when it needs to show that angle on the dial it obviously looks up that image to display it. It's passed every metric so far except for refresh rate, which I havent tested yet. But that's arguably the most important thing and the area where running a screen direct from arduino processing power is a let down. The only thing that's a pain so far, is that when you compile the program you have to do it via sd card reader, you cant plug the screen in and have it write to sd card. So I can see myself adding/removing the sd card on the back of the screen about a billion times over coming weeks. So there's no point in putting the screen in a nice housing until your design is rock solid. Will hopefully have some dials swishing around tonight.

Picking up my screen today, will post up some stuff when it arrives and let you know if its shit or not. I've been banging out some Arduino code for Canbus, it's been a bit of a mission. Most of the example code that I've found just tell you how to read a single incoming frame, or send a single outgoing frame - not deal with the complexities of trying to do this both at once, reading/writing multiple frames and how to filter them, how to structure it, and best way to convert the frames into data values etc etc. One thing which was a real facepalm moment when I figured out what was wrong. I was trying to use IF command to check for a particular can frame, and then do maths on the bytes to produce the data I wanted. But the data values were garbage as it would include all of the other frames for some reason. Eventually I figured out that "If canframe = 11" is wrong, and it should be "If canframe == 11" A single equals means that its just declaring the current can frame as 11, so it was turning them all into 11 even if it was canid 25 or whatever. D'oh! I only realised this once I had done troubleshooting on just about everything else and decided to look up the syntax for the "if" command. I've now got potentiometers writing to the ECU with a really awesome refresh rate and streaming the maximum amount of values from ECU back to arduino that the ECU can deal with. I still need to write some code to deal with some of the variables which are stored in only a single bit of a byte. (Basically on/off values for things) I've still got a bit to learn about writing to EEPROM / SD card too before I'm done with this. It's been a bit of a learning curve but feels like I'm nearly at the fun part where this all comes together. I'm glad I got this code mostly finished before the screen turned up, or I'd be distracted with fiddling with this instead of working out the tricky bits.

Altezza has the fpr inside the tank right by the pump. Unless youve got an especially good reason to go external its a million times less work to keep internal.

Great work on the graphs this makes me happy. Sweet economy too! Better than my Echo. Cant beat a light car. Does your FPR reference intake manifold pressure? If fpr is not not intake referenced the pressure difference between fuel rail and intake manifold increases with vaccum. So at a given pulsewidth you get more fuel than expected. Might account for your 10% perhaps. Maybe check what your fuel model in ECU thinks the fpr is doing.

If youve got big cams then high cr should be fine/needed? Do you know what dynamic CR is with that cam.

I bought an arduino mega kit to tinker with, has been a bit of fun. Then I bought a canbus shield, and after setting up some "send" frames in the ECU am receiving frames like this to the Arduino now: Get data from ID: 1 Data received: 12 73 69 0 37 0 0 0 So just need to work that back into what the data represents. And vice versa for using potentiometers etc to give a signal back to ECU. Goal is to have a little tuning box thingy to adjust cam timing and ign timing at part throttle. I ended up buying a display screen that has its own hardware/processing etc so all you are sending from the arduino is the values and it renders everything itself. Will be interesting to see if this makes any useful difference to framerate. But I'm understanding canbus and setting variables in the ardiuno code a bit better now.

That would actually be cool - Does MS2 have canbus? If so you could perhaps get them to sync together somewhat.

I wouldn't be too worried about injector angle to be honest, more important (in my opinion) for minimising tuning ball aches is that whatever you're spraying the injector onto is as hot as possible. (ie engine/coolant temp) What are your plans for operating the injectors? As in, how many injector drivers will you have available? If you're grouping the injectors into sets of 3 or 4 then you might get some weird issues at idle and similar. But since it's a V12 it wont be affected so much as a 4 cyl or whatever anyway so probably a moot point. TL;DR: I heartily approve of this project

Any reason heart set on a hall effect rather than a reluctor? Might give you some more options.

This is a rerun of an old test that I did. Going full throttle with different cam angles, to see which works best. But this time logged at 100hz and going from full range of intake cam advance from 0 degrees through to 55 and logging results with MAF sensor. The scale on the graph here is "Air per cylinder measured" so its effectively MAF reading divided by RPM. So its somewhat representative of the torque curve of the engine. It's pretty easy to see the results, which ever line is the highest up gives best airflow at that rpm. The colour scale down the side is degrees of cam advance. So a few slight changes to my VVTI settings it looks like there are some gains using about ~10 degrees advance up top rather than pulling back down to 4-5. And it wants as much advance as it can get at ~2000rpm. It's amazing to see what a compromise static cam timing is by comparison, even when only considering full throttle conditions. And using a MAF for this gives such amazingly clear resolution compared to trying to look for changes in oxy sensor readings.

Yep adding overlap at idle means it ruts like a car with big cams and you need lots of air and fuel to make it idle, and a higher idle speed. (1000+) It sounds cool but it's annoying to drive with and very noisy. So entirely contrary to my goals haha. Adjusting the injection timing was one of the best changes I made for reducing amount of fuel used at idle and improving idle stability.

Okay so are you just able to adjust this as a fixed number, or can you adjust based on rpm and load? One problem here is that you've only got two points of reference but there's a 3rd variable in the middle which is intake manifold temperature. Like you could have 20 deg IAT and 90deg ECT, and intake manifold is 25 degrees. So at low load/rpm you see a temperature gain of say 5 degrees or 10 degrees more than IAT. But then you could also have 20 deg IAT, 90 deg ECT and intake manifold is 45 degrees because you've been sitting in traffic / engine running a long time / etc. In this case even though your two data points are identical the temp increase could be 30 degrees (or whatever) So it's easy to chase your tail around. Although I guess it's fortunate that the areas mostly affected (low load/rpm) are very easy to trim effectively with wideband feedback in realtime.

My wideband responds super slowly at idle conditions, I think it's because it's quite far from the head and gas volume is so low in the pipe. Perhaps also because the tip of the sensor is just flush with the edge of the pipe rather than in the flow. (Which is how its supposed to be, but maybe not ideal for idle readings) So I dont really get anything reliable on heavily transient conditions. But you can also see affects of wall wetting stablising directly after transient conditions as well.

I live quite close to my neighbours, and my cars idle is very noisy - Especially when the car is cold. So for sake of not seeming like a jerk I've been wanting to make my car a bit quieter when coming in and out of the driveway. Based on some other time I've been looking to optimise ignition timing, I've found that when you dont have enough timing, the car is noisier - As more energy is going out the exhaust instead of pushing the piston down. Sooooo I tried advancing the timing at idle to about 20 degrees, (which makes rpm go up) and then pulling fuel out to 16:1 and closing throttle down to bring idle speed back down. Which gave a really nice stable idle at 700rpm which is awesome... And its really quiet too! Awesome. But now the next problem, which is that the car stalls a lot when idling this low. Like if you rev the engine up, and revs fall back down, its fine. But if you are driving along, clutch in, and coming to a stop the car will stall. Also when you try to first take off, the car will lurch and die sometimes. My first instinct here is to just raise the idle speed again, but I want best of both worlds damnit! So I found that I can have a 3D table for idle speed goal and throttle angle. So it says "If car is moving, idle higher" Now no stalling, and super stable low idle. Great success!

Alternatively you could consider upgrading to a Casio FX82

Plumbed in near the end of the 2-1 section, as this is where the standard narrowband sensor was positioned. I really just think the issue here might have been that the lines were too small and the pressure scale of the sensor too high. For the moment I've retired it, but will give it a rethink later on. Having the MAF back in is proving interesting enough so far.

Okay so after I finished building the MAF curve, and drove around to collect some data with it, and then I started building a fuel table using MAF as load axis. After plugging away at this for a while, I noticed something interesting - The fuel map becomes just a straight slope all the way across haha. So this is what my basemap looked like: And the car drove awesomely on it! After a few tweaks to the overall shape it's still pretty similar. Definitely a lot more linear than a MAP or TPS based tune. Which makes sense. With a MAF based tune you really do need some decel fuel cut, as when you shut the throttle the MAF value momentarily climbs and you get pops and bangs out the exhaust... Oh the humanity! In less awesome news though, this new gearbox seems stuffed. The synchros in 3rd seem non existent and I think I heard it break something when I hoofed it into 3rd today haha. So no OS drags for me in this car, and no trackdays this year either. sadface. WTB (non fucked) Altezza gearbox if anyone sees one for sale. EDIT: Also I ran over something with my AD08Rs on which put a big gash in one of my tyres as well. Blargh.