CamB

Thanks @Adamw and @Ducie54. I actually think I'm fairly happy - I know my test wasn't perfect and its not ideal that the flow might be different, but that is the flow I experienced... My key goal was getting a deadtime for the injectors with resistors and confirming they sprayed nicely when driven like that.
So this topic has any relevance, I've attached a spreadsheet if anyone is interested. It has a blank worksheet and one I filled in (and modified) for the 803 injectors, plus the Motec data I compared it against.
Injector test spreadsheet - Link forum.xlsx

My arduino based canbus box thingy has escalated into a digidash haha. 

So 3d printing a housing that will mount up to standard points and accept the standard loom plugs for power supply and so on. 

Lots of work left to do, but will be cool.


 

I've had a bit of a side project going on, I've wanted to learn about canbus so I bought an arduino and a canbus shield. 
Using some of the examples of code found on the net, managed to get frames both sending and recieving. I've never coded anything before so I had a few blunders like using = where I needed == and so on haha.

I'm using another shield on top of the canbus one that runs a screen, and have put together a box for it all.

The goal is to have the 4 pots control trim tables for goal AFR, ign timing, cam timing, and injector timing. So when I have cruise control turned on, I can quickly go through a lot of variations and have a graph showing fuel economy on the screen. 

I can also write a fuel economy value back to the ECU as well, and then have that log into the ECU's logs so that's cool.

Currently my car gets around the mid 7 litres per 100km mark, and I'd like to see if I can drop it into the sixes.

I'm most of the way there to finishing this thing so hopefully not too long till I can have a play around. 

I am thinking that for version 2.0 instead of pots I will have rotary encoders and then build an array which will act like a load vs rpm based trim table for each of the different areas. 
So it will hold the values in that area without affecting the others. It's a bit more complicated though so I'll just get this running as is for now.

Since I run 98 octane and MBT is quite far away from knocking I have also been thinking about using a feedback loop where the arduino adds a few degrees timing, see if this positively or negatively impacts economy, and then either reverts or keeps change. Then repeats, and maybe hones in by a smaller change each time. But I think that might work best once I've got some arrays setup, rather than just blanket applying a trim table to everything.



 

@CamB you can set the byte order to MS first or LS first to swap the order when setting up incoming frames 
(In G4+ at least)

From my messing around with it, all the raw data in the Generic stream is the second parameter + 256 * the first parameter (in the pair). Interestingly when you set a custom stream the order is reversed... 
Is there a reason not to just use the standard convention? (I guess efficient coding?)

I asked over at another forum where you asked this, but this is probably a better place... does the change in backpressure have any relativity to the change in cam timing?

I wouldnt jump to that conclusion.  If you want to diagnose a fuel mixture problem then you will need a lambda connected.  Without that we are shooting in the dark.  It might be more obvious to you as you can hear and see the engine running, but a log without that feedback is not very helpful.
 
The S54 Ethrottle has 6 ITB's (return spring on each), the linkage is very non-linear at the initial opening and Engine vacuum seems to have a large effect on them (I suspect the butterfly shaft isnt centered so vacuum pulls them closed, maybe a safety feature?)  It takes a lot of grunt to get open when there is high manifold vacuum.  Our E-throttle hardware is a bit borderline for driving these and some guys have trouble even after removing some springs.
 
This is normally the amount of throttle that the closed loop system is trimming the "E-throttle 1 target" to maintain the idle RPM target.  In this log however it appears Idle speed control is not even working - the idle status shows "speed not selected", which usually means a speed lockout is set up but there is no speed source.  I dont know if he has changed the map after the log was taken or whether there is something odd going on.

yeah i recon this will work. dual boost tables, first one has gear vs rpm as axis with the required boost curves and max boost for each gear, second one has analog input vs rpm as axis with the min and max boost setup for 0 and 5volts.
the selection of the boost map is chosen with virtual aux which will become active if gear > 3. 
 
like so
 

very early draft
 
http://paulr33.com/evo/vipec_can/
 

I still havent had time to do this justice but I did take a look at a few logs where BAP varied greatly through the run and measured lambda stays near target over large elevation changes.  So for now although I cant argue that there isnt possibly a better option out there for fuel table load axis I can say the present system seems to do the job well even in far more extreme environmental variations (aircraft) than our typical users will ever see.
Nice workaround though Cam - you will just need to find a very big hill...

The "minimum effective pulse width" setting becomes important when you have reasonably large injectors and dont have proper short pulse width adder data.  You can use this setting to stop the ecu from commanding a pulse width that is below the injectors linear or predictable response area.  So for instance if you know your injector flow rate is not linear "falls of the cliff" below 1.3ms pulse width then you set the "minimum effective pulse width" to 1.3ms and that will prevent the ECU from ever commanding less than 1.3ms even if the calculated fuel flow requires less than that.
Of course if you have short pulse width adder data then you are better to have a much lower setting in "minimum effective pulswidth" to allow that table to do it's job.  Having said that it is not common that you see engines running sequential that need pulswidths less than about 0.8ms at idle so your short pulse width adder table often will not need to go much below that point.

sorry for delay, had to sort out a few things and fix some bugs, but all working well with my new sensors
need to finish the documenation (ive done about 1/3 so far)
 
 

Good morning everybody,
Last night we released a new PCLink and Firmware, I updated this thread but it didn't stick (weird eh?)
Thanks for your patience with the 5.6.2 to 5.6.5 update-requiring-ECU unlock bug. Thanks Davidv for his work around.
 
I'll leave these notes attached because they're still quite relevant to this release:
As always, here's how to update your firmware the best way:

I hope so - it's what I plan to do. When I look at the help file it looks like it does:

Haven't forgotten about this, car still in storage for about another month 

Yep the Xtreme will go up to 10 peak and 3 hold. Anything under that is mint.

Never mind - I looked in the G4+ help file and found the following which confirms what I hoped:
Engine Limits - True when RPM Limit, MAP Limit, Speed Limit, GP RPM Limit 1 or GP RPM Limit 2 are active.The value of Engine Limits has no effect.

Noting I have configured it but not tested it yet as the car is a non-runner, so happy to be told "don't be silly, that will never work"....
Can't you already have a 3D shift light by configuring a GP output as PWM and using the Y axis as ECT?
I've gone a step further (maybe better referred to as "different direction", and pretty unsure if it will work) and basically tried to have different shift lights by gear and also have a lower shift light rpm if ECT < 70* by tinkering with the conditions for the output - see below.

this is where im upto with the current display. some minor changes, now includes oil temp, oil pressure and exhaust temp.
also included knock display status from the vipec and global knock triggered times # which reflects # of times vipec has trigger excessive knock and cut timing.

i cant find a good symbol for pressure so i used *
hi,
The board design is a simple arduino Uno with two shields (CANBUS shield & 4d displays systems shield). No other changes are required to the board and these are off the shelf items.
 
the rest of the solution is simple arduino code to drive the CANBUS adapter and then display values on the 4d display.
 
happy to post my code when it's finished