The Subaru SVX World Network   SVX Network Forums
Live Chat!
SVX or Subaru Links
Old Lockers
Photo Post
How-To Documents
Message Archive
SVX Shop Search
IRC users:

Go Back   The Subaru SVX World Network > SVX Main Forums > Technical Q & A

Reply
 
Thread Tools Display Modes
  #181  
Old 08-21-2007, 04:57 PM
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
That said, I still don't think it's in the software. I don't think there's some special "1992 Interpretation Protocol" written in the SVX cartridge. I think it's all down to the actual connection hardware.
I think the fact that your ECU works sometimes and not others proves that it is not a different protocol for 92 models.
__________________
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
Reply With Quote
  #182  
Old 08-21-2007, 05:07 PM
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 TomsSVX
The only thing wrong with the maps you are showing is the fuel map. It seems at low load, the engine management would want to keep consistant fuel related to higher rpms... To reword that, the map should be flat in low load as rpms increase... Thats what I have seen thus far... make reference to this post ECU Tune's measurements

Tom
Thanks Tom. That's reassuring.

The shape of the graph comes from the data in the table. It's the scales and units that I'm not 100% sure of. Thanks for posting the ECUtune graphs, I'd been looking for them, but couldn't find them. I'm happy that they look fairly similar to mine.

I understand what you are saying about the map should be flat in low load as rpms increase. I'll check the code again and make sure I haven't got the scale backwards.

There are some other tables in the memory that probably have an effect on things. I don't understand what they do yet.
__________________
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
Reply With Quote
  #183  
Old 08-21-2007, 05:57 PM
Calum Calum is offline
Registered User
 
Join Date: Aug 2007
Location: Lubbock, TX, USA
Posts: 43
Yea, . I couldn't get to sleep Friday night and just started wandering around the internet.

Oops, I spoke too soon. The 7791 is using peripherals the 7790 doesn't have. Its got two UARTs, but its only using one. It does have the same length interrupt vector table as the 7790 though. I wonder if its just the commercial grade 7700? Ever found a datasheet or pinout of the 7791? I'll re-disassemble trying it as a 7700 and see what that coughs out.

On the port speed: it depends on how they setup the UART. Its a little old school, you can actually supply an external clock to set the speed of the UART (Nissans do that), or use the internal clock. The Subaru is a little odd. Check out the code initializing the serial port:

Code:
0094B1    AD2980        lda     al, 0x8029
0094B4    D011          bne     0x94c7
0094B6    8DCF12        sta     al, 0x12cf
0094B9    643065        ldm     #0x65, dp + 0x30                ; Write to UART tx/rx mode register
0094BC    64317F        ldm     #0x7f, dp + 0x31                ; Write to Baud rate generator
0094BF    643404        ldm     #0x04, dp + 0x34                ; Write to Control register
0094C2    643505        ldm     #0x05, dp + 0x35                ; Write to Control register high byte
0094C5    800F          bra     0x94d6

Code block address: 94C7   Length: 145  M:1 X:0 called by: 94B4
0094C7    8DCF12        sta     al, 0x12cf                      ; Branch target from 94B4
0094CA    643005        ldm     #0x05, dp + 0x30                ; Write to UART tx/rx mode register
0094CD    643133        ldm     #0x33, dp + 0x31                ; Write to Baud rate generator
0094D0    643404        ldm     #0x04, dp + 0x34                ; Write to Control register
0094D3    643505        ldm     #0x05, dp + 0x35                ; Write to Control register high byte
0094D6    643801        ldm     #0x01, dp + 0x38                ; Branch target from 94C5, Write to unknown peripheral [38]
0094D9    643907        ldm     #0x07, dp + 0x39                ; Write to unknown peripheral [39]
0094DC    643C04        ldm     #0x04, dp + 0x3c                ; Write to unknown peripheral [3C]
0094DF    643D05        ldm     #0x05, dp + 0x3d                ; Write to unknown peripheral [3D]
The unknown peripheral writes is I think a second UART. But check out how the primary UART (this is the one used for the SSM) is setup: its got two modes, depending on a variable set in the ROM-

