MEMS 1.3

[Alex van Zanten]

Hi, 

my son owns a 1991 SPI with the MNE 10097 Mems. According to the web, this is a mems 1.3 version. Since the car has a catalist converter, i assume this is correct.

As the car is running a bit rough lately, we started using Mems-scan from Haro. Which is a 1.6 scanner.

Does anyone know we can use the Mems 1.6 scanner for the mems 1.3. Specifically regarding the meaning of the faultcodes?

Sofar 2 issues are persistant: 06 feul temp sensor (which the car doesn't have) and  18 one of the unknown codes.

We also downloaded MemsAnalyser and will be gathering logfiles from a drive.

We hope someone knows of any differences between mems1.3 and mems1.6.

Best regards, Alex.

[Martin Rubenstein]

Welcome, Alex.

From the Wikipedia on Rover MEMS:

“1.3: Designed with capability to control emissions-related equipment. ECU has two connectors (one 36-pin and one 18-pin).
1.6: Finned aluminum enclosure with single 36-pin connector.”

Don’t worry about the fuel temperature: I also do not have that sensor but it shows as a fault. Just ignore it. Not sure about unknown 18. Perhaps you will attach the logfile when you get one.

I may well be totally wrong but I thought that all the MEMS diagnostic programs read 1.3 and 1.6, but only the Android app can read 1.9 in addition. (I thought Al Richey, the MEMSAnalyser and MEMSLogger developer, answered this recently but I can find it in the ECU Readers topic on this group, which is where I thought it was. But the fact that you have got one of the programs to work seems to confirm that.

[Alan Richey]

Bot me I'm afraid, I don't recall discussing 1.3 at all.

[Martin Rubenstein]

Looking through an article I wrote about the diagnostic packages, at that time there were just 3, it looks as if Colin Bourassa’s original MEMSGauge only supported MEMS 1.6, and so the derivatives might be the same, but the Android app MEMS Diag supports 1.3, 1.6 and 1.9. Nevertheless, you must be reading something to know about Unknown 18 and fuel temp.

[Alex van Zanten]

Mems-scan indeed shows all kinds of information. What doesn't seems to work is adjusting of some of the values.

We recorded a drive this morning. Car runs bad, no idle, rough in low speeds, runs rich. On return some smoke was visible at the rear off the inlet manifold, my guess is the manifold heater unit that isn't being shut off.

The only errors visible were the fuel tempsensor and numbers 17 and 18.

 

Unfortunately memsanalyser isn't able to recognize the logfile of mems-scan (even the mems-diag demo file gets a runtime error '13' type mismatch).

And our logfile is judged as 'Not a valid MEMS data file', still it is a csv.

Anybody any suggestions on the logfile?

Regards, Alex.

[Alan Richey]

Logfile should be a text file not a csv.   Send a copy to al...@rmrsoft.com and I'll look at it.

[Martin Rubenstein]

I doubt that the manifold heater is affecting your car in any way. I’m not sure when (coolant temp) it turns off, but that could only be to save electrical power: if it never shut off, I can’t see it causing any problems at all. And I expect the inlet manifold gets hotter than that heater.

I’ve had that problem on several occasions with MEMSAnalyser not recognising the logfile. Strange it doesn’t open the demo file. Are you on Windows 10? Do you have access to a Windows 7 laptop? Is MEMSAnalyser up to date? Unfortunately, I rarely use these programs now so each time I do there’s a bit of a re-learning curve, and I can’t recall how I overcome that MEMSAnalyser error. One way I have in the past is to make my logfile using MENSLogger, Al Richey’s “sister” program to MEMSAnalyser, but that too has plenty of gotchas. I have to give it admin rights to run and you have to edit the .bat file beforehand to ensure the correct COM port is specified (for you lead) and the correct file location is specified. Clearly, though, you’ll want to get MEMSAnalyser reading its own demo files first otherwise you’ll be chasing too many variables.

I’m sorry I my memory isn’t better; I just keep persevering. One fragment of memory I think: in the past I ran MEMSAnalyser from my desktop (not even on the C drive) and I fixed it by following Al’s advice and made a C:\Spare folder and put it in there. I think it was an update to Windows 10 that forced that on me. But do read and digest the Readme in Al’s MEMSAnalyser package.

[Alan Richey]

I'm sorry about that.  The reason we have so much trouble is that I was trying to keep MEMSAnalyser compatible with 4 diagnostic programs, MEMSLogger, MEMSScan, MEMSRosco and MEMSGuage.   And each of the authors, understandably, kept making slight adjustments to their programs that affected the log files.  So I was continually having to tweak the program to adapt.   So unless you had matching versions it wouldn't work.

I have settled on MEMSScan as my personal favourite and have packaged a version together with a version of MEMSAnalyser that are guaranteed to work together (I hope)

Get it from www.rmrsoft.com/mems-scan.zip

Al

[Alex van Zanten]

Wow, this is more than i could hope for. What a service Al. Works like a charm. Even with the memsscan 0.5.2 version we are currently using.

For the others, we are using windows 10.

The recorded log is a .txt file, but the content is comma seperated, hence my referral to the file as a csv.

Were off examing the logging!

Again, many tanks Al for the big service.

Regards, Alex.

[Alex van Zanten]

Looks like the values of the lambda sensor are of the chart. But during the drive mems-scan didn't show any warning regarding the lambda.

Halfway i reset the adjustments. Mainly because the idle speed offset showed a value of -650 rpm (minus 650?). But still no idle and the value stayed -650 rpm.

Mind you, this uses the idle throttlepedal switch inside the car.

The two longer continues periods (4.8~6.5 and 9.6~11.5) are motorway readings. 

The readings are somewhat diffucult to interpret as the car stalled every time during down shifting.

The error of the air temp sensor was erased at the start of the recording and didn't return. I don't know for sure, but next time we will erase any errors before starting the log recording.   

For the diehards, i enclosed the log file and two prints of memsanalyser.

Any suggestions are welcome.

Regards, Alex.

[leopold....@t-online.de]

seems to be a comon fault.Check your low pressure lines.Map is always between 95 and 100.Should be 30 to 40 when idling!

[leopold....@t-online.de]

If you had read the help-file first, there is a link to blackbox solutions where all the values are explained and how mems will work with them.
When doing your drivers license you had to study rules before too. :-)

[Martin Rubenstein]

Alex,

Looks like Leopold is 100% right: the MAP sensor vacuum hose.    Be careful getting it off the ECU if it's stuck: the  ECU connection is plastic and can be damaged if you are rough.

I could not read your log file with MEMSAnalyser,     I get: not a valid MEMS data file,    So I don't know how you managed to get the screenshots from MEMSAnalyser.       I used the MEMSAnalyser program from the link Al Richey posted.    I also tried several older versions without success.    Did you do anything special to get SPi1991.txt to open in MEMSAnalyser?

But Leopold's mems-rosco-chart programs read your logfile.     That would account for the poor running and smoke: the ECU thinks the car is under maximum load all the time and is overfuelling.    (Hopefully, your catalytic converter isn't damaged by overfuelling.     Did the exhaust stink of petrol?)   However, when I look at your lambda readings with Leopold's program, lambda voltage seems not unreasonable for a rich mixture (because of the MAP readings).       Had I only looked at the MEMSAnalyser lambda screenshot I would have thought you also had a problem there.

