Welcome to the North American Subaru Impreza Owners Club Sunday July 13, 2014
Home Forums WikiNASIOC Products Store Modifications Upgrade Garage
NASIOC
Here you can view your subscribed threads, work with private messages and edit your profile and preferences Home Registration is free! Visit the NASIOC Store NASIOC Rules Search Find other members Frequently Asked Questions Calendar Archive NASIOC Upgrade Garage Logout
Go Back   NASIOC > NASIOC Technical > Normally Aspirated Powertrain

Welcome to NASIOC - The world's largest online community for Subaru enthusiasts!
Welcome to the NASIOC.com Subaru forum.

You are currently viewing our forum as a guest, which gives you limited access to view most discussions and access our other features. By joining our community, free of charge, you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content and access many other special features. Registration is free, fast and simple, so please join our community today!

If you have any problems with the registration process or your account login, please contact us.
* Registered users of the site do not see these ads.
Reply
 
Thread Tools Display Modes
Old 04-06-2009, 11:16 AM   #1
fastenova
Scooby Specialist
 
Member#: 38829
Join Date: Jun 2003
Chapter/Region: NWIC
Location: Tigard, OR
Vehicle:
Not your usual 1997
Legacy GT

Default JECS ECU modification

I have been looking for a way to bump the idle up a bit on my Legacy since I installed cams, as the stock idle is rough.

I spoke with Jay Storm a bit about changing the clock/crystal on the ECU and wanted to detail what I found out, as well as my ideas and the process for anyone else wanting to do the same. Also, by making this information public it allows anyone with more electronics experience to chime in with potential problems, as well as the people who've been using the reclocked ECU to let the community know how they like it.

IMPORTANT NOTE: This absolutely should NOT be used on newer ECUs that are opensource compatible. Modifying the idle speed and rev limit via software is the preferred method. This method is for older ECUs that do not have this option. I am not responsible for any damage you do to your ECU.

IMPORTANT NOTE #2: This can make your engine run leaner than intended. This could possibly result in extremely high combustion temperatures which can make your engine fail prematurely. Also, the other effects of this change are not completely known. Therefore, it is my personal opinion that anyone doing this should have a reliable way of measuring their AFR using a wideband O2 sensor, either permanently installed or by a tuner / on a dyno for safety.

I'd highly suggest trying this on a backup ECU, as you can render your ECU worthless very quickly if this is done improperly. Having said that, if you can solder and have a low-power soldering iron and a steady hand, this isn't very difficult.



Basic info:

The ECU is a computer, and all computers have to operate at a certain frequency. At the heart of the computer there is a quartz crystal that resonates at a specific frequency when voltage is applied. This crystal simply oscillates between providing an output voltage and zero voltage. Think switching back and forth from 0 to 1 back to 0 over and over at a given rate.

