NefMoto

Technical => Reverse Engineering => Topic started by: elRey on October 25, 2021, 08:40:44 PM



Title: CAN message generated from paddles?
Post by: elRey on October 25, 2021, 08:40:44 PM
Can/will anyone share the CAN message ID and payload for paddle up/down that dsg reads? On slow CAN it’s 0x289 bit 4 directly from J527.
However, I assume gateway passthough some message to fast CAN for dsg to read.

I don’t have a gateway to sniff (dsg swapped mk4).


Thanks


Title: Re: CAN message generated from paddles?
Post by: terok on October 26, 2021, 09:59:07 AM
ID 0x38A, byte 4
bit0 = tiptronic_tip_down
bit1 = tiptronic_tip_up

Gateway sends this to powertrain CAN.
Is this what you are looking for?


Title: Re: CAN message generated from paddles?
Post by: elRey on October 26, 2021, 01:52:29 PM
ID 0x38A, byte 4
bit0 = tiptronic_tip_down
bit1 = tiptronic_tip_up

Gateway sends this to powertrain CAN.
Is this what you are looking for?


Exactly what I was looking for. Thank you. I’ll double check, I don’t think the mk4 gateway does this. J527 does have direct access to fast/drivetrain BUS. I don’t understand why it doesn’t broadcast this info itself.


Title: Re: CAN message generated from paddles?
Post by: cherry on October 26, 2021, 05:24:09 PM
Wasnt MK4 paddles wired to DSG directly? But i think this require some old mechatronic...


Title: Re: CAN message generated from paddles?
Post by: aef on October 27, 2021, 01:51:32 AM
Wasnt MK4 paddles wired to DSG directly? But i think this require some old mechatronic...

R32 DSG is Cxx Mechatronic and the paddles are directly connected to T20/3 and T20/14 at the mechatronic.



Title: Re: CAN message generated from paddles?
Post by: elRey on October 27, 2021, 10:04:12 AM
My research turned up the same info. However, MK4 DSGs are rare and for VR6s.

I doubt anyone has tried hardwiring to same pins on a newer DSG to test if functionality still exists without flashing DSG.
And you would need to know the separate resistance of the paddle switches.

This question is for 4cyc DSG DQ250 on ME7.5 1.8T dash and ecu and a MK5+ steering wheel (really a 8P A3 steering wheel for my project).

My current options:
- use 8P wheel + J527 + custom module to read slow CAN 0x289 and broadcast 0x38A on fast CAN
- use 8P wheel + J527 + find a way to modify MK4 gateway to broadcast 0x38A
- use 8P wheel + custom module to read/write LIN to wheel and broadcast 0x38A
- use 8P wheel + modify wheel wiring to bypass LIN + custom module to read direct paddle contacts and broadcast 0x38A

Leaning toward first option at the moment since I already have a custom LCD reading fast CAN. I can leverage work done on that project.


MK4 R32 diagram below for reference.


Title: Re: CAN message generated from paddles?
Post by: elRey on October 27, 2021, 10:23:42 AM
ID 0x38A, byte 4
bit0 = tiptronic_tip_down
bit1 = tiptronic_tip_up

Gateway sends this to powertrain CAN.
Is this what you are looking for?


I assume the rest of the payload mirrors 0x289 on slow/convenience CAN, correct? And same broadcast frequency?