As for the smoke from the inlet manifold: has the car stood for a while and do you have an oil leak from the camshaft cover gasket (rocker box cover gasket) and the oil has run down and settled in the depressions in the inlet manifold?    Is it just engine oil smoking off a hot manifold?

[Alan Richey]

I couldn't read it either.  I suspect it's because Alex is using a different MEMSScan to the one in my package.   No idea why he can read it.  That's what I love about computers, they are totally illogical.

But I am not sure it is actually reading it correctly the weird lanbda trace indicates that MEMS Analyser is not reading the data correctly, so I would be wary of using the results.  If Alex installs the MEMSScan in my package then I think it will give a better log file that will give a truer picture.

[Alex van Zanten]

Thanks Leopold for pointing out the map pressure of 95-100. I will check the lines again. I fixed a torn rubber elbow connection and had to replace 2 old elbow connector which crumbled in my hands.

But apparently there still is a problem.

I don't know exactly which help-file you refer to, i only have readme files. I read all the readme files, but not the one provided by alan with his zip of 15:28.

And that readme file contains a lot of practical info, exactly what i have been looking for. Thanks again alan for supplying this info.

I studied all the messages in this group, as well as provided links, but didn't find any information which made any sense to me.

The only thing i recall is a list of values scanned, but no suggestion on what boundaries are normal. 

