MR2 Owners Club Forum banner

1 - 20 of 59 Posts

·
Registered
Joined
·
1,272 Posts
Discussion Starter #1 (Edited)
This may be of very limited interest because if you can't tune it then why would you want to log it and those who are capable of tuning this ECU probably have no need for this but here goes anyway.

I take that back there may be some interest in using this for making a semi-accurate evaluation of the effectiveness of bolt-ons or other performance enhancing mods without going to a full dyno session at $100/hr but then again the butt dyno is usually good enough for that purpose and it's free.

When I first tried logging the 2GR ECU I had a cheap knock-off ELM327 OBD2 Bluetooth adapter (cost about $12) and the Torque Pro App for Android ($5). I remember thinking this was completely useless. All I was able to produce were charts like this:



This is a composite of three or four separate WOT runs and the average data logging interval is 1.8 seconds. The data points are scattered all over the place, the data points are not consistently reproducible. This is not even good enough for government work.

So since then, by spending a relatively small amount of money ($50), I've been able to upgrade my capability and improve the average data-logging interval to 0.07 seconds logging 4 variables at once (for example, in these logs, RPM, MAF, Load, and TPS, but you could also log Ignition Angle, IAT, VVTI angle, and so on). This leads to charts like this:



For comparison, I've overlay-ed the data points from the previous chart. With the new setup, the data points are closely reproducible and they are accurate to within +/- a few percent. Heck if you squint just a little bit you can fool yourself into thinking they came off a $50,000 dyno.

Note that I've referred to an "average" data logging interval. This is because the data points are being obtained by query-response over a serial line (CANbus) - this is an extremely inefficient method of communication for data logging as there are latencies, delays, and other network factors that lead to a distribution of the data logging interval. Here's a representation of the actual distribution of data logging intervals obtained by differencing the time stamps of the data series from one point to the next:



There are two distributions pictured, one for logging 4 parameters at a time, and the other for logging 7 parameters. The more parameters you log, the greater the average time logging interval, the wider its distribution, and consequently, the greater the scatter in the data.

If there's any interest we can talk about other techniques for enhancing the speed and accuracy of the data.

The tools you need for doing this kind of thing are an OBD2 adapter, an Android device, and a suitable platform for post-processing the data. There is no wiring up or hooking up of anything beyond what is normal as stock in all cars.

PS. No, there is no way to do this with an Apple phone, or a Mac.
 

·
Registered
Joined
·
98 Posts
Not directly related to the 2GR, but interested in what you are doing and applying it to logging my 1MZ-VVTI. Currently using a similar ELM327 adapter that is supposedly a good quality one, curious if you have had better luck with something else? I wouldn't be surprised if the 1MZ can't output as fast at the 2GR ecu, but anything that might help make the process a little faster would be great.
 

·
Registered
Joined
·
1,272 Posts
Discussion Starter #3
Not directly related to the 2GR, but interested in what you are doing and applying it to logging my 1MZ-VVTI. Currently using a similar ELM327 adapter that is supposedly a good quality one, curious if you have had better luck with something else? I wouldn't be surprised if the 1MZ can't output as fast at the 2GR ecu, but anything that might help make the process a little faster would be great.
Start by characterizing your data rates, like I did in the last graph. Then you can make a decision if they are good enough or you need to do something different. Your ECU runs its external communications on k-line which is inherently slower. If I ever get around to it I'll go and measure data rates on a 1MZ ECU I do have several of these vehicles they are really nice for picking up groceries.
 

·
Premium Member
Joined
·
12,678 Posts
The biggest difference for me was switching to a higher quality bluetooth adapter. I think I went from 15 pids/s with the cheap one to 65-70 with the OBD Link LX OBDLink® LX Bluetooth | OBDLink® | OBD Solutions The Android device on the other end also makes a difference. My tablet (Pixel C) logs about 10 pid/s faster than my phone (a comparatively ancient Galaxy S5). But the phone is so much more convenient, and generally fast enough that it's what I usually use. The biggest thing to remember is to only log the bare minimum of PID's to get the data you want. I suspect it may also help to have a blank screen in Torque that you switch to before you start logging. Otherwise Torque is still polling all of the PID's for the screen you have active, in addition to the ones you are logging. Or maybe it is anyway, I'm not sure... That might be something worth testing. If it is, it may be worth setting up a separate profile just for logging with no real time gauges configured.

