hey guys, until I get my replacement cable, i figured Id try to do some troubleshooting the manual way. Update!!! took the ecu out and marked it where the input from a few sensors like the Fuel thermo, coolant thermo, tps, map and O2, goes into the ecu and found out that at the connection 1U, i'm getting a strong 12 volts. the FSM says that it should be 1.5 to 3.0 v which is the Fuel thermosensor. Could that be the problem, the ecu is being overloaded or something from the extra voltage or maybe it's responding to that voltage and doing something funky to the fuel curve? Im guessing here but im definitely getting 12 volts at connector 1U. The coolant thermo was about 3 volts so I assume thats ok. gonig to test the map after i finish my way too strong black medallion and coke!!! Dont hate!!

 

Awesome thread, suscribed.

 

"UPDATE" during the Map test, I found out that I was testing the wrong connection at the ecu for the fuel thermo. Not sure which one I actually tested cause the ecu was twisted around. I didnt want to stress the bundle but either way i found that the fuel and coolant thermos are fine "BUT"I also found that when I Give some throttle at idle, The wire at the ecu for the MAP signal is barely, if at all, changing voltage. AS I understand it, That voltage change is responsible for the air/fuel ratio. Hey, that sounds like my problem.

 

just purchased a stock sensor from "str8ryd" And as soon as it comes, I'll let ya know! Wish me luck.

 

You guys are lucky that I cant leave voice messages on this forum cause if I could, your ears would bleed from me shouting HOORAY!!!!!!!! All issues seem to be fixed. Replacement MAP is on and my baby is running like a champ!!!!! COLD AND AFTER WARM-UP. Dont worry, not boosting hard yet. Plus i have a boost leak anyway; which is actually good. I know exactly where it's coming from and will fix after break in period!!!!!!! Thank you all for all your help!

 

Hm... Anyone looked at the potential of production-grade building and selling of this? Members only, initially, of course.

I definitely think this could/ should be something that ought to be build and sold. I'd buy one!

Mebbe offer it like the MegaSquirt: Both assembled and as a kit.

 

Have you guys managed to use the simulation function with this approach? If that was possible it would be really cool.
Otherwise I think I will go with connecting every interesting cable at the PCME to my computer. That way I will have no problem with the update rate, number of signals or addresses, but I will never be able to control anything.

(By the way, I have been thinking to do this since february...)

 

Great stuff! Gonna order my parts today.

Do you know if it's possible to read data from the ECU beyond what's in the diagnostics tables? Seems like there's a much larger address space available. Specifically I'm looking for an easy way to read all the maps from the ECU. Suggestions?

 

The address space is a lot larger, however I have only tried reading addresses near the ones which contain the listed data. The majority of addresses seemed to return 0, one or two had data which seemed to change from time to time - but I only tried a range of 100 or so bytes. I suspect only a subset of the overall address space is able to be read, and only a subset of those addresses contain valid data.
Thus I don't think it is possible to read the ROM using this method, but I would love to be wrong!

I bought a PowerFC a recently, so I can't do anymore real time data gathering. However, I can still get it all working on my bench and work on the software if needed.

The japanese site listed in my original post has schematics for full map and real time map tracing on the stock ECU - he even made an emulator of sorts that allows for writable maps.

 

Hi Enervation,

I've built the adapter you posted and for some reason my ECU is not communicating with your program.

When I hook everything up and run your program I get...
- 6.6 Hz square wave on RTS which is opto-coupled to and verified on TEN
- data packets sent on TxD at about 2 per second (and 1ms per bit) going to FEN
- the same data packets are returned on RxD (feedback expected because of Q1)

So it looks like my adapter and your software are basically talking.

On the translated site he mentions a 20Hz square wave and I have a 6.6Hz wave. This makes me think the port settings might not be the same.

Could you please let us know your port settings? Is there anything else I might be missing?

Thanks!
- motor.man.alpha

 

If you're getting a 6.6 Hz wave, then something isn't right. The ECU will only communicate if the 20Hz wave is present.

The 20Hz wave is generated 'manually' in the software, indepdent from any other port settings. A multimedia timer is used, which is supposed to give precise timing - an event is called every 50ms, at which point the RTS pin is toggled.
I'll have a look when I get home, but perhaps try at the following:
- If you have a hardware COM port, try using that (without connecting the hardware) and look for the 20Hz wave.
- Perhaps your CPU is heavily loaded? (unlikely these days!)
- Try it on another PC (with the hardware, or perhaps just with a hardware com port).

If you're not afraid of software code, you can use the free Visual Studio C# express edition to compile/edit/run the software, and perhaps debug it on your PC that way.

Hope this helps. I'll try be of more use when I get home.

 