edit: it looks like cruise info is in that same ID. I hope this does not interfere with my non-CAN cruise controls. :(


Title: Re: CAN message generated from paddles?
Post by: terok on October 27, 2021, 11:56:18 AM
My understanding is that newer mechatronic units do not have analog inputs for paddles. I have not tested this.

If you have J527 already, imo easiest option is number one. Then you can also do other stuff if needed.
If you don't have it, i would read LIN directly and broadcast that forward.

You have parameter in ecu which tells where CCS information is coming, so should not interfere.

I have no information about convenience 0x289.
Btw, byte 1 is checksum for this packet, 8bit sum.
Tx interval 20ms.

Quote
GRA_Neu   0x38A   CHK_GRA_Neu         1   0..7   8   gültiger Wert   0   255   0 .. 255      0   1      
GRA_Neu   0x38A   GRA_Hauptschalter      2   0   1   gültiger Wert                     0 1   Gerastet Aus EIN
GRA_Neu   0x38A   Abbrechen         2   1   1   gültiger Wert                     0 1   Tippschalter nicht betaetigt Tippschalter betaetigt
GRA_Neu   0x38A   KurzTip_down         2   2   1   gültiger Wert                     0 1   Tippschalter nicht betaetigt Tippschalter betaetigt
GRA_Neu   0x38A   KurzTip_up         2   3   1   gültiger Wert                     0 1   Tippschalter nicht betaetigt Tippschalter betaetigt
GRA_Neu   0x38A   LangTip_down         2   4   1   gültiger Wert                     0 1   Tippschalter nicht betaetigt Tippschalter betaetigt
GRA_Neu   0x38A   LangTip_up         2   5   1   gültiger Wert                     0 1   Tippschalter nicht betaetigt Tippschalter betaetigt
GRA_Neu   0x38A   Bedienteil_Fehler      2   6   1   gültiger Wert                     0 1   i. O. Fehler Bedienteil
GRA_Neu   0x38A   Codierinfo_SMLS         2   7   1   gültiger Wert                     0 1   GRA codiert ACC codiert
GRA_Neu   0x38A   Tip_Setzen         3   0   1   gültiger Wert                     0 1   Tippschalter nicht betaetigt Tippschalter betaetigt
GRA_Neu   0x38A   Tip_Wiederaufnahme      3   1   1   gültiger Wert                     0 1   Tippschalter nicht betaetigt Tippschalter betaetigt
GRA_Neu   0x38A   Sendercodierung         3   2..3   2   gültiger Wert                     0 1 2 3   Bordnetzsteuergeraet Lenksaeulenmodul Motor SG nicht belegt
GRA_Neu   0x38A   BZ_GRA_Neu         3   4..7   4   gültiger Wert   0   15   0 .. 15      0   1      
GRA_Neu   0x38A   Tiptronic_Tip_Down      4   0   1   gültiger Wert                     0 1   Tippschalter nicht betaetigt Tippschalter betaetigt
GRA_Neu   0x38A   Tiptronic_Tip_Up      4   1   1   gültiger Wert                     0 1   Tippschalter nicht betaetigt Tippschalter betaetigt
GRA_Neu   0x38A   ACC_Zeitlueckenverstellung   4   2..3   2   gültiger Wert                     0 1 2   Taste nicht betaetigt Dist -1 Dist +1
GRA_Neu   0x38A   Tiptronic_Limiter      4   4   1   gültiger Wert                     0 1   Limiter aus Limiter ein
GRA_Neu   0x38A   Typ_Hauptschalter      4   5   1   gültiger Wert   0   1   0 .. 1      0   1      
GRA_Neu   0x38A   void            4   6                                             
GRA_Neu   0x38A   Tiptronic_Tip_Fehler      4   7   1   gültiger Wert                     0 1   i.O. Fehler erkannt


Title: Re: CAN message generated from paddles?
Post by: elRey on October 27, 2021, 02:00:28 PM
Great information. Thank you. I also just found same info in different format: ( I like your format better )

Description:
CHKSM: checksum
Bit addr. 0, bit num. 8, initial value 0
Valid range of values ​​0x00..0xFF

S_HAUPT: GRA / ADR - main switch
Bit addr. 8, bit num. 1, initial value 0
0 switched off, 1 switched on
RCOS message: mrmGRA

T_AUS: GRA / ADR - Tip switch "Off"
Bit addr. 9, bit num. 1, initial value 0
0 tip switch not activated, 1 tip switch activated
RCOS message: mrmGRA

T_VER: GRA / ADR - Tip switch "Decelerate"
Bit addr. 10, bit num. 1, initial value 0
0 tip switch not activated, 1 tip switch activated
RCOS message: mrmGRA

T_BES: GRA / ADR - Tip switch "Accelerate"
Bit addr. 11, bit num. 1, initial value 0
0 tip switch not activated, 1 tip switch activated
RCOS message: mrmGRA

ZU_VER: GRA / ADR delay; is not processed
Bit addr. 12, bit num. 1, initial value 0
0 Don't accelerate, 1 accelerate
RCOS message: mrmGRA

ZU_BES: GRA / ADR accelerate; is not processed
Bit addr. 13, bit num. 1, initial value 0
0 Don't delay, 1 delay
RCOS message: mrmGRA

F_BTL: GRA / ADR - keypad error
Bit addr. 14, bit num. 1, initial value 0
0 OK, 1 control lever error
RCOS message: mrmGRA

T_SET: GRA / ADR - Tip switch "Set"
Bit addr. 16, bit num. 1, initial value 0
0 tip switch not activated, 1 tip switch activated
RCOS message: mrmGRA

T_WA: GRA / ADR - Tip switch "Resume"
Bit addr. 17, bit num. 1, initial value 0
0 tip switch not activated, 1 tip switch activated
RCOS message: mrmGRA

COD_SND: Sender coding
Bit addr. 18, bit num. 2, initial value 0
00 On-board power supply control unit
01 steering column module
10 engine SG
11 not used
RCOS message: mrmGRA

Z_Count: message counter
Bit addr. 20, bit num. 4, initial value 0 Valid range of values ​​0x0..0xF

T_TDN: tip-down; is not processed
Bit addr. 24, bit num. 1, initial value 0
0 tip switch not actuated, 1 tip down

T_TUP: Tip-Up; is not processed
Bit addr. 25, bit num. 1, initial value 0
0 tip switch not actuated, 1 tip up

T_DST: ADR - Tip switch distance request; is not processed
Bit addr. 26, bit num. 2, initial value 0
00 Key not pressed
01 Nobody wants distance
10 Desired distance greater
11 not used

ZU_LIM: Limiter on; is not processed
Bit addr. 28, bit num. 1, initial value 0
0 tip switch not actuated, 1 tip up

F_BTLT: Tiptronic control unit error; is not processed
Bit addr. 31, bit num. 1, initial value 0
0 tip switch not actuated, 1 tip up


Title: Re: CAN message generated from paddles?
Post by: aef on October 28, 2021, 12:27:23 AM
Do you have a Exx or Fxx Gearbox including gear selector?

Have you logged the up and downshifts while manually shifting?

Maybe you can wire your paddles to the switches in the shifter, idk.



Title: Re: CAN message generated from paddles?
Post by: elRey on October 28, 2021, 06:10:53 AM
Do you have a Exx or Fxx Gearbox including gear selector?

Have you logged the up and downshifts while manually shifting?

Maybe you can wire your paddles to the switches in the shifter, idk.



I have logged those. The selector does not use physical switches. Instead it uses hall effect sensors for selector location. Nice thought tho.


Title: Re: CAN message generated from paddles?
Post by: elRey on October 28, 2021, 08:33:43 AM
edit:
nevermind. I finally found it in FR (searching terms shared here by terok - thanks)

chksum = byte 2 XOR byte 3 XOR byte 4

FR section = GGCGRA <- just found this
end edit


Btw, byte 1 is checksum for this packet, 8bit sum.


CHKSM: checksum
Bit addr. 0, bit num. 8, initial value 0
Valid range of values ​​0x00..0xFF

I'm onto this part. Since my setup might ignore any cruise control data, I want to use those bits for my own purposes. This requires me to calc the checksum instead of just repeating what's on slow CAN 0x289 with it's checksum already calculated.

With that said. I've been looking at the data and I cannot grasp how overflow/carry over is applied to checksum.
example data:

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=20071.0;attach=35247;image)





