View Single Post
  #195  
Old 08-22-2007, 09:16 AM
b3lha's Avatar
b3lha b3lha is offline
Phil & Belha
 
Join Date: Aug 2001
Location: Alcyone Limited, Buckinghamshire UK
Posts: 2,671
Quote:
Originally Posted by Nomake Wan
Okay, I will now share the results of my test.
First off, I can't figure out how to do any of the baud stuff. I tried setting to 4808-8N1 but then the ECU wouldn't respond. Duh I wasn't talking in ascii. So I tried typing "7f111213141010" but that got no response. Nothing I tried got any response. I know NOTHING about ASCII, so I'm probably just doing it wrong.
This is just a guess, because I haven't had the chance to try it yet, but I would set the baud rate and then send the following as hex 7F313233343532

7F is the read code

31 is the ascii code for 1
32 is the ascii code for 2
33 is the ascii code for 3
34 is the ascii code for 4

35 is the ascii code for 5 } I'm not entirely sure what kashima-san meant with "R" in
32 is the ascii code for 2 } column 5 & 6. I'm assuming this. 52 is the ascii code for R.

I think this should be equivalent to 78 12 34 'R' in binary mode.

Quote:
Originally Posted by Nomake Wan
I also don't know how to overwrite the 7f for the baud rate UART control. Please explain what memory address this is. I thought it was "94BC" but that got "64" not "7F." If I knew where to read/write from, I could test this whole override thing out.
At 94BC the data reads 64 31 7F. That decodes to LDM #$7F,$31 which means load the byte of memory at address 31 with the value 7F. See how it works? 64 is the code for the "LDM" instruction. 31 is the address and 7F is the value. The 7F byte you would actually change is at 94BE. However, memory locations 8000-FFFF are in ROM not RAM. So you can't update it no matter how hard you try.
Quote:
Originally Posted by Nomake Wan
However! I DID make a HUGE HUGE HUGE HUGE breakthrough. HUGE. GIGANTIC.

I found out the source of the junk data in my car.

When I ran the program with the car off running from the laptop battery, I got good data. When I ran the program with the car idling after a while with the laptop running on the inverter, I got junk data. But I noticed suddenly that while indeed it was junk, it wasn't nearly as bad as before. Not as many FF readings. And to my shock, there were a few random lines that read "123400."

So I unplugged the inverter. I got good data, to my extreme shock. But then the radiator fans came on, and I started getting As and Bs and stuff. I waited for them to turn off... and decided it was time to do a real experiment. I cleared my screen, sent the read command, and let it run.

Idling Low, Nothing On: 123400... (good data)
Idling Low, Headlights On: FFEEECFDFDE (extreme junk data)
Idling Low, Parking Lights On: AACABDDS906590A (not as much junk)
Revved up ~2000 RPM, Parking Lights On: 123400... (good data)
Revved up ~3500 RPM, headlights on: 123400.... (good data)

IT'S POWER. Power has something to do with it. I'll attach all of my logs here. Please enjoy them.

EDIT: To be clear, it seems to be a lack of power. When a load is placed on the SVX electrical system, the converter box can no longer read coherent data. When the load is relieved (i.e. by revving up to increase alternator output) the converter box can once more read coherent data.
I think you are right. On my 92, I had a few random lines of good data in amongst the junk when the battery was low, but it all turned to junk when I charged the battery. Maybe the later ECUs have better voltage regulation.

I'm hoping that Calum will come back with a schematic for us. He suggested using a comparator. It sounds like the Nissan guys have found a solution to this problem.
__________________
Subaru ECU and TCU Website
1992 Alcyone SVX Version L
1992 Alcyone SVX Version L
1994 Alcyone SVX S40-II
2004 Subaru Legacy 2.5 SE Sports Tourer
1996 Subaru Legacy 2.2 GX Wagon
1988 Subaru Justy J12 SL-II

Last edited by b3lha; 08-22-2007 at 09:19 AM.
Reply With Quote