Perhaps you can provide me with the link you refer as a future reference for me.

Funny how software works sometimes. I copied the MEMSanalyse from the 15:28 zip into my memms-scan directory and was able to open up the log file. We use mems-scan 0.5.2.

Looking at the MEMSAnalyser version i downloade before and the one from the 15:28 zip-file, I noticed both version are the 2.0 version. Anyway we now have a working combination.

Again, thank you all for thinking along with us.

We will keep you posted on any developments.

Regards, Alex.

[Alan Richey]

I've managed to make the logfile readable by my MEMSAnalyser.   A copy is attached.

I see the MAP stays at 15psi all time so you were right about the vacuum no making it to the ECU.

The lamda sensor is unusable so there is no short term fuel adjustment.   It either needs a new sensor or it does bear some resemble to a readout I got when the signal lead from the sensor to the ECU was not screened properly.

The good news is the alternator looks healthy :-)

[Alan Richey]

Alex.   Just so you can see what you should be seeing here is one from my car.   Note the lamda sensor should rapidly cycle between top and bottom, and that the MAP (Manifold pressure) should drop to about 6psi when you rev the engine and only go to 15psi when idling

[Alex van Zanten]

Got it, Leopold refered to https://blackbox-solutions.com/help/SM002.html. I indeed read thouroughly through the text at the bottom. Sorry.

[Alan Richey]

Some other 'oddities'

1.   My air/fuel ration seems fixed at 143 and I had assume that was what the ECU was aiming for, ie a 14.3 to 1 ratio.  But yours wanders all over the place.   But we need to see the result of you fixing the lambda sensor and the vacuum line, as they be screwing it up.

2.  My crank sensor switches from 0 to 1 when I start the engine, and stays there.  Yours is all over the place.   May be faulty or again, may not be screened properly.  Could explain a lot.

Cheers

Al

[leopold....@t-online.de]

Hi Alex, this is a very good guide for repairing SPI problems :http://www.theminiforum.co.uk/forums/topic/20533-having-problems-with-spi-single-point-injection/

Hi Al, nice to hear from you here again.
I do not think that the lambda sensor is bad, when you have a look to the curve you see it is working but as it stays for long times at about 900mV  ecu does not switch to closed loop even lambda status is 1. I think when map is ok lambda will swing and closed loop will apear.
About the air fuel ratio: I can not see any abnormal behavior it starts with 8.4 and settles at 12. what means engine is running very rich, no swinging!
With the idle switch you may be right, possibly it sticks in its on-position. I would flood it with some contact spray (WD40) and press it a view times until it shows Zero in all readings when idling.

We want the next logfile
Leopold

[Andrew Jackson]

@leopold you mention "air fuel ratio: I can not see any abnormal behavior it starts with 8.4 and settles at 12."

Maybe a stupid question .. 

Is this a ratio? (8.4:1, 12:1)? 

What are the nominal 'good' boundaries for this value?

Best Regards

[leopold]

Yes and see here:https://en.wikipedia.org/wiki/Air%E2%80%93fuel_ratio

Best is at 14,7:1

[Alex van Zanten]

I have new results. fixed several leakes in the vacuum lines and ordered all new lines. Those rubber elbows are not very sturdy if they fail after only three years.

I checked the pedalswitch. It moves freely.

Were able make a testrun just now. The car runs way to rich and still no cold run. Idle rpm is just 600.

Looking at the graphs to me it seems all the sensors are working fine.

We suspect the steppermotor isn't working. After turning on the ignition, the fuel pump primes, but we no longer hear the clicker-the-click of the steppermotor.

I have a spare one. Any tips on measuring the steppermotor are welcome. 

