Progress has been a bit slow on this lately but probably enough to be worth an update!
The insurance has now lapsed on the car and it has been sorned from the start of this month. Fortunately before this happened I was able to collect a couple of hours CAN logs.
This was the CAN logging setup I ended up with:
The GVRET box is connected inline with the engine ECU, the car side bus connects to one CAN port on the box with the engine on the other. The box is then set to do port forwarding so that the intercepted messages get forwarded on to their destination as well as being logged. This setup means that the log file contains details of whether the source of the message was the car's bus or the engine ECU and so saves a lot of guessing. Tip - if doing this and saving to SD card make sire that you set the box to GVRET format, if you leave it in the default CRTD mode it doesn't save the source bus information.
The power supply for the box was initially from a cigarette lighter USB adaptor which meant that it turned on and off with the ignition (and so could be left connected without draining the car battery). Unfortunately, while the car started and appeared happy, the ESP and ABS were non functional. Presumably there is some early initialisation that was missed while the box booted up. Powering the box from from a separate battery sorted this.
Some initial captures were taken with the car up in the air and the wheels spinning to identify the main bus messages and then more logs on the road to get a better understanding.
I found it quite surprising just how useful the full CAN bus data can be. I've used OBD in the past for diagnosing problems and while it's useful you only get half the picture. The following isn't particularly EV related but I found it interesting so will include it here.
Take for example the ABS - the car is happy, no fault codes, no warning lights and no odd behaviour, however, looking at the CAN logs for the ABS sensors (message 0x080, two consecutive bytes per wheel):
Two of the traces, the front wheels are fine, nice and clean. The two rear wheels aren't quite so good, one is OK just a bit noisy but the other is obviously on its last legs. Lots of noise and the occasional full scale spike - not nice! Quite surprised the ABS warning light isn't on yet.
Looks like a pair of new rear ABS rings will be needed while the car is in bits.
Also think I have identified the messages needed to keep the ESP working. I'm sure a lot of people will think that this isn't worth the bother and if it was just a summer car I would agree but the plan is to use it all year round and having had a couple of interesting handling experiences with rwd cars on greasy roads in the past I'd prefer it to continue to function. Initial tests on the car lift (front wheels stationary so ESP trying as hard as it could to keep the rear wheels stationary identified the relevant message from the ESP unit (message 0x208, byte2, 8bits). This seems to be a torque limit massage which normally sits at a value of 255. When the ESP becomes active it drops to a lower level which appears to be the torque which the engine should limit to. This only makes sense if the engine also tells the ESP unit what torque it is currently generating and this appears to be message 0x310, byte 4, 8bits.
Below is a plot taken while out on wet roads going round a fairly long. open, medium speed corner. Now going round the corner I didn't notice anything going on, the throttle possibly felt a little unresponsive but nothing concerning. On leaving the corner I noticed the ESP light flashing and at the time thought it must be the earlier mentioned ABS issue starting to act up. On analysing the data though the ESP can clearly seen to be working!
The red trace here is the torque output torque message sent by the engine, the blue trace is the torque limit sent by the ESP module and the green trace is the reported boost. I haven't shown the throttle but it essentially matches the engine torque output trace (but scaled). It can clearly be seen that when the ESP becomes active (when the blue ESP trace drops down from its normal unlimited 255 value) it effectively takes over control of the engine replacing the red trace.
What confused me initially was that the engine output (red trace) didn't seem to follow the commanded ESP torque value. To better understand what was going on I added the boost trace. This clearly shows that the engine output torque message is lying and the torque does actually follow that commanded by the ESP message. On thinking about this a little more it appears that the engine message isn't actually the torque output from the engine but rather the torque requested by the driver from the throttle. This makes perfect sense because the ESP module can then use this to determine when it is safe to pass control back to the driver (obviously a bad idea if the car is still slipping slightly and they have the throttle wide open - which is actually quite likely as I'm pretty sure my automatic response to the slightly unresponsive throttle was to unconsciously press it down harder! - can be seen by the rise in the red trace just after the ESP kicks in).
On the traces you can clearly see the wiggle on the blue trace where control is 'taken' by the ESP module (~210000) and then returned to the driver (~214750). I'm wondering whether the is also a slight reduction in the throttle even after control is returned until the ESP value returns to the full 255 value as there seems to a step in the red torque curve there but there isn't enough data to be sure.
So the plan for the conversion is to send a scaled value of the throttle pedal position on the 0x310 message and accept a torque limit message to inverter on 0x210. Hopefully that will allow the ESP operation to continue to function and if not hopefully there is enough captured data to figure out what else is needed.
On a completely non related topic I have also started playing with a replacement for the rev counter. This is the standard instrument cluster:
The right hand RPM gauge will be fairly useless following the conversion. I considered repurposing it for something but it seemed a bit of a waste of space. Instead I'm going to use a Pimoroni Hyperpixel display, these are round, 480x480 pixel, IPS displays that are just about the right size to replace the rev counter. A Pi Zero 2W plugs onto the back meaning that it can be programmed using any standard Linux tools (I've got it set up with remote cross compile and debug in Qt which simplifies development). This is a mock up of what the screen will look like in normal operation:
The ring round the top half will show battery current (regen on the left, drive on the right, colour coded to battery capability - green up to 3C then turning to red), the middle bit is predicted range with inverter and motor temperatures below and then battery voltage and temperature graphed below that (again colour coded, red for anything that is not considered normal - no idea what sensible limits should be here!). Beneath that is a general info/warning/error display. It will also be active during charging to show charge status.
There is also a I2C to CAN bus board connected that will be used to pick the required messages up of the bus.
At the moment it's just a basic framework and still needs all the CAN message handling adding.
I also added Navit sat nav to it - not quite sure why but then why not!
The satnav turned into a bigger project that the gauges in the end, and probably not worth the bother, but it's done now.
Unfortunately I'm way behind on the house and still have a bathroom to refit and couple of rooms to decorate before I can start pulling the car to pieces but will try to keep chipping away at it in the background.