Some other interesting threads on similar topics about the stock ecu from HWND

https://www.rx7club.com/showthread.php?t=876250
https://www.rx7club.com/showthread.php?t=875273

 

Thanks Enervation,

I get the correct 20Hz wave when going directly through the com1 port on the computer. I get the bad 6.6Hz wave when going through my Prolific Technologies Inc. USB to RS232 converter, so I consider the mystery 6.6Hz wave problem solved (I just won't use the converter).

Unfortunately, I've tried two different cars (a 93 and a 94 US spec) and still don't see communication to your program.

I see on the translated site that he's talking to 16 bit ECUs, is this feature not available on the 8 bit ECUs?

Before I dig into the software too much, is there an easy command I could use to see if I'm talking at all, like using HyperTerminal and asking for MAP value?

My test machine is an older, 650Mhz P3 with 256Meg Ram, XP Pro SP3 with .NET framework 3.5, but I can try it on a faster machine.

I don't expect you to fix everything, but would love to have your input.
Thanks,
mma

 

Hi motorman,

The prolific devices are very odd, we have had alot of issues with them at work. FTDI make far, far better usb-serial converters! But nothing beats a real COM port!

My car was (it's now got a powerFC) the JDM 8 bit ecu, code N3A8, for an automatic car. So I can guarantee it works on 8 bit JDM ecu's. As I said earlier, I can only assume it will work on the US spec ones (can't remember the exact code, something like N3A1???). I see no reason why they would change it, as they are almost identical.

More things to check:

1. I assume you have a 'scope of some form if you're able to measure the frequency? - The data being transmitted on the FEN terminal should be at 976 baud, or in other words, a bit length of 1.024ms. If you can't find any pulses of this length then your COM port isn't able to run at 976 baud.

2. As soon as the 20HZ wave is applied, the ECU automatically spits out the ECU code (as well as some other junk and checksum etc). Doing this via hyperterminal is a bit tricky as you can't get hyperterminal to toggle TEN at 20Hz!
However, if you put a scope on the FEN line and turn my program on (so the 20HZ wave starts), you *should* see a burst of data on the FEN line.

 

Excellent Enervation, you've enlightened me!

To answer your questions first... yes 1ms pulses are there, and our ECU model number is N3C1A.

So I made a 0-12 volt 50% square wave with a function generator and the ECU spit out the pulses you described perfectly. The FEN line goes high and pulls down to show data bits.

But I remembered when connected to the computer the FEN data was *low* and went *high* to show data. So I checked the polarity of the data on the RS232 side and found that TxD is low most of the time and only goes high to show data. I think this is the issue. On your schematic follow this...

If TxD is usually low, then the optoisolator is usually lit, then Q1 has base current, then FEN is pulled low! That's why I saw matching pulses. When TxD goes high is the only time that FEN could possibly send any information! It is otherwise blocked! The essence of the problem.

So I can prove...
- FEN goes high and sends data by pulling low
and I can conclude...
- FEN gets data being pulled low.

So I question the polarity of the data on the serial port since TxD appears reversed. Twan also saw his Led's on all the time, so his data was blocked as well.

Now my questions: Is there a software setting that could be flipping the data? Is the schematic missing one or more inverters?

Thanks!
mma

 

Good progress! Your ECU is evidently capable of data comms if it is spitting the code out, so that's promising.

However, I believe you must be mistaken where you say

"TxD is low most of the time and only goes high to show data"

This isn't the case for RS232, which is high for 0bit/idle, and low for 1bit.

If you're using the hardware COM port note that the data lines go from +12V (0 bit) to -12V (1 bit). I don't think you will be able to use the hardware COM port without level conversion hardware.
Note that your prolific USB device is *probably* converting the levels to +12/-12V, which won't be suitable.
That's why I used the FTDI TTL level cable, which has the voltage levels at 0-5V, with 5V being idle/0bit, and 0V being a 1bit.

It isn't really possible to flip the bits in software, as the RS232 protocol has a start bit, 8 data bits, and a stop bit. The start and stop bits must be a 1 (low voltage), and it isn't possible to change this in software. I can, however, easily invert the data bits but that won't do anything if the start and stop bits aren't detected!

Sorry I can't help you more at the moment, but I can say the schematic is accurate, there are no additional inverters needed, nor are my optocouplers inverting. If I were to guess, you're not using a TTL level RS232-Serial converter?

However, if you're convinced that what you've got is correct, but just inverted, then (off the top of my head... which isn't all that bright today!) wouldn't it be possible to invert the data lines by simply reversing the LED/transmitter side of the optocoupler?

 

I've thought about this for a while...
Would anyone be interested in buying pre-made and tested devices?

If there is enough interest, I can put design a PCB and route them out at my work on a prototyope PCB router. This should make it robust and small, and I can mount it nicely in a small box. I would guess the cost would be about US $50, around half of which is the USB-serial converter cable.

I figured if anyone needs something like this for diagnostic uses, such as a rotary shop or someone who wants to stick with the stock ECU, then they may be interested.
However due to the potential differences in ECUs, it would be good if someone can verify that it works 100% with the USA spec ECU (especially the variable addresses).

 

I suspect that their would be people interested in that option but I would make to order if you can rather than pre-made. Demand might not be huge except to a select few such as shops.

There are plenty of people with stock ECUs sitting in the garage. Do you want someone from US to send you one for testing?

Anyone want to donate a stock ECU to the cause?

 

Hi Enervation,

You are correct that I am using a standard rs232 port. I thought you were using a generic converter, I didn't realize it was TTL converting. I never thought twice about the old rs232 levels.

Don't worry about inverting the signal or anything since the two are obviously incompatible. I'll either buy the proper cable or rebuild my converter and set it up for +12/-12.

It's a great idea for you to sell the pre-built cables! You should charge more like $60 to $80. We want you to stay in business.

I'll try to verify for you that it talks to the US spec in the next few days, it's the least I can do for all of your contributions to the group and myself.

Thanks again,
motor.man.alpha

 

More than happy to help. This forum has given more to me than I can ever hope to give back.

Don't worry about shipping me an ECU, it would really be better if I shipped my prototype unit to one of you fellas in the states so you can have a test with it.

But if motorman gets his working soon then that is even better

As I said, do let me know if you or anyone you know will be interested in one. If there are more than a handful I can make a batch up (with some kind of deposit, largely for the cable).

 

Well, just ordered everything. I am hoping this will help debug my "limp" mode engine problems. Have we verified it works on the US ECUs yet?

 

Hi Enervation,

I ordered the TTL cable last week and it arrived today. After removing my RS232 connector and installing the 6 pin SIP everything worked great! Thank you for your post!

I can't use the gauge feature very well, but I think that's because it's a slow computer. If I limit myself to just the list view then everything is reliably refreshed every 10 seconds or so. This is exactly what I needed.

Here's the build...
http://www.flickr.com/photos/motormanalpha/5283479131/

Now I am doing all this on the benchtop, so I haven't verified that the data displayed is correct yet. I'll be getting to that in the next week or so.

So, to help you out - What are you calling the "variable addresses" and how would you like them verified?

Thanks again!
mma

 

Great news Glad it worked out.

The gauge feature is certainly very resource intensive - It works fine on my quad core desktop, but on a little netbook its pretty laggy. Making the gauges window small helps, as it is the drawing routines that are slow - so the less pixels to draw, the less work it needs to do.

When I say 'variables addresses', I'm referring to the 'address' in the following process, for example:
1. You set up a gauge that is to display RPM.
2. The PC sends a request to the ECU for data from 'address' 0x002C.
3. The ECU sends back a few bytes of information.
4. The PC then converts the data and displays the RPM.

Now depending on the series of the ECU (ie 1992-95, 96-98, or 99+), the same data reading may be stored at different addresses.
In this case the ECU will still return data to the PC, but the data will generally be meaningless junk.

I expect that the US ECUs will be 99% identical to the Series6 JDM ones (which the software was designed for), so the addresses will all be setup already in the software.

When you actually start using the device on a live car, if you find that any readings are weird (too high, low, or not changing) then chances are the address for that reading isn't correct for that ECU type. If so, let me know and I may be able to help with finding the correct address.
So if you find everything works, and the readings are correct, then you've verified that it works on your ECU type.


Just a note on the main list view, if you untick all but a few rows, then the rows left checked will be updated much, much faster.

Enjoy, and have a merry xmas

 

Hi Enervation,

The logging looks good! You're a genius!

I've got three files for you... the first two are generated log files from two different cars and the third is a summary showing the min's and max's

- car 1 is my car (US 1994 with pipes)
- car 2 is my friend's car (US 1993 with pipes) that currently has an over-boosting problem (sticky primary turbo)
- and the summary is just to save you the time of going through the logs. Numbers colored green match and are probably the control limits, numbers in red have significant and interesting differences.

Hope this helps you out, you sure helped me out!
Thanks!
- Matt (mma) -

 

Looking good!
Everything certainly looks within spec (except for perhaps idle speed control, but I remember that was also whacky on my one too). All values are changing, which indicates that the addresses are all correct.

Thanks for sharing that, it looks as though the software works for both US spec and 1992-1995 JDM RX7s