I attached the new logfile. If anyone sees something out of the ordinary, please let us know.

Regards, Alex.

[Alan Richey]

It looks much healthier.   The lambda sensor seems to indicate the fuel mixture is correct, not running rich.

It may be different on MEMS 1.3, but on MEMS 1.6 the stepper motor works AFTER you turn off the engine and resets to the start position.  You don't hear anything at startup.

For those who get "Not a valid MEMS file" I have attached a fixed version.

Al

[leopold]

Hi Alex, hi Al
like Al said, everything looks much better now.I see a few things what make me wonder,
can you state that nobody changed the setting of the upper screw on the photo.Is the cable as loose that the lever is on midpoint ? If both is yes, i would do a reset of the ecu with memsscan or mems rosco. Then drive the car for a few miles.Then have a logfile again. If longtermfueltrim is still at 134 then set it down to 125 on the trim-table and drive it for a while and logfile again. Additionally do a logfile  with ignition on but engine off. I would like to see if throttle pot corresponds to throttle angle and as well what idleswitch is doing. If you have a voltmeter you could check idleswitch on its own. When pressed  it should be open!
At the moment your longtermfueltrim is at 134 what means your engine is running to rich in total. Normal value for ltftr is between 125 and 128. You would not pass mot at the moment,. CO is too high.
Your throttle angle is always greater than 25.
But your lambda sensor is working well, map is working and IAC is working, so don`t touch the stepper.
Do one after the other not all at the same time.

[leopold]

The picture is from here:http://www.theminiforum.co.uk/forums/topic/20533-having-problems-with-spi-single-point-injection/
rights are by "Sprocket"
I hope he will excuse me for publishing it here.

[Martin Rubenstein]

Unlike Leopold, I would hesitate to alter the Long Term Fuel Trim (LTFT) for a couple of reasons:

1. Your LTFT is higher than 125 is because of your previous vacuum leaks. The lambda sensor, reading a weaker-than-normal mixture, caused the ECU to add more fuel. Now that you’ve fixed those leaks, the ECU doesn’t need to add more-than-normak fuel. And, after a bit of urban driving (idling at traffic lights etc) you should see the ECU bring down the LTFT. It might take a while; on the other hand it might happen relatively quickly; I have seen a quick adaptation and I’ve also seen one that took more than 50 miles - depends on your journeys . So as an interesting experiment, I’d say leave LTFT alone, keep an eye on it after each trip or each day and let us know how it changes with time, so we too can learn from it.

It won’t cause any harm: all the time the car is closed loop (99.9%), the ECU is adjusting the fuelling around once or twice a second to keep it around 14.7:1 no matter what LTFT is.

2. By not altering LTFT manually ie letting the ECU do the adaptation, when LTFT does reduce, you’ll get a warm feeling that all is as it should be.

My LTFT is 116. It’s been that since I overhauled the cylinder head some 3 years ago, following which my fuel consumption improved a lot and LTFT reduced slightly. It doesn’t bother me what the number is as long as it doesn’t suddenly change, which would indicate a problem: as long as the car is in closed loop (and the lambda sensor is working properly) the ECU is controlling the fuelling and LTFT is sort of setting a starting point based on recent driving. And as Al Richey has pointed out in the past, whilst we call it LTFT, we are still a bit in the dark about it and not totally convinced it is long term fuel trim. My own theory is that it goes back to the Austin Montego, which was open loop, no catalytic converter, no lambda sensor, just a fuel map and an injector (and MAP sensor and temp sensors). The mixture was adjusted at idle by the garage using a CO gas analyser and all fuelling was then in accordance with the fuel map - no lambda sensor, no constant adjustment of fuelling. And I believe what we call the LTFT adjustment is simply that idle mixture setting. In the past I have deliberately altered LTFT perhaps by as much as 10 or 15 units just to watch it return to its previous setting over the following week.

So if you do decide not to alter LTFT, do monitor it over a couple of weeks and give us feedback so we can perhaps better understand what it does.

[leopold]

Hi Martin,
yes, ltftr on other systems is called BlockLearnModifier, But those systems work with a grid of adjustment points.For each field in the grid they define a certain mixture.(grid may depend on x=rpm and y=map or other factors)
With thw mems ecu I have never found or rode something about a fuelling grid, so I think we have a  nearly constant fueltrim value and you will see changes only over a very long period.
On mistake I had set LTFTr high , drove the car for a period and didn`t pass mot because of high CO emission even the lambda system worked..
For having the engine running immediately in good condition, i would have a reset. As well the reset could work on throttle position sensor and idle switch .
Leopold

