Open ECU?

[jedibow]

Originally Posted by bambbrose

Is the bus sending the WBO2 as 11 bit or 29 bit frame? What is the bus rate? I know earlier (2010) Subaru used both 125 kb/s and 500 kb/s for different CAN groups. I'm assuming the diagnostic is still on the slower body CAN speed, and the 500 kb/s is for manufacturer specific information.

So far we know:

1 000 0011 1110 0 X blah blah blah

Find out if X is 0 or 1 and we can start to determine the Lambda packet.

As of right now I'm only reading CAN requests, nobody other than EcuTek has been able to access the SSM data, so the only aspect I can work on is the request ID which I have posted, byte length, and the bitrate. As of now I have only been attempting to log at both 1000 kb/s, and 500 kb/s neither is working very well. Thank you for the tip I will try 125 kb/s tonight. also by process of elimination request id 3E is 11 byte, none of the 29 byte Id's communicate through the tactix cable.

Originally Posted by bambbrose

On a side note, I have the factory wiring diagram, and it shows that the injectors have their own MCU on the CAN network.

This means that the engine ECU sends signals to an injector MCU, and that injector MCU then does the fancy work on the injectors and DI system. This means traditional ROMs may just change the main ECU, and it will send out a standardized signal to the injector MCU, and the injector MCU will know how to handle it.

This may also mean that an entirely new ROM has to be developed to manipulate the injector MCU CAN Node values. This is going to be the key to tuning. The first tuners probably will get the standard ROM, but the tuning software that has the MCU for the injectors flashable will be the winner.

This is all just speculation of course since I haven't connected to the network.

This is interesting, I read in the EcuTek thread that they are finding multiple maps for fuel (not just the typical high octane, low octane maps), this maybe the cause, Good info thank you!

G

[jedibow]

I have a local tuner here that has the linux interface, I may ask him if he needs a summer project? HaHa

Good thing we are friends...

[bambbrose]

Originally Posted by jedibow

As of right now I'm only reading CAN requests, nobody other than EcuTek has been able to access the SSM data, so the only aspect I can work on is the request ID which I have posted, byte length, and the bitrate. As of now I have only been attempting to log at both 1000 kb/s, and 500 kb/s neither is working very well. Thank you for the tip I will try 125 kb/s tonight. also by process of elimination request id 3E is 11 byte, none of the 29 byte Id's communicate through the tactix cable.



This is interesting, I read in the EcuTek thread that they are finding multiple maps for fuel (not just the typical high octane, low octane maps), this maybe the cause, Good info thank you!

G

I think they only use one bit rate per line, otherwise things get messy. I believe if you are getting data that is accurate at 500kb/s then that is probably the correct speed.

I have a new Kvaser Leaf CAN to USB on the way in the mail. When it gets here I'm going to log raw data into BUSMASTER and see what we are getting. It has the ability to monitor in silent mode (doesn't send the acknowledgement bit), so we can pull everything off the bus in raw format.

[jedibow]

Originally Posted by bambbrose

I think they only use one bit rate per line, otherwise things get messy. I believe if you are getting data that is accurate at 500kb/s then that is probably the correct speed.

I have a new Kvaser Leaf CAN to USB on the way in the mail. When it gets here I'm going to log raw data into BUSMASTER and see what we are getting. It has the ability to monitor in silent mode (doesn't send the acknowledgement bit), so we can pull everything off the bus in raw format.

Cool, I get proper readings, however I get a overthreshold error and it stops the logger, thus I was thinking I should attempt the lower speed. I never knew subies ran 125kb/s so I never thought to lower it past 500...

BTW, the readings do not change when I change the bitrate from 1000 to 500, they are the same, the logger runs better at 500 kb/s however..

G

[bambbrose]

Originally Posted by jedibow

Cool, I get proper readings, however I get a overthreshold error and it stops the logger, thus I was thinking I should attempt the lower speed. I never knew subies ran 125kb/s so I never thought to lower it past 500...

BTW, the readings do not change when I change the bitrate from 1000 to 500, they are the same, the logger runs better at 500 kb/s however..

G

The 125kb rate is only used for non-essential functions like some radio and body functions if I recall correctly.

If a 125kb signal is sent out on the 500kb line, it will muddle the entire line with noise.

If a 1000kb signal is sent out on a 500kb line, it will be ok because it fits in between the 500kb signals due to higher bit resolution. It's essentially just too much data.

[jedibow]

Well then I'm back to dealing with a scaling issue within EvoScan, that makes sense however.


***Runs to the closet and hangs himself with a wet noodle***

[E92M3Guy]

Originally Posted by bambbrose

Helpful info! Can you get ahold of IS0 11898-2?

I would like this as well.

Is the bus sending the WBO2 as 11 bit or 29 bit frame? What is the bus rate?

My CAN analyzer says it's 11-bit, 500kb/s. I'm reading engine CAN, not D-CAN.

