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):
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.
