Not quite sure why you can't see the commands? hardware maybe?
Below isa snippet of an onstar unlock.
[00:00:20.4788681] : 00000100 // Wakeup
[00:00:20.4830955] : 00000100 // Wakeup
[00:00:20.4996561] : 0000062D0140000000000000 // Onstar???
[00:00:20.5025471] : 1028409700 // onstar to BCM??
[00:00:20.5044733] : 13FFE066
[00:00:20.5074669] : 0C6080AF00
[00:00:20.5110880] : 0C7920AFFC10FCF400
[00:00:20.5145411] : 0C2F604000
[00:00:20.5182154] : 102A8097000020204040 // onstar to radio?
[00:00:20.5194145] : 102680AF04
[00:00:20.5216819] : 0C2F804000
[00:00:20.5262542] : 1043A04000806D0000000000
[00:00:20.5283640] : 0C2FA04000
[00:00:20.5321906] : 1043C0A41000000000
[00:00:20.5396583] : 102AA0974000000080000000 // Onstar to drivers door??
[00:00:20.5445312] : 0C39004000
[00:00:20.5450537] : 105A00A400000002
[00:00:20.5456373] : 0C6AA0A400
[00:00:20.5505090] : 102AC09700000000000186A0 // onstar to theft module?
[00:00:20.5521048] : 0C3940400020FFFF00
[00:00:20.5558215] : 0C6B40A400
[00:00:20.5581513] : 0C63004000
[00:00:20.5617119] : 106CE0993C000000
[00:00:20.5645132] : 1043409700000000 // onstar to bcm?
[00:00:20.5667018] : 0C71404007
[00:00:20.5692806] : 1038009900
[00:00:20.5737299] : 10440099080000008A8041
[00:00:20.5778794] : 0C8000400095C0C00000
[00:00:20.5791494] : 10624099000000
[00:00:20.5828841] : 106D4099100046
[00:00:20.5876080] : 1020C0400000000801
[00:00:20.5886647] : 1024406000
[00:00:20.5942621] : 102100400000000000008000
[00:00:20.5977782] : 10734099100000910000
[00:00:20.5996129] : 102C60600008840038F3
[00:00:20.6037237] : 10754040000000
[00:00:20.6048982] : 1024204000
[00:00:20.6096115] : 104300970000000000000000
[00:00:20.6134580] : 103BC06000
[00:00:20.6147978] : 1081409900002300
[00:00:20.6175561] : 102500400001
[00:00:20.6217765] : 103D606000000000000000
[00:00:20.6242697] : 13FFE040
[00:00:20.6267934] : 103DA06000
[00:00:20.6308365] : 102540400000000002000070
[00:00:20.6336238] : 1024E0970003FF // Onstar to EO???
[00:00:20.6366976] : 10260040000001
[00:00:20.6420294] : 10288040000000
[00:00:20.6457246] : 1044806000000000
[00:00:20.6462113] : 106E00970000 // Onstar to EO???
[00:00:20.6481924] : 1045C06040
[00:00:20.6527509] : 102100400000000000008000
[00:00:20.6562851] : 1070409702000000 // Onstar to BCM?
[00:00:20.6606288] : 103200580000000000000000
[00:00:20.6644037] : 10324058000004D40000
[00:00:20.6687364] : 10220040100020000FFF0000
[00:00:20.6725346] : 10330058737300000000
[00:00:20.6749632] : 1077406000
[00:00:20.6789739] : 1022A04000F0000000540C00
Enabling mixed frame and or extended Low Speed CAN single wire frames like those posted on GMLAN bible
-
ironduke
- Posts: 820
- Joined: Thu Feb 13, 2020 1:32 pm
- cars: Mainly GM trucks, a Cruze and an Equinox for dailys..
-
Gatecrasher
- Posts: 435
- Joined: Fri Apr 24, 2020 8:09 pm
Re: Enabling mixed frame and or extended Low Speed CAN single wire frames like those posted on GMLAN bible
I'm not sure where you're getting that "Onstar to xx" stuff. That's not how it works. CAN modules broadcast a message to everyone on the bus and it's up to the receivers to decide to do something with it. 102AA097 is a GPS position message for example. If the BCM sends out an ignition status message for example, that's going to be picked up and used by multiple modules.
The frame header breaks down like this:
The first 3 bits are the message priority.
Next 13 bits are the message ID.
Final 13 bits are the source module ID.
The frame header breaks down like this:
Code: Select all
Hexadecimal: 0x10 0x0D 0x00 0x60
Binary: 00010000 00001101 00000000 01100000
Priority: ---
Arbitration: -- -------- ---
Sending ECU: ----- --------
Next 13 bits are the message ID.
Final 13 bits are the source module ID.
-
ironduke
- Posts: 820
- Joined: Thu Feb 13, 2020 1:32 pm
- cars: Mainly GM trucks, a Cruze and an Equinox for dailys..
Re: Enabling mixed frame and or extended Low Speed CAN single wire frames like those posted on GMLAN bible
I don't do a lot of 29 bit stuff but did a little bit of research and it totally depends on a few bits as to if it's a global broadcast or for a specific module. I could have it wrong or off a bit but don't think I'm off that far..
As by your pic the sending ecu ID is where I was getting that it was from onstar. I could be wrong but the low speed was dead quiet until I hit the fob and that was the first bit of activity.
I even wrote some code to help me with it. I was following J1939 29-bit ID format, or at least I was trying to.
In any case I was able to see those messages with a clone mdi on low speed lan using my logging program. OP isn't seeing the messages and I'm not sure why.
Thought I'd ask chatgpt since I don't have notes from home.
The J1939 29-bit Identifier Layout
| Priority (3) | Reserved (1) | Data Page (1) | PDU Format (8) | PDU Specific (8) | Source Address (8) |
bits 28..26 bit 25 bit 24 bits 23..16 bits 15..8 bits 7..0
Priority (3 bits) → arbitration on the CAN bus (0 = highest priority, 7 = lowest).
Reserved (1 bit) → currently unused.
Data Page (1 bit) → extends PGN range.
PDU Format (PF, 8 bits) → determines the type of message.
PDU Specific (PS, 8 bits) → meaning depends on PF.
Source Address (SA, 8 bits) → who sent the message (each ECU has a unique SA).
Broadcast vs Destination-Specific
The difference is based on PDU Format (PF):
PF < 240 (0xF0) → Peer-to-Peer / Destination-Specific
PS = Destination Address (the ECU you are sending to).
Example: PF = 0xEE (238) → Request message.
If PS = 0x01, the request is only for ECU at SA 0x01.
PGN = {DP, PF, 0x00} (PS is NOT part of PGN, because it’s the destination).
PF ≥ 240 (0xF0–0xFF) → Broadcast / Global
PS = Group Extension, not a destination.
All ECUs that care about this PGN listen to it.
Example: PF = 0xFF, PS = 0x50 → PGN 0xFF50.
Everyone listens, regardless of destination.
Example of Destination-Specific Message
CAN ID: 0x18EEFF01
Priority = 6
PF = 0xEE (Request message, < 240 → destination specific)
PS = 0x01 (Destination = ECU at address 0x01)
SA = 0xFF (Sender = ECU 0xFF)
PGN = 0xEE00
This is a Request sent specifically to ECU 0x01.
As by your pic the sending ecu ID is where I was getting that it was from onstar. I could be wrong but the low speed was dead quiet until I hit the fob and that was the first bit of activity.
I even wrote some code to help me with it. I was following J1939 29-bit ID format, or at least I was trying to.
In any case I was able to see those messages with a clone mdi on low speed lan using my logging program. OP isn't seeing the messages and I'm not sure why.
Thought I'd ask chatgpt since I don't have notes from home.
| Priority (3) | Reserved (1) | Data Page (1) | PDU Format (8) | PDU Specific (8) | Source Address (8) |
bits 28..26 bit 25 bit 24 bits 23..16 bits 15..8 bits 7..0
Priority (3 bits) → arbitration on the CAN bus (0 = highest priority, 7 = lowest).
Reserved (1 bit) → currently unused.
Data Page (1 bit) → extends PGN range.
PDU Format (PF, 8 bits) → determines the type of message.
PDU Specific (PS, 8 bits) → meaning depends on PF.
Source Address (SA, 8 bits) → who sent the message (each ECU has a unique SA).
The difference is based on PDU Format (PF):
PF < 240 (0xF0) → Peer-to-Peer / Destination-Specific
PS = Destination Address (the ECU you are sending to).
Example: PF = 0xEE (238) → Request message.
If PS = 0x01, the request is only for ECU at SA 0x01.
PGN = {DP, PF, 0x00} (PS is NOT part of PGN, because it’s the destination).
PF ≥ 240 (0xF0–0xFF) → Broadcast / Global
PS = Group Extension, not a destination.
All ECUs that care about this PGN listen to it.
Example: PF = 0xFF, PS = 0x50 → PGN 0xFF50.
Everyone listens, regardless of destination.
Example of Destination-Specific Message
CAN ID: 0x18EEFF01
Priority = 6
PF = 0xEE (Request message, < 240 → destination specific)
PS = 0x01 (Destination = ECU at address 0x01)
SA = 0xFF (Sender = ECU 0xFF)
PGN = 0xEE00
-
Gatecrasher
- Posts: 435
- Joined: Fri Apr 24, 2020 8:09 pm
Re: Enabling mixed frame and or extended Low Speed CAN single wire frames like those posted on GMLAN bible
I never said it wasn't from Onstar. My example was very clear that the bottom 13 bits are the sending module ID. I said it wasn't talking to anyone in particular.
The chatbot is full of shit, as usual.
J1939 is a heavy duty truck diagnostic protocol. As far as I know, it's not used in light duty vehicles and definitely not in GM light duty vehicles.
This is from GMW3104 - GMLAN Communication Strategy Specification.
In GMLAN, the only time one module or tool is speaking directly to another module or tool is when it's using the 2xx/6xx request and response frames. Everything else is a broadcast and it is up to each receiver to act on it or ignore it.
The chatbot is full of shit, as usual.
J1939 is a heavy duty truck diagnostic protocol. As far as I know, it's not used in light duty vehicles and definitely not in GM light duty vehicles.
This is from GMW3104 - GMLAN Communication Strategy Specification.
In GMLAN, the only time one module or tool is speaking directly to another module or tool is when it's using the 2xx/6xx request and response frames. Everything else is a broadcast and it is up to each receiver to act on it or ignore it.
You do not have the required permissions to view the files attached to this post.
-
ironduke
- Posts: 820
- Joined: Thu Feb 13, 2020 1:32 pm
- cars: Mainly GM trucks, a Cruze and an Equinox for dailys..
Re: Enabling mixed frame and or extended Low Speed CAN single wire frames like those posted on GMLAN bible
Wonder why my messages broke down so nicely then? Wonder if gmw3104-3-8 covers up to 2024??
No idea, but thank u for being so helpful..
No idea, but thank u for being so helpful..
-
Gatecrasher
- Posts: 435
- Joined: Fri Apr 24, 2020 8:09 pm
Re: Enabling mixed frame and or extended Low Speed CAN single wire frames like those posted on GMLAN bible
Lined up how? The only thing I see is guesses based on a chat bot telling you to use a semi truck diagnostic standard, and you think that means Onstar is talking to modules that don't exist, saying things you can't decipher.
Nothing you're saying makes any sense. It's not backed up by any documentation or demonstrable theory. All you've got is a CAN log where "thing happened".
Nothing you're saying makes any sense. It's not backed up by any documentation or demonstrable theory. All you've got is a CAN log where "thing happened".
-
kur4o
- Posts: 1145
- Joined: Sun Apr 10, 2016 11:20 am
Re: Enabling mixed frame and or extended Low Speed CAN single wire frames like those posted on GMLAN bible
Gm 29bit CAN have modules ID encoded in header,[as requested by 1A B0] if used for module to module communication.
3rd byte is destination, 4th byte is source, first 2 bytes might be some bit encoded to specify what the message is.
It can also broadcast to all modules if destination is FE[to all modules]
It resembles VPW communication for sure.
3rd byte is destination, 4th byte is source, first 2 bytes might be some bit encoded to specify what the message is.
It can also broadcast to all modules if destination is FE[to all modules]
It resembles VPW communication for sure.
-
Gatecrasher
- Posts: 435
- Joined: Fri Apr 24, 2020 8:09 pm
-
kur4o
- Posts: 1145
- Joined: Sun Apr 10, 2016 11:20 am
Re: Enabling mixed frame and or extended Low Speed CAN single wire frames like those posted on GMLAN bible
Take it as a different layer of CAN network that is not documented and is GM proprietary protocol.
some example of globalB headers used for diagnostics
18 DA F1 18
18 DA 18 F1
F1 - ID of tool, 18 - id of module
first 2 bytes needs decoding but pattern can be found if more logs are present.
As you can see mongoose cable can`t even pick those messages on the bus.
-
Gatecrasher
- Posts: 435
- Joined: Fri Apr 24, 2020 8:09 pm
Re: Enabling mixed frame and or extended Low Speed CAN single wire frames like those posted on GMLAN bible
Nobody is talking about Global B.
Nobody is talking about scan tool procedures.
Nobody is talking about scan tool procedures.