My guess is that LAN is the "guru" to be chatting with on this...
-Bill

I'll take whatever help I can get. All I'm asking at present is whether the values shown in the screen shot are reasonable for an EG33 running at 2000rpm.

I reckon the RPM, TEMP, MAF, LOAD and TPS are right and the knock correction might be wrong. The others I don't really don't know if the values are within the ballpark or not.

Phil, you are doing some great work.

I therefore hope that my opinion, in answer to your query, may make you happy, i.e. that your ignition advance figure appears OK, at something around 42 degrees.

At light loads, as in normal everyday cruise conditions, an ignition advance of 36 - 40 degrees is now common. Engines with very good combustion chamber design will be able to run up to 45 degrees in these conditions. Fuel economy is obviously very much dependant on light load ignition timing.

At high loads and engine speed there can be large variations, engine to engine. I have seen specs from 10 to 30 degrees. Obviously there are many variables involved including fuel octane rating.

You will appreciate all of the above comments are confined to normally aspirated engines.

Cheers, Trevor.

Thanks Trevor, your wisdom is appreciated as always.

I just had another peek at the code on my lunch break and I've found the parameters for battery voltage and vehicle speed - so the top two rows of gauges are fully populated now.

This is awesome! Ever since Vikash put out the code for the first-gen Legacy I've wanted to try this, and now there's gonna be an SVX version.:D Sadly I don't know any assembly so I can't be of much use except as a beta tester. I've got an old omnibook sitting around with the proper port, I just have to make the Serial->SM plug for it.

I read through the info on your site... I'd say SVXride is right. At least for the fuel maps, you should try to get in touch with Longassname. He's written his own for the SVX, so I think he's the resident genius in that field. :)

SVXRide & Nomake Wan,

I am aware that Longassname has done all this work before and is the established expert in the matter. But I deliberately haven't asked him because he is in the ECU tuning business and I don't think it's fair to ask him to give away his commercial secrets. If he wishes to volunteer some information then that is his call.

I am not in the engine tuning business and I will make public whatever information I can find about the ECU for the benefit of the SVX community. I am hoping by making this knowledge available, that other people will build upon it and we'll see some interesting new developments.

Phil.

MED text editor is a great assembly language editor (supports higher level languges too). I find it simple to use and I appreciate the color coding when sifting through code.
MED Programmer's Editor
If you want to try another program. There is ASM IDE which is another simple yet useful tool. I use it with my Dragon12 board for assembly programming.
Embedded Tools by Eric Engler
Now that school's out, I think I will try to sit down with that code and see whats going. I am not knowledgable about engines so I will ask some local SVXers for help in that area(odepaj, sa svx - I'm thinking of you guys!). :)
cheers!
Marisa

Hi Marisa,

Thanks for your interest. The job is sure to be easier with two of us working on it.

Be sure to pick up the latest copy of the disassembled code from my website. I uploaded an updated copy a few minutes ago. I've fixed up areas where the disassembler got confused by inline data or incorrect M flag. I've broken it down into subroutines and added some comments.

I'll be adding further comments as my analysis continues.

Phil.

I think I downloaded the latest code from your site and hoping I can work through it on my free time. My mom has me going over to do a few projects for her. One being - installing a new laminate floor in her living room this week. So we'll see how much free time I can get my hands on! :)
Take care,
Marisa

Greetings Marisa,

It is the little asides within the technical stuff, that make this site so interesting. You must be jack of all trades, which is an attribute close to my heart. :D

P.S. All the best to you both, in your combined effort. *<)

I found this thread over at Legacy Central, where they discuss getting into the ECU on Legacy's. I'm not sure if any of it would be useful to those trying to get into the SVX ECU, but I thought I'd post it for your info.

Thanks Hocrest,

I've seen that thread before, and yes it is relevant. Thanks for posting it.

Vikash made some comments on Legacy Central about the scaling formulas being wrong in the vwrx software. I had a look at his software and there are some differences. I can't say who is right and who is wrong.

For example, suppose the ECU stores the TPS voltage value as F8 hex.
Kevin's vwrx software calculates (N * 5) / 256 and reports 4.84 volts
Vikash's legacy software calculates N / 50 and reports 4.96 volts

At some point I'll check with a voltmeter and see which one is correct. Assuming my cheapo meter can measure accurately to 0.01v.

There are other examples too. If you look back at the screenshot of the vwrx software, you will see that the knock correction is reported as 128 degrees. According to Vikash's source code, the number 128 actually corresponds to 0 degrees retard. It counts up in quarter degree increments. 129 is 0.25 degrees retard, 130 is 0.5 degrees, 131 is 0.75 degrees etc. Presumably this value is subtracted from the ignition advance value somewhere in the ECU code.

I don't want to say that one software is better than the other, just to highlight that the values reported by either one may not be spot on.

I wonder if Vikash's rounded calculations might be wrong?

My reasoning is because when reading voltages there must be some kind of A/D conversion going on (A/D => analog to digital). Normal analog conversion will produce something along the lines of 1024, 256, 512, 2^N.. etc.. Vikash's formula just took Kevin's and factored it out. (i.e. 5/256 => 1/51.2 and Vikash is essentially multiplying by 1/50). Depending on the # of bit conversion, rounding can loose a lot or just a little bit of information.
So I would think Vikash's math is losing some of the original value and therefore isn't as accurate unless he is trying to compensate for some kind of sampling error not mentioned??
just some thoughts...

~Marisa

p.s. I just like to try a little of anything. I like taking stuff apart and then seeing if I can put it back in working order (except with my SVX! I love her running:)). I enjoy building things most of all.. I don't really care what.. just putting stuff together is fun enough for me..

I see what you're saying. 5 volts being the max and 256 being the number of steps, so 5/256 sounds right. Vikash's code simply left shifts the value and displays it to 2 decimal places. ie. N*2/100 = N/50

Thinking about it some more, wouldn't 5/255 make more sense? That way 0x00=0v and 0xFF=5v. Otherwise 0xFF=4.98 Kevin's way or 5.10 VIkash's way.

I'll have a read of the m377 datasheet and see what it says about how the built in A/D converters work. That's of course assuming that the TPS is connected to one of the internal A/D converters rather than an external one on the board.

Hi Phil,

You are way out of my league on this, but it would appear that you are assuming that an analogue voltage signal from the TPS, comprises the input component and can be directly related.

The manual shows a quite wide tolerance in respect of correct voltage under test. I would not expect otherwise. It would be likely that the voltage is only presented as a means of testing.

It is possible/likely that the TPS comprises part of an interface circuit. This could take the form of a bridge or an operational amplifier (A single IC), so that the final output, is in the form of an accurate variable, as the result of comparison with a known value.

I am likely off the track, but you have called for ideas. :confused: ;)