Title: Re: CAN message generated from paddles?
Post by: terok on October 28, 2021, 10:06:08 AM
I'm not sure i understand the problem.
If you do 8bit XOR, there's no overflow.


Title: Re: CAN message generated from paddles?
Post by: elRey on October 28, 2021, 10:15:29 AM
No problem now. I was just adding/summing bytes, not XOR. It wasn't until I found the info in FR that I realized I needed to XOR.

My edit at the the top of my previous post was me saying I had found the answer to that post.


Title: Re: CAN message generated from paddles?
Post by: elRey on November 13, 2021, 07:24:46 PM
So, it looks like I need to turn off ECU sending 0x38A messages before I inject my own. I'll ask here before I create a new post:

Can someone help me locate CW_CAN_R from this assembly code:

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=20071.0;attach=35370;image)

I still down know how to follow memory location offsets:

Code:
movbz   r4, byte_FA05
shl     r4, #1
mov     r5, [r4+word_8132B4]
and     r5, #8

^ know this is checking for CW_CAN_S bit 3


Title: Re: CAN message generated from paddles?
Post by: prj on November 14, 2021, 03:16:01 AM
Your assumption that the newer mechatronic units would have different inputs is flat out wrong.
When DQ250 a Cxx mechatronic unit goes bad it is always replaced by a Fxx unit, because Cxx are out of production for a long time. Has been like that for ten years or more.
Same for DL501 with Gen1 vs Gen2, if a Gen1 is bad it is replaced with a Gen2.

