More CAN filtering and next ideas...

In the last post I mentioned some warnings and errors appearing in the dashboard due to my hacking of message 0x167. Because the CEM now thinks that the engine is running, it validates some other messages coming from the ECM. Today I found some time to tackle the issue - and it took only 2 hours to not only fix the problem but enhance the situation even more :)
I found out that the status of the alternator and probably even some information about the cooling system (not the temperature itself) is sent via message 0x3d3. I replace the content of this message with values from the other S80: 0x24, 0x42, 0x00, 0x04, 0x75, 0x78, 0x76, 0x08 and after clearing the DTC's, the Dashboard is happy - as will be the experts conducting the regular checks for street worthiness. I didn't bother yet to find out exactly which bytes are relevant.
As I was already at it, I thought somewhere the RPM must be hidden too. In my previous hacks, I only focused on the climate controls and error messages in the dash. I never checked the tachometer. So I checked the logs in Excel again to find messages from the ECM which differ between "ignition on" and "engine idle". In "engine idle" they case must fluctuate a bit because the engine speed is never 100% constant. As Murphy's law requires, I started on the wrong side with the high numbered message id's until I hit message 0x12a and saw the needle jump up to 700rpm. Bingo! The engine speed is encoded in the last two bytes - well, actually only the last 13 bits. As byte 7 already had the value 0xe0 with ignition on (in my car), I simply add the two values. So that's what it looks like now (mind that the array starts at [0] - hence [7] is byte 8:

bytes[6] = 0xe0 | (rpm & 0xff00) >> 8;
bytes[7] = rpm & 0xff;

To transport the rpm of the electric motor over to the CAN filter, I use GEVCU's CAN bus which is connected to the car's high-speed bus and send the value in a new message id 0x129. The filter picks up the value when message 0x129 is received. Then, when message 0x12a is received, it injects the value. Works perfectly fine and now I have a working tachometer - well, except that the instrument doesn't display rpm's between 0 and 500 - it stays at 0 and then jumps to 500 - but what the heck, I can live with that.
The code for the filter can be found on github:

Next ideas

As I don't have a clutch anymore, shifting has become a bit tricky. Gears can only be shifted with zero torque and the synchros are used to adjust the motor speed. This shortens the life of the synchros and is also difficult for drivers unfamiliar with the procedure. Even I get into trouble now and then when the GEVCU dash isn't working and I don't find the spot where I'm coasting (zero torque). So the next step is to grab the vehicle's speed from the CAN bus (not via OBD2, too slow) and from the ratio of engine vs. vehicle speed find out in which gear I'm driving. Then I'll add a capacitive switch to the gear shifter and change the code of GEVCU like follows:

1. When the switch is activated (gear knob touched), the torque is reduced to 0 for 1 sec (or less).
2. With 0 torque, the driver can switch the gear to "neutral".
3. Depending on wether the throttle is in "acceleration" or "deceleration" mode, GEVCU will adjust the motor speed within 0.2-0.5sec so it fits the next lower or higher gear.
4. Torque is again reduced to 0 (or almost 0) so the gear can be inserted.
5. When the knob/switch is released, normal operation is resumed.

I just made up the timing as I have no experience yet on how long the steps will take. I'll have to experiment with the timing as well as the torque applied to adjust the speed quickly enough but without unnecessarily stressing the hardware.
And of course I won't be entering the speed ratios for the different gears.. the GEVCU has to be able to find the different ratios automatically.