65h - even parity, 1 stop bit, internal clock (8Mhz/2), 8 data bits, 1953.125 baud

or

05h - no parity, 1 stop bit, internal clock (8MHz/2), 8 data bits, 4807.69 baud

It looks like it can also swap between the two modes in software (it sets the UART registers later in the code), maybe. This matches the two SSM data transmission modes Kaele (Kashima) documented:

http://kaele.com/~kashima/car/gc8.html

The Japanese to English translation isn't great, but it looks like Kashima at least though about upping the speed to 9600 baud. I don't know how that would work in a car like the SVX with multiple ecus sharing the same diagnostic port. You might have to separate the engine ecu from the rest. to try it just change the line in the '65h mode:

ldm #0x7f, dp + 0x31 ; Write to Baud rate generator

to 19h istead of 7Fh. That should set it to 9600 baud instead of 1953.
Reply With Quote
  #184  
Old 08-21-2007, 08:02 PM
Nomake Wan's Avatar
Nomake Wan Nomake Wan is offline
Retired
 
Join Date: Jan 2007
Location: Orange, CA
Posts: 1,031
Send a message via AIM to Nomake Wan Send a message via MSN to Nomake Wan Send a message via Yahoo to Nomake Wan Send a message via Skype™ to Nomake Wan
Actually, there's no need to use online translation tools for that page, because he's bilingual. If you click the "ENGLISH" link on that page, it'll be translated for you.

http://kaele.com/~kashima/car/gc8-e.html

Quote:
Originally Posted by b3lha
You may be right, but it's a big assumption that anything with a 25pin D is parallel. Particularly on proprietrary devices like this. Remember that serial used 25pin D in the days when this car was built, before the 9pin D became common.
Yeah, that's exactly what my dad told me over the phone. That's what I get, I guess. It's definitely serial communications, just not RS232. But you already know that, hahaha.
Reply With Quote
  #185  
Old 08-21-2007, 08:08 PM
Calum Calum is offline
Registered User
 
Join Date: Aug 2007
Location: Lubbock, TX, USA
Posts: 43
His English version abbreviated the description of the protocol, and didn't describe the alternate ASCII mode.
Reply With Quote
  #186  
Old 08-21-2007, 08:12 PM
Nomake Wan's Avatar
Nomake Wan Nomake Wan is offline
Retired
 
Join Date: Jan 2007
Location: Orange, CA
Posts: 1,031
Send a message via AIM to Nomake Wan Send a message via MSN to Nomake Wan Send a message via Yahoo to Nomake Wan Send a message via Skype™ to Nomake Wan
Oh you're right, he cut off the part in the middle. I'm at work right now and the computers here don't support Japanese text, or I would translate it for you myself. When I get home, I'll translate what I can, okay? Just three more hours...
Reply With Quote
  #187  
Old 08-22-2007, 12:59 AM
Nomake Wan's Avatar
Nomake Wan Nomake Wan is offline
Retired
 
Join Date: Jan 2007
Location: Orange, CA
Posts: 1,031
Send a message via AIM to Nomake Wan Send a message via MSN to Nomake Wan Send a message via Yahoo to Nomake Wan Send a message via Skype™ to Nomake Wan
Now sadly I don't know enough about the hardware we're dealing with to be 100% sure about my translation of the final paragraph. But HOLY CRAP GUYS, YOU HAVE TO READ IT!!! IT'S AMAZING!!!!! Maybe this will solve the problems with the feedback coming in so slowly!!


Quote:
Originally Posted by Kashima-san
I analyzed the communication processing routine, but I couldn't find something like "read command" or "write command" in it. Most likely, the [functional? while-running?] engine data is directly read from the program's work area.

It appears that there's a default binary-mode communication format, but that an ASCII format also exists. In ASCII mode, the baud rate is CLOCK / 832 (4808.9 bps), whereas in Binary mode it's CLOCK / 2048 (1953.6 bps). Furthermore, The CPU clock speed is 8.0020 MHz. Now, while ASCII mode is 8 Bit Data, 1 Stop Bit, and No Parity, Binary mode is 8 Bit Data, 1 Stop Bit, and Even Parity.

