Enabling mixed frame and or extended Low Speed CAN single wire frames like those posted on GMLAN bible

Disassembly, Reassembly, Tools and devleopment. Going deep with Hardware and Software.
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

Post by ironduke »

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
User avatar
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

Post by Gatecrasher »

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:

Code: Select all

Hexadecimal:    0x10     0x0D     0x00     0x60
    Binary:       00010000 00001101 00000000 01100000
    Priority:        ---
    Arbitration:        -- -------- ---
    Sending ECU:                       ----- --------
    
The first 3 bits are the message priority.
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

Post by ironduke »

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.
User avatar
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

Post by Gatecrasher »

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.
GMW3104-3-8.jpg
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

Post by ironduke »

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..
User avatar
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

Post by Gatecrasher »

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".
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

Post by kur4o »

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.
User avatar
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

Post by Gatecrasher »

I give up.
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

Post by kur4o »

Gatecrasher wrote: Thu Sep 04, 2025 1:34 pm I give up.
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.
User avatar
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

Post by Gatecrasher »

Nobody is talking about Global B.
Nobody is talking about scan tool procedures.