VW GTE 3.6Kw charger 5QE 915 682 AF reverse engineer

[RetroZero]

Starting new thread as too many models being discussed all at the same time.
I however hope to learn from those topics to build up info to get this charger documented. There is a good chance that this charger is not identicle to the one Damien got working, or there's another issue due to him not being able to get it working again, so slightly different CAN messages will be needed.

Charger reference is 5QE 915 682 AF (compatible with BL & BG)
Charge cable is 5G0 971 509 F (compatible with N)
60 pin plug as the other VAG chargers, along with the pins.
VCDS is connected looking at different actual values, erasing faults & coding
SavvyCAN running to send commands to find different CAN messages
Arduino due with CAN transceiver running Damiens code.

First will be to play back this log - thanks DomT - https://github.com/DomT177/GolfGTE
Along with crasbe magic byte cracker - viewtopic.php?p=48154#p48154
DBC files that we know of - viewtopic.php?p=48104#p48104

[RetroZero]

Two other items have come to my attention that might need spoofing
1 - the PILOT control signal
2 - the MAINTENANCE plug signal

Both signals give me values between 8vdc & 10vdc if I create a short circuit using myself (resistance) between each wire & the battery positive pole. This could be a pwm signal for all I know, so I'll investigate further with VCDS.

[Bigpie]

You will also need to spoof the lock feedback signal. I coded it out with ODIS, but it was still expecting it and causing a fault.

[Mitchy]

Can you take a snip of the coding values in ODIS (The list of available options?)

Do you have the charge plug wired to the charger similarly to a golf GTE wiring diagram? Just trying to determine if you're using it in a 'stock' type arrangement, as mentioned the lock feedback and plug temp sensors are likely needed.
You may also need a few LED lights for the status indications, as well as a momentary switch for the charger port button.

Shouldn't the pilot control signal come from your EVSE?

[Bigpie]

It was over a year since I looked at it, I'll try dig out all the screenshots and can logs from discord.

[Bigpie]

Screenshot_2023-08-23_at_12.06.12_pm.png

Screenshot_2023-08-23_at_12.06.25_pm.png

Screenshot_2023-08-23_at_12.06.35_pm.png

Screenshot_2023-08-23_at_12.07.10_pm.png

If you scroll back in the #reverse-engineering channel in discord to around — 17/08/2023, 14:39 that's when I was looking at it.

I did workout that my Chinese type 1 to type 2 adaptor I was using at the time turned out to have the lock cutout too large so the lock pin was over extending, which was possibly my issue with the feedback.

[RetroZero]

I have the stock set-up with the flap locking mechanism and LED push buttons. If I reset to factory settings, the lock fault is erased, until I activate it again. I have a type 2 charger plug connected so normally there is no over run of the locking actuator.
I've looped the HV connectors for A/C, Heating & DC-DC to spoof them being plugged in.

[RetroZero]

I don't see any actual values in VCDS relating to the maintenance or pilot lines, and I have yet to find anything relating to them in the CAN messages. Their voltages do not seem standard either. But in a normal oem setup, either of these signals would flag a fault and cancel any charging. I'm thinking of putting 100kOhm resistor on each line and connect to positive to see if there are any changes.

[Bigpie]

Use ODIS. The signals and faults are listed there

[Mitchy]

I'd use ODIS and see what you get for the plug resistances for the locking and temp sensors.
Confirm they're coming in on the A channel and not the B channel.
In some wiring diagrams it seems they use the B as the primary channel.

I'd also confirm that they need to be connected to the 12V rail, been a while but I seem to recall that the resistances are all based off of a ground connection.

[Mitchy]

Just checked my notes and confirmed, the resistances should all be tied to sensor ground.
All the resistances are variable, so a high (+12V) or low (Grounded) state will likely trigger a fault.

Hopefully no damage is done to the sense circuits for the lock signals, etc... I'd assume they're all 12V tolerant.

In ODIS you should be able to see what the current resistance is by reading the mV status (at least on some models), as it seems that internally there's a resistor divider. The switch state values can be viewed as well.
The limits for the lock feedback in VCDS for the larger chargers seem to be:

Code: Select all

IDE14287-ENG251101,Connector lock loading hatch 1: voltage values-actual_voltage_plug_interlock_a,11812, mV
IDE14287-ENG251048,Connector lock loading hatch 1: voltage values-Max_limit_voltage_plug_interlock_locked_a,12169, mV
IDE14287-ENG250931,Connector lock loading hatch 1: voltage values-Max_limit_voltage_plug_interlock_not_locked_a,4565, mV
IDE14287-ENG250782,Connector lock loading hatch 1: voltage values-min_limit_voltage_plug_interlock_locked_a,6657, mV
IDE14287-ENG250651,Connector lock loading hatch 1: voltage values-min_limit_voltage_plug_interlock_not_locked_a,1651, mV

You could likely confirm these values with a multimeter on the input pin.
It seems the charger sources the 12V thru the resistive switch of the lock, and measures the voltage drop.

[RetroZero]

Seems my previous message did not get sent. My resistances are all internal and connected directly between OBC & Locking actuator.
The resistace values add up to Damiens initial testing values.
I think the OBC is in fault mode & just locks the actuator - because when I connect up my Arduino with Damiens code, the actuator locks & unlocks a few times. To me that indicates that the messages are getting received by the OBC.
Un-coding the lock, causes the charge sequence communication between OBC & Type2 charger to not function, so I coded the lock back.
What sequence are you using when activating the charger?
I plug in my Type 2 charger, wait for the charger to detect AC voltage, & start the code "a" as per the instructions.
It just sits there laughing at me....
I have numerous faults. Could anyone provide me with their stored faults so I can compare?