In the Legacy and Impreza's case, it takes 1024 microseconds for one cycle of an interrupt processing call once it has a call from the communication processing routine. I am switching from the default binary mode to the ASCII mode for changing the values of data in the memory addresses containing the work area. When switching to ASCII mode the baud rate changes, but when it comes time to switch back to binary mode the baud rate does not return to normal. If I switch once and immediately go back to binary mode, then I can effectively increase the baud rate of binary mode. This being so, then even in Binary mode the UART's baud rate setting should be able to be manipulated directly all the way up to something like 9600 bps. The end of the command is identified from the head of the received data, so when the "regulation amount" data is received the command "raises an event."
EDIT: I thought about that some. It makes sense. Also, it should be noted that the TCU does NOT have an ASCII interpretation mode. How do I know? Look at the command that Kashima-san gives for "STOP" in ASCII mode. On the ECU, that works even when receiving binary data (I've just typed "12" into the comm tool and it stopped the stream). On the TCU, sending it only "12" has NO effect at all. You have to type "12000000" for it to stop. So I guess the ECU is the only computer in the car with an alternate mode... which means it's probably the only one we can mess around with the baud rate on.

EDIT2: A friend of mine offered to take a look at what I've got and try to figure something out with me. He's pretty good with electronics, so we might be able to find something out.

Last edited by Nomake Wan; 08-22-2007 at 01:50 AM.
Reply With Quote
  #188  
Old 08-22-2007, 02:46 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 Calum
Hi,

Just by random luck and insomnia I wandered across this thread. I don't own an SVX or even a Subaru, but do happen to do quite a bit of work with early 90s Nissan ECUs (I make a product called the 'Realtime' daughterboard, it does memory emulation that allows seamless changes to the rom while the car is running, and also bundles the Nissan CONSULT -somewhat like the Subaru diagnostic stuff- over a single USB connection, fun stuff). Anywho, it looks like the ecus have quite a few similarities on the hardware level (they're based on 77xx mcus too), and I thought this might help you guys out. If this is just duplicate stuff you already know, nevermind me.
Welcome. Thanks for helping out.
Quote:
Originally Posted by Calum
First off, the 7791 looks pretty much identical to the 7790. I'm judging that by the matching interrupt vector tables. I bet they're pretty much the same processor, maybe a different package? If you look in this directory:

http://www.calumsult.com/calumsu/disassembler/

Under docs I've posted the short datasheet for the 7790. Also posted is a longer datasheet for a 7700 that is useful for reference. The newer 77xx chips had different peripherals (the ADC changed, etc) than the older ones, and the 7700 is in the same era as the 7790 so its peripheral documentation is useful. It has a different combination of peripherals than the 7790 though (no biggie). Combine its datasheet with the short 7790 datasheet and you've got a pretty decent 7790 datasheet.

Also listed is the software manual, but without the stupid 'EOL' splashed in the middle of every page.

Anywho, how we've got a different disassemble put together than what your using. Rather than just starting blindly at 8000, ours walks Kaele's dasm77 through the bin, using the interrupt vector table as the starting points. As it disassembles it keeps track of the M and X flag, and sets them correctly. This is a bit more complicated than it sounds, because its doing this for every single branch, and they tend to get quite nested. It takes the disassembler a while to fully run, but the end result is I think a bit more readable. I went ahead and put together a version for the SVX bin that b3lha had posted, check out the SVX directory. The disassembler will also autocomment known memory variables, and you can add to the list in a file called memory.txt. I put the locations b3lha had listed in when I ran the disassembler. The big txt file in the SVX folder is the result.

