AnthonyHardy2
4-door Apologist
- Joined
- Aug 31, 2010
- Location
- Oakland, CA
https://github.com/michaelabuchanan/volvo_ps_controller
It seems like the hard part of figuring out the CAN messages has been done already and is publicly available.
-
Hello Guest, welcome to the initial stages of our new platform!
You can find some additional information about where we are in the process of migrating the board and setting up our new software hereThank you for being a part of our community!
Volvo Electric Power Steering (C30 S40 V50 V60 S60 V70) on a 240 | + Power Steering Bypass/Delete Idler Pulley | Installation & Review
- Thread starter Sharpie_Eastern
- Start date
It seems like the hard part of figuring out the CAN messages has been done already and is publicly available.
nalletill1000
Member
- Joined
- Apr 25, 2008
- Location
- On the bayou
Found them, but verify the keying is correct, although it looks to me. $8.40 rn.
It seems like they are made by Volvo so definitely not something that Mouser or Digikey will sell.
It seems like they are made by Volvo so definitely not something that Mouser or Digikey will sell.
- Joined
- Jul 30, 2002
- Location
- Rockville, MD
Volvo doesnt make any of those types of things. They would always source them from a large tier 1 automotive supplier like Aptiv
nalletill1000
Member
- Joined
- Apr 25, 2008
- Location
- On the bayou
No you are right. No need to invent the wheel again but AI lured me into that thinking. A bit more digging and I found they are Yazaki brand.
Part numbers should be
7283-3214-30
7283-8977-30
Can be bought on Mouser if I am correct
Found them on Aliexpress as well and to better price with connectors and seals.
Part numbers should be
7283-3214-30
7283-8977-30
Can be bought on Mouser if I am correct
Found them on Aliexpress as well and to better price with connectors and seals.
Khrrck
Professional Amateur
- Joined
- Mar 11, 2015
- Location
- Beaverton, OR
Just be careful the AliExpress versions are often clones rather than OEM.
Sometimes very good clones, but...
Meatball
Well-known member
- Joined
- Jul 30, 2004
- Location
- Living in my 245
That CAN ID is likely one of many based on different EPS pump part #s. I think that this is an obstacle that I can assist with if so. I'll have to collect more data though to be sure and that takes time.
Edit://
If you can give me a concise list of the vehicles with the most desirable pump, I will investigate and see how many variations (if any) there are between the vehicles with that pump installed. I am certain that gen1 and gen2 pumps will be acting on different IDs.
Last edited:
Meatball
Well-known member
- Joined
- Jul 30, 2004
- Location
- Living in my 245
I think it is a wise thing to be cautious on the AliExpress parts.
What I would really advise you against is buying the terminals and the wire from there.
FWIW, I bought Deutsch connectors off of Amazon based on the photos showing Deutsch being molded into the cavity. They're either legit or EXTREMELY good clones. Because they're virtually indistinguishable from the legit Deutsch bought from Imperial. Heavy duty pins too.
I've found that a lot of OEM modules from teir 1 suppliers use the same CAN messaging protocols across the line, especially if they are from a Japanese supplier.
Meatball
Well-known member
- Joined
- Jul 30, 2004
- Location
- Living in my 245
I can absolutely guarantee you that this is not true across the board:
That's two *identical* Denso ECMs.
- Same part numbers.
- Serial numbers indicate same year,
- Completely different EEPROM flash.
---
That's all I'm going to say about that. Y'all DM me if I can be of use. I currently stay knee deep in a sea of old Volvos M-F 0730-1700. So, I don't really want to do it... But I will for the fam
Last edited:
ABS, steering pumps, EPAS columns, etc are often the same. Denso doesn't make specific comms protocol changes, but they will change the control loop gains and stability model inside the ABS pump controller. Communication is the same, outputs are different.
ECM is going to be vehicle specific for sure due to vehicle spec modules changing, which is why most ECMs require a calibration (really familiarization with the system) before a vehicle can run.
A lot happens in SW development in 3 months, it's always fun when you get "the same" module and it behaves differently due to a few new lines that were added in. Usually the supplier just tells you that you weren't using it correctly to begin with. Not all work arounds are good work arounds
Edit:
Then there are hardware addressable CAN devices. These change their node IDs based on how they are wired. Usually there's 3-4 pins on the connector that can be used to change the ID of the device, and these are supplied voltage through the chassis harness. Which is awesome so you have one PN for 4+ different CAN devices that perform completely different tasks.
Meatball
Well-known member
- Joined
- Jul 30, 2004
- Location
- Living in my 245
ABS, steering pumps, EPAS columns, etc are often the same. Denso doesn't make specific comms protocol changes, but they will change the control loop gains and stability model inside the ABS pump controller. Communication is the same, outputs are different.
ECM is going to be vehicle specific for sure due to vehicle spec modules changing, which is why most ECMs require a calibration (really familiarization with the system) before a vehicle can run.
A lot happens in SW development in 3 months, it's always fun when you get "the same" module and it behaves differently due to a few new lines that were added in. Usually the supplier just tells you that you weren't using it correctly to begin with. Not all work arounds are good work arounds
I too am aware of the difference between eeprom and calibration bins. I know how to use Ghidra and WinOLS.
Those two ECMs have different eeproms *and* calibration data. Both ECMs were pulled from working vehicles and read with a legit Alienware Kess3.
They absolutely DO NOT share the same CAN architecture.
The same goes for the TCM and the BCM (ABS pump controller). Nearly identical hardware responding to completely different messages.
Edit:// I'm not talking about the structure of the frame data or even the way that the signal is packed.
I'm talking about 0x020 vs 0x0080401E being the frame ID (for example - the frame carrying the engine speed signal broadcast by the ECM)
Last edited:
Maybe?
0x020 isn't a valid j1939 or NMEA or ISO CAN frame ID. 0x0080401E is though.
0x020 is most likely the parameter value being sent along from device 0x0080401E (Hybrid System Control 1).
J1939 Explained - A Simple Intro [2026]
What is J1939? What is a PGN and an SPN? How do you log heavy-duty vehicle data? And how do you decode the J1939 protocol? Check out our simple intro!
www.csselectronics.com
J1939 PGN vs. 29-Bit CAN ID - Online Converter [+ PGN List]
Need to convert a 29-bit CAN ID to a J1939 PGN (Parameter Group Number)? Or view the full J1939 PGN list? Then check out our online J1939 PGN converter tool!
www.csselectronics.com
I'd double check that you are reading and sending messages correctly on the bus. Either I'm not understanding what you're saying (very possible) or you're mixing up device ID and parameter values.
The 2nd link above is really helpful with braking down standard CAN IDs into the specific devices.
Meatball
Well-known member
- Joined
- Jul 30, 2004
- Location
- Living in my 245
Brother, I'm going to let you believe what you want to believe.Maybe?
0x020 isn't a valid j1939 or NMEA or ISO CAN frame ID. 0x0080401E is though.
0x020 is most likely the parameter value being sent along from device 0x0080401E (Hybrid System Control 1).
J1939 Explained - A Simple Intro [2026]
What is J1939? What is a PGN and an SPN? How do you log heavy-duty vehicle data? And how do you decode the J1939 protocol? Check out our simple intro!J1939 PGN vs. 29-Bit CAN ID - Online Converter [+ PGN List]
Need to convert a 29-bit CAN ID to a J1939 PGN (Parameter Group Number)? Or view the full J1939 PGN list? Then check out our online J1939 PGN converter tool!
I'd double check that you are reading and sending messages correctly on the bus. Either I'm not understanding what you're saying (very possible) or you're mixing up device ID and parameter values.
The 2nd link above is really helpful with braking down standard CAN IDs into the specific devices.
I have spent my last year being trained by industry leaders to understand this topic.
Meatball
Well-known member
- Joined
- Jul 30, 2004
- Location
- Living in my 245
Also, I promise that this is my last post in this thread for today but I feel the need to share the fact that I am using industry standard hardware to do my captures with as well.
I don't send ANY data when I do a broadcast data capture. I listen in passive mode. Whichever modules are communicating on the network are the modules that I get data from.
This is the device that I use:
I initially used their software to do the capture with as well but found that SavvyCan is a suitable replacement that allows me to identify signals and use the Kvaser database editor to build a DBC file for the vehicle.
Once I've done that, the unknown signals start to dwindle. Figuring out multiplex signals is the hardest. Those are used on the DIM for example to display messages. The VIN is also broadcast like that.
Key status is like that but not an actual multiplex. The binary value is incremented.
Something like (and I'm totally pulling this out of my ass but the XC90 does something similar...)
KP1 = 010001
KP2 = 010010
KP3 = 010011
KP3 (momentary) = 010111
KP3 (latched - running, authorized) = 111111
Again, I contrived this example because it's easy to see the pattern.
It's not like that in real life.
Finally, I'm going to address this:
0x0080401E only appears on the network when the P2 XC90 ECM is plugged in.
You can even bench power the ECM and verify this. It only runs for about 5 seconds and then shuts down. No authorization. No network response.
---
Edit:// in the link that I shared to OT that has my videos and GitHub, I AM using a scan tool WHILE doing a broadcast capture. The good thing about the hardware that I use, is that it ignores UDS (OBD2 PID) traffic unless it's in "promiscuous mode" (PEAK calls it something else). That mode is set to off by default. That's because hardly anyone needs to validate/troubleshoot/duplicate that traffic because it is a matter of public record:
en.wikipedia.org
Edit2:// you are correct about 0x020. It is 0x12A vs 0x0080401E. It also only appears when the P3 S60 ECM is plugged in.
If you watch the video in the OT thread, I am actually using the capture that I am vaguely referencing (containing 0x12A). It is a P3 car with the identical ECM part number from above. It is however, sending the 11 bit identifiers on the frames instead of 29 bit like the P2 XC90.
Have a good day sir.
I don't send ANY data when I do a broadcast data capture. I listen in passive mode. Whichever modules are communicating on the network are the modules that I get data from.
This is the device that I use:
I initially used their software to do the capture with as well but found that SavvyCan is a suitable replacement that allows me to identify signals and use the Kvaser database editor to build a DBC file for the vehicle.
Once I've done that, the unknown signals start to dwindle. Figuring out multiplex signals is the hardest. Those are used on the DIM for example to display messages. The VIN is also broadcast like that.
Key status is like that but not an actual multiplex. The binary value is incremented.
Something like (and I'm totally pulling this out of my ass but the XC90 does something similar...)
KP1 = 010001
KP2 = 010010
KP3 = 010011
KP3 (momentary) = 010111
KP3 (latched - running, authorized) = 111111
Again, I contrived this example because it's easy to see the pattern.
It's not like that in real life.
Finally, I'm going to address this:
0x0080401E only appears on the network when the P2 XC90 ECM is plugged in.
You can even bench power the ECM and verify this. It only runs for about 5 seconds and then shuts down. No authorization. No network response.
---
Edit:// in the link that I shared to OT that has my videos and GitHub, I AM using a scan tool WHILE doing a broadcast capture. The good thing about the hardware that I use, is that it ignores UDS (OBD2 PID) traffic unless it's in "promiscuous mode" (PEAK calls it something else). That mode is set to off by default. That's because hardly anyone needs to validate/troubleshoot/duplicate that traffic because it is a matter of public record:
OBD-II PIDs - Wikipedia
Edit2:// you are correct about 0x020. It is 0x12A vs 0x0080401E. It also only appears when the P3 S60 ECM is plugged in.
If you watch the video in the OT thread, I am actually using the capture that I am vaguely referencing (containing 0x12A). It is a P3 car with the identical ECM part number from above. It is however, sending the 11 bit identifiers on the frames instead of 29 bit like the P2 XC90.
Have a good day sir.
Last edited:
That's great, I'm glad you pursued this and learned a bunch. I've been working with vehicle CANbus systems since ~2010 on the hw design and comms side.
Anytime there is a handshake requirement that's embedded in firmware it's a huge PITA to figure that out, and those will all be device/module specific. Vehicle security is a big reason for these.
I'll have to look into your dev tool, looks interesting.
- Joined
- Jul 30, 2002
- Location
- Rockville, MD
looks we got ourselves a good old fashion TB nerdfest in here.
Do you even speak hex bro?
I just had to do a deep dive on 100base-t1 automotive Ethernet for work. It’s like CAN since it’s just two wires, but a much bigger pain in the ass in regard to decoding and device management. It is about 100x faster data transmission rate though, so that’s nice I guess.
Khrrck
Professional Amateur
- Joined
- Mar 11, 2015
- Location
- Beaverton, OR
And let me guess, just different enough from regular Ethernet to need its own unique set of capture tools?
Yes, and translation modules if you want to use it on a network with regular Ethernet devices.
Look into it, it’s wild. 1 gig speed with a single twisted pair.