Do you have any tricks beyond that for upping the speed? Your post is a little vague on that subject ;)

VVTI angle
This I must know more about!
 

·
Premium Member
Joined
·
3,511 Posts
Frank, I'm using the same adapter that Alex pointed to. (maybe i pointed him towards it? i forget) you can see it on amazon here: https://www.amazon.com/gp/product/B00H9S71LW

I'm using that adapter with a slow~ish windows tablet.

Generally i get about 70pids/sec with that setup and sometimes it goes up to 120pids/sec.

But, let's do a bit of math out of curiosity, what's the max possible pids/sec on a setup like this. The OBDII system runs at 500kbps but generally you can only get to about 80% of that because of the collisions and back-offs.

A pid request has 3 bytes in the message and by the time you put all the bits around it for the address, checksum, mode and inter-message space you get to 71bits.
a pid reply with 2 bytes of data has 4 bytes in the message (some are 1 byte, some are 4 bytes but most that we care about are 2 bytes) so that's 79bits.

So that means in theory the OBDII protocol can handle roughly 2600pids/sec

Of course there's a bit of overhead on that from messages the ECU is sending out but i wasn't expecting that number to be so high. Why are these OBDII adapters so damn terrible we could get a full frame of data every 4ms or so on 10 variables being watched.
 

·
1991/2001 V6 Mr2 #8
Joined
·
2,217 Posts
I still prefer my TIS Techstream V1 VIM made by Denso.
When attached to a more modern laptop running the newest Techstream software via USB, it still works as intended years after it was first introduced.

Same idea, the fewer the variable list you are watching in live data, the faster the refresh rate.
But I can watch 20+ and still feel like it’s decent.
And it will graph the data for me.

And I’m running it in windows on my MAC.
 

·
Registered
Joined
·
1,272 Posts
Discussion Starter #7 (Edited)
Definitely there are some inefficiencies somewhere.

A clear indication of inefficiency is the time interval distribution. The PIDs are never being logged at a steady constant rate. When logging 7 PIDs at an average time interval of 0.1395 seconds (this is about 50PIDs/sec), there can be time intervals of close to 0.4 seconds in the mix. This is nearly one half second where the system is maybe watching television or doing the dishes or walking the dog or something but it is not logging data. This is based on a log with more than 8000 steps in the time series and there are about 20 of these outlier time intervals.

Next I might try logging with my Tactrix Openport 2.0 I have not tried that yet and I don't even know if it's possible but it should be.

PS> Techstream on my Windows 10 logs about 2 PIDs/sec. It's not even in the running. The program is one of the best examples of BLOATWARE that I have ever seen. It takes literally seconds to switch between modules i.e. Engine, Chassis, ABS, Immo. This is laughable.
 

·
Premium Member
Joined
·
3,511 Posts
Yeah, the ECU could be limiting things beyond just the bus rate. I actually have my BEAN module here (
) That thing is bare metal and I've already written a PID request library in there to request the coolant temperature. I'll see about cranking up the request rate and see what the ECU can do. If the ECU can support going beyond that 100pid/s reliably then we know that it's something worth pursuing further.

If we can get anywhere near that theoretical 2600pid/s then we know the limitation for logging on this thing is not the ECU.

It would be interesting to log the CAN bus when the TIS is requesting data to see how it requests it.
 

·
Registered
Joined
·
1,272 Posts
Discussion Starter #9 (Edited)
I'll see about cranking up the request rate and see what the ECU can do.
I tried to see the maximum PID/sec rate with logging JUST ONE PID.

Expected: less overhead, faster rate. Right? Wrong. [I take this back the overhead ratio is higher with just one PID but still the result below is unexpected.]

#PIDs PIDs/sec
7 50.2
4 56.7
1 42.0