During each clock cycle, the CPU executes part of a simple instruction. For example, a pipelined RISC processor completes one stage of a 5-stage instruction per cycle (see http://en.wikipedia.org/wiki/Clock_cycle for more information). So the operating speed of the processor is based on the frequency at which it executes instructions. This frequency is determined by the crystal.

Now, during each instruction, the CPU analyses some data point. Whether it is adding two numbers together, or just moving numbers around in memory, each operation requires a variable amount of time based on the clock speed of the CPU. If you increase the clock speed, you increase the number of operations it can perform in a fixed time period, say one second.

Note that clock speed is expressed in Hertz (Hz) or Megahertz (MHz) in this case. 1 Hz = 1 clock cycle per second, and 1MHz = 1 million clock cycles per second. This can be thought of as "operations per unit time".

The way that we think about our engines is based on a fixed time period, such as RPM (revolutions per minute) or g/s (grams per second of air in a MAF-based car). These time denominations are fixed. If we increase the clock speed of the ECU, RPM is still measured in revs per minute, and air delivery is still measured in grams per second. These are fixed. Therefore, these readings will not be changed by the increased clockspeed.



JECS ECU information:

1998 2.5L ECU has a 15.996 MHz crystal
Idle speed: 700 RPM
Fuel cut: 6500 RPM
Printed on crystal: 15996.0 7BT A M Q - 2 8

I will be adding pictures of the ECU here as well as the crystal later.



Theory:

For the purposes of this exercise, let's assume a 8.0 MHz crystal/clock speed

The ECU measures certain parameters such as idle speed and fuel cut (rev limiter) based on revolutions per unit where unit is a preset number of clock cycles. So, if the target idle speed is 750RPM,

750/60 = 12.5 revs/second,
and if 8.0MHz = 8 million cycles per second, then it follows that the ECU will target 12.5 revs per 8 million clock cycles, or 1 revolution every 640,000 clock cycles.

By increasing the frequency that the CPU is operating instructions at, we can effectively change the time period by which the ECU is measuring these parameters. Let's say we increase the clock speed by 10%, so that it operates at 8.80MHz:

Hardcoded target of 1 rev every 640,000 clock cycles. At 8.8 million cycles per second, that means 13.75 revs per second...
13.75*60 = 825 RPM.

We just increased idle speed by 10% (75RPM)!

Now if the fuel cut is measured the same way...
6500RPM maximum = 108.33 revs/sec maximum, or 108.33/8 million clock cycles, that's one rev every 73,846 clock cycles.

At 8.8 million cycles per second, that is about 119.17 revs per second, or...
119*60 = 7,150 RPM

We just increased our rev limiter by 10% (650RPM)!

Pretty cool, huh? What I don't know is what other parameters the ECU measures based on clock cycles. I have been told that the people who have overclocked ECUs haven't found any other issues, aside from one important one, detailed next.



Problems:

Loss of OBDII communication. This is because when the OBDII protocol used by Subaru sends data to either a scanner or a computer, it sends data based on clockspeed of the ECU. If the ECU is overclocked, it sends data too fast and cannot establish a connection with the other device. In most states, that means you can't pass emissions.

My workaround for that is a simple DPDT slider switch. On one side, you use the stock 16.0 Mhz crystal, on the other side, you have your faster crystal. With the ignition off and the key out, you should be able to safely switch between the two crystals.

Want faster idle speed/increased rev limiter? With the car off, switch to the faster crystal. Need to pull codes or pass emissions? With the car off, switch to the stock crystal.

I think it's prudent to switch both the input and output of the crystal, as you don't want the output from one crystal being used as the input for the other if they're left connected while powered.



My experience:

I am running the stock crystal and a 17.739 MHz crystal, still working out the bugs... see below.


My beautiful finished product... I didn't have a good way to cut a rectangle in the ECU case and as this was just my "trial" version I didn't really care. I think I'll use a dremel or rotozip on my final product.

* Registered users of the site do not see these ads.

Last edited by fastenova; 04-16-2009 at 10:11 AM.
fastenova is offline   Reply With Quote
Old 04-06-2009, 11:16 AM   #2
fastenova
Scooby Specialist
 
Member#: 38829
Join Date: Jun 2003
Chapter/Region: NWIC
Location: Tigard, OR
Vehicle:
Not your usual 1997
Legacy GT

Default

Online Suppliers:
Digi-Key Corporation - www.digikey.com
Mouser Electronics - www.mouser.com


Crystal Manufacturers:

ECS, Inc.
www.ecsxtal.com
Correct package for stock replacement: http://www.ecsxtal.com/store/pc-21-7-hc-49usx.aspx
Standard frequency abbreviations and crystal identification: http://www.ecsxtal.com/store/pdf/partnumber4.pdf


DPDT Switch I used:
http://search.digikey.com/scripts/Dk...ame=CKN9158-ND
This is a slide switch with a recessed screwdriver slot as the switching mechanism. I opted for this flush-mount switch since I mounted the switch in the ECU case. I didn't want it getting accidentally flipped as the stock ECU location is in the passenger footwell. There is a metal cover that goes over the ECU, but I just felt like putting a rocker switch wasn't a good idea. It's marked simply as '0' for one throw and '1' for the other.

Last edited by fastenova; 04-07-2009 at 11:04 AM.
fastenova is offline   Reply With Quote
Old 04-06-2009, 11:16 AM   #3
fastenova
Scooby Specialist
 
Member#: 38829
Join Date: Jun 2003
Chapter/Region: NWIC
Location: Tigard, OR
Vehicle:
Not your usual 1997
Legacy GT

Default

Reserved #2
fastenova is offline   Reply With Quote
Old 04-06-2009, 12:02 PM   #4
Skidd
Scooby Specialist
 
Member#: 1853
Join Date: Jul 2000
Chapter/Region: TXIC
Location: SA-TX (Hozer expat)
Vehicle:
GC6 Supercharged
STM

Default

Hang on a sec... I just gotta ask, is your car OBD2?
I have yet to see an OBD2 Subaru that can't have it's idle increased through the use of ECUExplorer and the SSM Protocol. Granted, I have not personally tried every model. FYI, My 00RS runs a JECS/Unisa ECU, and I set my idle to 950 with ECUExplorer.
Skidd is offline   Reply With Quote
Old 04-06-2009, 12:30 PM   #5
fastenova
Scooby Specialist
 
Member#: 38829
Join Date: Jun 2003
Chapter/Region: NWIC
Location: Tigard, OR
Vehicle:
Not your usual 1997
Legacy GT

Default

Yes, the car is OBD2. No, ECUExplorer does NOT work with 95-99 ECUs, nor does anyone have a decoded map for them as far as I know.

I bought a tactrix cable over a year ago and tried all of the open source ECU programs I could find with absolutely no luck.

It's a good thing those cables are easy to sell used!
fastenova is offline   Reply With Quote
Old 04-06-2009, 01:50 PM   #6
Skidd
Scooby Specialist
 
Member#: 1853
Join Date: Jul 2000
Chapter/Region: TXIC
Location: SA-TX (Hozer expat)
Vehicle:
GC6 Supercharged
STM

Default

I admit, I'm surprised! I was under the impression that all Subaru OBD2 cars supported the SSM protocol. I know it's not reflashable, but I honestly expected it to at least work with ECUExplorer. Go Figure! At least you have "almost" find a work around.
Skidd is offline   Reply With Quote
Old 04-06-2009, 05:19 PM   #7
Storm
Scooby Guru
 
Member#: 5218
Join Date: Mar 2001
Chapter/Region: MWSOC
Location: SAUL'S Motorsports
Vehicle:
96L Most Over-
Developed Beater

Default

I find it a bit odd that the idle is hunting like it is. I haven't had any trouble in that regard. Even bumping it up 10, 15, 20 or 25%. The idle (for me) has always settled down to a stable number that always OEM+ x%. If you have a scope or access to one, it would be interesting to see if A: you got a bad crystal, or B: the switch is altering the freq. of the higher crystal.

Supposedly, the SSM will work with the 99 and older ECUs, but I have never personally had any of mine connected to one. I have tried the opensource way of changing settings, but it just doesn't work. I have read up on the TechTom system of removing one of the ROM chips for a socket and daughterboard.....but I haven't gotten any more info on what it would take for the older ECUs.

Oh, and it seems like all of the 96-99 ECU's I've opened up are running at 15.996mHz. Those looking to overclock, should check their boards before buying crystals. I can tell you that a 9mHz xtal in a 98RS ECU will give you an idle of like 450-500rpm. The rev limit is hideously low too..... oops! On the other hand, a 20mHz xtal in a 98RS ECU will give you an 875rpm idle and an 8125rpm limit, and the OEM valvetrain will run right up to it!!!!

If there's any other info I can give, let me know.

Jay

Last edited by Storm; 04-07-2009 at 06:41 PM. Reason: edited crystal values
Storm is offline   Reply With Quote
Old 04-06-2009, 05:26 PM   #8
fastenova
Scooby Specialist
 
Member#: 38829
Join Date: Jun 2003
Chapter/Region: NWIC
Location: Tigard, OR
Vehicle:
Not your usual 1997
Legacy GT

Default

Jay,

Thanks for the input! I updated the post and maybe we can record what freq. each ECU is. How did you figure out what speed the stock crystal was running at?

I had a knowledgeable guy at an electronics retailer (not BestBuy or something, it's a small specialty store) help me out. I didn't put it on a scope or anything...

You could be totally right, and maybe I have the wrong speed, so it was wanting to idle slowly and the ECU realized it was about to die, so it opened up the IACV.
fastenova is offline   Reply With Quote
Old 04-06-2009, 06:21 PM   #9
Storm
Scooby Guru
 
Member#: 5218
Join Date: Mar 2001
Chapter/Region: MWSOC
Location: SAUL'S Motorsports
Vehicle:
96L Most Over-
Developed Beater

Default

The freq is printed on the can. It may not be labeled as mHz, but the digits are a representation of the value. When I searched for values, 15.996mHz was one of the values listed, so I took a gamble, used that value to base the % changes and spent the $.99 on a few values that would represent bumps by different percentages.

I can't take credit for coming up with this idea, it came to me in a roundabout way through the original builder of the infamous "torquechip". The theory was validated by a mailorder ECU hacker selling increased rev limits for various ECUs. He had never done a Subaru ECU before I contacted him, but I took a chance and sent him one of mine and $100. It came back a few days later and the crystal was the only item I could see that had been changed physically.

It is important to note that later ECUs use multiple reference points (crystals or IC timers) for different functions based on time. Without knowing which crystal is feeding what functions, it is best to leave them alone and use alternate methods of madness, such as openecu, romraider, or others.

Jay

Last edited by Storm; 04-07-2009 at 06:42 PM. Reason: crystal values again....
Storm is offline   Reply With Quote
Old 04-06-2009, 06:42 PM   #10
fastenova
Scooby Specialist
 
Member#: 38829
Join Date: Jun 2003
Chapter/Region: NWIC
Location: Tigard, OR
Vehicle:
Not your usual 1997
Legacy GT

Default

Also - do you agree that the reason why RPM, timing, etc. aren't really affected is because those are "event-based" meaning when the cam/crank sensors pulse the ECU does something, like trigger a spark and send a signal to the tach? Versus time/clockcycle-based like I explained above?

I guess another way of saying it is that the ECU uses the clockline mostly for its' own calculations, and for doing checks of variables to make sure they're within a certain range. It does not make combustion occur any differently, because most of it is mechanical, save for spark, and even that's a simple delayed trigger mechanism based off the hall effect sensors for the crankshaft and camshaft. The ECU just adjusts the timing slightly but it's still triggered by electromechanical means...

I guess that's why I wasn't too afraid to try this. That, or I'm just plain stupid!
fastenova is offline   Reply With Quote
Old 04-06-2009, 09:43 PM   #11
Storm
Scooby Guru
 
Member#: 5218
Join Date: Mar 2001
Chapter/Region: MWSOC
Location: SAUL'S Motorsports
Vehicle:
96L Most Over-
Developed Beater

Default

I'd agree with that, with some noteworthy info. Ignition and fueling are timed on engine position in degrees. Although, the loading of the engine is directly related to MAF/MAP input along with RPM. Those inputs are time based (RPM anyway). What does that mean for overall fuel/ign maps? I think that what the overclocking does is take each end of those curves and pull them apart to reach the ends of the rpm range.

Here's how I understand the overclocking to work in the case of rpm alone:

RPM limit of 6500: I put 10 spaces between each digit and * at 6.5 to indicate real time.
[1 2 3 4 5 6 * 7]
Overclocking will decrease those spaces by the percentage of change. Below is +20% or -2 spaces:
[1 2 3 4 5 6 7 8 ]
[1 2 3 4 5 6 * 7]

Line up the asterics to see the new rpm limit is 7800.

Hopefully the ascii art is coherent enough to understand. The ECU is still limiting the rpm at what it thinks is 6500rpm, but in real time, it's 7800rpm. It seems bass ackwards, but it is what the ECU does when it's measuring time at a different rate than in reality.

Jay
edit: all that stinkin time making a chart and the forums removes my spaces!!!!
Storm is offline   Reply With Quote
Old 04-07-2009, 03:24 AM   #12
Patrick Olsen
NASIOC Supporter
 
Member#: 120
Join Date: Jul 1999
Chapter/Region: AKIC
Location: Where the Navy sends me...
Vehicle:
1997 Legacy 2.5GT
QuickSilver Metallic

Default

So with my 10% reclocked ECU I should be seeing a higher idle, too? I can't say I ever noticed that, but then I don't pay a whole lot of attention to idle speed. I definitely didn't have any surging idle issues with mine.

Pat Olsen
Patrick Olsen is offline   Reply With Quote
Old 04-07-2009, 07:33 AM   #13
Storm
Scooby Guru
 
Member#: 5218
Join Date: Mar 2001
Chapter/Region: MWSOC
Location: SAUL'S Motorsports
Vehicle:
96L Most Over-
Developed Beater

Default

To be honest, Pat....I think the idle on the RS remained close to the same with that modded ECU I "bought". That just tells me that the guy did something else that I can't see. Every one that I have done myself has had the idle speed change with the % bump.

Jay
Quote:
Originally Posted by Patrick Olsen View Post
So with my 10% reclocked ECU I should be seeing a higher idle, too? I can't say I ever noticed that, but then I don't pay a whole lot of attention to idle speed. I definitely didn't have any surging idle issues with mine.

Pat Olsen
Storm is offline   Reply With Quote
Old 04-07-2009, 08:58 AM   #14
kc8apm
Scooby Newbie
 
Member#: 121153
Join Date: Jul 2006
Default

I'm a bit of a lurker here, but on this one I've got to chime in -- as someone with a background in computer engineering, this is just asking for trouble. Problems are likely if one is just changing out the oscillator. Who knows what else the ECU uses timing loops for?
kc8apm is offline   Reply With Quote
Old 04-07-2009, 10:22 AM   #15
Storm
Scooby Guru
 
Member#: 5218
Join Date: Mar 2001
Chapter/Region: MWSOC
Location: SAUL'S Motorsports
Vehicle:
96L Most Over-
Developed Beater

Default

4 years of trouble free operation prove to me that the ECU doesn't rely on the oscillating crystal for much. Thank you for the vote of confidence though!

Jay
Quote:
Originally Posted by kc8apm View Post
I'm a bit of a lurker here, but on this one I've got to chime in -- as someone with a background in computer engineering, this is just asking for trouble. Problems are likely if one is just changing out the oscillator. Who knows what else the ECU uses timing loops for?
Storm is offline   Reply With Quote
Old 04-07-2009, 10:24 AM   #16
renyo
Scooby Newbie
 
Member#: 93577
Join Date: Aug 2005
Chapter/Region: MAIC
Location: Orlando, unfortunately
Vehicle:
98 Impreza

Default

Quote:
Originally Posted by Storm View Post
Here's how I understand the overclocking to work in the case of rpm alone:

RPM limit of 6500: I put 10 spaces between each digit and * at 6.5 to indicate real time.
Code:
[1          2          3          4          5          6     *    7 ]
Overclocking will decrease those spaces by the percentage of change. Below is +20% or -2 spaces:
Code:
[1        2        3        4        5        6        7        8    ]
[1          2          3          4          5          6     *     7]
Line up the asterics to see the new rpm limit is 7800.

Hopefully the ascii art is coherent enough to understand. The ECU is still limiting the rpm at what it thinks is 6500rpm, but in real time, it's 7800rpm. It seems bass ackwards, but it is what the ECU does when it's measuring time at a different rate than in reality.
I added code tags, hopefully they'll help. The SSM protocol the early OBDII protocols uses actually uses a communications routine (based on some kinda timer I'm guessing) that is called every specific amount of time. It sends byes every 512us. With an 8MHz clock that's every 4096 clock cycles. In addition to bumping the redline, you should in theory be able to speed up the SSM protocol.. which would be nice..
renyo is offline   Reply With Quote
Old 04-07-2009, 10:31 AM   #17
fastenova
Scooby Specialist
 
Member#: 38829
Join Date: Jun 2003
Chapter/Region: NWIC
Location: Tigard, OR
Vehicle:
Not your usual 1997
Legacy GT

Default

Jay, what would truly be interesting is to do some detailed logging with the stock crystal and the faster one. (Using my switch would make this process easy and painless!) Log as many parameters as possible, like STFT, LTFT, idc, afr, and various voltages across as many sensors as one could get access to.

Unfortunately, to log all of these parameters, I think a fellow would need some sort of datalogger like this: http://www.innovatemotorsports.com/products/dl_32.php.

The PP6 piggyback I'm using has limited functionality for logging, as it dumps the logs to a csv file with seemingly arbitrary numbers to represent different values, and Perfect Power couldn't offer any assistance in making sense out of them. The LC-1 I have does a great job of providing AFR to an external device, but the PP6 is the only logging device I have.

Anyway, that way you could accurately say what else is affected. But it does seem like any problems would have shown themselves by now with the number of people running overclocked ECUs.

Aaron
fastenova is offline   Reply With Quote
Old 04-07-2009, 10:38 AM   #18
fastenova
Scooby Specialist
 
Member#: 38829
Join Date: Jun 2003
Chapter/Region: NWIC
Location: Tigard, OR
Vehicle:
Not your usual 1997
Legacy GT

Default

Quote:
Originally Posted by renyo View Post
I added code tags, hopefully they'll help. The SSM protocol the early OBDII protocols uses actually uses a communications routine (based on some kinda timer I'm guessing) that is called every specific amount of time. It sends byes every 512us. With an 8MHz clock that's every 4096 clock cycles. In addition to bumping the redline, you should in theory be able to speed up the SSM protocol.. which would be nice..
So this makes sense if you could change the speed at which the device communicating with the ECU receives and sends data at; but I'm not sure whether that option is available in most cases. The ISO 9141-2 protocol used by early OBD-II Subaru ECUs has a specific speed at which it communicates, 10.4 Kbps, and if you change the clockline, you're changing the speed at which the ECU is sending/receiving data. As I mentioned, this makes regular OBD-II communication impossible using ISO9141 on any standard scan tool.
fastenova is offline   Reply With Quote
Old 04-07-2009, 11:36 AM   #19
renyo
Scooby Newbie
 