[Martin Rubenstein]

Exactly, Leopold, block learn modifier on modern cars modifies each cell of the fuel map making the whole fuel map like a flexible net, with the aim of keeping the short term fuel trim (STFT) for each cell as close to zero as possible, leaving STFT then free to move its full range of perhaps +/- 20% before limp-home mode is triggered . On the other hand our LTFT possibly alters only the bottom left-hand cell - low engine speed, and load. Or perhaps it alters each cell to the same fixed degree?

In the early days of MEMSAnalyser and Pawel’s Android memsdiag, I reduced LTFT right down to 60 and then set off. Looking at the logfile afterwards with MEMSAnalyser, I saw that the STFT had immediately started climbing upwards, adding more and more fuel to compensate until it hit the limit, and, with LTFT being so low, wasn’t able to compensate any further because it hit the limit set by the software and MEMS went into “limp home” open loop mode. That would be an interesting experiment to repeat, especially driving off quickly, under load afterwards (whilst STFT is still compensating). That would possibly clarify if LTFT does affect the other cells in the fuel map.

[Andrew Jackson]

Alex, I've attached a PDF output created from your mems-scan file that shows the parameters in a graphical format. 

The diagnostics are work in progress. The descriptions are an assembly of knowledge from various sources much more informed than me :) 

Andy

[Alex van Zanten]

Tanks voor all the information and the PDF is a wonderfull start for exploring the scans of a mems ecu.
I plan to do a reset using mems-scan.
With the rosco analyser I noticed unexpected behaviour of the pedal idle switch (I hope the real switch is shown and not the calculated value). Between 17:13 and 17:15
Yesterday we had to wait in front of a traffic light. The graph of the idle switch shows no changes. Before the testdrive I allready tried out the reset by depressing the pedal 5 times within 10 seconds after turning on the ignition and waiting 20 seconds. The switch moves. I’ll check the switch using a multimeter.
The ‘never touch this nut’ had never been toucher. The steppermotor sound is no longer present (also not on switch off).
I did however adjust the speedo cable, in an effort to proper align the notch.
So, my actions are: measure the pedal switch, reset the mems, go for a testdrive. And try recording several logs.

Hopefully we can do testruns tomorrow.

Regards, Alex

[rboin]

This is an Excellent source of information. Many thanks for computing such a comprehensive guide.

[Martin Rubenstein]

I carried out the experiment to delve a bit deeper into LTFT..    I reset my LTFT from 116 to zero ie -128.    And using MEMSLogger to make my logfile, I drove off through the gears.     I have screenshot RPM, Loop and STFT and lambda and attached a screenshot in RTF format showing them all together.    You first see the engine in open loop as the lambda sensor warms up.    The ECU goes into closed loop around 30 seconds after engine start.     At around 1.2 mins, the STFT starts compensating for the LTFT being reduced to zero.      STFT climbs to +18% at which point the ECU sees the mixture is still too weak despite adding more and more fuel, and so it goes into open loop (limp home mode).   The ECU keeps trying to get back into closed loop but because LTFT is so low, it simply cannot add enough fuel to get the stochiometric 14.7:1 mixture.    The lambda curve shows it: lean mixture in closed loop all the time despite the ECU adding more and more fuel to compensate, and then going rich when it gives up and goes into open loop, then dropping lean again as the ECU tries again to establish closed loop.      

I reset the LTFT back to 116 and all was well again.

This tells me, because it was under load and at various RPM, that the LTFT adaptive setting has an effect throughout the fuel map and not just at no-load idle.cell in the fuel map.

[Martin Rubenstein]

