electric power steering mini cooper (R56) [SOLVED]

[alehandro]

Hello everybody! I got to use the electric power steering mini Cooper p56, for conversion to the evi project. I was able to receive survey messages with the help of kanhacker arduino. But there is no further launch progress, now I need the ID of the launch byte on the can bus so that I can send it to the ECU. Can someone scan data from the can bus in their mini cooper?

[MattsAwesomeStuff]

You're probably better off contacting nerds from some Mini forum, than hoping someone here happens to own a mini.

[tom91]

Required Messages
0x130 - Terminal status
0x1A0 - Vehicle speed - Impact on assistance
0x1D0 - Engine Run

[MattsAwesomeStuff]

Or you can win a lottery and have Tom get you the answer right away. :p

Well done Tom.

[tom91]

Or you can win a lottery and have Tom get you the answer right away. :p

Well done Tom.

Im working on a R56, similiar to BMW stuff so logged a working car then disconnected the engine and turned messages on one by one.

Also tested it on the bench.

[alehandro]

Required Messages
0x130 - Terminal status
0x1A0 - Vehicle speed - Impact on assistance
0x1D0 - Engine Run

Thank you, Tom91. Your information helped me a lot, now I can get help from the electric amplifier

[mane2]

Heya! I'm experimenting with this Mini R56 steering unit. Here's some more info that wasn't previously posted here:

Yellow cable is ignition.
Yellow/black is can high.
Yellow/brown is can low.
Can speed is 500kbs.

To have it working, send these:

every 100ms : id: 0x130 data: 0x45 0x41 0x21 0x8F 0x24
every 50ms : id: 0x1A0 data: 0x00 0x80 0x00 0x00 0x80 0x00 0x78 0x1B
every 50ms : id: 0x1D0 data: 0x61 0xFF 0x6E 0xD2 0x24 0x78 0xCC 0xA4

Vechicle speed is 0x1A0 like Tom said. Googling for specs, some say it's first 12 bits for speed (using 10 multiplier), but looking at Toms capture data, it does not match. Seems like first byte is speed related as goes from 0 to about 120 - though it looks like the car did not do 120km/h in that short time. So not sure what the scalar is here. Second byte seems to be 0x80 when standstill and 0xB0 when moving.

Anyway, changing the first byte from 0 to 255, does not seem to affect the effort required to turn the "wheel". I guess this is down to checksum in the end of can message. ECU probably reads the message that I send via Arduino, but drops it as checksum does not match.

I found Toms code where checksum calculation is done for BMW i3 BMS, which probably isn't far from Mini stuff. Here https://github.com/Tom-evnut/BMWI3BMS/b ... .ino#L3680 but using the same crc calculation, with whatever final xor value (I tried everything between 0-255), I could not find a common pattern for this checksum. (I took that can message, eg 6F B0 E9 0F 80 00 A8 E3 where the E3 is the checksum. Removed that, and added can id to beginning. Like so 1A 00 6F B0 E9 0F 80 00 A8. Then used that custom J1850 CRC8 with different final xor values)

Any ideas how to calculate that checksum for 0x1A0 can message? I did not measure the resistance with any device, just by turning the axle by hand. Even if the speed was 255, I could still turn the axle with my hand .. and did not feel big difference between 0kmh or 255kmh. I think it should be pretty stiff on higher speeds.

[mane2]

Actually, I think it works without checksum after all. I did another test, by sending just

Code: Select all

static uint8_t speedData[1] = {0xff};

.. I could barely turn it by hand..

then doing another test with just this

Code: Select all

static uint8_t speedData[1] = {0x00};

.. it was lighter. Maybe the difference is more clearer when turning the actual wheel.

I would just love to crack that checksum thing before doing new brackets for this EPAS and going through all that hassle. Would be annoying to realize that I can't make it adjust by speed.

[tom91]

Just play back a log of a BMW E series or Mini running

Playing back my log works. Also attached my modified BMW DBC with my R56 findings

[mane2]

It’s assisting alright, but my point was just to figure out how the checksum is calculated, as I’m sending current speed to it. But I think it’s not needed, ecu does not care about the checksum.

Thanks for the dbc file. Need to check it out. Does it have checksum calculation explained?

[mane2]

Oh, very nice that DBC file, so much data to use with the log!

I guess I just need to do some brute force calculation to find that checksum. Trying all different combinations of data and can id, with all possible CRC checks and see what matches

[mane2]

After hours of trying different checksum calculation methods, with varying parameters none of them worked. Then Googling for some more checksum calculations, I found one checksum solution hidden in bimmerforums. Formula was:

(<sum of bytes 1 - 7> - (0xFF - <can message id>) ) % 0xFF

I tried this and accidentally typed wrong can message id 0xA1 when I should have typed 0x1A - but it worked! Also with other test data I have. I realised my error when looking at the code, tested with correct can-id but that didn't work. Was this just a lucky strike or some math weirdness that I don't understand. Asking that from AI, it didn't give any reasonable maths explanation either. Maybe someone can. I'm puzzled