If you guys get down to the hex level please post any findings such as Node ids for requests, data packet bit size, etc.

Logs are too big to post. Dozens of megabytes each. I can give you this histogram of addresses on the CAN bus and showing which bits are changing.

ID(xxxxxxxx): B1, B2, B3, B4, B5, B6, B7, B8
ID(00000018): FF, FF, 70, 0E, 00, 00, 00, FF
ID(000000D0): FF, FF, FF, FF, 00, 00, FF, FF
ID(000000D1): FF, 07, 7F, 00, 00, 00, 00, 00
ID(000000D2): 00, 00, FF, FF, 00, 00, 00, 00
ID(000000D3): 00, 06, E0, 0F, FC, 00, FF, 00
ID(000000D4): FF, 07, FF, 07, FF, 07, FF, 07
ID(00000140): 7F, 4F, FF, 4F, FF, 7F, FF, 21
ID(00000141): FF, 2F, FF, 2F, FF, 8F, E0, 18
ID(00000142): FF, AF, FF, 00, 00, 00, 00, 00
ID(00000144): DC, 00, FF, 41, 06, A4, 29, 00
ID(00000148): 7F, 1F, FF, 0F, 00, 00, FF, 05
ID(00000149): 00, C7, 00, 00, 00, 00, 48, 0F
ID(0000014A): FF, 03, FF, 7F, 10, A7, 00, 80
ID(00000152): F0, F4, 00, 00, 00, 02, 18, 03
ID(00000156): 00, 80, 00, 00, 00, 00, 00, 00
ID(00000282): FF, F7, FA, 8F, 8F, 00, 20, 00
ID(00000360): FF, 1F, FF, FF, FF, 90, B2, 00
ID(00000361): 00, 29, 00, DF, 0F, F0, FF, 57
ID(00000368): 12, 00, 00, 00, 00, 00, 00, 00
ID(00000370): FF, 03, 00, 00, 00, 0F, 00, 00
ID(00000372): 00, F0, 00, 00, 00, 00, 00, 00
ID(00000374): 00, 00, 00, 00, 00, 00, 00, 00
ID(00000375): 00, 00, 00, 00, 00, 00, 00, 10
ID(00000440): 42, 02, 00, 00, 00, 00, 00, 00
ID(00000442): 40, 02, 00, 00, 00, 00, 00, 00
ID(000004C1): 01, 00, 00, 00, 00, 00, 00, 00
ID(000004C2): 02, 00, 00, 00, 00, 00, 00, 00
ID(000004C3): 03, 00, 00, 00, 00, 00, 00, 00
ID(000004C6): 07, 00, 00, 00, 00, 00, 00, 00
ID(000004C8): 09, 00, 00, 00, 00, 00, 00, 00
ID(000004DD): 1E, 00, 00, 00, 00, 00, 00, 00
ID(0000063B): 00, 00, 00, 81, 00, 00, 3F, FF
ID(000006E1): A1, 80, 00, 00, 00, 70, 00, 00
ID(000006E2): A2, 80, 00, 6C, 6C, 6C, FE, FE

[bambbrose]

Originally Posted by E92M3Guy

I would like this as well.



My CAN analyzer says it's 11-bit, 500kb/s. I'm reading engine CAN, not D-CAN.



Logs are too big to post. Dozens of megabytes each. I can give you this histogram of addresses on the CAN bus and showing which bits are changing.

ID(xxxxxxxx): B1, B2, B3, B4, B5, B6, B7, B8
ID(00000018): FF, FF, 70, 0E, 00, 00, 00, FF
ID(000000D0): FF, FF, FF, FF, 00, 00, FF, FF
ID(000000D1): FF, 07, 7F, 00, 00, 00, 00, 00
ID(000000D2): 00, 00, FF, FF, 00, 00, 00, 00
ID(000000D3): 00, 06, E0, 0F, FC, 00, FF, 00
ID(000000D4): FF, 07, FF, 07, FF, 07, FF, 07
ID(00000140): 7F, 4F, FF, 4F, FF, 7F, FF, 21
ID(00000141): FF, 2F, FF, 2F, FF, 8F, E0, 18
ID(00000142): FF, AF, FF, 00, 00, 00, 00, 00
ID(00000144): DC, 00, FF, 41, 06, A4, 29, 00
ID(00000148): 7F, 1F, FF, 0F, 00, 00, FF, 05
ID(00000149): 00, C7, 00, 00, 00, 00, 48, 0F
ID(0000014A): FF, 03, FF, 7F, 10, A7, 00, 80
ID(00000152): F0, F4, 00, 00, 00, 02, 18, 03
ID(00000156): 00, 80, 00, 00, 00, 00, 00, 00
ID(00000282): FF, F7, FA, 8F, 8F, 00, 20, 00
ID(00000360): FF, 1F, FF, FF, FF, 90, B2, 00
ID(00000361): 00, 29, 00, DF, 0F, F0, FF, 57
ID(00000368): 12, 00, 00, 00, 00, 00, 00, 00
ID(00000370): FF, 03, 00, 00, 00, 0F, 00, 00
ID(00000372): 00, F0, 00, 00, 00, 00, 00, 00
ID(00000374): 00, 00, 00, 00, 00, 00, 00, 00
ID(00000375): 00, 00, 00, 00, 00, 00, 00, 10
ID(00000440): 42, 02, 00, 00, 00, 00, 00, 00
ID(00000442): 40, 02, 00, 00, 00, 00, 00, 00
ID(000004C1): 01, 00, 00, 00, 00, 00, 00, 00
ID(000004C2): 02, 00, 00, 00, 00, 00, 00, 00
ID(000004C3): 03, 00, 00, 00, 00, 00, 00, 00
ID(000004C6): 07, 00, 00, 00, 00, 00, 00, 00
ID(000004C8): 09, 00, 00, 00, 00, 00, 00, 00
ID(000004DD): 1E, 00, 00, 00, 00, 00, 00, 00
ID(0000063B): 00, 00, 00, 81, 00, 00, 3F, FF
ID(000006E1): A1, 80, 00, 00, 00, 70, 00, 00
ID(000006E2): A2, 80, 00, 6C, 6C, 6C, FE, FE