There is also a replacement software for every single Cxx unit ever made.

So if you wire it up as per the R32 and then flash the R32 software into it, then it will read the analog in.


Title: Re: CAN message generated from paddles?
Post by: elRey on November 14, 2021, 06:50:29 AM
I appreciate the correction an additional option. However, I’d prefer the CAN bus route. The wheel is LIN bus. I don’t have an analog wheel. Nor have I yet acquired the means/knowledge to read/write mechatronics. I’m very close to finishing with CAN bus.

I need to stop ECU from sending 0x38A msg, but I don’t have the address for CW_CANs.

Another assumption that I might have wrong is that my dsg actual uses 0x38A for paddles.

Also, I don't understand why the J527 does not send 0x38A itself (on the bench). Does it need to see the dsg on the bus before it sends 0x38A? First things first, disable ECU sending 0x38A. Then maybe the J527 will start sending. If not, then I'll try adding dsg to bench CAN bus. If still no 0x38A from J527, I'll add my CAN node.


Title: Re: CAN message generated from paddles?
Post by: terok on November 15, 2021, 02:45:31 PM
Gateway sends 0x38A, not ECU or steering column unit.


Title: Re: CAN message generated from paddles?
Post by: elRey on November 16, 2021, 04:35:20 PM
Gateway sends 0x38A, not ECU or steering column unit.

ME7.5 032 HF

Quote
FDEF GGCGRA 1.20 Function definition

The GRA operating lever signals are recorded either via HW signals or CAN. from PROKON: CWGRABH (bit 0) = B_gracan
     false: Signals are recorded via HW and must be sent via CAN
     true: Signals are received by the CAN

To activate the CAN, bit 3 must be set in CW_CAN_S.
  It is then decided via B_gracan whether the message should be sent or received.
The same applies to the old GRA message if SY_CAN_CONFIG = 5, 10 or 11.

And the msg itself ,byte 3 bit 2-3, states the source:

Quote
COD_SND: Sender coding
Bit addr. 18, bit num. 2, initial value 0
00 On-board power supply control unit
01 steering column module
10 engine SG
11 not used
RCOS message: mrmGRA

I cofirmed on the bench that ECU was sending 0x38A (only ECU on bus). Once I changed CW_CAN_S.3 (found it), ECU stopped. No 0x38A msgs.   Now with mk4 Cluster, mk4 gateway, mk4 ecu, and 8p a3 steering wheel on bus and confirmed steering wheel sending 0x289 on slow bus, but no 0x38A on fast bus.

As for steering wheel vs gateway sending 0x38A (once ecu is configured correctly), do you happen to have any documentation stating gateway is the source?

Thanks,
Rey


Title: Re: CAN message generated from paddles?
Post by: terok on November 17, 2021, 06:09:39 AM
Ok i was incorrect. I didin't bother to check FR, but it makes sense on older cars to ECU to send this because there is no steering column unit, nor BCM.
8P A3 (and G5) for example is different. Gateway relays this packet from convenience-CAN to drivetrain-CAN (among many other things).

I have never sniffed what mk4 gateway does, but mk5 works like this.
All CAN versions above 4.0 support this (CANVERS >= 0x9).
Drivertrain-CAN is indeed available on J527, but maybe it is only for steering angle sensor (id 0x0C2).
Are there any coding or adaptation options in J527 (or mk4 gateway) that you could experiment with?


