Roman

Oh snap! That sounds awesome. As I'd been considering making next project on a Rasberry Pi instead. But that sounds ideal as I can use my existing shields. I thought the Arduino Mega was the big boss.

I just found a cool piece of code for optimising how long your loop takes. unsigned long start_time = 0; unsigned long end_time = 0; void loop() { start_time = micros(); (code goes here in the middle) end_time = micros(); Serial.println(end_time - start_time); } So whatever is inbetween start_time and end_time it will tell you how many microseconds it runs for. Currently my loop when not going through any of the IF commands because canbus isnt connected. Takes 13,000 microseconds so full loop run time is about 75hz. So there's no point trying to log anything at 200hz or send canbus commands at 200hz. Good to know! Will be interesting to see how/if that drops when the code is tidied up. Also you could partition this out to smaller segments of code to see how long each of them take. After all, what use is an economy based tool that doesnt have economical code EDIT: With some liberal application of IF commands, got it running at over 150hz now. woot

For version 2.0 I will switch the pots for rotary encoders and then have some arrays that work as load vs rpm tables in the arduino. So when I turn the dial it only affects the rpm/load area that you are currently in, rather than changes across everything. And once I have my cam angle / inj timing / goal AFR sorted I think I will try an automated ignition trim method that floats the timing by a few degrees either way and see what gives the best economy value. And then hone in by a smaller margin for a few iterations. I think this might help cover situations like where air temp etc vary away from the conditions in which you initially optimized the ignition timing. So might be a good way to either setup a 4d ignition table orrrr just leave it running all of the time when the car is in cruise conditions. Maybe when cruise control is turned on. It's pretty sweet to be able to add some experimental functions to the ECU this way!

Woops have been lazy. But did a bit more on this today. Had some garbage values coming through so thought I'd better have a single place to check them all: Found a few problems in the code or arrangement of canbus frames and now most things are working. So now I can try make some more useful screens and know the values are as expected. Still need to get all of the pots working but my soldering sucks on things that small and fiddly. Bah. But you can see when each of the values updates and the refresh rate is reasonable, that's with canbus running at 500kbps, can go up to 1000kbps so might try that too. But it might not be the canbus itself that is the bottleneck to values refreshing. My code can definitely be optimized a bit by putting more of the tasks into the "if" structures I have in place but for starters its been good to just group all of the commands together and run them all through each loop, just for sake of easy troubleshooting. (Like when you copy pasted a piece of code 20 times and forgot the ; each time)

Ugh yeah i pulled hilux engine out when i was down at HPA, not sure if it was a 1kd? Cant remember. Was running a prototype diesel ECU from motec. With too much boost towing the race car back to HQ from highlands it split a piston. The oil coming tgrough the split kept combusting and nanged the engine at max revs haha. Intake looked amazingly disgusting.

Yeah thats why some Toyota DI engines still have an injector in the port as well. Ive seen some gdi engines that blew my mind with how fucked they looked!

Interesting! I've seen that electric VVTI on the 1UR (?) V8. Oh yeah so that leads me to another thought. People say that you can reduce pumping losses (and so improve economy) by reducing vaccum amount. But, you also have compression losses as well. If you have more vaccum, you have less air to compress when the piston comes back up. I wonder what the balance is here? Looking at BSFC maps it seems like you can very quickly move up a few isobars by staying away from that very low load area. But then very diminishing gains towards that 80%ish throttle peak. But also, by changing AFR or cam timing etc you are changing the shape of the BSFC map as you go. Hmm.

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.