IPace Air Con Valve Block

Jaguar / Landrover hardware hacking
Post Reply
Pete9008
Posts: 141
Joined: Sun Apr 03, 2022 1:57 pm

IPace Air Con Valve Block

Post by Pete9008 »

Just bought this I-Pace air con valve block:
I-Pace Valve Block.JPG
Hoping to use most of the bits off it but need to figure out the valve controls - does anyone have any experience or information on this type of valve that they could share?

I'm fairly sure all the valves come from Sanhua Automotive (https://www.sanhuaautomotive.com/produc ... ion-valve/)based on the logo on the electronic expansion valve. While the valve I have doesn't look quite like the one on their web page I think it is probably the previous generation as there are a few pictures of a similar one on the web linked to Sanhua.

The larger valves only have Jaguar marking but I think they are electric ball valves also from the same company (https://www.sanhuaautomotive.com/produc ... all-valve/).
I-Pace Valve.JPG
Again they don't look exactly like the picture but similar enough, and with the same connectors, to make me think they are older generation Sanhua parts.

I can't find any information on the electrical interface online. While I could sacrifice one of the valves to work it out (the case is glued/plastic welded shut so would need cutting open) I'd prefer not to if possible.

All current Sanhua parts are detailed as having either both LIN and PWM interfaces (expansion valves) or just a LIN (ball valves) so LIN seems a likely candidate.

Does anyone have any tips for identifying which pins are power and which are comms, or a good process for hacking LIN bus interfaces?
User avatar
EV_Builder
Posts: 799
Joined: Tue Apr 28, 2020 3:50 pm
Location: The Netherlands

Re: IPace Air Con Valve Block

Post by EV_Builder »

Pete9008 wrote: Sat Jun 18, 2022 2:12 pm Just bought this I-Pace air con valve block:
I-Pace Valve Block.JPG

Hoping to use most of the bits off it but need to figure out the valve controls - does anyone have any experience or information on this type of valve that they could share?

I'm fairly sure all the valves come from Sanhua Automotive (https://www.sanhuaautomotive.com/produc ... ion-valve/)based on the logo on the electronic expansion valve. While the valve I have doesn't look quite like the one on their web page I think it is probably the previous generation as there are a few pictures of a similar one on the web linked to Sanhua.

The larger valves only have Jaguar marking but I think they are electric ball valves also from the same company (https://www.sanhuaautomotive.com/produc ... all-valve/).
I-Pace Valve.JPG
Again they don't look exactly like the picture but similar enough, and with the same connectors, to make me think they are older generation Sanhua parts.

I can't find any information on the electrical interface online. While I could sacrifice one of the valves to work it out (the case is glued/plastic welded shut so would need cutting open) I'd prefer not to if possible.

All current Sanhua parts are detailed as having either both LIN and PWM interfaces (expansion valves) or just a LIN (ball valves) so LIN seems a likely candidate.

Does anyone have any tips for identifying which pins are power and which are comms, or a good process for hacking LIN bus interfaces?
I'm haveing the same device from Tesla EXV to open/discover. Looking for the same answer being well fit with CanBus LIN is another type of structure. With message types and with Checksum types.

To determine interface i would try to dig up the jaguar schematics for the vehicle it comes from. i'm planning on building a thermo controller for using those sensors and the canbus AC unit from tesla.
Pete9008
Posts: 141
Joined: Sun Apr 03, 2022 1:57 pm

Re: IPace Air Con Valve Block

Post by Pete9008 »

EV_Builder wrote: Mon Jun 20, 2022 7:50 am To determine interface i would try to dig up the jaguar schematics for the vehicle it comes from. i'm planning on building a thermo controller for using those sensors and the canbus AC unit from tesla.
Unfortunately I haven't had any success finding the diagrams or workshop manuals (even paid for ones) online. If anyone has access to them I'd appreciate it if they could let me know the pinouts?

In absence of the pinouts I'm going to assume that the electronics are well designed and reverse polarity protected! The plan is to try to power the valves on each possible combination of pins (using a current limited supply to increase the chance of not killing anything). If the current consumption looks sensible I'll then send LIN headers into each of the remaining pins in turn. If there is no response move to the next permutation.

I have ordered a LIN transceiver (TJA1020) to connect to an FTDI USB to TTL serial cable I already have. I can't find any LIN hacking tools so have written a fairly crude program to send out all the possible frame headers in sequence. There are only 64 so it is a pretty quick test to run. If the valve responds to any address I'll then add code to send data frames of varying length and content to see if they can be persuaded to move. This stage is likely take a lot longer as there are a lot more combinations of slower tests :(
Pete9008
Posts: 141
Joined: Sun Apr 03, 2022 1:57 pm

Re: IPace Air Con Valve Block

Post by Pete9008 »

Think I've got the first of the I-Pace valves working, the electronic expansion valve one - this one (there are various numbers on it and I'm not sure which is the Jaguar part number):
LINTestRig.JPG
Ignore the wire colours, they were from an initial setup based on some Tesla (who use a similar looking valve) wiring diagrams and don't match the signals (in the picture +12V is on the grey and LIN is on the red wire). The pins are numbered inside the valve connector and the pinout is:
  • Gnd - Pin3
  • LIN - Pin2
  • +12V - Pin1
The picture also shows my serial to LIN bus cable. It is just an FTDI USB to serial converter with a TJA1020 used to provide the interface. I'm talking to it with a very rough Qt command line application.

The valve talks LIN at 9600baud and uses the LIN 2.0 extended checksum calculation.

It responds to two LIN bis ID's:
0x35 - read from the valve, returns 8bytes plus checksum. The last 4bytes are always 0xff, the other 4 bytes are:
  • Byte0 - Status
  • Byte1 - Error Flags
  • Byte2 - Current valve position - low byte
  • Byte3 - Current valve position - high byte
I've only figured out half of the status bits:
  • Bit0 - Receive error flag - 1 if a receive error has occurred since last status read
  • Bit1 - Unknown - to date always 1
  • Bit2 - Valve is currently calibrating end positions
  • Bit3 - Calibration process has completed (0 at power up until calibration is commanded and has completed)
  • Bit4 - Valve is moving
  • Bit5 - Unknown - to date always 0
  • Bit6 - Unknown - to date always 1
  • Bit6 - Unknown - to date always 1
And two of the error bits:
  • Bit4 - Supply over voltage ( > ~17.5V)
  • Bit5 - Supply under voltage ( < ~8V)
  • Others - Unknown - to date always 0
Fairly sure there will be bits to flag a stalled motor, motor open/short circuit, maybe temperature, etc but have no means to identify them.

0x34 - write to the valve, accepts 8bytes plus checksum. The last 4bytes are always 0xff, the other 4 bytes are:
  • Byte0 - Target position - low byte
  • Byte1 - Target position - high byte
  • Byte2 - Valve enable, 0x01 to enable, 0 to disable
  • Byte3 - Force calibration, 0x01 to start, needs valve to be enabled
Some notes:

The valve will revert to the closed position and then power down if no status read is received for a few seconds. Commands only need to be sent when a position update is needed. I've used 100ms and 200ms message intervals and both worked fine.

Power consumption is less than 10mA when powered down, ~20mA when powered up but stationary and around 100mA when moving.

Valid valve command positions range from 0 (closed I think) to 480 (0x1e0 - fully open).

On power up the valve will report a position of 120, no idea if this is real or not as I can't see the needle valve. It won't accept a target position until a calibration has been run but a target position when sent with the calibration is accepted.

The calibration winds the valve to fully open (0x1e0) and then to fully closed (0x00) and then to the target position. You can hear the motor stall at the endpoints.

The status register reads the position during calibrations and moves (real time update).

I'm sure there are other fields and flags but this seems to cover the basic operation so I'm going to stop there and move onto the ball valves. There is a patent from Sanhua describing a very similar looking valve. It gives some details of LIN packets but they don't match the above (guessing an early prototype). However it does mention commands to control the stepper motor current and step speed so it is possible these may still be in the protocol somewhere?

For anyone interested the test process I developed to figure this out was:
  • Had a good look for pinouts or wiring diagrams online. Couldn't find any so had to try a slightly more risky approach.
  • Randomly made connections to the valve, using a current limited power supply (~20mA), until it pulled a sensible current. Note - in doing this there is a high likely hood or reverse powering the valve - a well designed valve should be able to survive this but there is no guarantee. Similarly the LIN bus pin should survive this. Would be much less inclined to try this with other buses though.
  • Send all ID (0-60) headers to the valve to see what it responds to. I started at 19200baud and then dropped it to see what worked. 9600 was the only rate that got a response.
  • Scoped the valve response to check it was actually 9600
  • Checked the message checksum from the valve to see which one it was using.
  • Added code to send data packets with the same checksum to all other IDs while watching the status register. Noticed that only 0x34 caused a change to the status register and then only if it wasn't an 8byte packet. Hypothesised that the status change was an error bit and therefore 8bytes on 0x34 was the only valid ID.
  • This wasn't a good result as there are an awful lot of combination of 8bytes. Tried setting the last 6bytes to 0xff (same as status message) and cycling through all the values for the first two bytes (automated in code looking for a status reg change but still took over an hour) with no result.
  • Got lucky! Tried sending the same value to all 8bytes and found that 0x01 got the valve to move. Once it was moving a few more lucky guesses found the rest.
Post Reply