I've had fairly good luck logging vehicle speed, rpm, timing, knock and airflow. Having a working load % so that I could see exactly where I was on the load maps would get me 90% of where I need to be to tune the car well. Right now I'm using tricks like keeping the timing advance values different horizontally until I figure out what load cells I am likely operating in at that RPM.

If anyone has any ideas on how to add two cells to get valid load counts I could experiment with some different values and might get lucky. :P

Of course the GaugeMax="255" or ChartMax="255" doesn't seem right when other cells are listing values up to 8000 for example on RPM values, I should be seeing around 240 load then fading down to 220 or a little less from 6000 rpm to 7500 so those values should be 320 once we get the right data stream logged.

 

Well I checked out CAN20:0 to 3 and whilst 0 and 1 look like loads (although they dont match!?!?)

2 and 3 stay on 0, even when 0/1 max to 255..

IF you think they are doing a "2byte MUT" type thing you will see the small byte of the load loop over.

so if you see something like this in the logs then you know you have found a 2byte load:

230
240
250
254
4
6
4
8
4
6
240
120


And you just need to find the "high" byte...

 

OK - I checked in the code AND can confirm that:

CAN11-1 is KnockSum
CAN11-0 is timing advance

I have found 2byte load BUT I can't work out how to reference it properly... I should have it sorted out soon (in a couple of days)

I might get Hamish to change his method of using CANXX-Y back to proper PID's, that way we can reference them properly..

 

I'll see if I can find time tonight to look at what you sent.

 

Also:

CAN11-2 is OctaneNumber - AT least if the MUT stuff is correct... So it's probably right..

 

CAN6-0 should be MAP - so whatever the scaling from mrFred's 3bar sensor is - use that.
CAN8-1 should be IPW

both these need more confirming...

 

I was using 7-0 for timing advance and that seemed to be correct.

I'll check out 11-0 and compare it with other loggers.

 

yeah there is about 8 references to timingadv.

the advantage of logging it on the same PID as knocksum is that it requires 1/2 the bandwitdh (since you are already getting CAN11 0-3 - once hamish implements it)

 

Ah okay, that makes sense

 

Thanks tephra for finding and posting all those updated CAN ID's! I'll try them out as soon as I can (sometime this week). It'd be great if others can test them out too!

 

Ok so I finally got this to log with a usable sample rate on a Evo 10. I simply turned "multithreading" off and it actually logs pretty well now.

However, I then tried to log a couple days later on another Evo 10, the sample rate was fine, but the logs where jumping all over the place, total gibberish for logging. :-/

 

When is a straight up non-beta version going to be available?

 

ok 2byte load SHOULD BE, PID 0x21F6. return bytes 0 and 1

So hasmish will need to add 0x21F6 into evoscan (or just do what I said about dumping the CANXX stuff and using direct PID's)

 

active wgdc should be 0x210E (1st return byte)
passive wgdc should be 0x210E (2nd return byte)

 

So I take it this means nothing to us until Hamish puts it in evoscan?

btw I used the IPW CAN you listed above today and it "seemed" correct... the problem is I have nothing of trust to reference it to.