With seven PIDs being logged, the overall rate is 50 PID/sec. With 4 PIDs being logged, it is nearly 57 PID/sec. But with just one PID being logged, the PID/sec rate dropped down when I went to just one PID being loggedto 42 PID/sec. The overall rate is faster with 4 PID's being logged.

Not only that, the time interval distribution has a distinct bi-modal character.



I took two samples, just to make sure.

And not only that, if I inspect the log I see some weirdnesses like the PID scalar value repeating from one step in the time series to the next. Not possible physically under the conditions where this was seen.

So there are some artifacts being introduced into the log somewhere.

I have more other stuff to report with hitting nearly 8200RPM but that will have to come later.
 

·
Premium Member
Joined
·
3,511 Posts
So i forgot when i mentioned what i would test earlier that my early prototype is in a customer's hands right now for some testing.

I used a wired USB CAN adapter i have here to do some tests without any extra software in the way. But it seems this adapter is running into it's own internal bandwidth issues. it seems to be maxing out at about 280messages/second and the ECU sends out about 150 messages/second without any additional requests so i'm only getting about 65 pids/sec with this setup.

I'll have to run the test again when i get my next board up and going.
 

·
Registered
Joined
·
1,272 Posts
Discussion Starter #11
I'm gearing up with a CAN logger. Just have to figure out some time stamp stuff. My total investment in cable and software is $12. Ha ha. This is the mother of all reverse engineering tools.



Here's a log of query and response on a single PID.

 

·
Premium Member
Joined
·
12,678 Posts
This appears to be confirmation of a high-rpm crossover in the ACIS, at about 7700. You seen it here first. Ha ha.
Did you get it working? I see a pink trace in there that appears to be normal ECU controlled operation.

Is that logged from multiple pulls? If it's just one you are getting MUCH higher logging speeds than I am!
 

·
Premium Member
Joined
·
3,511 Posts
Oh, NICE! i wonder how high those cams would keep pulling if given the RPM?

Is this the stage one or stage two cams?
 

·
Premium Member
Joined
·
12,678 Posts
Oh, NICE! i wonder how high those cams would keep pulling if given the RPM?

Is this the stage one or stage two cams?
Good point. With ACIS switched off, there is no sign of a fall off even at 8k, the trend line on the MAF reading just keeps climbing. The question is, what would it take to safely rev to, say, 8500?
 

·
Registered
Joined
·
1,272 Posts
Discussion Starter #16 (Edited)
These are MWR Stage 1 cams with MWR springs.

Some tentative thoughts (intended to provoke discussion):

So basically I think this is the equivalent of coming in to the turn too hot and bouncing off the guardrail.

Meaning: throttling down the inlet velocity (by putting it through the ACIS channel - long runner) allows more flow. Velocity too high (short runner) and there is a reflected wave coming off "something." This is the analogue of exhaust reversion with too short runner but on the intake side.

Possibly the way to fix this is with the valve timing and overlap. We're talking about the areas I circled in red on the intake and exhaust vvti maps below.



What I would want to do here is advance the intake (make the number bigger) and retard the exhaust (make the number smaller) to allow the filling to begin sooner and also increase overlap to get some help from the exhaust flow. It looks like there's plenty room in the numbers to try this, not like anything is maxed out.

Maybe this was addressed in Marc's new MAF tunes? I'm not running those yet.

One possible issue is all this is happening WAY off the edge of the OEM maps that go to only 6200. Ha ha.

Possibly this is all moot because I have been persuaded that 7700 is the safe limit to run with this setup - even though I have not had any problem yet in more than 2 years now. But recently Matt mentioned to me a number of people spitting their rockers at 8. For all I know this could have been due to them not putting them back in place correctly this is a factor and it is mentioned even in the repair manual.

With that said... if there's a possibility to palliate the tapering off that starts at 6700, then this would be productive.

PS. Since we're on the subject here's a useful link for cam timing.
https://www.supraforums.com/threads/cam-tuning-turbo-and-n-a-sticky-please.411951/
 

·
Premium Member
Joined
·
12,678 Posts
What I would want to do here is advance the intake (make the number bigger) and retard the exhaust (make the number smaller) to allow the filling to begin sooner and also increase overlap to get some help from the exhaust flow. It looks like there's plenty room in the numbers to try this, not like anything is maxed out.

