Steering Angle Sensor Data - GM HS CAN

Hi Scott, the SAS talks on CAN bus using ID 0x1E5. I have found mentions of this ID on the internet when people tried to communicate with such sensors directly, so I am reasonably sure that these messages are not relayed. Bytes 2 and 3 are used to create a signed integer in range …, mapped to (approximately) … degrees. diag​.​net/file/f4kf4edzf… ​ This graph…

Hi Dimitry, thanks for looking into this. Attached is a 5 second data recording from PICO of CAN Hi only at 10MS/s. Can you explain to me is laymen's terms how you were able to arrive at which bytes were used and how? I exported the filtered data for 1 E5 from Pico for this broken vehicle which is a 2014 Corvette that has a U0428 stored in the PSCM and have attached that CSV. I'd love to learn…

This is a fantastic dataset, Scott! The SAS still transmits values on 0x1E5, but they look off (uncalibrated?), and the first byte is 0x1C instead of 0x4F – probably this is a status byte that indicates the data are not good. It would be insightful to see how this byte changes once the car is fixed. The PSCM seems to use 0x130 to transmit its data. Bytes 4,5, and (mostly) 6 are zero for the…

Wow, thank you Dmitriy. Tomorrow I should have the new part and I plan on acquiring the data and will of course upload it here. Lots to learn here on this application. I grabbed your reference tool and opened it up in Pico and created a screenshot. Once I get this vehicle fixed and we wade through the new data, I'll consolidate the info for the Corvette and add a new resource tied to the…

Here is a pico data sample with the new sensor installed diag​.​net/file/f6qgmvs96… ​

Is it calibrated and no more U codes? The first byte in 0x1e5 messages changed to 0x5c (was 0x1c). Compare binary codes: >>> format(0x1c, '08b') '…' >>> format(0x5c, '08b') '…' The values derived from bytes 2 and 3 are in the attached file. As for message ID 0x130, I was wrong – bytes 4 and 5 are still zeros, so not sure what they mean. They were changing for…

Yes Dmitriy, it's calibrated and no more U codes. Here is the GDS data recording I'm pretty sure I collected at the same time I captured the Pico data. Here's a screenshot of that activity as well. And again, thank you for dissecting this data, here's a screenshot of the Pico data collected along with your reference data

Scott, sorry I could not check the GDS file right away, but now I took a look and something is not right – the stop positions are shown as ‘not learned’ and steering angle values jump all over the place. Could you review this file and see if you have another GDS file for the new SAS data?

Hi Dmitriy, I apologize for the delay, I saw your message last week and have been buried… I’ll look and see where I may have screwed up with the GDS data sample. In the meantime, I’ve been reading up on various CAN tools and started playing with SAVVYcan. The tool is a little finicky and when I try using the MDI2, it sets a bunch of codes. However, I was able to obtain a number of .dbc files…

Hi Scott, these tools are quite handy when dbc files are available, but for reverse engineering I prefer to fetch the raw data and process it in Python or MATLAB/Octave. One thing that I like about the scope – it is already connected when the diagnostics happens. Picoscope is capable of capturing 5-10 seconds of data, which is a perfect amount for an experiment such as you carried out with…

Here is the recording I made right after sensor replacement and performing the reset and zero operations. The soft-stop relearn process had not yet been performed when I recorded this data. I looked at the csv file and it looks like the data isn't reflecting what I se on the graph playback. I just generated these files this morning.

OK, so this is how unlearned SAS looks like on the scantool… This is the same export scan data you have attached before here: diag​.​net/file/f3emuwcjb… ls *.csv 'GDS-PSCM-SAS-New-Softstops not relearned​.​csv 'CAN-H New SAS​.​csv diff -s 'CAN-H New SAS​.​csv 'GDS-PSCM-SAS-New-Softstops not relearned​.​csv Files CAN-H New…

Yes, that is the same file. GDS isn't exporting the data correctly. I just performed another export and can see the same bogus data unfortunately.

Actually… it turns out it is the right file, but it looks confusing unless zoomed in into the right region, which is 170-180 seconds. Sorry about not realizing that sooner. So, I decided to check if the Picoscope data is for the Unlearned New SAS as well. Put that in my script, and lo and behold: diag​.​net/file/f321as7je… ​ Black “x” markers are GDS data points, blue trace comes directly…

