Awesome news.. things keep getting better and better for us XD.

 

Awesome job! thanks to all you guys that work so hard (for free) so we can play

 

once again thank you. an outstanding effort and even more outstanding generosity for sharing your fruits with everybody in the community. I hope karma rewards you guys well.

 

I did show a map switch routine previously - switches the octane number from 0 to 100 and back again. All you need to do is disable the usual octane increment/decrement numbers. There is space to store a few maps in the 9, possibly two in the 8 - what would be the most important maps people would want to have two sets of?

There is of course space in the ROM for further maps as well.

 

Me personally, all I would really like is real time tuning, as far as switching maps on the fly, I would just turn my car off and load a new map lol, but that is just me.

 

I suppose the absolute essentials for live RAM tuning are:

Hi oct fuel
Hi oct ign

If you don't use a boost controller just one copy of the following two in RAM that all the tables point to:
Boost desired engine load
Max WG duty

I think the rest should be set in the ROM at least initially - eg VVT, idle, boost control load offset, RPM limits, injector size, MAF calibrations, etc etc.

Keep it simple, then we have enough space to do this on the Evo 7 and 8 which have less RAM than the 9.

 

Having the Mivec table in RAM would make tuning mivec via fixed loading on a mustang/DD dyno great.

Same with the IGN tables.

By the way, did I mention you rock?

 

John do you think there is a possibility of using a potientiometer to switch maps in the future or just by sending a custom request as you outlined previously?

 

There is already code to switch maps with a pot - I think it uses the rear O2 sensor input. Just disable the inc/dec of octane value (change two bytes in ROM). See aktivematrix.

Bryan, I could put VVT in RAM too since the IX has spare RAM.

I would probably just put high octane #2 into RAM and put the pointers for all 3 or 4 (depending on model) high octane maps to the same. On the FQ360 they are all the same anyway except number 3 which we think is fault triggered, and that is only -1 compared with the others. Same with the between 3 or 4 boost desired engine load and the 3 to 7 max wastegate tables.

I just think we have to place some careful limits to stop the project growing arms and legs, but I will add VVT as you request

 

Totally agree, I do really think Real-time tuning of VVT/Mivec would be great though. Holding a RPM/Load via dyno load and moving the Mivec up and down would be awesome.

Nice job. Let me know when I can get you a couple rounds.

 

Awesome work!

I'm watching this thread with great interest!

 

As other have said, thank you.

I wanted to say that having a WG duty cycle would make it much easier to tune with a 3-port bcs. This is something that I miss from the Subaru ecu where I could log it during a pull.

 

I've tried to find WG duty before, but will have another look to get it logging.

 

JCS, does this also mean if you were to run LogWorks with a RAM computer it wont be so blocky,?more precise visual display

 

It isn't the RAM mapping that would reduce the blockiness but the resolution of the logged data.

MUT protocol is fast, but only 1 byte. Speed and RPM in particular are very blocky. If you output 2 byte speed and 2 byte RPM it should be a lot nicer.

I can modify a range of request IDs to output 2 byte and leave the rest as 1 byte to keep compatibility, but the loggers aren't ready yet to do high speed and fault free logging of a mixture of 1 and 2 byte replies but Jack and Hamish are working on their loggers.

I could also quite quickly implement a high speed stream of 8 x 2 byte items that are logged from a single request ID - all simultaneously. Perhaps RPM, load, speed, MAP, airflow, knock, octane, O2?