2012 ZX-10R Reverse Engineering CAN Bus Data

Hi, first time poster (I think?)

Okay, my aim (pun not intended, read on) is to reverse engineer the can-bus on my Gen4 (2012) ZX-10R, standard ECU (not race ECU).

I bought an AiM (there's the pun) Solo2 DL for geeky fun and to data log and analyze my track day exploits to see just how terrible I am and where I can do better. Data analysis is kinda fun, I know I know, I'm a nerd!

I am suitably geeky and because the Solo2 DL doesn't log as much as I wanted I now want to create a custom driver to expand the range of data logged by it, if possible.

Things I would like to add:
Front and rear wheel speed sensors (AiM claims they log it, but it's always zero, AiM support states its expected)
Secondary Throttle Position (This will show when TC is doing things, very interesting!)

Thats for a start at least.

Already logged by AiM by default:
RPM
Gear
Clutch
TPS (Throttle position)
Wheel Speeds (But always zero, disappointingly, see above!)

So I've made a CAN Bus sniffer from my Raspberry Pi and tonight I have managed to log some data.
I've already found:
Front and Rear wheel speed sensors (Not clear what format the data is in, pulses per <something> perhaps?)
Throttle Position (AiM already logs this)
Rate of change of throttle. (How fast you are opening/closign the throttle)

The last one was a little surprising I didn't know that data existed.

I will post updates as I make progress in case anyone is interested.

What I *REALLY* need is, if anybody has it, all the CAN data AiM already has. So I can "build on" what they have, rather than reinvent the wheel!

I'm not sure how far I will take this before I either get what I want, or get bored with lack of progress. (Being honest) But so far things are looking interesting.

 

So CAN ID 010, byte 3 & 4 is rear wheel speed, I believe. I had ignition on, engine off, bike on paddock stands and I spun the rear wheel by hand to get:

00 72, is the moment I spun the rear wheel and the number slowly decreases as the rear wheel slows...

Then for the front wheel I get CAN ID 010, bytes 1 and 2.


All these numbers are hexadecimal, so for the rear it represents a max reading of 114. (114 what? I am not yet sure.)
For the front the max is 149.
It could be pulses per <some unit of time>. But I can look into that in due course.

 

Cant help with much, but that bike uses a encoder ring on the front and rear wheel to measure speed.
You might be getting pulses per second.

Would make sense the front has a higher number as the overall wheel diameter is smaller.

 

Small update. I am working on the assumption the wheel speed sensor readings are in pulses per second, this seems ”logical”. I have started to create a protocol for my new ECU configuration in the AiM software. I calculated an “ideal” gain and offset value for the wheel speed sensors.

I didn’t bother to measure tire circumference yet, I just calculated it based on tire diameter.
17” wheel, with 120/70 front tire and 190/55 rear tire. Based on this I came up with a gain value (just a scaling factor) to convert from pulses per second to mph.
I also counted the number of “teeth” on the reluctor rings, 50 for rear wheel and 48 for the front wheel.

Next step, I will populate TPS, and TPS rate in the protocol. As I have CAN ID’s for these already.

I need to test my new protocol out. I will update my Solo 2, run up the rear wheel on the paddock stands and compare rear wheel speed on the Solo to that shown on the dash to see if I am even able to read it (1) and if it’s even close to the correct ball-park figure (2).

Here is what I still need to find CAN ID’s for:
Gear position (Should be easy)
Clutch position (Should be easy, it’s just a switch)
RPM (Should be easy)
ECT (harder as it changes more slowly, unless I unplug the sensor and create a dirty “simulator” to plug into the harness.
IAT (harder, but I can maybe warm with my hands to look for the changing can data.)
Secondary Throttle Plate. (Harder as I have no direct control over it to make it move, but I might be able to flash a weird STP map into the ECU to force a clear STP position change at a known RPM in neutral.)

Rob

 

Yes possibly. But I was spinning both wheels by hand, with the bike on the stands. I can spin the front a lot quicker as it doesn’t have the added mass of a chain and counter sprocket, sapping energy.

Interesting the front and rear wheels have different number of pulses per revolution too. Front = 48, rear = 50, which will make the raw number for the rear higher always as well.

 

So I’ve found and identified a lot of data in the raw CAN stream, still more to ID though.

I’ve managed to create a small CAN driver/protocol to log both front and rear wheel speed sensors which AiM was getting a fixed 0 mph for on my bike, in addition I’ve added TPS and RPM which I found also. Tomorrow I will test RPM, and RWS accurate VS the speedo, when the kids are not in bed.

 

Now that people are awake I and start the engine. I can already see my gain for the RWS -> MPH conversion is off a little.



Rob

 

So far I have found:

1. Engine RPM
2. Gear Position
3. Clutch Switch
4. Throttle Position
5. Rate of change of Throttle position
6. Secondary Throttle Plate Position (I am not 100% rue this is STP, it could also be intake air pressure drop across the throttle butterflies.)
7. Engine Coolant Temp
8. Intake coolant temp
9. Front & Rear Wheel Speed
10. A signal I’m calling “no drive” or “free wheel”, it indicates when in neutral OR clutch pulled in.
11. “Some kind of counter that counts up when the engine is not at idle, it’s rate also varies, not sure what this is, higher rpm = faster rate of increase.”

There is still more there, but this is what I’ve reverse engineered so far, the rest of the data is “nearly static”

Rob