Another quick question for the guru - as in my previous post I have two mgf's both with MEMS 2J (96 reg and 97 reg)- one of them works perfectly when connected- the other continually drops out the connection - my thoughts are that my connector on the car is a bit worn or problematic as the other car works fine - however I have noticed the ecu numbers are different by one digit ie MKC104000 and MKC104001 - could this be relevant ?

I have similar connection failures with my mems2j f.

I've communicated with Philip and he's investigating.

I'll check my ecu number next week when the weather clears a bit!

which is good and which is bad?

this could indeed be a clue

Hi Thanks for the reply - the good one is the later R plate with the MKC104001 ECU - hope that helps.

The ECU that I have been using for development is from a Rover 200 BRM. I can't find any MKC numbers on it, however as the BRM didn't come out until the end of 1998 I guess that I must have the newer type.

Also Cairnsys has had problems with reliability of the diagnostics protocol with the engine running which is impossible for me to repeat as I only have the ECU and not a whole car.

I think I am going to need to meet up with someone who has one of these cars.

Hi Philip - you are welcome to pop up to Northant's and compare my two F's if that's any help - Marty

Just checked my ECU and it is MKC104001

Is it a physical check?

Yes, just read it from the label on the side of the ecu.

I think that maybe there are two seperate issues here.

1. Connection issues if the engine is started. Possibly our protocol implementation is not as robust as the T4.

2. The other tools that I have used do not allow access to all live data parameters at the same time. Maybe our tool is asking the early ECU for more data than it is capable of delivering and putting too much load on its processor.

Anyway I will have to do some work to get to the bottom of it.

2 sounds plausible because it happily delivers all the data when the engine is not running. It's only when trying to capture live data on a running engine that the connection fails and then only after requesting around 10 to 12 parameters. It's ok up till that point.

Robin

Ok had a play today and noted -

1.No problem talking to the ABS - engine on or off (ABS light illuminates on the dash during checking.)
2.No problem talking to the Airbag ecu - tells me circuit condition bar code etc.
3. Engine ECU -Communication lag and dropping connection but able to read a fair amount of data with engine off - much worse and constant dropping connection when engine on.

This was all on my P REG VVC MEMS 2J (MKC104000)

All works fine on my R REG VVC MEMS 2J (MKC104001)

Strangely all works fine on the same ECU number as Cairnsys is having problems with.

I have feeling that this one may take a but of sorting out!

Hi Any update on this issue ?

I am pretty sure that the early ECUs just don't have a powerful enough processor to deliver more than about 12 or 13 parameters with the engine running. There isn't much I can do about that other than to detect that model of ECU and limit the number of parameters that you can select.

Concerning the dropout when the engine is started I will need to visit you in Northants during January. I have to do a business trip to Luton during January anyway so if possible I would like to visit Northants on the same day.

I briefly tried out my new Pscan today. Seems to work well. I have an ABS fault that is slowly developing (fairly sure it's a wheel bearing with the integral magnet). The Pscan connects ok, reading ABS I didn't know which type to select so tried them all in order until it did, the last ABS option connects ok (with ignition on II but engine off. Rover 75 CDT year 2002 ).

I cleared the faults then selected live data, I selected the wheel speed from each sensor as I wanted to find out which wheel is mis-reporting. Went for a drive and the Pscan disconnects within a minute. I tried this a couple times, including live data 2. Each time I had all four wheel data selected and live update speed. I don't understand why the Pscan disconnects. I'll try later with less live data selected.

Not sure if it's relevant, but when connecting to any ECU, I get a message saying suspect K line short or similar. I don't understand the significance.

As an aside, the symptoms of my ABS are crunching brake pedal. I sometimes get an ABS error light and the ABS disables itself for the rest of the journey and I sometimes get a brake error. My drive this morning after clearing the error codes didn't trigger new errors, so I didn't see them on my return home. I am feeling confident when I am thrown an ABS error in future that logs in the ECU I'll be able to diagnose my developing fault.

If Rover had implemented things according to the standards then this would not happen. The idea is that the tool should be able to detect shorts in the line so that it doesn't get damaged attempting to drive into +12V battery live. Unfortunately Rover messed it up, and I have not gotten round to removing the feature from the code. One day I will.


This is a "health and safety" feature of the ABS ECU, common to quite a lot of cars, not just the 75. When the diagnostic tool is talking to the ABS the ABS is disabled. The lawyers don't want you driving around without ABS so they made the ECU throw you out. Either that or it doesn't have enough processing power to keep the protocol up as the wheels spin faster..... Anyway it is a feature of the ECU not pscan.eu so I'm afraid we are stuck with it.

A lot of cars when doing live data on ABS as above will kick you however some have a speed threshold so as long as you stay say below 10mph it will allow communication go over that and it will disconnect Rover may of implimented that into the coding so try a few low end speeds and see if connection remains

I have found that even at low speeds if there is an issue it can soon be seen by the speeds of the sensors