Hello,
My EAS is giving me problems and I don´t know how to proceed further. I would be great if I could get some hints....I have read about every manual, document tand internet post there is for the EAS but I am at a loss now....

Since I have the car (2 years) it will rise to high without me commanding it. Sometimes every couple of minutes, sometimes once a month. Also when the inhibit switch is on. I could usually tell it to go down again, It would also give me faults (usually "pressure switch open") with the same regularity. I have a Nanocom.

I removed both multi-connectors behind the left and right kick panels and soldered them. They still look dry and fine. No change in behaviour.
Car will not lose height overnight, but will often be too low at rear left (new airbag) when I park. I replaced both left airbags when I got the car, of the remaining ones 1 looks like new, the other OK.

Since a couple of months the usual fault changed to "invalid fault code" which I can clear but will come back regularly, sometimes doing nothing, sometimes leading to soft fault, sometimes to hard fault. Usually when the fault comes the car will be high at the back and low at the front...

Compressor was loud for some time but is quiet again now and works well (fills empty system in under 5 minutes). The green/purple cable leading to the compressor was burnt at the connector but still worked, fixed that.
I just refurbished the valve block but that made no difference other than now the rear left, which was usually to low when i park, is now too high.

Other new observations:
Compressor will run even when engine is off.
Height will change even when door is open ! That is new. But Nanocom confirms that door is open, so no lock switch fault...

I can switch on/off all valves with nanocom and hear them engage.

All that comes to my mind now would be the ECU or the driver pack.....any ideas or further questions would be very welcome before I lose faith in this wonderful car....

greetings, Max.

Most likely cause is the left rear height sensor has a dead spot or poor connection at the plug. I was asked to look at one car that was doing the same, suddenly deciding to go to the High setting and a squirt of contact cleaner in the plug on the height sensor cured it (although I did tell the owner that a new height sensor may be needed in the not too distant). Use the Nano to look at the sensor readings and move the car up and down a few times. If you get a sudden low reading on one of the sensors, the ECU will think a corner is low so try to pump it up to get the reading correct.

What a conicidence, today a new fault came up: "Rear left height sensor out of range" so you might be right there, thanks....:-)

I still have some questions though:

When I drove today it did all kinds of weird stuff up and down. and even though the rear left was very high most of the time, the height sensor reported this correctly. The system war very erratic but the reported height at each corner always corresponded to the actual heights. Only the system didn´t react when one side was very high.

Also when the car goes to high on its own, I suspect it is going in the "super-high" mode, or is this the normal "high" height in this picture:
https://c.web.de/@337510546125364120/NhK4NfUiShKmRFb1PF9QDQ
I measured the height on the rear from mid-hub to wheel arch and its 57 cm (normal high is supposed to be 51 cm).

Also when I open the driver (left) door, the Becm will report door open, but the EAS will not detect an open door. Other doors report correctly.

Maybe I´ll also look for a used EAS ECU....?

greetings, Max.

As you have Nanocom, do a recording to SD card while driving a few miles. This might show a sensor dead spot.

It definitely looks like the car has gone "Extended Mode" which is a failsafe if the ECU thinks the chassis is grounded. Simply if the ECU sees no change in height when trying to adjust, it assumes it's grounded and extends fully !!

The other thing that causes the same issue is bad connections between the driver pack & solenoid valves. This triggers the same extended mode to happen. The connector is underneath the valve block, so that has to come out to check it.

OK, I did a test drive with several height settings and logged them on the Nanocom (didn´t know that that worked :-)

I tried the CSV Viewer Program from BBS but the program would not open the csv files, saying they contain invalid charactes and no log data, (any ideas why???) but I managed to convert the raw height sensor data to a graph with Excel. Here are three test drives:



The bottom four colours in the legend correspond to the height sensors described on the left hand side.
On the second drive the EAS went into Error mode and in the log the status went from "high profile" to "dormant" which is probably when the actual heights do not change as the EAS expects them to...but it didn´t go to extended mode though...

What I make of all this is that sometimes the system just does not react to the target heights and sometimes it does.
The front left sensor mostly sems to read too high and the rear left mostly too low.
There are also some peaks (mostly on the left side) that may show the sensor sending a wrong signal. But it was a bumpy road so I don´t know as to how much the signals fluctuate normally.....

I guess next would be to swap the sensors from side to side....?

Oh yeah, the connector from driver pack to solenoids looks clean, nothing obvious there....

greetings and thanks, Max.

Graphs aren't showing up I'm afraid and if I try to open the links, I get a message that I think is saying I don't have permission to view them. I had the same problem with the CSV Viewer but found it does work on some files. I think it has something to do with how they are closed when you stop recording. Although I use Excel quite a bit, only for numbers and have never managed to get it to convert to graphs.