Here is the pdf version of the rtf screenshots file in the posting above, just in case you can’t view an rtf file.

[leopold]

Hi Martin,
set the LTFT to 125 and your car will run smoother and will have more power, fun on driving will increase . Saving fuel is not everything!

[Martin Rubenstein]

Leopold, each time I have reset the ECU I have left LTFT at its default of 128, but the adaptation/block-learning process brings it back down to 116, ie the level that makes STFT close as practical to zero, as it should.

For power under harsh acceleration, the ECU goes into open loop so the extra fuel (ie around 12:1 or less) can be delivered. So do you think the LTFT setting affects the open-loop fuelling map?

(Did you notice that the ECU trips out into open loop/limp-home mode at different STFT peak levels, 18% the first time, 5% on the next occasion and 12% or so on another? I suppose that may be down to where the engine parameters are ie which fuel map cell the ECU is using.)

[Alex van Zanten]

So I checked the throttle switch and free the switch up. You have to be flexible with small hands, what a pain!

Started the car, still no higher idle speed at low temp.

Swithed off the car, switched on again and reset the ecu.

LTFT is at 128. Made the testrun, LTFT stays at 128. Then paused afer about 3:38 minutes, adjusted the LTFT to 124 (it went down in steps of two). Drove on.

Made a short stop at 8:32 minutes and noties the LTFT had been adjusted to 122 by the ECU. So the mems and sensors seem to work fine again now.

Driving along will bring it further down i guess.

The air full ratio seems okay. 14.6 when cruising, 12.5 at the lowest on acceleration.

But accelarating up from 2000 rpm is hesistant up to about 3000 rpm, above 3000 rpm accelaration is smooth. Slow response adding extra fuel?

And no response from the steppermotor sofar and still no higher idle speed at low temp. I checked the steppermotor connection, used some wd40 to be sure, but no response fo far.

Is there a way to check the cable towards the steppermotor? To see if any current is present.

I enclosed the logging of the testrun and the logging when we just switch on the ingintion for the throttle angle.

Regards, Alex.

[Alex van Zanten]

Oops forgot the log files

[Martin Rubenstein]

Thanks for the feedback, Alex, including the details on the adaptation of LTFT.

I’ve not looked at the logfiles yet. In a working stepper motor, someone has already mentioned you can hear it clicking when you turn the ignition off, but you can also see it on the Throttle display in MEMSAnalyser: if you switch off the ignition (engine off or on) and leave the logfile running, you see the throttle open and close as a spike and it settles at an opening higher than idle ready for your next start. You could make a quick logfile turning the ignition on and off a couple of times. Looking at the current flow isn’t easy: you’d need a breakout lead. You can also get someone to turn the ignition off whilst you watch the lever arm of the throttle plate and the end-stop. The change in gap of the throttle stop is clearly visible even if you can’t hear the clicks. You can watch the voltage across the various pin at the connector but unless you have the proper tools, if you lash up pins or loose wires, there is a danger 2 wires will touch and short. If you are careful it’s not difficult but a visual check is safe and simple. (I have stripped and cleaned my stepper to make sure it moved freely. It wasn’t difficult or demanding, and in my case, it wasn’t necessary.)

I not noticed the air-fuel ratio before. I wonder how it is derived? The hesitancy between 2000 and 3000 RPM - does it show up on the lambda display? It’s not a harsh ignition misfire is it ie a judder in the forward motion?

[Martin Rubenstein]

Again, I can't read your logfile in MEMSAnalyser, which is a real shame.   I can however read it with Leopold's mems-rosco-charts and I don't see the spike in throttle position when you switch off. indicating you are right in diagnosing a fault in the stepper motor system.      Has the car stood for a long time?    That might suggest the motor is simply stuck.    Do you have a spare one you could attach to the connector to simply test the circuit?    Maybe a quick disconnection and reconnection of the connector - unlikely but worth a go.

[Martin Rubenstein]

Al Richey very kindly fixed your logfile so I can read it in MEMSAnalyser, and now when I look at your logfile, I think you stopped logging just before the stepper motor would have made it’s shutting down moves. So now I can’t be sure about whether or not there is a fault in your stepper motor system.