Would you share the log in PM?

Looks like ID 140 is in an error state (7F).

Have you connected any IDs to specific parameters yet?

What CAN analyzer software and cable are you using?

Moto-P stated the the IDs would be open source and released by Toyota, but I haven't heard anything else about this since then.

[E92M3Guy]

Originally Posted by bambbrose

Would you share the log in PM?

Sure, PM me your email address. I'll be away for the weekend, but should have email access.

Looks like ID 140 is in an error state (7F).

That's a histogram, not a value. The 7F means that somewhere in the entire log, all lower 7 bits have changed.

Have you connected any IDs to specific parameters yet?

Yeah, I have the usual stuff. RPM, wheel speed sensors, gear selection, steering angle, a bunch of buttons on the dash, 2x accelerometers (suspected), 1x gyro (suspected), etc.

What CAN analyzer software and cable are you using?

Vehicle Spy-3. It's pretty pricey, but very comprehensive and supports just about any protocal including multi-frame messages.

Moto-P stated the the IDs would be open source and released by Toyota, but I haven't heard anything else about this since then.

Yeah, once I saw that announement, I kind of quit working on reverse-engineering it...figuring I'm wasting my time.

[E92M3Guy]

More info:

0xD0 = Steering angle and motion sensors
0xD1 = Brakes & Speedometer
0xD4 = Individual wheel speed sensors
0x140 = Throttle position, RPM
0x148 = Gear selection

I guess I didn't add the dash switches to the map on my desktop; they must be on my laptop instead.

[jedibow]

Took my car to the dyno today and what I found most interesting was that the AFR was within 0.1 point at all rpm points of the command AFR. Could it be possible that the ECU is running full time closed loop? Another possibility is that the MAF Scaling is spot on, however I doubt this...

[serialk11r]

Originally Posted by jedibow

Took my car to the dyno today and what I found most interesting was that the AFR was within 0.1 point at all rpm points of the command AFR. Could it be possible that the ECU is running full time closed loop? Another possibility is that the MAF Scaling is spot on, however I doubt this...

Did you swap the intake?
Also when the AFR gets lower, each increment in AFR gets "bigger" in terms of fuel mass/volume if you know what I mean, maybe that sort of resolution isn't considered impressive or something. I have no idea what it typically is, so I might be talking out of my ass.

[Visconti]

Originally Posted by jedibow

Took my car to the dyno today and what I found most interesting was that the AFR was within 0.1 point at all rpm points of the command AFR. Could it be possible that the ECU is running full time closed loop? Another possibility is that the MAF Scaling is spot on, however I doubt this...

Does not run closed loop during WOT.

-John

[jedibow]

Originally Posted by serialk11r

Did you swap the intake?
Also when the AFR gets lower, each increment in AFR gets "bigger" in terms of fuel mass/volume if you know what I mean, maybe that sort of resolution isn't considered impressive or something. I have no idea what it typically is, so I might be talking out of my ass.

The intake did smooth out the MAF readings, and according to visconti the ECU runs open loop at WOT, so the only reason the command AFR and actual AFR ratios would be the same is whoever tuned the factory MAF scalings and compensation were spot on, kind of cool.

What this means is once tuning is available you will not have to arbitrarely assign values to the independant cells in the fuel map, what you enter is what you will see in the external wideband gauge. It will make life easier.

I would also like to comment that the oscillations between AFR on the dyno were +/- 0.2 points in AFR, after the intake, it did not oscillate at all.

BTW max hp 171, max torque 146. these values are SAE corrected ofcourse for my being at 5500 feet above see level, however uncorrect it was 136, and 117 almost exactly what evoscan predicted, awesome.