I went ahead and posted the SVX version of the disassembler exe and source code (its in C++, and compiles under the free MS Visual C++ 2005 Express compiler). Its a console app, and you need to have it in the same directory as DASM77. Also, I didn't compile it for use on machines that don't have C++ Express installed (I'll do that later), sorry!

If you want to add to your current disassembler the code above has the memory locations for the peripherals, and correct order and contents of the interrupt vector table.
Thanks! I just downloaded it all from your site. The disassembly I posted at the start of this thread is rubbish. After that I wrote a program to call the MAME disassembler and keep track of the M flag at each branch instruction. I've had a look at your disassembly and the end result seems to be the same as the one on my website, except for differences in notation. The auto-commenting is a great idea and also, your disassembler is automatically skipping dead code and inline data where I have to do that manually.
I am undecided whether to use your disassembler or update mine with your ideas. At present I'm using a linux box which rules out MS C++.
Quote:
Originally Posted by Calum
Btw, on your interface problem, I'd guess that the ecu RX signal isn't exactly CMOS compatible (i.e. truly 0-5V logic). The Nissan CONSULT had a similar issue. A quick look with a 'scope would verify this (want to ship me an ecu and wiring harness, lol?). Just stick a comparator in front of the max232. I'd be happy to whip out a schematic if you need help.
If this is a proven working solution on the Nissan then it's certainly worth a try. You sure came along at the right time.
I've had a look at some comparator datasheets (LM339 & LM311) but I can't figure out how to add them to our circuit. If you have a schematic it would help immensely.
__________________
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
Reply With Quote
  #189  
Old 08-22-2007, 03:35 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
Now sadly I don't know enough about the hardware we're dealing with to be 100% sure about my translation of the final paragraph. But HOLY CRAP GUYS, YOU HAVE TO READ IT!!! IT'S AMAZING!!!!! Maybe this will solve the problems with the feedback coming in so slowly!!
Yes!!! That is very useful information. Thanks for the translation.
The ASCII mode comms routine is at FCDD in the SVX code. The commands are 12, 7F and 20 exactly as per Kashima-san's website. I'll give it a try later and see if it works at the higher baud rate. I'll also check what he said about the rate not returning to normal, but at first glance it looks like the baud rate is reset at the start of each comms routine.
If it doesn't work then there may be another way: At the start of each comms routine there is a flag (bit 6 of location 11CF), which indicates which baud rate is currently in use. It checks the flag to see whether it needs to reset the baud rate. Perhaps by switching to the ASCII mode and then clearing the flag we can make it skip the reset when it gets to the Normal mode routine.
Quote:
Originally Posted by Nomake Wan
EDIT: I thought about that some. It makes sense. Also, it should be noted that the TCU does NOT have an ASCII interpretation mode. How do I know? Look at the command that Kashima-san gives for "STOP" in ASCII mode. On the ECU, that works even when receiving binary data (I've just typed "12" into the comm tool and it stopped the stream). On the TCU, sending it only "12" has NO effect at all. You have to type "12000000" for it to stop. So I guess the ECU is the only computer in the car with an alternate mode... which means it's probably the only one we can mess around with the baud rate on.
You are right, but not for that reason. Even in the binary mode, the ECU only requires a single "12" to make it stop. If I understand you right, you sent the single 12 at 1936 baud (binary mode) not 4808 baud (ASCII mode)?
I had a quick scan through the TCU code but I can't see anything that looks like an ASCII mode routine.
__________________
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
Reply With Quote
  #190  
Old 08-22-2007, 04:13 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 Calum
Yea, . I couldn't get to sleep Friday night and just started wandering around the internet.

Oops, I spoke too soon. The 7791 is using peripherals the 7790 doesn't have. Its got two UARTs, but its only using one. It does have the same length interrupt vector table as the 7790 though. I wonder if its just the commercial grade 7700? Ever found a datasheet or pinout of the 7791? I'll re-disassemble trying it as a 7700 and see what that coughs out.

On the port speed: it depends on how they setup the UART. Its a little old school, you can actually supply an external clock to set the speed of the UART (Nissans do that), or use the internal clock. The Subaru is a little odd. Check out the code initializing the serial port:

Code:
0094B1    AD2980        lda     al, 0x8029
0094B4    D011          bne     0x94c7
0094B6    8DCF12        sta     al, 0x12cf
0094B9    643065        ldm     #0x65, dp + 0x30                ; Write to UART tx/rx mode register
0094BC    64317F        ldm     #0x7f, dp + 0x31                ; Write to Baud rate generator
0094BF    643404        ldm     #0x04, dp + 0x34                ; Write to Control register
0094C2    643505        ldm     #0x05, dp + 0x35                ; Write to Control register high byte
0094C5    800F          bra     0x94d6

Code block address: 94C7   Length: 145  M:1 X:0 called by: 94B4
0094C7    8DCF12        sta     al, 0x12cf                      ; Branch target from 94B4
0094CA    643005        ldm     #0x05, dp + 0x30                ; Write to UART tx/rx mode register
0094CD    643133        ldm     #0x33, dp + 0x31                ; Write to Baud rate generator
0094D0    643404        ldm     #0x04, dp + 0x34                ; Write to Control register
0094D3    643505        ldm     #0x05, dp + 0x35                ; Write to Control register high byte
0094D6    643801        ldm     #0x01, dp + 0x38                ; Branch target from 94C5, Write to unknown peripheral [38]
0094D9    643907        ldm     #0x07, dp + 0x39                ; Write to unknown peripheral [39]
0094DC    643C04        ldm     #0x04, dp + 0x3c                ; Write to unknown peripheral [3C]
0094DF    643D05        ldm     #0x05, dp + 0x3d                ; Write to unknown peripheral [3D]
The unknown peripheral writes is I think a second UART. But check out how the primary UART (this is the one used for the SSM) is setup: its got two modes, depending on a variable set in the ROM-

65h - even parity, 1 stop bit, internal clock (8Mhz/2), 8 data bits, 1953.125 baud

or

05h - no parity, 1 stop bit, internal clock (8MHz/2), 8 data bits, 4807.69 baud

It looks like it can also swap between the two modes in software (it sets the UART registers later in the code), maybe. This matches the two SSM data transmission modes Kaele (Kashima) documented:

http://kaele.com/~kashima/car/gc8.html

The Japanese to English translation isn't great, but it looks like Kashima at least though about upping the speed to 9600 baud. I don't know how that would work in a car like the SVX with multiple ecus sharing the same diagnostic port. You might have to separate the engine ecu from the rest. to try it just change the line in the '65h mode:

ldm #0x7f, dp + 0x31 ; Write to Baud rate generator

to 19h istead of 7Fh. That should set it to 9600 baud instead of 1953.
I haven't been able to find a datasheet for the 37791 anywhere.

I don't think it would be an issue having the separate units on different baud rates. They stay silent until woken by their own specific read command.

At present we don't have the ability to make changes to the ROM.

As I understand it, the 28C1028 EPROM required by the ECU and TCU is no longer available. There is a guy who makes an adapter that will allow a pair of 27C512 EPROMS to be used instead. http://www.scoobyecu.co.uk. This is the same approach taken by Longassname (ECUtune) for his Stage 1.

A burner for 27C512 eproms can be found on ebay for about $18. http://search.ebay.com/Enhanced-Univ...ROM-Programmer I may think about getting one in the future, but at the moment I can't devote enough time to the project.

Phil.
__________________
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
Reply With Quote
  #191  
Old 08-22-2007, 04:22 AM
Nomake Wan's Avatar
Nomake Wan Nomake Wan is offline
Retired
 
Join Date: Jan 2007
Location: Orange, CA
Posts: 1,031
Send a message via AIM to Nomake Wan Send a message via MSN to Nomake Wan Send a message via Yahoo to Nomake Wan Send a message via Skype™ to Nomake Wan
Quote:
Originally Posted by b3lha
Yes!!! That is very useful information. Thanks for the translation.
You're welcome, as always.

Quote:
Originally Posted by b3lha
The ASCII mode comms routine is at FCDD in the SVX code. The commands are 12, 7F and 20 exactly as per Kashima-san's website. I'll give it a try later and see if it works at the higher baud rate. I'll also check what he said about the rate not returning to normal, but at first glance it looks like the baud rate is reset at the start of each comms routine.
If it doesn't work then there may be another way: At the start of each comms routine there is a flag (bit 6 of location 11CF), which indicates which baud rate is currently in use. It checks the flag to see whether it needs to reset the baud rate. Perhaps by switching to the ASCII mode and then clearing the flag we can make it skip the reset when it gets to the Normal mode routine.
I think that's what he meant with the last sentence, actually. He uses the word "head" as in the "beginning" or the "start" of. I now believe the proper translation is this:

Quote:
Originally Posted by Kashima-san
The result of the command is identified from the header of the received data, so when the baud rate data is received the command creates a baud rate change event.
Does this make sense now?

Quote:
Originally Posted by b3lha
You are right, but not for that reason. Even in the binary mode, the ECU only requires a single "12" to make it stop. If I understand you right, you sent the single 12 at 1936 baud (binary mode) not 4808 baud (ASCII mode)?
I had a quick scan through the TCU code but I can't see anything that looks like an ASCII mode routine.
Ah, no, you're right. I just sent 12 @ 1936. But then why won't the TCU respond as well to 0x12?
Reply With Quote
  #192  
Old 08-22-2007, 04:59 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
You're welcome, as always.
How about another one? Is there anything new here, or just stuff we know already?
http://homepage1.nifty.com/BG5A59D/r.../dataread.html
Quote:
Originally Posted by Nomake Wan
I think that's what he meant with the last sentence, actually. He uses the word "head" as in the "beginning" or the "start" of. I now believe the proper translation is this:
Does this make sense now?
Maybe. I think I need to try this out, see what happens and then refer back to what he said. Have you tried it yet?
Quote:
Originally Posted by Nomake Wan
Ah, no, you're right. I just sent 12 @ 1936. But then why won't the TCU respond as well to 0x12?
Because the TCU is programmed to wait until it receives the full command before doing anything. Whereas the ECU is act as soon as it receives the 12.
__________________
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
Reply With Quote
  #193  
Old 08-22-2007, 05:05 AM
Nomake Wan's Avatar
Nomake Wan Nomake Wan is offline
Retired
 
Join Date: Jan 2007
Location: Orange, CA
Posts: 1,031
Send a message via AIM to Nomake Wan Send a message via MSN to Nomake Wan Send a message via Yahoo to Nomake Wan Send a message via Skype™ to Nomake Wan
Quote:
Originally Posted by b3lha
How about another one? Is there anything new here, or just stuff we know already?
http://homepage1.nifty.com/BG5A59D/r.../dataread.html
I will take a look at that as soon as I can. See below.

Quote:
Originally Posted by b3lha
Maybe. I think I need to try this out, see what happens and then refer back to what he said. Have you tried it yet?
You saw right through me. You know me, I would much rather run out to the car and run the risk of frying something in the name of progress, hahaha. I was just about to leave to go test it, I was just making sure I had all the commands I needed to use noted before running away.
Reply With Quote
  #194  
Old 08-22-2007, 07:35 AM
Nomake Wan's Avatar
Nomake Wan Nomake Wan is offline
Retired
 
Join Date: Jan 2007
Location: Orange, CA
Posts: 1,031
Send a message via AIM to Nomake Wan Send a message via MSN to Nomake Wan Send a message via Yahoo to Nomake Wan Send a message via Skype™ to 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.

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.

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.
Attached Files
File Type: txt idle-noinverter.txt (1.1 KB, 405 views)
File Type: txt junk-idle.txt (954 Bytes, 398 views)
File Type: txt junk-fansidle.txt (1.2 KB, 359 views)
File Type: txt junk-idleheadlights.txt (628 Bytes, 369 views)
File Type: txt FULL TEST.txt (12.5 KB, 442 views)

Last edited by Nomake Wan; 08-22-2007 at 08:21 AM.
Reply With Quote
  #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
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -6. The time now is 03:57 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
© 2001-2015 SVX World Network
(208)-906-1122