Your logfile ends whilst the RPM is still falling and the MAP is still rising to atmospheric. Frustrating.

[Martin Rubenstein]

Whilst looking through the Blackbox Solutions stuff for anything on the air-fuel ratio readings and how they could possibly be derived, I stumbled across this:

“ Injector time: This is a representative value (0 to 255) of the correction trim value of the fuel injection time currently being used by the MEMS ECU. This value is mainly used to adjust the idle fuelling. The value of Injector time is normally an adaptive value which is set up automatically by the ECU on Vehicles fitted with an oxygen sensor. However for vehicles not equipped with an Oxygen sensor this value must be adjusted manually to obtain the correct fuelling. This is done by using a CO meter to monitor the exhaust output and adjusting this value until it is correct (open loop tuning) The correct CO values for a given engine can usually be found in the Workshop manual. This value is also shown under dynamic inputs in a scale of microseconds.“

This must be what we call LTFT.

[Alex van Zanten]

I don't know what the problem is with the logfiles. I did copy memsanalyser in the memssanner directory and am abel to read most of the reading. Only the lambda values fail to show and memsanalyser shutsdown.

And indeed mems-rosco-charts doesn't crash over the lambda values.

Luckily we do have a spare injectorbody. I hooked up the steppermotor of the spare one and voila, clicking noices!! Good suggestion Martin!!!

Just switched over the steppermotor (the motor itself), checked the gaps (ignition on, fully move the thtottle open by hand), the gaps are even. Started up the car and bingo, the steppermotor kicks in and elevates the idle.

So the main problem has been solved right now or at least the reason why we began this venture.

Think we have to do a clearing of the errors once more and go for a drive again (tomorrow). My son needs to drive some kilometers and log what's going on.

Perhaps accelaration will improve during the relearning of the ecu. But perhaps someone can gives still us a hint what might be going on.

To be continued tomorrow.

Regards, Alex.

 

[Alan Richey]

>>>I don't know what the problem is with the logfiles.

It's not your fault, it's Microsoft's fault.    Colin, Leopold and Haro have all written their programs in a version of C++  (I think).   When they generate the logfile they use the keyword 'newline' as the field separator.   Unfortunately when they compile the programs the way the compiler treats that keyword as not consistent,   Sometimes it uses just a single byte 0x0A hex, (known as newline) but sometimes they use the 2 bytes with the values 0x0D 0x0A (Carriage Return and Newline).

I can only assume that MEMSAnalyser is the same.  Depending on when it was compiled it eiter recognises the single byte 0x0A, or it recognises the 2 byte 0x0D 0x0A.   I can only guess it has to do which Microsoft library is used.

So basically you have to have versions of the 2 program that both recognise the single byte 0x0A or both recognise the 2 byte 0x0D 0x0A.   We seem to have the situation where both your MEMSScan and your MEMSAnalyser recognise and use the 2 byte 0x0D 0x0A.   So your MEMSAnalyser can read your logfiles from MEMSAcan.

However, both Martin and my versions of MEMSAnalyser use just the single byte 0x0A value so we cannot read your logfiles.

The solution is simple, we just run a 'Find & Replace' option in a hex editor to convert your 0x0D 0X0A values to the single 0x0A.

So need to change your working version, it's a matter of seconds to convert your log files for us,

Hope that makes sense.

[Martin Rubenstein]

Excellent, Alex.

Al Richey kindly explained to me the inconsistency in the non-MEMSLogger logfiles and how to fix them.

Goid news on your spare stepper. Quite likely your original one is gummed up. Having a spare is a great confidence booster when stripping a part: if, when you take the lid off, there’s an explosion of springs and brass contacts, you still have a spare and you’ve learned never to do that again. But you’re lucky: you’ll find cleaning up the old stepper is a very simple, undemanding job, and your old stepper should then be a good, working spare.

[Alex van Zanten]

Oh, the answer to the hesitance between 2000 and 3000 rpm. No misfires but more of a slight stuttering (that is perhaps to strong). It feels likes it slows down a bit and then reluctantly accelarates and above 3000 takes off.

From my experience with carbs, It feels like a lean mixture.