Maybe this was addressed in Marc's new MAF tunes? I'm not running those yet.

One possible issue is all this is happening WAY off the edge of the OEM maps that go to only 6200. Ha ha.

Possibly this is all moot because I have been persuaded that 7700 is the safe limit to run with this setup - even though I have not had any problem yet in more than 2 years now. But recently Matt mentioned to me a number of people spitting their rockers at 8. For all I know this could have been due to them not putting them back in place correctly this is a factor and it is mentioned even in the repair manual.

With that said... if there's a possibility to palliate the tapering off that starts at 6700, then this would be productive.

PS. Since we're on the subject here's a useful link for cam timing.
https://www.supraforums.com/threads/cam-tuning-turbo-and-n-a-sticky-please.411951/
Marc and I played with this quite a bit about a year ago (granted, with stock cams). I think we tried 8 different combinations of VVTi maps (on my car) on various visits to the dyno. Unfortunately none of them really produced any worth while gains in peak power, although I would have to look back through my notes to say with more accuracy what exactly we tried and what the results were. We were able to get some small improvements in the low end of the curve, mostly smoothing some of the dips and bumps there, but again, nothing earth shattering.

But it's entirely possible that a set of cams would make it worth while to revisite the VVTi maps.
 

·
Premium Member
Joined
·
3,511 Posts
Exactly as Alex said, the 2GR VVT-I maps only have a few minor tweaks, most of it is smoothing. the OEM setup is designed to give you different power "steps" that you distinctly hear but this shows up as dips in the power band. There's also some efficiency stuff in the exhaust map at the cruise region of that particular car. It moves around a bit depending on the source application but none of them are anywhere near the MR2's cruise RPM (about 3000RPM or so) so there's hardly a reason to keep it. We also played around quite a bit with extending the map above 6200rpm and seeing what could be done. In the end we extended the intake map slightly but nothing on the exhaust map.

If i had an engine dyno and way more hours there's probably a few horses here and there but using a chassis dyno woudl take way too long for the little gains at this point.
 

·
Registered
Joined
·
1,272 Posts
Discussion Starter #19
Ok thanks for the responses on the VVTi that was very interesting. Let's go back to data logging.

It would be interesting to log the CAN bus when the TIS is requesting data to see how it requests it.
This is exactly what I was aiming to do all along before getting distracted with MAFs and VVTis, so here we go.

I've got a cracked version of Techstream and I'm out to crack some of the Toyota PID's. So I'm logging CAN traffic with my cracked 2GR ECU using a cracked CAN cable and a cracked CAN sniffer. If this does not crack you up then nothing else will.

For the RAV4 2GR, Techstream lists about 60 available PIDs. I'm not planning to crack them all at once. Let's start with something simple, the two knock-related PID's, and see how far we can get with those.

They are:

Knock Feedback Value - deg (CA) [crank angle?] and
Knock Correct Learn Value -deg (CA)

I did not come up with these names, this is exactly the way they are listed in Techstream. Without really knowing anything, I assume that these are, by analogy to fuel trims, an instantaneous value and a stored value.

So I set up a Techstream log with three variables, (1) RPM, (2) Knock Feedback, and (3) Knock Learn. I did two takes, one stationary, and one under acceleration. These are pictured below.





Woohoo, right? Why do I say WOOHOO?

Reason 1 to woohoo. By some stroke of luck we got some kind of knock event and this is the ziggy-zaggy line in the second chart.

Reason 2 to woohoo. By another stroke of luck we also managed to get four different stored values, they are 20.7, 21.0, 21.4, 20.1. Why I'm excited about four values will be apparent shortly.

So while I'm doing this I'm logging the CANbus traffic and a very short excerpt of the very long file looks like this:



Using the same colors as the Techstream charts, I've circled the OBD2 request and response that correspond to the three variables being logged. Red for RPM, Blue for Knock Feedback, and Green for Knock Learn. HOW DO I KNOW THIS? I'll get to it shortly.