Member#: 93577
Join Date: Aug 2005
Chapter/Region: MAIC
Location: Orlando, unfortunately
Vehicle:
98 Impreza

Default

Quote:
Originally Posted by fastenova View Post
So this makes sense if you could change the speed at which the device communicating with the ECU receives and sends data at; but I'm not sure whether that option is available in most cases. The ISO 9141-2 protocol used by early OBD-II Subaru ECUs has a specific speed at which it communicates, 10.4 Kbps, and if you change the clockline, you're changing the speed at which the ECU is sending/receiving data. As I mentioned, this makes regular OBD-II communication impossible using ISO9141 on any standard scan tool.
True, however I was referring to the first version of SSM, and talking with a laptop. People say that (along with OBDII) this first version of SSM is too slow for logging. If we can speed it up... (which like I said is done by the main programming calling a routine every ~512us) then it might make it viable for logging. There's not a huge amount of things SSM will report, but it's better than the OBD protocol and still has some pretty good parameters..

Edit: Also, 1953 (the SSM-1 baud rate) isn't standard anyway. If it can be sped up, maybe as an added bonus we can hit a standard baud rate.
renyo is offline   Reply With Quote
Old 04-07-2009, 11:46 AM   #20
fastenova
Scooby Specialist
 
Member#: 38829
Join Date: Jun 2003
Chapter/Region: NWIC
Location: Tigard, OR
Vehicle:
Not your usual 1997
Legacy GT

