Quote:
|
The absolute best way to troubleshoot communications is with the Hex Com Tool.
Send a command eg. "78123400" and observe what the ECU sends back. It should be three bytes repeated over and over, the first two being the address and the last being the data. Something like "123400123400123400123400.....". If there is any corruption then you need the "92 problem" comparator board. I haven't tried the port monitor software myself, so I can't comment on that. The VWRX software is great, but it does have some bugs, which we can't fix without access to the source code. It does not seem to clear the input buffer when sending a new command, nor validate the data being returned. So if there is any data left in the buffer from the previous command then it assumes that is the reply from the current command.:rolleyes: I also suspect that it polls the port rather than being interrupt driven. That means the program repeatedly asks the interface if there is any data available rather than the interface informing the program when data is received. Reading the data using polling can cause a loss of sync if the buffer overflows in between polls. My linux software, while is isn't pretty or user-friendly, goes to a lot of trouble to ensure that the data returned is accurate. |
i actually got the idea for trying the port monitor from using hexcomm. i'd get back something like:
123400123400 1234 00123400 123400123400123400 so i thought it was just a formatting issue. then, while running something in the foreground, i saw a good pure: 12340012340012340012340012340012340012340012340012 3400123400 12340012340012340012340012340012340012340012340012 3400123400 coming out, leading me to thinking it was a CPU or buffering issue. that's when i tried portmon (a GREAT free tool btw: http://sysinternals.com) and saw the improvement. i never saw corruption in the actual 123400 being returned, so thought the comparator might not be the issue.... |
Quote:
|
Yeah. Like Nomake said, you don't have the "92 problem" and you don't need the comparator. I reckon the issue you see is due to the serial input buffer overflowing in between being polled by the VWRX software. Presumably the portmon software is changing the port buffer settings in some way that helps. That's good to know.:)
You could also try messing with the registry values in HKLM\SYSTEM\CurrentControlSet\Services\Serial technet reference page |
Sorry if this is old hat, but I'm way behind on this thread and there's just too much to read. :P
Is there a windows tool for dumping the memory from a stock ecu yet? I'd rather not do the Linux stuff, just to save time. |
Quote:
Tom |
At the moment, there is no Windows application. However, there is a way to run Linux applications natively within Windows which you might want to check out.
http://www.ulteo.com/home/en/home?autolang=en |
I don't have any experience at writing software for Windows. Only DOS, Unix, IBM Mainframes and Telco equipment.
That ulteo thing looks interesting. Please let me know if it works. I tried to compile the ecudump software under cygwin once but it seemed to be missing some libraries. |
Hey Joe, did you get the chance to try out that TCU yet, or is it on hold until you fix the Jersery Girl?
|
It's on hold
Phil, I may actually get a chance over the next few weeks, but the gearbox problem has to be a priority.
The main problem I face could be that all clutch friction material may have a tenuous grip on the metal parts, and more driving will remove more material. [As a consequence of the water mixing with the ATF] If it is the case that the brake band was out of tension and needed adjustment, and that the friction material still remains on the band, then my problem may only be one of adjustment. That's what I'm hoping. :rolleyes: My initial plan is to replace the fluid this weekend, check the filter in the sump while doing so, and adjust the band. If that works and gives me all four gears, then I am good to go :). As I'm sure you realise, testing the remapped TCU while having these physical problems with the transmission will not give us any kind of reliable comparison. Fingers crossed. Joe :) |
Quote:
I'll hack together a little vb.net utility. With MS Express its free and easy to do little stuff like this. |
Solenoid A
Having read about Harvey's new gadget I started looking at how the solenoid A duty cycle gets generated by the TCU. The QC shift kit, as I understand it, generates a duty cycle that is proportional to the throttle opening.
I haven't managed to figure it all out yet, because there are still lots of unknown variables in the code. But it looks like the TCU also bases the sol A duty cycle on the throttle opening. For a USDM TCU, the function in question starts at location EBAA in the TCU code. At location EC49, it selects a map, based on the gear that the transmission is currently in. A different map is used depending on whether the car is in 1st, 2nd, 3rd or 4th. The maps describe a graph using the straight line formula y=mx+c and each map has up to 6 segments. For example: The map for 2nd gear is stored at 0xCABE and it looks like this: 1F 3E 2580 3F 4B 23F0 5F 0C 3390 7F 0C 3390 BF 03 3840 FF 19 27D8 The first byte is X, the throttle signal as a proportion. 00 is closed, FF is full. The second byte is M, the gradient of the line. The third and 4th bytes are a 16 bit word representing C, the Y offset of the line. Converted from hex to decimal it looks like this: 012% 62 9600 025% 75 9200 037% 12 13200 075% 03 14400 100% 25 10200 This means from 0 to 12% throttle, the duty cycle is ( 62 x throttle ) + 9600. From 12% to 25% it is ( 75 x throttle ) + 9200. To convert the result Y to a percentage, you divide it by 200. I have plotted the duty cycle versus throttle opening graphs for each gear. http://www.alcyone.org.uk/ssm/tcu/solAduty.jpg But there is more to it that I haven't analysed yet. For vehicles fitted with an atmospheric pressure sensor (USDM and any others with the 2nd byte of the ROM ID less than 55), the TCU subtracts a correction value based on the atmospheric pressure and throttle opening. Then later it adds a correction based on the current gear and vehicle speed. Then there is the question of how the TCU calculates the duty cycle to reduce the line pressure during gear changes. I don't know yet. It seems to me that a similar effect to Harvey's QC could be achieved in software by simply modifying the data in these maps to change the shape of the graphs. Obviously a lot more analysis is required before any kind of TCU mod could be developed. When I'm a little less busy, I'm going to use my TCUSCAN program to log the duty cycle and throttle opening values on my car and try to reconcile them with the graph to make sure I'm on the right track. |
Re: Solenoid A
Quote:
There is also a gross misunderstanding recorded within the description of the gadget, regarding the effect of throttle position. This is in no way association with the signal delivered via the resistor. The TPS signal is normally processed and the duty cycle to solenoid A modified in accordance with total requirements, including gear shifting. (P.S. and throttle position. Quote -- "But it looks like the TCU also bases the sol A duty cycle on the throttle opening.") |
Re: Memory dump of ECU
Check this out! A guy from UKLegacy alerted me to it. A nice diagnostics and datalogging program for Windows that supposedly works with the SVX and other Subarus. :D Unfortunately it's not free, but it is cheap. I haven't tried it yet, but I certainly plan to have a look at it.
http://www.limitless.co.nz/ http://www.limitless.co.nz/EvoScan/i...augeLayout.gif I can't help wondering if they borrowed some of our research for this. I don't see how else they could find the memory locations for the SVX without having access to an SVX to experiment with.;) |
All times are GMT -6. The time now is 08:57 PM. |
Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
© 2001-2015 SVX World Network
(208)-906-1122