So for these particular PID's Techstream is following very closely the OBD2standard as described for example in Wikipedia:

https://en.wikipedia.org/wiki/OBD-II_PIDs#Service_01

So right there in the common OBD2 definition, we see that the hex code for RPM is 0x0C, therefore inspecting the log file we find lots of RPM query/response sequences like for example:

02 21 0C 00 00 00 00 00
04 61 0C 10 C2 00 00 00

which is the one circled in red. 02 21 is the query string identifier, and 04 61 is the response string identifier, where the ECU adds 0x40 to the 0x21. Using the equation from Wikipedia for RPM, this particular response can be decoded as:

RPM = (256*0x10 + 0xC2)/4 which is left as an exercise for the reader to calculate.

So far so good, this takes care of the RPM. Now, how do we know which of the other two PID's is which? Which is the Feedback value, and which is the Learn? Simple, we just scan the files, and we notice that PID 0xB2 is the one that has a response alternating between one of two values in each file.

So therefore, tentatively:
PID code for Knock Learn = B2
PID code for Knock Feedback = E1

Yah BFD. So how do we get to something useful?

Comparing the CANbus log with the Techstream log, we can correlate the two logs:

06 61 B2 0A 97 07 D0 00 <--> 20.7
06 61 B2 0A A2 07 E1 00 <--> 21.0
06 61 B2 0A AE 07 D0 00 <--> 21.4
06 61 B2 0A 85 07 D0 00 <--> 20.1

The HEX values on the left came from the CANbus log, and the scalar values on right were logged in Techstream, and we are positing a direct correspondence between the two.

So now we do some reasoning of the kind you do when you do not know what the heck is going on. This is called deductive reasoning, or in other words, guessing.

By studying the OBD2 standard definitions as see that the responses come in the format

04 61 A B C D

Where A, B, C, and D are hexadecimal values. We are going to, for now, gloss over the fact that the responses we are seeing here are beginning with 0x06 not 0x04 as we would expect for common PIDs.

We also see that most PID values are calculated from two elements of the response string, which are A and B. There other two elements, C and D (when present) have another purpose - again we gloss over this for now. And in general, the form of the equation for the PID is

PID = x*A + y*B + z

Where x, y and z are constants factors for that PID.

So basically all we have to do is solve a set of three equations in three unknowns. Referring to the correlations listed just above here:

20.1 = x * 0x0A + y * 0x85 + z
21.4 = x * 0x0A + y * 0xAE + z
20.7 = x * 0x0A + y * 0x97 + z

Three equations, three unknowns, x, y and z. Long story short, solve for x, y and z and massage the numbers a little, to get the calculation expression for PID B2 which is Knock Learn Value:

Knock Learn = (A * 256 + B) /32 – 64

So this equation you can now take and put in Torque Pro for Android as a user-defined variable and if you do that then Torque Pro will display and log Knock Learn Value for you along with all the other standard PID's that are available in that app.

That's enough for one day and besides I don't even know if anyone has any interest whatsoever in this so I'm a gonna stop right here.

This was a very long-winded way of answering the simple question how does Techstream query the ECU.
 

·
Premium Member
Joined
·
3,511 Posts
Frank, I've been somewhat wanting to do that for a while. You're somewhat overcomplicating your solve section but the important info is that you've figured out the TIS uses service 21 which is not an officially documented service. But that's normal, OEMs are allowed to use the undefined services for their own purposes.

a list of pids on service 21 along with their scalars would be great.

Also, the knock learn value will make tuning *WAY* easier. I can just drive the car around for a day or two and then adjust my table based on the knock learn values. Especially if it shows timing advance in there also. Which looks like your car is showing you anyways, what you captured is not a knock event but rather a "i could use more timing here" event. That graph has awful scaling but the motor gained maybe 0.3 degrees of timing around ~3500rpm?

It also makes sense that your tune learned positive timing since I'm pretty sure you have my pre MAF-Pipe tune right now. I've added a ton of timing to that tune and the motor loves it.

Curiously, do you have a rough sample rate on the TIS pids? the data looks to be gathered at a very small time interval.
 
1 - 20 of 59 Posts
Top