Swapping sensors side to side is a good plan as not only will it show the suspect readings moving from one side to the other but it will also be using a less used part of the track so may even cure the problem. You will need to recalibrate afterwards and it does get offended if the bit counts from side to side are very different.

Hm, if I copy the entire Link and paste it into a new browser tab it will show a thumbnail of the graph and give the options "herunterladen " (download) or "öffnen" (open/show).
Is there a better way to integrate pictures into this forum ?

I had the log files "closed" for quite a bit as I left the Naocom on until I was back home from the test drive....Maybe it didn´t work because I have the 1.37 beta version on the Nanocom ? Changed back to 1.36 and will see if it works then....

I am amazingly bad at excel but making a graph from the numbers was surprisingly easy :-)

OK, so calibration would be necessary, will have to make up some blocks then...

Thanks, Max.

I would suspect the easiest, or at least the most reliable way of doing it, would be to save the graph as a picture (using the Windows snipping tool if you have to), upload it to imgur.com or similar and insert it as a picture (see https://rangerovers.pub/topic/1021-inserting-an-image-from-imgur)

OK, I tried doing that via imgur, but I don't understand how imgur works, it doesn't seem to be a filehosting Service but some Kind of "instagram" type thing, or?
So I create an account, post the picture and theb share the link or how does it work...?

You create an account, sign in then click on your name. A drop down menu appears with Images as one option. Click on that and it will show that you don't have any but with a big green Add Images button.

OK, I finally managed it, tried it on the phone but wouldn´t work, but did on the computer.

Now updated Post #5 with the graphs.

That's better. For some reason it is only showing 2 of the 4 target heights, but they are as you would expect, straight lines of varying height depending on what height it is supposed to be aiming for. But, although there is going to be movement up and down on the actual heights as you drive, I would have expected them to roughly follow the target heights with a bit of variation either side of target. The first graph shows something like I would expect, the others look completely wrong.

Would be useful to know what your stored targets actually are ?? Was the change from Motorway to Standard, or Std to High mode.
Also the speed & valve status during the drive would help.

It certainly appears that the ECU commanded a height change about third of the way in & target heights went up accordingly, but the actual sensor values stayed in the same range for a while. Then after a few mins the heights actually increased. Would be interesting to see the valve status & confirm this.

Also was the pump trying to fill the tank, hence not enough air ?

Regarding to Driver to Solenoid connector, you need to take one pin out, and test the tightness of each socket contact. Even if they are clean, the sockets do lose their grip on the pins & become intermittent.

I agree swapping sensors over might give more info, but they seem to be working within normal variation to me.

Lastly, remember Nanocom can only read the data relatively slowly, so can miss data if the ECU is doing stuff in-between the readings. Nanocom grabs all data every cycle, rather than just what is needed for the trace. Lots of useless data is read.

So I spent some hours going into the details of all the logs in excel and converted them so one can see them graphically in the csv Viewer.

The trick is to convert any "words" in the spreadsheet (like on/off, closed/open, standard/high pro, etc.) into numeric values (e.g. on=1, off=0). Then you can open the csv file with the Nanocom csv viewer which is great to see every detail although the handling of the program is pretty clumsy.

Here are the logs directly from the Nanocom (the ones I created for Post #5) Here one can read all the switches and valve positions:
https://c.web.de/@337510546125364120/VGPX1iUQQ0yyaWKdqnPx3g

As they are not images, one can not upload them to imgur....

And, in case anyone is interested, the csvs converted from "words" to numbers:
https://c.web.de/@337510546125364120/G8MjRHxSRq6vZhwm2agvLQ

My conclusion from going through all the data:

• Some of the time the system works as is intended, user inputs become the correct valve actions which lead to correct heights. (log EAS1)
• Some of the time (usually resulting in an EAS error) the user inputs become the correct valve actions but do not lead to the heights changing as expected. The only explanation that comes to my mind is that the valve actions of the ECU do not actually take place as intended, therefore the target height is not achieved. That would lead me to believe that the driver pack (or cable connections between ECU and valves) does not drive the valves properly. Since the ECU has no feedback if the valve is actually opening/closing or not.
• Another thing is that the on/off of the compressor is not in sync with the opening/closing of the pressure switch. Does that have to be?

Sorry to have dug this deep into this EAS hole, but I would like to know what is happening and found the log function of the Nanocom to be invaluable and new to me. Throwing new parts at the car and in the end not knowing which actually cured the problem is very unsatisfying...
Tomorrow I will be doing a longer drive with trailer, I will log the whole trip, there are bound to be surprises then, so I might catch something interesting on the log then.

greetings, Max.

Mirafiori-Max wrote:

My conclusion from going through all the data:

• Some of the time the system works as is intended, user inputs become the correct valve actions which lead to correct heights. (log EAS1)
• Some of the time (usually resulting in an EAS error) the user inputs become the correct valve actions but do not lead to the heights changing as expected. The only explanation that comes to my mind is that the valve actions of the ECU do not actually take place as intended, therefore the target height is not achieved. That would lead me to believe that the driver pack (or cable connections between ECU and valves) does not drive the valves properly. Since the ECU has no feedback if the valve is actually opening/closing or not.
• Another thing is that the on/off of the compressor is not in sync with the opening/closing of the pressure switch. Does that have to be?

At least its working some of the time, so all components are actually functional.

Definitely check the pin & socket contacts inside the connector under the valve block. As I said take one pin out of the housing, and try it into each socket contact. Bet you a pint or two that some are loose !!

Generally if the pressure switch show tank low, then the pump will cycle on & off each time the ECU does even small height adjustments. Only if the tank is full & pressure switch closed will the ECU do height adjustments without pump coming on . . . and then only for small adjustments.

I definitely noticed that Nanocom often shows strange combinations, such as pump running after pressure switch closes, but I do suspect it's simply the delay in reading the data. Consequently the pump is already running, but Nano doesn't yet know that the pressure switch has changed state.

Going off at a slight tangent but having consulted my Excel expert (the missus), I now know why I can't get the data to convert to graphs. The csv file from the Nanocom is semi-colon delimited which my version of Excel (Office Pro 2013) doesn't recognise so puts each line in the same column rather than splitting each figure into a separate column. I seem to recall that the previous versions of Excel gave the option of telling it what the delimiter was but neither of us can find out how to do it in this version.

@Gilbertd

Doesn't look like its very obvious, but this should help there with Excel

https://support.affinity.co/hc/en-us/articles/360044453711-How-to-open-CSV-files-with-the-correct-delimiter-separator

Still works in office 365 so it should be the same in 2013 or at least similar enough.

Found the Convert from Text command and that got each reading into separate columns but can't then convert that into graphs. I thought it was because some columns had words rather than numbers in them (On or Off for the compressor, Standard or Low for target height, etc) so I hid all columns with non-numeric entries. Still can't get a graph to appear though, I just get a box appear with nothing in it.

I marked the spreadsheet starting at the left top corner, marking the first couple of columns down to the end, then right-clicked "fast analasys (?)" (Schnellanalyse in german) and then one can choose what kind of graph excel shall produce....
But the Nanocom csv viewer is a lot better to analyse the data because you have many more viewing options. You just have to convert all words (on/off, open/close, etc.) to numbers. But that is easy with Ctrl-H (find and substitute).

I have now done several test drives with the Nanocom logging the data and have ploughed through numerous log files with endless number columns and many many graphs, comparing all data and how height changes ate influenced by them....
The cars I had until now mainly needed a set of spanners and a welder, but with this one I am staring at excel spreadsheets for hours...^^ Well, that´s evolution for you....

There are more ride states aside from Extended, High Profile, Standard, Low Profile and Access, namely "ECU Wakeup", "Levelling" and "Dormant". They are mentioned in the Blackbox Solutions Manual, but for example not what they really mean.

What I found out is that "ECU Wakeup" can occur at any time while driving, always after (in my case the rear left) one corner is too high, the corresponding valve and inlet valve have opened, but no change in height has occurred. (This can of course also happen without resulting in the ECU Wakeup Mode, so I am not sure how the ECU decides to do so.) When the ECU goes into ECU Wakeup, all valves are closed. This Mode is always followed be "Levelling", which causes all corner valves and the exhaust valve to open, the ECU sets Target height to 20, and the car goes all the way down to the bump stops (hard fault). This will stay. As fault I will then always have the "invalid fault code".

The other state is "Dormant", which can also occur at any time, but when one corner (again, rear left) is too low, the corresponding valve and inlet valve are open for some time and no height change has occurred. But in this state the ECU continues to function "normally", i.e. opening and closing valves according to target height, and no sinking to the bump stops.

Another, maybe not connected, thing is that when I open the driver (left) door, the inner light does not come on and the opening of the door is not recorded by the EAS ECU, so no inhibiting of function. But in the BECM Menu, I can see that the "Door ajar" switch is functioning properly. As far as I know the BECM send that signal to the EAS ECU....could that be related and point toward some kind of intermittent electrical problem or is that something else...?

BTW, I have not checked/tightened the Multiconnector in the EAS box, that is still to be done....

hope I am not boring anyone but I am trying to sort this all in my head and writing it helps too :-)

greetings, Max.

P.S. The forum response time seems extremely slow since yesterday or is that just me?