Default

Quote:
Originally Posted by renyo View Post
True, however I was referring to the first version of SSM, and talking with a laptop. People say that (along with OBDII) this first version of SSM is too slow for logging. If we can speed it up... (which like I said is done by the main programming calling a routine every ~512us) then it might make it viable for logging. There's not a huge amount of things SSM will report, but it's better than the OBD protocol and still has some pretty good parameters..

Edit: Also, 1953 (the SSM-1 baud rate) isn't standard anyway. If it can be sped up, maybe as an added bonus we can hit a standard baud rate.
Aha! OK, so help me understand this, because the only communication I've done with the ECU on my car is via OBD-II. I haven't ever gotten anything else to work.

Dealerships have a hardware device used for communicating via SSM. Or at least a hardware device that is in between their laptop and the OBD-II port, right? If you wanted to increase the bps wouldn't you have to speed up BOTH devices, that is, the ECU and the SSM box? I mean, being a serial protocol, the two must have a clockline that is synced up, so if one end is faster you won't be able to communicate unless the buffers are set up correctly...

I must be missing something. Can you elaborate a bit, please?
fastenova is offline   Reply With Quote
Old 04-07-2009, 12:26 PM   #21
renyo
Scooby Newbie
 
Member#: 93577
Join Date: Aug 2005
Chapter/Region: MAIC
Location: Orlando, unfortunately
Vehicle:
98 Impreza