Ok great, glad to hear this. I was getting ready to doubt my sanity for a moment! Thank you so much for the following things I learned here (I think, please correct me where I'm wrong): - Message ID 1E5 comes from the SAS and is also known as the arbitration ID and also contains the payload info? - The first byte likely is being used as a SOH data point letting everyone know that its data…

Pretty much agree on all points. I take it we can expect an epic presentation on the topic in the near future?

Yes, first I’m finishing up an article for PTEN on network diagnostics. I’ve been working on this for a little while now and it’s not due to be published until Mar-Apr. The Corvette challenge introduced itself perfectly for this article. I really wish I was recording the CANBUS when the Scantool issued its reset/relearn instructions to see what the hell happened to the SAS. Not sure if the…

I'm glad I could be helpful, so no problem mentioning me. I will send you a brief prof. bio by e-mail, in case you need it. Can only guess about the sensor failure… may be it could not write into its EEPROM, or some sanity check failed even though most of the time the values make sense. Unfortunately, we could not find the datasheet for it to see the exact meaning of the first byte…

Here are some images from the old sensor.

Here's a link to the datasheet for the R5F2134CWJFP micro: Here is the data sheet for the 363ABB Magnetometer Chips:

That's insightful info, Scott. The microcontroller is the version of R5F2134 with CAN interface, polling two Magnetometer chips over SPI. Redundancy is expected for this safety-critical component. There should also be a CAN transceiver somewhere on the board, do you happen to know which one it is? The micro can be programmed any way the manufacturer wants it, so the datasheet does not really…

Here's a close up of the CAN Chip

This is a TVS (transient voltage suppressor) diode array, though. The space right above it is for the optional termination resistors. The 8-pin chip below the TVS looks like a voltage regulator; can not read markings on the 8-pin chip above. diag​.​net/file/f1vcwjc0q… ​

Ah I see, I should have known there was more to this. I checked pin connections and found the 8-pin device that is the CAN chip. I also marked up the chip label as well. nxp​.​com/docs/en/data-s…​.​pdf

If someone decides to run an intermediate CAN bus class, building a prop out of an Arduino, a CAN bus shield, and a Magnetometer demo board that sends messages that can be correctly interpreted by SavvyCAN, would be a lot of fun. This is something I would be very much interested in!

I believe you are looking for the Macchina M2. It has 2 HS CAN & 1 GMLAN bus, an Arduino Due, able to Rx/Tx, and interfaces with SavvyCAN well. Firmware is available specifically for the M2 to play nice with SC.

One more question about the can messages: I sampled CAN Data from a 2013 Cruze and I see that the 1st byte for 1E5 = 44. This screenshot shows the interpreted data after loading the DBC file in SavvyCan. The DBC editor shows that there are two signals in 1E5 - Steering angle and Steering rate of change. Since I'm not fluent in reading binary data, can you help me understand the bit table shown…

Human-readable binary numbers are written with most significant bit first. For example, Binary 1000 is 1 * 2^3 + 0 * 2^2 + 0 * 2^1 + 0 * 2^0 = 8 (this corresponds to DLC field in your previous message) So the bits of the first byte (byte 0) are numbered 7, …, 0. For further bytes, such reverse order continues and is referred to as sawtooth manner in the DBC file documentation. I agree that the…

Excellent info, I just learned something new! I will probably experiment and check the LSB box and see what happens. Thanks again, this has been an incredible learning experience for me.

Scott and Dimitry, I've been learning a TON following this thread. Cool stuff! I wanted to ask what interface you've been using to get your SavvyCAN data. I've tried a J2534 box and a GM MDI, can't seem to make SavvyCAN happy. Can I get a J-box to work? Or do I need to buy a separate interface?

Hi Tyler, I have been able to get the MDI-2 to work on a couple of 2013 GM vehicles but found that its buggy and will often time cause trouble on the bus and set tons of codes. I have been looking at other tools on the market and might be picking up this device: cancapture​.​com/cancapture for research.

If I wanted to look at intelligent battery sensor lin data using pico via decode what resource out there could allow me to do this ?? IN OTHER WORDS TELL ME THE ACTUAL BATTERY CURRENT TO MONITOR OVERNIGHT .

Hi Justin, I suspect that you would need a library to figure out how the message you seek is interpreted. However, you may be able to watch the PICO decode data and say a carbon pile to monitor and record the data while moving amperage up and down. You then might have some data that could be useful to you. Here are a few GitHub links that might help (or not) but be warned, this could be a…

Hi Dmitriy, It's truly remarkable to witness the ability to import our own custom psreference. file. I would greatly appreciate it if you could teach me more about this cutting-ed… technique. Thank you in advance!

THIS MAKES MY HEAD SPIN"! Very interesting, keep it up.

Hi Scott, i follow the steps, why the ima… created by ID 0XIE5 Bytes 2 and 3 like this.

Finally, I made it, it really interesting, thanks.

Good job!