Freelander 1 L series - Bosch MSA-11 DCU and 93C46 EEPROM / IMMO removal ?

I don't know if this makes things any easier - you'd still need to code the eprom content and you need to know what the code is - but there does look to be a 'factory new' code setting. Presumably the first time the ignition is turned on, the 'factory new' code is replaced with the CCU code.

"Not Programmed - Also known as uncoded, virgin, or blank - this means the item does not hold a code and does require programming/coding. A part that's not programmed can be swapped with another one without you having to do anything. The part is plug and play."

https://autotekcarparts.com/part/737/

Couple of things of interest. as @GrumpyGel says, you need the fob and a working battery for the L series. Now sure what you are getting at above GG -

GrumpyGel said:

A part that's not programmed can be swapped with another one without you having to do anything. The part is plug and play."

Click to expand...

There is no such situation AFAIK. There is no plug and play without re-coding of the security parameter.

I do not understand the logic in the statement from the site -

""Not Programmed - Also known as uncoded, virgin, or blank - this means the item does not hold a code and does require programming/coding. A part that's not programmed can be swapped with another one without you having to do anything. The part is plug and play.""
It seems to contradict itself and makes no sense
There MAY actually be a setting in the security eeprom that alloys a first time coding from the CCU - but I have seen no evidence of that and would question any viability due to the OTP UV eproms used for the OS. However it is an interesting but unlikely possibility. You also have to consider that - as above -a 'virgin ecu' in this breed uses one time programmable dual 27C256 uv erasable eproms. - they COULD NOT BE BLANK as they have the OS on one of them. There would HAVE to be a minimum of some form of bootloader system in one of the UV eproms. Also the data / map entry - and code / firmware entry is a one time operation, no changes are possible EVER after that via OBD as the parts are only erasable via sustained UV. There is no 'update service available via T4 or any other system. Once they are programmed that is it - no changes ever without removing them and they are almost always soldered directly to the board. I often wonder when people use the term 'virgin ecu' when they talk about non - re- programmable main UV eproms such as in the 1.3.1. as said there MUST be at least a boot loader, or a full operating system on board. I do not know for certain, but I doubt that the 1.3.1 system can even self program the main eproms in a one off mode.
Certainly the 8 pin 93C46 units - yes. but these hold absolutely minimum data.
That ECU advertised is for an 825 Rover and some aspects may be different in the coding. The 8051 processors (dual) have two EEPROMS that can be controlled and altered by the processors (these are the two tiny 8 pin ones. The two 28 pin 27C256 units contain the mapping and also the firmware to operate the system. There are considerable differences between fitments.
The T4 can program the parameters and the security code details to the EDU, also program details of a new CCU.
Both must match though for the immo to work and for the engine to start. Yes, I am sure a dealer can disable (or someone with a T4) can disable the features but aftermarket devices do dont unfortunately. The lynx for example can code parameters of the CCU and certain secuirty related features, but only in the area of superlocking, single door open on one press and on off function of the interior sensor. not much use really..

Apparently, from research, the only way at this time to get around the immobiliser bit is to completely remove the left hand 8 pin security eeprom from the ecu (top LH as seen from connector). you then need to cut the security code signal wire from the CCU to ECU and also enable the starter relay by hard wiring it.
This bypasses the immo and due to the eeprom removal the ecu actually does not disable the control and running ability as it does normally, but for some reason does not able the starter relay.. strange - but.
Seems too much like hard work
Joe

GrumpyGel said:

This topic appears to imply the ECU is checking the CCU and immobilising the engine if there's a mismatch. However, is it the other way around? If the ECU does not match the CCU is it the CCU that is immobilising the engine by not raising the starter's earth?

Click to expand...

Hi GG, to clarify the above,. The way the system works is as follows. On pressing the keyfob the rf receiver gets a coded signal from the fob. The signal authenticity is sent to the CCU. Meanwhile the ECU is awaiting a code sequence from the CCU. When it receives a valid the code sequence from the CCU the ECU removes the starter lockout and the engine solenoid operation lock. It also removes the flashing immo led.
Opening the drivers door with the key switches off the alarm.
With the immo mod (remove the 8 pin security eeprom and fudge the starter solenoid, also cutting the wire from the CCU to the ECU you can enter via the key and the immobiliser is disabled. The alarm works fine though and switches off when you use the key.
Using the Lynx, I can set the single door opening to all doors, however, I have not tried to see if this is fob only - it may be.
Removing the immo would certainly be a huge bonus of the keyfob battery was flat but you could always carry a spare battery in the vehicle and open by the key (we actually have one in the glove box). This does not cover fob failure though. *which I HAVE had - I bought one new programmed fob / key for 75 Euro from the local locksmith, and also bought a fob case and button replacement from ebay.

The work you are doing on the protocols is of interest and is surely fascinating. As for alarm disable, it would be done in the ccu. The immobiliser would be in both the ccu and ecu.
The lynx can program many areas of the CCU and it would be very interesting to look at the eeprom files inside the ccu when activating / deactivating a 'feature' then by old fashioned trial and error you could possibly find the locations to deactivate alarm functions.
I considered a look at the protocols in details (as far as info is available) but decided - for me - it was far easier to just buy the lynx. However, 10 years a go I would have relished the challenge.

The CCU I will certainly get though and get the bin / hex files from the eeprom and play.

How far have you actually got with it ? do you have a two way talking system as base level yet ?
Joe.

Looks like you're right about "no such situation". That link was titled "Bosch EDC 1.3.1 (MSA 11-1) that was listed for a Rover diesel and sounded like a Freelander one. It listed the following part numbers:

0281001417
EDC131
MSA111016
MSB100380

Looking at their website, they list a Freelander L Series ECU as simply "BOSCH - Engine Management ECU" with the following part numbers:

0281001420
MSB101070

With this one they say...

"Transferable - This part is programmed. The code from your original unit can be transfered into the replacement via the vehicles diagnostic socket. Alternatively, we offer to transfer the code from your original part into this one. In order to enable us to transfer the program for you, please send us your original part. You do not need to send us the keys or the immobilizer, just the part itself. This is a 24-hour turnaround service."

https://autotekcarparts.com/part/1318

So looks like the 2 different ECUs, although looking almost identical from their descriptions - must be quite different beasts. It ties in with what you say about WORMT.

...

It is DEFINITELY the CCU that ultimately will allow or inhibit the starter from cranking. Rave is confusing in its initial description of this, because it says the ECM does this - but the ECM sends a message to the CCU and the CCU then decides whether to allow cranking. The wiring diagrams show this and later in the "Electrical Library" in Rave (p 4.43) it contradicts its earlier description by stating...

"The earth path from the starter relay is from the engine management relay module (C154-4) to the Central Control Unit (CCU) (C429-15) on a black and yellow wire. When the CCU determines that starter operation is allowed, the earth path is completed and the starter relay energizes."

There may be some confusion due to the term "engine management relay module" - which is a 'PCB' with mounted relays rather than the ECM (EDC).

...

I'm going round in circles gathering info on the protocols. At various times I've started gathering info and not quite got there! So I'm going through the process again to see if I can't get a definitive description. I'd love to know what ICs the i930 or pscan.eu use to hook up to the networking. I'm sure that once this core info is known it will be a 'simple' task of hooking an IC into an Arduino (or similar) and doing the programming. Having said that, I'd probably need something like a Hawkeye to plug in and sniff the actual format of messages sent and received. There's lots here that I've never done before, but I've got my eye on an Arduino starter kit that will give me the basic knowledge of the tools required for Android programming and connectivity to the Arduino.

I did quite a bit of research and investigation to do the VVC swap in my 1.8i FL (originally MEMS 1.8. It may not be relevant for the oil burners.

In the MEMS 1.8 there is a single EEPROM which contains stored tuning parameters as well as the immobiliser code, so simply removing it was not seen as an option. I would have expected the same with the EDC system.

There is definitely a configuration of MEMS with no immobiliser code in a run state, it is used in Japan versions as they either don't permit or don't desire immobilisation. A first easy step might be to see of you can get an ex Japan ECU, or get an EEPROM image of one. This is the approach I used. I must admit it was more by accident than design. I have left the link between the ECU and the CCU disconnected.

Does anyone speak Polish?

I'd love to know what the fella used to build this...

Hi guys

GrumpyGel said:

"The earth path from the starter relay is from the engine management relay module (C154-4) to the Central Control Unit (CCU) (C429-15) on a black and yellow wire. When the CCU determines that starter operation is allowed, the earth path is completed and the starter relay energizes."

There may be some confusion due to the term "engine management relay module" - which is a 'PCB' with mounted relays rather than the ECM (EDC).

Click to expand...

Hi GG, yes, you are absolutely correct - it even says 'relay starter' under the 'engine management relay module'

Also, - to confirm the NORMAL part number for the L series freelander DCU (ECU) is Bosch 0 281 010 113 TYPE 4125 WITH lr MSB of 10171
the 0281001420 MSB101070 Is also used but I have never seen one - I was told there were two but have no idea if there is any difference at all.
My wabco ABS Modulator - usual part number is LR part SRB101230 (99 these last 2 are model year only) WABCO 4784070300. However, Microcat lists an SRB100800 unit which is also an equivalent unit with same Wabco Part Number 4784070300 - gawd knows why... It would appear that despite the numbering, the 100800 is actually the later part as the date code shows on this one (it must have been used as a replacement to have an 04 date code

GrumpyGel said:

I'm going round in circles gathering info on the protocols. At various times I've started gathering info and not quite got there! So I'm going through the process again to see if I can't get a definitive description. I'd love to know what ICs the i930 or pscan.eu use to hook up to the networking. I'm sure that once this core info is known it will be a 'simple' task of hooking an IC into an Arduino (or similar) and doing the programming. Having said that, I'd probably need something like a Hawkeye to plug in and sniff the actual format of messages sent and received. There's lots here that I've never done before, but I've got my eye on an Arduino starter kit that will give me the basic knowledge of the tools required for Android programming and connectivity to the Arduino.

Click to expand...

I would have though that the arduino was more that capable of doing the job. As you will have found out it is the protocol info that you need and I would imagine it as as rare as rocking horse sh!t. A hawkeye or similar would be great to help once the basic communication has been established. Not something I would like to undertake personally but a challenge is a great way to learn and when progress is made is so very rewarding.

Tony Reeves said:

I did quite a bit of research and investigation to do the VVC swap in my 1.8i FL (originally MEMS 1.8. It may not be relevant for the oil burners.

In the MEMS 1.8 there is a single EEPROM which contains stored tuning parameters as well as the immobiliser code, so simply removing it was not seen as an option. I would have expected the same with the EDC system.

There is definitely a configuration of MEMS with no immobiliser code in a run state, it is used in Japan versions as they either don't permit or don't desire immobilisation. A first easy step might be to see of you can get an ex Japan ECU, or get an EEPROM image of one. This is the approach I used. I must admit it was more by accident than design. I have left the link between the ECU and the CCU disconnected.

Click to expand...

Hi Tony, the alarm conditions according to market are configurable at the CCU - according to rave. The market settings for Japan and the Gulf states inhibit alarm functions. There are some great details in freelander 1 <2000 rave - technical brochure - page 17 on.. I can set transit mode (which appears to be related to market options) and many other CCU features with the Lynx - I will order a spare CCU and see if I can rig up a jury rig to hook up the Lynx and then read the eeprom data in the CCU to note code changes.
AFAIK the EDC 1.3.1 unit does not save any data relating to tuning / self learning, however, it will certainly save data / DTC etc.
As to which specific 8 pin eeprom is used (and in the FL L series DCU it has to be in one of the two 93C46 units as the main 256K eproms are non writable - also AFAIK the 8051 used has no internal writable code by the chip itself) (no self writing ability)
Have 2 spare ecu (DCU's) that I am using for experiments. I could create DTC situations and then remove the eeproms and read the to see what has changed. With re-flow it is perfectly possible for a considerable number of times without damage to the board at all. (cannot read in circuit unfortunately)
In the image attached you can clearly see that the right hand 93c46 has vin identification and build date in ASCII. (images from 2 separate ECUS.)
Whilst the left has very little repeating and constant code.some is obviously immo code key checking but as to the rest ?? dunno at this stage.
The same experiments on CCU (VT27) units would be also good to perform. I will get a couple from my very friendly breaker in the UK. Only trouble is there are LH and RD drive units - and all uk units will be RHD) - but the theory would be the same - it looks easy to rig a unit up on the bench.

GrumpyGel said:

Does anyone speak Polish?
I'd love to know what the fella used to build this...

Click to expand...

He would appear to speak English Grumpy mate - or seems to by the display - drop him a line and see. Also the Polish translator in google is good if other languages are anything to go by.

Anyway - for the L series - the EDC EEPROM dumps are as follow for two different EDC units. There would appear to be the only units programmable by the internal processors.
Nerdy stuff is great lol
Joe
The VIN is from 0X32 on the bottom right hand eeprom - you just need to add the SAL before it for the assembly area code - hence bottom right would be SALLNABB7YA512770 with a build date of 29/09/1999
and on the top right hand eeprom would be
SALLNABB7XA690805 with a build date of 12/05/1999
as in this image from microcat

Joe_H said:

He would appear to speak English Grumpy mate - or seems to by the display - drop him a line and see. Also the Polish translator in google is good if other languages are anything to go by.

Click to expand...

I've dropped the chap an email. It'll be great if the guy comes back with some help.

GrumpyGel said:

I've dropped the chap an email. It'll be great if the guy comes back with some help.

Click to expand...

Definitely ! keep me informed - it sounds fascinating fingers crossed.!
Joe

Joe_H said:

Hi guys


I would have though that the arduino was more that capable of doing the job. As you will have found out it is the protocol info that you need and I would imagine it as as rare as rocking horse sh!t.

Click to expand...

Yes, I was going to head down that route as well, got all the kit ready and started looking at the data transfer from the CCU to the MEMS ECU. Identified it as a 16 bit value, 9600 bps (I think, from memory) which keeps repeating every few seconds. But stopped dead when the engine started and ran without the feed to the Japan MEMS ECU is place.

I had captured the protocol on my scope and had started to consider an op amp to shape the line values to RS232 or something I could deal with.

Joe_H said:

Hi Tony, the alarm conditions according to market are configurable at the CCU - according to rave. as in this image from microcat.......

Click to expand...

Well clearly there is some immobiliser condition configured in the ECU. Looking at ECU hacking sites etc., there seem to be 3 ECU EEPROM immobiliser configs - a 16 bit code, waiting for a code to go in, or no imobiliser. My next step had been to look at dumps of different configs and see how these conditions were recorded. My uneducated guess was there was a flag somewhere, or code 00 might be waiting for code to come in and use that, code FF might be ignore code and run as normal (or vice versa) and anything in between means stop engine if another code in received.

Tony Reeves said:

My uneducated guess was there was a flag somewhere, or code 00 might be waiting for code to come in and use that, code FF might be ignore code and run as normal (or vice versa) and anything in between means stop engine if another code in received.

Click to expand...

That's what I was thinking - and it appears some (like the Rover 825's ECU) are like that - but not the Freelander's.

Joe_H said:

Definitely ! keep me informed - it sounds fascinating fingers crossed.!
Joe

Click to expand...

I got an email back, the guy sounds right clever - also sounds like an enthusiast - I've got to read over some stuff he sent through and he's going to send some more today. It sounds like he's analysed the start up code and made a sniffer that logged a T4 to find out all the message formats. It is all for Rover/Honda cars - but I'd have thought most of the Bosch talk is similar between ECUs of that era.

He's asking how I an with electronics and soldering - of which I am a complete noob and will probably have very stubby fingers when I pick up a soldering iron - but your message to Alibro earlier may come in very useful!.

Joe_H said:

Also, - to confirm the NORMAL part number for the L series freelander DCU (ECU) is Bosch 0 281 010 113 TYPE 4125 WITH lr MSB of 10171
the 0281001420 MSB101070 Is also used but I have never seen one - I was told there were two but have no idea if there is any difference at all.

Click to expand...

I shall take a pic of my ECU for you then - cos I just checked and its a 0 281 001 420.

Mine's a 'normal' '98 L Series - not 1 of the early ones with the 112 (was it?) tooth belt (and different turbo?) or a Japanese import with no immobiliser. It has A/C. Not sure what else might be a reason for 2 different ECU types. Shouldn't think LHD/RHD would have any impact on the ECU.

Great info for the soldering 'handman's' suggested tools by the way.

GrumpyGel said:

That's what I was thinking - and it appears some (like the Rover 825's ECU) are like that - but not the Freelander's.

I got an email back, the guy sounds right clever - also sounds like an enthusiast - I've got to read over some stuff he sent through and he's going to send some more today. It sounds like he's analysed the start up code and made a sniffer that logged a T4 to find out all the message formats. It is all for Rover/Honda cars - but I'd have thought most of the Bosch talk is similar between ECUs of that era.

He's asking how I an with electronics and soldering - of which I am a complete noob and will probably have very stubby fingers when I pick up a soldering iron - but your message to Alibro earlier may come in very useful!.

Click to expand...

Hello Grumpy,
Way to go, ! sound great. I can recommend some cheap but incredibly good gear to set you up for any electronics work really. Also, If I can help I definitely will.
First it would be good to see a sample for what kind of soldering / pcb work or whatever is needed. Depending what he is doing for a microprocessor I am sure we can sort something no worries.
You saw the prices of the soldering rework stuff and also programmer (it would be good to see what he is using)
A good soldering iron can be had for little - here is a nice unit complete with hot air rework, iron and also a small bench adjustable dc power supply - crazy cheap !
http://www.ebay.co.uk/itm/853D-3-in...766331?hash=item3f6654b23b:g:HbMAAOSwkl5Xfm6c
Honestly mate, If I can help in any way just ask. ! - most programming of microprocessors these days is doen via ICSP (In circuit serial programming) which is really ease and cheap to get the geat - the programmer I listed will work - and several others.
Units like th Arduin etc are programmed simply by USB inmost cases and a literaly - load the code into the arduino IDE and click and program - Job done.
Regards mate

Sound bloody excellent - we chuffed

Joe

Tony Reeves said:

Yes, I was going to head down that route as well, got all the kit ready and started looking at the data transfer from the CCU to the MEMS ECU. Identified it as a 16 bit value, 9600 bps (I think, from memory) which keeps repeating every few seconds. But stopped dead when the engine started and ran without the feed to the Japan MEMS ECU is place.

I had captured the protocol on my scope and had started to consider an op amp to shape the line values to RS232 or something I could deal with.

Well clearly there is some immobiliser condition configured in the ECU. Looking at ECU hacking sites etc., there seem to be 3 ECU EEPROM immobiliser configs - a 16 bit code, waiting for a code to go in, or no imobiliser. My next step had been to look at dumps of different configs and see how these conditions were recorded. My uneducated guess was there was a flag somewhere, or code 00 might be waiting for code to come in and use that, code FF might be ignore code and run as normal (or vice versa) and anything in between means stop engine if another code in received.

Click to expand...

Hi Tony,
I would agree that there is definitely a setting in the CCU that disables alarm / immo.. Disabling alarm features is all in the CCU, however, the IMMO basically is in the ECU (with the result depending on the signal sent - or - settings in both CCU and ECU)

Can you explain in slightly more detail the data transfer situation (not protocol) of the Japan market unit CCU combo. Are you saying that data WAS transferring with IMMO / Alarm OFF - or that there was not connection between the two units ? - I am a little confused by your description. mate.

Also, depending on the answer to the above - there may well be a code sequence sent from the CCU that the ECU interprets as IMMO OFF - IGNORE - a bit like an aircraft transponder squawking 7700
That would be east to implement. However, IF the connection link remains established, then yes, the ECU must have an IMMO OFF code.
It is interesting that the 'read' of the eeprom in circuit (well - the read IF the eeprom is NOT in circuit still occurs and returns OxFFFF.
Perhaps a speciifc location setting of OXFFF with no CCU link is immo off (which ties into the removal of the 93C46 eeprom and ccu link disabling ECU immo) but not CCU starter immo or alarm. - or as said, a specific reserved code if ccu linked. or even a normal ecu immo with ccu linked but simply no alarm or auto delay immo setting. If the alarm is completely disabled, and the immo delay and led display is disabled, AND the link CCU to ECU is in place, then a standard immo signal can still be sent using original codes.
Jeez, so many combos
Was the CCU a VT27 unit ? (as used with the 1.3.1) - also do you know what processor / eeprom etc was in it ?
Cheers
Joe

This is what the chap has built...

http://s1341.photobucket.com/user/sail3058/library/OBD Series-L pump VP37?sort=3&page=1

He has built 6 of them. 1 he has kept, the others have been sold - presumably to friends on the Polish Rover forum he frequents.

I would be more comfortable building this on something like an Ardiuno. I've read heaps on it. If you know what components you need (or are told which and how to use) the Arduino / breadboard looks like a good starting point for a novice to get in, build and program. Then take it over to a "proper" PCB type affair.

Looks like this is going straight into a PCB. Hopefully I can build one - but even then it will only be the prototype as ultimately this will be permanently installed in the car and connected to a permanent tablet that will be "my interface" to it. It will need to connect to the WABCO ECU and I'll also be adding bespoke diags for IRD/diff temps and possibly prop speeds. As well as manual diagnostics, I want it to permanently monitor the transmission to warn me hopefully of problems - that is my primary goal.

Down the line, It will also do other things....

I can't get on with the Freelander cup holder jobbie (as sought after as they are!) - the cup holders on my Disco were much better - I want to replace the stereo with something like this...

http://www.ebay.com/itm/Universal-I...cement-Pocket-Storage-Box-Audio-/320661702093

So my device/tablet will need to make use of something like this....

http://www.trademe.co.nz/Browse/Listing.aspx?id=1145314486

We only use the radio, but it'll presumably expand to connectivity for phone/MP3 player.

I'm also considering mounting the tablet where the reversing mirror is. In which case, it will need a rear camera so that it can act as the mirror.

GrumpyGel said:

This is what the chap has built...

http://s1341.photobucket.com/user/sail3058/library/OBD Series-L pump VP37?sort=3&page=1

He has built 6 of them. 1 he has kept, the others have been sold - presumably to friends on the Polish Rover forum he frequents.

I would be more comfortable building this on something like an Ardiuno. I've read heaps on it. If you know what components you need (or are told which and how to use) the Arduino / breadboard looks like a good starting point for a novice to get in, build and program. Then take it over to a "proper" PCB type affair.

Looks like this is going straight into a PCB. Hopefully I can build one - but even then it will only be the prototype as ultimately this will be permanently installed in the car and connected to a permanent tablet that will be "my interface" to it. It will need to connect to the WABCO ECU and I'll also be adding bespoke diags for IRD/diff temps and possibly prop speeds. As well as manual diagnostics, I want it to permanently monitor the transmission to warn me hopefully of problems - that is my primary goal.

Down the line, It will also do other things....

I can't get on with the Freelander cup holder jobbie (as sought after as they are!) - the cup holders on my Disco were much better - I want to replace the stereo with something like this...

http://www.ebay.com/itm/Universal-I...cement-Pocket-Storage-Box-Audio-/320661702093

So my device/tablet will need to make use of something like this....

http://www.trademe.co.nz/Browse/Listing.aspx?id=1145314486

We only use the radio, but it'll presumably expand to connectivity for phone/MP3 player.

I'm also considering mounting the tablet where the reversing mirror is. In which case, it will need a rear camera so that it can act as the mirror.

Click to expand...

Hi GG, I wouldn't try at this stage to go any further than he has - first of all, ask if he can provide a PCB ready made (if so - we want 2 lol - one for you and one for me! - definitely)
99% of the parts seem to be surface mount so you would use your rework gun / station, solder paste and flux. - you would have it down to a tee in about 10 mins practice.
Also, the microprocessor, what is he using ? I cannot see from the images. If he can provide details and the code we can program them no worries. It looks like he has ICSP on the board so updates are simple !. the 10 pin connector I presume offers ICSP and link to ODB socket (only 3 connections on that for ODB .....)

Get a ready made board, a display (looks like a bog standard 128 x 64 STN display ?) a processor - programmed or not and the code.
LONG after you have a working example - then use it to interrogate the protocols.. Considering changing from whatever processor he is using would be detrimental at this stage. Build it first and then study. You would also need ALL the code as otherwise it is fairly meaningless for development. Hopefully he is allowing it in the public domain.

Has he a website ?
Joe

Joe_H said:

Hi GG, I wouldn't try at this stage to go any further than he has - first of all, ask if he can provide a PCB ready made (if so - we want 2 lol - one for you and one for me! - definitely)
99% of the parts seem to be surface mount so you would use your rework gun / station, solder paste and flux. - you would have it down to a tee in about 10 mins practice.
Also, the microprocessor, what is he using ? I cannot see from the images. If he can provide details and the code we can program them no worries. It looks like he has ICSP on the board so updates are simple !. the 10 pin connector I presume offers ICSP and link to ODB socket (only 3 connections on that for ODB .....)

Get a ready made board, a display (looks like a bog standard 128 x 64 STN display ?) a processor - programmed or not and the code.
LONG after you have a working example - then use it to interrogate the protocols.. Considering changing from whatever processor he is using would be detrimental at this stage. Build it first and then study. You would also need ALL the code as otherwise it is fairly meaningless for development. Hopefully he is allowing it in the public domain.

Has he a website ?
Joe

Click to expand...

He has none made up other than his own personal 1 and does not want to build any more himself - reasons being part time and part expense.

My thoughts exactly in building a device. Step 1 recreate exactly what he has as it looks to be great at what it does. There are some language issues, but I think he has offered to supply the parts or parts list and how to use them. He is saying that he had 6 PCBs made in China - but a "universal PCB" could be used easier and cheaper - which is absolutely fine with me as it does not need to look elegant. As for programming, he says I will need a JTAG programmer - I have no clue what this is - I need to read up! In an ideal world his Rover code will just work with the Freelander - but there may be different initialisation and messages not in the Rover. As you say though - Step 2. Then there's the WABCO to consider!

I'll ask him if he mind's me sharing his info with my fellow L Series Freelander buddy

GrumpyGel said:

He has none made up other than his own personal 1 and does not want to build any more himself - reasons being part time and part expense.

My thoughts exactly in building a device. Step 1 recreate exactly what he has as it looks to be great at what it does. There are some language issues, but I think he has offered to supply the parts or parts list and how to use them. He is saying that he had 6 PCBs made in China - but a "universal PCB" could be used easier and cheaper - which is absolutely fine with me as it does not need to look elegant. As for programming, he says I will need a JTAG programmer - I have no clue what this is - I need to read up! In an ideal world his Rover code will just work with the Freelander - but there may be different initialisation and messages not in the Rover. As you say though - Step 2. Then there's the WABCO to consider!

I'll ask him if he mind's me sharing his info with my fellow L Series Freelander buddy

Click to expand...

Hi GG, JTAG is simply a header protocol for programming - no worries there -- programming headers are less than 4 quid.
A minimum list of requirements though are as follow - a FULL schematic, a FULL parts list and a FULL code and Hex / Bin dump for programming.
We would also need to know exactly what features he has with the L series unit or it may not be worth bothering with.
The L series was used in various rovers and also the honda civic diesels.I am sure he should be able to answer regarding the feature set for this model ....
If not, to be honest - AND - if it really only supports the 1.3.X ecu / dcu - then it is pretty useless on the freelander L series. It would probably not support the wabco and SRS. Actuator function on the DCU is not really worth bothering with - only on the ABS unit where it is vital !.
I actually suspect that as far as functionality and cost it would be easier and cheaper to get an 930 icarsoft unit.
This still has no actuator tests but would be as good (me thinks - without more info)
Or, just begger it and get a lynx

Joe_H said:

Hi Tony,
I would agree that there is definitely a setting in the CCU that disables alarm / immo.. Disabling alarm features is all in the CCU, however, the IMMO basically is in the ECU (with the result depending on the signal sent - or - settings in both CCU and ECU)

Can you explain in slightly more detail the data transfer situation (not protocol) of the Japan market unit CCU combo. Are you saying that data WAS transferring with IMMO / Alarm OFF - or that there was not connection between the two units ? - I am a little confused by your description. mate.

Also, depending on the answer to the above - there may well be a code sequence sent from the CCU that the ECU interprets as IMMO OFF - IGNORE - a bit like an aircraft transponder squawking 7700
That would be east to implement. However, IF the connection link remains established, then yes, the ECU must have an IMMO OFF code.
It is interesting that the 'read' of the eeprom in circuit (well - the read IF the eeprom is NOT in circuit still occurs and returns OxFFFF.
Perhaps a speciifc location setting of OXFFF with no CCU link is immo off (which ties into the removal of the 93C46 eeprom and ccu link disabling ECU immo) but not CCU starter immo or alarm. - or as said, a specific reserved code if ccu linked. or even a normal ecu immo with ccu linked but simply no alarm or auto delay immo setting. If the alarm is completely disabled, and the immo delay and led display is disabled, AND the link CCU to ECU is in place, then a standard immo signal can still be sent using original codes.
Jeez, so many combos
Was the CCU a VT27 unit ? (as used with the 1.3.1) - also do you know what processor / eeprom etc was in it ?
Cheers
Joe

Click to expand...

Hi Joe,

Some confusion here, I don't know about any setting in the CCU that disables immobilisation, maybe just alarm. But I am sure there is one in the ECU that does disable immobilisation.

In my case, I have an NZ new 1999 LR1 1.8i that had immobilisation (and alarm). I fitted a VVC motor out of an ex Japan Rover of the same year. The gory detail is here... https://www.landyzone.co.uk/land-rover/a-minor-upgrade-vvc.301389/

After I fitted the VVC ECU (which took longer than it takes to write), I found the car started and ran just fine, with no immobilisation line connected between ECU and CCU. CCU was unchanged in any way.

Prior to fitting the new VVC ex Japan ECU I spent some time trying to debug the data transferred between the two. With the original ECU and CCU, if I disconnected the data line between the two, the engine would not start and run.

I never looked at or opened the CCU.

So in my case, I have two ECU's, one, the original unit that won't run unless it receives the right signal from the CCU, and the ex Japan market one that runs quite happily without any data from the CCU. The CCU runs fine, manages remote locking, alarms etc. no matter what ECU is fitted.

Tony Reeves said:

Hi Joe,

Some confusion here, I don't know about any setting in the CCU that disables immobilisation, maybe just alarm. But I am sure there is one in the ECU that does disable immobilisation.

In my case, I have an NZ new 1999 LR1 1.8i that had immobilisation (and alarm). I fitted a VVC motor out of an ex Japan Rover of the same year. The gory detail is here... https://www.landyzone.co.uk/land-rover/a-minor-upgrade-vvc.301389/

After I fitted the VVC ECU (which took longer than it takes to write), I found the car started and ran just fine, with no immobilisation line connected between ECU and CCU. CCU was unchanged in any way.

Prior to fitting the new VVC ex Japan ECU I spent some time trying to debug the data transferred between the two. With the original ECU and CCU, if I disconnected the data line between the two, the engine would not start and run.

I never looked at or opened the CCU.

So in my case, I have two ECU's, one, the original unit that won't run unless it receives the right signal from the CCU, and the ex Japan market one that runs quite happily without any data from the CCU. The CCU runs fine, manages remote locking, alarms etc. no matter what ECU is fitted.

Click to expand...

Hi Tony, that answers a lot of questions, thanks for the info. However, it also brings up otherr questions...
If (on a standard ecu) you remove the appropriate 8 pin EEprom from the ecu then the immo is removed. However. If you leave the comms connection from CCU to ECU - OR - disconnect it, then the CCU disables the cranking via the starter relay. So in all cases afaik the ccu will disable crank without a valid comms link.
If I read you correctly, then you have the original CCU with a Jap ECU without IMMO. Yet on disconnecting the CCU - ECU comms the engine STILL starts ? - that I find confusing (based purely on the info I have). I considered a two way single wire data flow from the ccu to ecu with an ack return to the ccu to confirm key authenticity, however, this could not occur with ccu comms disconnected.
The question raised is - under what circumstances does the CCU enable start cranking unless a two way ACK / NAC is occurring.
You also appear to have this issue with the original ecu and ccu with comms disconnected. You also see a no crank ? - or, do you get crank but no start.?
This is highly confusing
The original CCU has to have a way to know when to enable the starter - NB - I have not tried this (yet) I have just ordered an ECU CCU matched combo to experiment with. I am purely going from researched info so far. It could be that the key fob data exchange with the CCU is enough to enable CCU Starter activation but the ECU needs comms for the Immo deactivation. If that is the case, removing comms would cause a crank but no start situation.
Can you confirm if this is the case or not ? - this bit confuses me Tony

"With the original ECU and CCU, if I disconnected the data line between the two, the engine would not start and run."

Joe