Default

Quote:
Originally Posted by fastenova View Post
Aha! OK, so help me understand this, because the only communication I've done with the ECU on my car is via OBD-II. I haven't ever gotten anything else to work.

Dealerships have a hardware device used for communicating via SSM. Or at least a hardware device that is in between their laptop and the OBD-II port, right? If you wanted to increase the bps wouldn't you have to speed up BOTH devices, that is, the ECU and the SSM box? I mean, being a serial protocol, the two must have a clockline that is synced up, so if one end is faster you won't be able to communicate unless the buffers are set up correctly...

I must be missing something. Can you elaborate a bit, please?
Sure.. first only synchronous serial communication requires a clock line. I'm not completely sure about OBD-II but I know at least the SSM protocol is asynchronous. Asynchronous only requires Rx, Tx, and Gnd (although if the devices share the same ground I doubt it would be necessary other than for noise issues). Timing is done with start and stop bits transmitted with the data. Second, both OBDII and SSM protocols can be used with a laptop. True, you won't be able to use OBD-II or SSM handheld tools with the system because their internal clocks will be off like you're saying. The serial port on your laptop however, can generate a bunch of different baud rates. If we take the default SSM baud rate 1953, and manage to increase it via changing the crystal and make it, lets say 245.7% faster, we should be around 4800 baud. All we would have to do is set the laptop (or whatever we're communicating with it with) serial port to use 4800 instead of 1953 and it will communicate just fine.