[RetroZero]

Screenshot (51).png

Carrying on with this project, I am now trying to spoof additional messages.
What I did notice, is that when I have the Arduino code running & Charger not yet activated
Frequency, Control voltage & Duty cycle are activated.
Current cond - StandBy = normal as I have not yet activated the Charge process.
Limit, Battery temp (spoofed by Damiens code) & A/C requirements seem normal.
The next 2 are where I am not sure how this works...
Voltage HV battery - The code is supposed to take AC supply Voltage, which it reads correctly, and duplicate it for simulating HV battery voltage. This stays at 0V
Current HV Battery - this remains at 0A, but I do not have a charge process activated.
Spoofing CAN ID 097 for battery voltage, it seems the values do not stay constant, so I am assuming there is a checksum thingy going on.
From what I understand, If Battery voltage is not detected, the Activate Charge will not function.
Does this make sense?

[RetroZero]

I have spoofed SOC, but that has not advanced the charge process.
I have also found the 'Itermediate charger voltage value' which I hope to spoof to get the charger to see Battery Voltage.
I'm now comparing e-tron sketch, gte log & phev.ino code to find additional values using vcds.
Will keep updating here.

[RetroZero]

So I managed to spoof BMS voltage using incomming AC Voltage on ID 0x097. STill not enough to get charger happy to charge.
Will continue digging and adding more values over the weekend.

[RetroZero]

Small update.. I added ID's 131[3], 3DD, 869, 945, 958, 1628, 1714, 116 & 37C to basic sketch, as I have multiple faults stored. Tha charger still does not go into Charge Mode, but I now have the Red LED light coming on during communication between charger & EVSE type2 charger....
I'll break down the ID,s meanings over next few days.

[RetroZero]

Spent the day spoofing the charger. I did so much, I had to go backwards, as I created heaps of faults - quite a few due to Checksum errors.
Good news is I got the charger to work ONCE. I thought I was creating a short circuit, so stopped the charge. Now can't reproduce the process.
Back to drawing board tomorrow, but there is light at end of tunnel....I think

[Mitchy]

Post up your sketch to see if anything is sticking out as a potential issue.

I wish I could help more with these, but I don’t have a unit to test with.

It is a good sign that it did begin to charge though!

[Bigpie]

You can have mine if you want it

[RetroZero]

This is the .ino file I have.

[RetroZero]

For info, I do not have the charger connected to a battery, so spoofing all the way to get it initially to work with the good old cooker element test, as per the irishman....

[RetroZero]

Still no luck in getting a charge going. I have been adding more messages, however they throw up quite a few additional faults, which might or might not be adding extra problems to the charge sequence.
Anyhow, I thought I would share & see if anyone can pick up issues that can break down issues.

I do have a question regarding 0x124[5], this byte is required for the Battery current actual value, but is being used to set the Idc setpoint. I cannot get to spoof this value, which might be where part of the problem is.

[Mitchy]

In your sketch, some of the ids are in decimal, but notated as hex.
for instance your BEM_05 has a ID of 0x869, but it should be either 869 (decimal) or 0x365 (hex)

Is your charger coded for a EV or Hybrid? If it's coded as a hybrid, may be worthwhile trying to code it as an EV (or vice versa)

Motor_12 - 0x0A8 - Has CRC - Magic Bytes: 0x52,0x8c,0x50,0xee,0x4f,0xa6,0xcc,0xcf,0x7d,0x2f,0x98,0x6b,0x27,0x41,0x9f,0x93;
Motor_14 - 0x3BE - Has CRC - Magic Bytes: 0x1f,0x28,0xc6,0x85,0xe6,0xf8,0xb0,0x19,0x5b,0x64,0x35,0x21,0xe4,0xf7,0x9c,0x24;
Motor_31 - 0x556 - No CRC
BEM_05 - 0x365 - No CRC
Diagnose_01 - 0x6B2 - No CRC - Just has KMs and Time, Etc, Used for Diagnostic Freeze Frame stuff.
DC_HYB_01 - 0x09C - Has CRC - Magic Bytes: 0x04,0x4c,0x86,0xac,0x03,0x0d,0xb9,0xb3,0xbd,0x13,0x62,0xab,0x26,0x36,0x23,0xeb;
DC_HYB_02 - 0x3AF - Has CRC - Magic Bytes: 0x94,0x6a,0xb5,0x38,0x8a,0xb4,0xab,0x27,0xcb,0x22,0x88,0xef,0xa3,0xe1,0xd0,0xbb;
OBD_01 - 0x391 - Not mission critical, just stuff that is used for OBD Freeze Frame data

for most of these, you may be best to just playback the GTE log for these items, clear the faults, and try to charge.

If you add these, you'll need to add the magic bytes to the magic byte logic, along with the addresses and copy the crc parts from an existing crc message function.
I can't add them at the moment, but I can give it a shot later tonight.

[RetroZero]

THANKS HEAPS @Mitchy!
The decimal/hex ID's explain a few of my findings, as I have been using the mqb dbc file along with your e-tron code & DomT's log to try and find additional ID's. I probably have been using the decimal ID's and not the hex version.
I'll add the Magic Bytes you provided thanks, and look into messages with crc functions from @DomT's log, but that will take some searching.
I am trying to put as much into the code, so SavvyCan and VCDS don't have too much to do but follow along. Otherwise, another computer is in order to spread the load.
I'll swap my charger version from Hybrid to Electric & see what that does too! Thanks again for the reply and vital info.