[mane2]

Now when playing with that, it can be simplified to just summing up the 7 bytes and subtracting 604 from that. It will give you correct checksum. Like this

Code: Select all

uint8_t calculate_checksum(const uint8_t data[7], uint8_t can_msg_id) {
    uint16_t sum = 0;

    // Sum the first 7 bytes of data
    for (int i = 0; i < 7; i++) {
        sum += data[i];
    }
    return sum-604;
}

Now, let's see does it make any difference on the ecu

[tom91]

What are you measuring or trying to do? You seem to just be spamming in the thread with any real purpose.

Which data did you use to come to this conclusion, if you take a zero speed example from the log I shared this does not work.

[mane2]

What are you trying to do? Telling people what to post or not? Tell that what they do, is not worth it? Blaming for spamming?

I feel forums are the place to openly write your findings, that might help other people. I explained above what I'm trying to do - to find how checksum is calculated for speed message, because I felt that the speed message I sent, didn't have effect.

Related to that function, you're right. Simplifying that does not seem work on all cases. I had 5 test datas, and it worked with those.

Code: Select all

uint8_t calculate_checksum(const uint8_t data[7], uint8_t can_msg_id) {
    uint16_t sum = 0;

    // Sum the first 7 bytes of data
    for (int i = 0; i < 7; i++) {
        sum += data[i];
    }

    // Calculate the checksum
    uint8_t checksum = (sum - (0xFF - 0xA1)) % 0xFF;
    return checksum;
}

This function works with the first row of the log too. Haven't done a script that goes through the whole log data though.

[tom91]

Are you trying to use the steering rack on another vehicle? This would be the only reason to try and reverse engineer the checksum.

The DSC that sends the message is the ABS module and any E-series BMW sends the same message with same content.

[tom91]

If you are so set on solving this, have a look here for a usefull tool others have used in the past.

https://github.com/colinoflynn/crcbeagle

[mane2]

Yes, I'm planning to use it on my non-Mini car. Currently I have Citroen C2 EPS in my bmw that I got working with can, with speed data sent to it. Mini R56 rack is narrow enough to fit that 70s car. My problem with Citroen rack is, that it won't return to center properly. (Everything is checked, alignment, caster, camber, toe in, etc.. just won't return to center properly for some weird reason). Hoping this R56 rack fixes that.

I got the checksum code to my Arduino sketch and tested that rack on a bench. I added the counter can message too. I was able to spot the difference when I set speed to 250km/h and 0km/h now. But, when removing that checksum and counter, it still worked I think I might have had some error in my 12-bit speed calculation previously. That's why I started looking into checksum calculation.

Oh well, at least I can sleep well now, knowing that if I need that checksum for something later, I can calculate it

While testing, I noticed that if ECU misses can data for some seconds, it goes to safe/limp-mode. My lab power source shows it's pulling 0,35 amps how ever I turn the axle in that mode, not more or less. When can messages are being sent when it turns on, it exits limp mode, and can pull 0,6 amps when quickly turning the axle with 0km/h speed. Also interesting was, that when I set speed to 250km/h, and try to turn it, it actually resists. Power source shows lower amps than idle, almost like it's regening a bit.

Anyway, long story short. No need to worry about checksum, it's not in limp mode, even if it's not calculated per message. ECU does not seem to check and drop messages if it won't match. It's probably some other ECUs in Mini that do check it.

One thing I'm still wondering. Does that ECU use those that yaw data from 0x1A message. I think it's steering angle sensor data. It could make sense that motor assists wheels to return to center, if it notices that steering angle is not straight, and you don't pull the wheel to any direction and you are moving.. Would be interesting to hear experiences from people who are using this in ev-conversion cars. Especially how return-to-center works.

[jrbe]

My problem with Citroen rack is, that it won't return to center properly. (Everything is checked, alignment, caster, camber, toe in, etc.. just won't return to center properly for some weird reason). Hoping this R56 rack fixes that.

Caster trail is what really accomplishes steering centering.

Most vehicles have the ball joints / struts / pivots in line with the wheel center so it's easy enough to just look at caster.

Is the strut / balljoints in line with the wheel bearing center? Does it have at least a few degrees of caster?

Also look at ball joints. When they get dry and crusty they can start to stick.

Could also be the rack is bound up or the assist is doing odd things.

[mane2]

It has standard caster angle & trail, and on standard steering-box cars it returns to center very well. There is +8,14 degrees of caster, so that should not be the problem (ideal is 3-5). It's been aligned and adjusted many times, trying to find what's wrong. Not binding, struct bearings checked (all new). I'm going to install front sway bar back - it was removed when we thought the battery box wouldn't fit with that. Need to do another round of check if it's binding. If those don't not help, I'm going to switch to this Mini R56 rack and hope for the best. (That it was assist related)

But yeah, that's another topic. Let's keep this thread Mini Cooper R56 EPS related.