Title: Re: CAN message generated from paddles?
Post by: Dave9n3 on November 22, 2021, 11:47:06 AM
CW_CAN_R_0___A = 132AC
CW_CAN_R_1___A = 132AE
CW_CAN_R_2___A = 132B0
CW_CAN_R_3___A = 132B2

CW_CAN_S_0___A = 132B4
CW_CAN_S_1___A = 132B6
CW_CAN_S_2___A = 132B8
CW_CAN_S_3___A = 132BA

Those are the addresses I have for 032HF SW0004. Not tested, but might be of some use to you.


Title: Re: CAN message generated from paddles?
Post by: Dave9n3 on November 22, 2021, 02:51:18 PM
Your assumption that the newer mechatronic units would have different inputs is flat out wrong.
When DQ250 a Cxx mechatronic unit goes bad it is always replaced by a Fxx unit, because Cxx are out of production for a long time. Has been like that for ten years or more.
Same for DL501 with Gen1 vs Gen2, if a Gen1 is bad it is replaced with a Gen2.

There is also a replacement software for every single Cxx unit ever made.

So if you wire it up as per the R32 and then flash the R32 software into it, then it will read the analog in.

Please forgive my ignorance - but if for example I buy a CXX from a MKV gti, and flash it with the R32 DSG software, the only thing that I would need to change then would be the gear ratio maps, as a bare minimum?


Title: Re: CAN message generated from paddles?
Post by: prj on November 24, 2021, 12:35:18 PM
Please forgive my ignorance - but if for example I buy a CXX from a MKV gti, and flash it with the R32 DSG software, the only thing that I would need to change then would be the gear ratio maps, as a bare minimum?
Why would you want a Cxx DSG unit? Those mechatronic units are failure prone. Buy a Exx or Fxx unit (they are the same), find one with the gear ratios you like etc. There's R32 software that goes into a Fxx unit, because if you need a new mechatronic unit for an R32 nobody in the last 10+ years would have sold you a Cxx new, they had a very short production run.


Title: Re: CAN message generated from paddles?
Post by: tao13 on January 07, 2022, 01:02:07 PM
I confirm too what elRey said.
Ecu send 0x38A DLC: 4! I tried with CAN_R , CWKONFZ1 , CWGC, nothing change.
BUT BUT, good news today i tried with CAN_S and ....038a....not appear!
I search a lin to can convertor but no luck.
Only what i found is a lin to uart , but lin protocol is hard to find too.
We can not put the steering wheel ring and controler on our mk4 platform because must add a can gateway and all others arms witch works different like ours with other confort controller.
I thinked to send the same canbus message like dsg knobs send on + and - but if you look in cxx file , you will see paddles had some specific maps so the dsg waiti other messages from paddles(j527 , bla bla bla) than knob + and - messages! And i think this can be confirmed again because cars with dq250 have or not paddles and steering wheel ring must coded different.
The easy way is to send on canbus the message. For the moment i don;t have the steering wheel ring and controler , but i ordered to try to sniffer it.
elRey are you sure what dsg waiting is 0x38A for paddels?