Regards, Alex.

[leopold]

Hi Alex,
do a reset of the ecu again and leave the rest untouched then.Drive it for a while and then do a logfile again.
The provided logfiles have very strange values (no ltft and other unexplaineable values.) But the idle switch seems to work now.

[Martin Rubenstein]

That’s what I was thinking, Alex, and that’s why I wondered if the lambda readings showed anything eg a lean period (less than 0.45V) during that period of hesitancy. However, even if it didn’t it wouldn’t prove anything. When you’re accelerating hard, you’ll be in open loop and a rich mixture (for power). As far as the lambda sensor is concerned, 0.46V or higher is rich but no way of knowing how rich. So your lambda during this period could easily still show rich ie ~0.8V and yet it might not be rich enough to support the acceleration you are demanding. So I doubt that lambda would show lean anyway. And what would that mean, that your fuelling map in the ECU is wrong? Not unless you have done a major mod eg a different camshaft or a remapped ECU (you can’t do that with MEMS, as far as I know). And it can’t be a vacuum leak at those high revs (and not be evident at idle). So my money is on weak ignition under load. An oscilloscope with capacitive HT ignition pickups would show it. Otherwise it’s guesswork: a weak coil, HT leads or plugs, or dodgy distributor cap or rotor arm. Is yours a solid rotor arm or does it have an epoxy-embedded carbon fibre resistance between the centre and the outer brass pieces? I dig those dreadful things out and solder a copper wire between the two and backfill with epoxy. Those rotor arms are a disaster. (Don’t ever buy Intermotor stuff: the quality is bad. Only buy quality, trusted-brand parts.)

I’m guessing you are in the Netherlands, although from your English you could easily be living here in the UK.

[Alex van Zanten]

First a reply to Martin. Apart from the feel of a weak mixture, I Always doubted the coil/sparkplug setup. Every two years the car gets inspected by a real garage. Last time around they tried to change the plugs, but the standard R-type plugs didn't work at all in high revs. That made me suspicious. Before you mentioned the plugs and coil probability, I allready had ordered a different coil and the R-type plugs. Fiited them today and the car runs better. Not completely satisfied yet, but it is definitely an improvement. Turns out the lucas sports coil i was provide with was a ballast type coil for points ignition.

So we will keep this setup. The coil used is the Intermotor 11410 and the plugs are NGK BPR6ES.

Regards Alex.

[Alex van Zanten]

Update on the mems-readings.

So i went all the way, bought all of the 'original' vacuum hoses at MiniSpares and fitted them today aswell.

Reset the entire ecu again (not only the faults) and went for a drive. The log is enclosed and I think the readings are now consistent throughout the drive.

LTFT is back at 128 due to the reset and this time i will make no corrections, but we will see if anything changes over time.

Again, if someone notices something odd, please report is back.

For now we wil drive the car as is and then produce a log again.

A big thanks to everyone writing the software (scan and anlysers) and giving their expert opinion on our findings.

Regards, Alex. 

[Alan Richey]

Looks good to me.

[leopold]

Congratulation.
The only thing is a high IAC, should be simular to idlebase, but I would drive it like it is for a hundred of kilometers and then check again.
Let us know about the fuel consumption and how it drives!
Leopold

[Martin Rubenstein]

Excellent. Haven’t seen the logfile but if Al and Leopold say it’s good, that’s good enough for me.

What about your rotor arm? I was once sold an Intermotor one where the central contact was canted over by some 20 degrees; on exchange, I went through 2 Intermotor arms that misfired immediately on startup: the HT preferred to short through to the distributor shaft rather than pass through the resistor. That’s why I get rid of the rotor arm resistor. (That and a near miss on an Opel where that rotor arm resistor became so hot that the rotor arm was almost destroyed. A routine inspection found it just in time.)

I’m running on an Intermotor coil. When I compared its ‘scope waveforms with those of the recommended Lucas coil, the Intermotor coil had better characteristics, so it’s maybe not all bad at Intermotor but do beware.

I use the Bosch Super 4 spark plug: 4 earth electrodes around the centre electrode (non adjustable). No complaints at all.