Forum » CANBus Communications Decoded » Workd Example reverse engineering steering angle

Workd Example reverse engineering steering angle

CANBus Communications Decoded

Forum Posts

Courses

Blog

Tech Articles

Discussion and questions related to the course CAN Bus Communications Decoded

= Resolved threads

Page 1
Author
131 Views

Your worked example reverse engineering the steering angle signal looks a lot like garbage in / garbage out given the crude way you estimate the steering wheel angle. Good calibration data is needed to have confidence in the scaling factor. In this case, a scaling factor of 10 is extremely unlikely. A rotary encoder will have a binary number of steps in it, and the closest match to your data is 2^12 = 4096 steps. This will lead to a scaling factor of 11.377 via a bit of math.

It implies your test angles were 0, 39.0 cw, 80.2 cw, 52.5 ccw, 82.6 ccw. Given the uncertainty inherent in your calibration data, my numbers are just as likely true, and the logic I have applied would have me hanging my hat on my scaling factor, not yours.

I've looked at a lot of can data and it's more typical to have a base-10 scaling factor. YMMV.

My luck to be teething on a BMW, David.

https://github.com/commaai/opendbc

A quick scan of a few vehicles noted in this link shows you are right about the prevalence of base-10 scaling. Specifically, the Toyotas on the list are base-10, so it is fair to expect the 86 in the example is too.

That said, the "calibration" data used in the worked example was not accurate enough to differentiate between base-10 and hex.

I havent watched the video that you are talking about, but steering angle is always one of the easier ones to scale accurately. Line up something on the steering wheel such as a spoke/stitch/seam/piece of tape with something in the background such as the indicator stalk, then turn steering wheel 360 deg until the marks line up again, note down change in data.

Steering angle ROC on the other hand is often more tricky to figure out...

G'day James. It's a good point you raise, and perhaps it would have been better in this instance to have a scan tool outputting the ODB2 requested data at the same time for clarity / wheel angle aim. The CAN output data is unlikely to be the number of binary encoder steps however, as this will have been read and interpreted before being pushed out over the bus. The raw number of encoder steps would be a step too raw... The proof is in the pudding however, and in this application we're getting valid data that matches up to the real world, so I'm confident it is correct, cheers :-).