Other model of GRA, but i think this is for me7.5 witch work with old cxx model, we must see if the new cxx model (not analogic input from paddles) from golf 5 , passat b6 had the same structure.
[START_MSG] GRA_Neu,906,4,20,1,S,XXX
[START_SIGNALS] GRA_Checksum,8,1,0,U,255,0,1,0,1,,,XXX
[START_SIGNALS] GRA_Hauptschalt,1,2,0,B,1,0,1,0,1,,,XXX
[START_SIGNALS] GRA_Abbrechen,1,2,1,B,1,0,1,0,1,,,XXX
[START_SIGNALS] GRA_Down_kurz,1,2,2,B,1,0,1,0,1,,,XXX
[START_SIGNALS] GRA_Up_kurz,1,2,3,B,1,0,1,0,1,,,XXX
[START_SIGNALS] GRA_Down_lang,1,2,4,B,1,0,1,0,1,,,XXX
[START_SIGNALS] GRA_Up_lang,1,2,5,B,1,0,1,0,1,,,XXX
[START_SIGNALS] GRA_Fehler_Bed,1,2,6,B,1,0,1,0,1,,,XXX
[START_SIGNALS] GRA_Kodierinfo,1,2,7,B,1,0,1,0,1,,,XXX
[START_SIGNALS] GRA_Neu_Setzen,1,3,0,B,1,0,1,0,1,,,XXX
[START_SIGNALS] GRA_Recall,1,3,1,B,1,0,1,0,1,,,XXX
[START_SIGNALS] GRA_Sender,2,3,2,U,3,0,1,0,1,,,XXX
[START_SIGNALS] GRA_Neu_Zaehler,4,3,4,U,15,0,1,0,1,,,XXX
[START_SIGNALS] GRA_Tip_Down,1,4,0,B,1,0,1,0,1,,,XXX
[START_SIGNALS] GRA_Tip_Up,1,4,1,B,1,0,1,0,1,,,XXX
[START_SIGNALS] GRA_Zeitluecke,2,4,2,U,3,0,1,0,1,,,XXX
[START_SIGNALS] GRA_Sta_Limiter,1,4,4,B,1,0,1,0,1,,,XXX
[START_SIGNALS] GRA_Typ_Hauptschalt,1,4,5,B,1,0,1,0,1,,,XXX
[START_SIGNALS] GRA_Sportschalter,1,4,6,B,1,0,1,0,1,,,XXX
[START_SIGNALS] GRA_Fehler_Tip,1,4,7,B,1,0,1,0,1,,,XXX
[END_MSG]


Title: Re: CAN message generated from paddles?
Post by: Dave9n3 on April 11, 2024, 11:16:22 AM
Does anyone know which other modules are sending 0x38A onto the bus?

I currently have aftermarket pedals sending the 0x38A message for the tip up and down, and they work but I get the occasional double shift. I’m assuming this is because there is multiple 0x38A being sent by different modules (I have an aftermarket module plugged in transmitting the paddle messages)

I have disabled the ECU sending it with CW_CAN_S as suggested previously, and confirmed this on the bench with a CAN sniffer, but I notice on the car I still have some other module sending 0x38A

I plan to monitor the canbus and unplug other modules until it stops, to narrow down which unit is sending it, but let’s say I find it’s the convenience module or the gateway and I have no way to change the coding to stop this.

Is there a hardware method I can use? Some sort of filter to allow a module to send every message it likes apart from 0x38A?

I’m a bit stuck and would appreciate someone’s advice


Title: Re: CAN message generated from paddles?
Post by: prj on April 11, 2024, 12:37:16 PM
You can always add a CAN filter between that module and the bus. A device with 2x canbus that filters or alters messages as you see fit.
No idea if there is something ready to go like that, which you can buy, but any micro with 2x CAN will do.


Title: Re: CAN message generated from paddles?
Post by: Dave9n3 on April 11, 2024, 01:41:23 PM
You can always add a CAN filter between that module and the bus. A device with 2x canbus that filters or alters messages as you see fit.
No idea if there is something ready to go like that, which you can buy, but any micro with 2x CAN will do.

That would be good, not sure how hard that will be but at least it’s a possibility!


Title: Re: CAN message generated from paddles?
Post by: Dave9n3 on May 03, 2024, 03:02:58 PM
Did some sniffing and now worked out that J519 is sending 0x38A onto the bus also, I just plugged the sniffer in and left it running whilst I killed modules one at a time until the message wasn’t present. I have tried recording the module, none of the predefined options VCDS shows you yielded any result. Then went trigger happy and just started unticking boxes in the long coding in the hope I’d mash my way to success but unfortunately not.

Looks like I may end up building some can-bridge/MITM module. Before that I wonder if I can just remove the module from the powertrain bus. Not entirely sure what other info it’s sending to the bus







Title: Re: CAN message generated from paddles?
Post by: terok on May 06, 2024, 11:06:13 AM
If you have PQ25 J519 (Polo, Transporter, for example), which also includes gateway, then yes it does this.