Also, (I'm not as knowledgeable in the following as the above) but I thought the clock line in synchronous communication was produced by one of the devices and used by both.

Last edited by renyo; 04-07-2009 at 01:28 PM.
renyo is offline   Reply With Quote
Old 04-07-2009, 04:32 PM   #22
Storm
Scooby Guru
 
Member#: 5218
Join Date: Mar 2001
Chapter/Region: MWSOC
Location: SAUL'S Motorsports
Vehicle:
96L Most Over-
Developed Beater

Default

Well the logging bit and asynchronous baud rates just shot over my pea brain!!!!

When I get around to putting an OEM ECU back into the car, I will look into getting some logging info.

Jay
Storm is offline   Reply With Quote
Old 04-07-2009, 04:40 PM   #23
fastenova
Scooby Specialist
 
Member#: 38829
Join Date: Jun 2003
Chapter/Region: NWIC
Location: Tigard, OR
Vehicle:
Not your usual 1997
Legacy GT

Default

Quote:
Originally Posted by renyo View Post
Sure.. first only synchronous serial communication requires a clock line. I'm not completely sure about OBD-II but I know at least the SSM protocol is asynchronous. Asynchronous only requires Rx, Tx, and Gnd (although if the devices share the same ground I doubt it would be necessary other than for noise issues). Timing is done with start and stop bits transmitted with the data. Second, both OBDII and SSM protocols can be used with a laptop. True, you won't be able to use OBD-II or SSM handheld tools with the system because their internal clocks will be off like you're saying...
Thanks for the great info! I never knew about asyncronous serial comm. It totally makes sense, just never thought about it, I guess, and the only serial stuff I've worked with was synced up. As far as just one device generating the clockline, you may be right. Again, my experience is limited. I just know that both devices have an input/output for that function.

So, here's the problem I see. If the same crystal is used for both idle speed and OBD-II clockline, then if we speed up the OBD-II/SSM 250%, you're gonna have a car that idles at 1800RPM!!!

If a separate crystal was used just for the SSM/OBD-II then maybe you could only swap that out. But, at least on my ECU, there is only one crystal.
fastenova is offline   Reply With Quote
Old 04-07-2009, 06:44 PM   #24
Storm
Scooby Guru
 
Member#: 5218
Join Date: Mar 2001
Chapter/Region: MWSOC
Location: SAUL'S Motorsports
Vehicle:
96L Most Over-
Developed Beater

Default

I also never even thought about any of that stuff. I may try to reconnect with the laptop set to a different baud rate(if possible).

Jay
Storm is offline   Reply With Quote
Old 04-07-2009, 08:03 PM   #25
rivman05
Scooby Specialist
 
Member#: 159986
Join Date: Sep 2007
Chapter/Region: AKIC
Location: YK Delta
Vehicle:
1994 Acura Integra
Milano Red

Default

Ill chime in as Ive read the thread. Im a network tech and it depends really....the interface may have a different baud rate than teh actual device, secondly which is determinging clock rate, the ecu or the pc...the DTC (termination end) will use the supplied clock. the buffer issue might check out if you can get the baud rate close enough and give it enough head room for error, like with routers both are DTC capable, and sometimes that can cause an issue. Im thinking really hard since Ive been at a site for 3 days, and been up for 26 hrs troublshooting a switch stack...Im gonna get off and check back once i can think again. hyperterminal would be able to read things....maybe not textual tho depending, just throwing it out there, good luck and keep us posted as I wanted to over clock my 95 ecu...but leary about doing so.

Gabe Car
rivman05 is offline   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

Similar Threads
Thread Thread Starter Forum Replies Last Post
Impreza 2.2 ecu needed jrzpdx NWIC Private Classifieds 1 06-04-2010 05:41 PM
ECU Modifications in Street Prepared? FSelekler Motorsports 24 05-13-2004 11:24 AM
ECU Modifications for H6 StuartC Outback Forum 9 12-02-2003 08:54 AM
JECS ecu model nr? dpjef Engine Management & Tuning 2 06-04-2003 04:51 AM
STI - Know any European tuners for ECU modification? fassts4 Factory 2.0L Turbo Powertrain 2 06-20-2002 06:05 AM


All times are GMT -4. The time now is 09:13 PM.


Powered by vBulletin® Version 3.7.0
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Powered by Searchlight © 2014 Axivo Inc.
Copyright ©1999 - 2014, North American Subaru Impreza Owners Club, Inc.