MQB Chargers

[uhi22]

Do I assume correctly that the button is physically connected to the charger and you are looking to the CAN messages sent by the charger, and looking for a button signal?
It may be, that the charger does not send a button signal at all, If all button-consumers are inside the charger and no other control unit needs to know this button.

[RetroZero]

I'd say the button is hard wired to the charger. It seems to impact the charge process but I don't know if any other control unit needs this info. There is however a dedicated message somehow, because there's a specific actual value for it in VCDS. Even if there isn't a signal, I would have thought the Proximity Pilot would have a dedicated ID, but i can't see it either. Could my CAN set-up have an issue?

[Mitchy]

I believe the PP signal is referred to in mV (as a result of the resistor divider network in the plug/charger), with the CP being referenced in the duty cycle frequency.

Code: Select all

IDE08423-MAS02949,Control signal for power outlet A for battery charging-Frequency,0, Hz
IDE08423-MAS02952,Control signal for power outlet A for battery charging-Control voltage,0, mV

What model charger are you working with?

Do you have a Teensy 4 chip handy? it should be possible to load the test code and attempt a charge session. Doing this should let you see the scope of signals required and allow you to follow along with the VCDS values updating.

The design of the charger means that we're talking with a charge manager; we tell it what we want from the charger, and it interfaces with the unit to make it happen. This is likely due to the inclusion of CCS charging within the charger as well, so it acts like a master vs a slave unit that just outputs voltage on request.
I'm doubtful that we'll be able to start a charge session via VCDS, mainly due to the fact that it eliminates so many safeguards.

Some safeguards are:

• Charger needs to see signals from BMS for voltage which match the charger DC voltage value +/-5v DC

• The 'HV Healthy' status for a few modules are in a good state, and the DC bus is energized.

I should soon have the code simplified a bit more, as I'm trying to implement the charge control within another controller I intend to use.
I haven't had my charger connected since initially doing the proof of concept, so I'm a bit rusty.

[RetroZero]

All great info for understanding going forward. Thanks!

So let's say the CP and PP are hardwired internally and only the charger see's them, VCDS recognises them as independent values. That means there is data being modified each time any of the 'outside components ' are engaged/pressed/lit up etc....
Now to find out where it is hidden in the CAN data.
Could there be some kind of internal layer that VCDS has access to and that the 'outside world ' does not see? A bit like the internals of a battery pack communicating with its BMS?

I have a STM32NUCLEO dev board sitting hear looking for something to do....

[uhi22]

Yes, there is a kind of 'internal layer'. Such a software has a lot of variables, which are just sitting in the RAM, and are written by a certain software component, and are read by other software components. And for each variable the designer has the freedom to decide whether the variable will be sent in a cyclic CAN Message, or will be accessable via UDS, or both, or none of them.
Usually, the plain CAN data contains only signals which are functionally needed by an other control unit. In contrast, the UDS usually allows access to some more details, to support the repair shop in case of trouble shooting.

[Mitchy]

Not to complicate the discussion.
But I've also always wondered if there's a shortcut in getting these chargers working by implementing a slave mode.
In some autos, there are 2 chargers working in a master/slave arrangement.
Should be technically possible to mimic the master and associated CAN signals to make the slave charge without as many interlocks.

This also makes me wonder if the system can accommodate more than one slave

Of course the slaves will not have any DC Charge capability.

[uhi22]

Do we have information whether master and slave have the same part number?
And more general, which part number does RetroZeros charger have?

[larsrengersen]

It is not likely that the MEB chargers operate as master and slave since (if I’m correct) there is only one of them in a car.
Ie the charging power of the OBC’s one to one match the max charge power of the donor vehicle (3,6 / 7,2 / 11 kW)

[Mitchy]

Ahh I may have gotten my chargers confused.
The MLB 11kw options have the ability to be configured to 22kW.
I haven't found the trigger which designates those as a master or slave though.

[uhi22]

Part Numbers please, in best case together with the donor vehicle type and year. Just to avoid mixing topics and causing more confusion.

[RetroZero]

Vw Golf GTE circa 2015
5QE 915 682 AF - charger (3,6 Kw)
5G0 971 509 F - complete charger plug (one phase ac) for the same vehicle.

[RetroZero]

Just to throw a spanner in the works....
I have 'finally' got another CAN board running with savvyCAN - PCAN.
What is interesting is that the ID's are not the same as the wifican setup. I did a log of the RED LED button and played it back with a successful LED Blinking.
I have not had time to go through the log properly, but I did see some bits alternating in sequence with the LED.
I'll look into it tomorrow - might just be false hope.....might not.

[RetroZero]

Pcan unstable and not giving the same results.
I keep coming back to doubts about my setup. When I am in CAN sniff mode, should I not be able to see bits changing when activating différent components connected directly to the charger?

[RetroZero]

Another day spent trying to get some kind of return messages from the charger.
I once again rebooted computer, savvycan, PCan View and VCDS. Played about with getting the PCan board running without success in Savvycan.
I got it to 'work' in PCan View, once again with more ID's than in Savvycan.
I isolated byte 8 on adress 0X566 which is iether C0 or EO when plugging in the charger plug. This is good news I think.
PCan View doesn't have as much functionning as Savvycan, but it makes me believe that my setup with SavvyCan is missing something for it not to function and see the same amount of ID's as PCan. Frustrating, as I feel I have quite a bit of hardware setup and can do nothing with it to move this RE forward. There is definitely Id's that can be decripted with sniffing the bus and selecting different values with VCDS, but something is not setup correctly.

[Mitchy]

What version of Nucleo board do you have?
It should be able to be setup to run the arduino sketch that Damien setup for these. You'll require a can transceiver, but I believe you have one already.

I think once you get the simulation code working, it'll become clearer on what the charger requires to be spoofed into charging.
https://github.com/damienmaguire/VW-OnB ... phev_1.ino
0x566 contains the following signals:

Code: Select all

BO_ 1382 HVLM_01: 8 Ladegeraet_PAG_PF
 SG_ HVLM_01_CHK : 0|8@1+ (1,0) [0|255] ""  BMS_PlugIn,Motor_MED17_SIMOS8_PlugIn_PAG_PF
 SG_ HVLM_01_BZ : 8|4@1+ (1,0) [0|15] ""  BMS_PlugIn,Motor_MED17_SIMOS8_PlugIn_PAG_PF
 SG_ HVLM_Fehler_Ladestecker : 12|1@1+ (1,0) [0|1] "" Vector__XXX
 SG_ HVLM_Fehler_Verriegelung : 13|1@1+ (1,0) [0|1] "" Vector__XXX
 SG_ HVLM_SollStrom_HV_Offset : 14|1@1+ (1,0) [0|1] "" Vector__XXX
 SG_ HVLM_IstStrom : 17|9@1+ (1,-255) [-255|254] "Unit_Amper"  Motor_MED17_SIMOS8_PlugIn_PAG_PF
 SG_ HVLM_IstModus_02 : 26|2@1+ (1,0) [0|3] ""  Motor_MED17_SIMOS8_PlugIn_PAG_PF
 SG_ HVLM_Konditionierung_Anf : 28|1@1+ (1,0) [0|1] ""  Motor_MED17_SIMOS8_PlugIn_PAG_PF
 SG_ HVLM_LadeAnforderung : 29|3@1+ (1,0) [0|7] ""  Motor_MED17_SIMOS8_PlugIn_PAG_PF
 SG_ HVLM_Stecker_Status : 32|2@1+ (1,0) [0|3] ""  BMS_PlugIn,Motor_MED17_SIMOS8_PlugIn_PAG_PF
 SG_ HVLM_SollStrom_HV : 34|10@1+ (0.2,-102) [-102|102.2] "Unit_Amper" Vector__XXX
 SG_ HVLM_MaxSpannung_HV : 44|10@1+ (1,0) [0|1021] "Unit_Volt" Vector__XXX

so what you're likely seeing is the 'Stecker_Status,

Damien's code has the following signals (0x564, 0x565, 0x566 & 0x67E) being received from the charger:

Code: Select all

if(inFrame.id ==0x564)
    {
      charger_status.ACvoltage=(inFrame.data.bytes[2]*2);//charger AC voltage is 9 bits from bit 15 to 23 (byte 1 bit 7 and all of byte 2)
      charger_status.HVVoltage=((inFrame.data.bytes[4]<<8) | inFrame.data.bytes[3])&0x3ff;//HVDC volts 10 bit from bit 24 to 33. Byte 3 and bits 0 and 1 of byte 4.
      charger_status.temperature=(inFrame.data.bytes[6]-40);//temp in byte 6 40 offset.
      charger_status.current=(((((inFrame.data.bytes[5]<<8) | inFrame.data.bytes[4])>>2)&0x3ff)*0.2)-102;//10 bit bytes 4 and 5.
      charger_status.mode=((inFrame.data.bytes[1])>>4)&0x07;//mode in byte 1. Bits 12-14. 0=standby,1=AC charging,3=DC charging,4=Precharge,5=Fail,7=init.
    }

    if(inFrame.id ==0x565)
    {
      charger_status.MaxACAmps=((inFrame.data.bytes[3])&0x7f)*0.5;
    }

    if(inFrame.id ==0x566)
    {
      charger_status.MaxHV=(((inFrame.data.bytes[6]<<8) | inFrame.data.bytes[5])>>4)&0x3ff;
      charger_status.ISetPnt=(((((inFrame.data.bytes[5]<<8) | inFrame.data.bytes[4])>>2)&0x3ff)*0.2)-102;
    }

    if(inFrame.id ==0x67E)
    {
      charger_status.PPLim=(inFrame.data.bytes[4])&0x07;//0=13A,1=20A,2=32A,3=63A,6=init,7=failed.
    }

  }

[RetroZero]

I'll give it a go on the Nucleo board thanks.
I'd love to know how you worked out that the values in that DBC file are in ID 0x566, or any other values.

Edit : dirty translation of the dbc file you attached

1382 HVLM_01: 8 charger_PAG_PF
SG_ HVLM_01_CHK : 0|8@1+ (1,0) [0|255] "" BMS_PlugIn,Motor_MED17_SIMOS8_PlugIn_PAG_PF
SG_ HVLM_01_BZ : 8|4@1+ (1,0) [0|15] "" BMS_PlugIn,Motor_MED17_SIMOS8_PlugIn_PAG_PF
SG_ HVLM_Charging plug error : 12|1@1+ (1,0) [0|1] "" Vector__XXX
SG_ HVLM error
Locking : 13|1@1+ (1,0) [0|1] "" Vector__XXX
SG_ HVLM_Target current_HV_Offset : 14|1@1+ (1,0) [0|1] "" Vector__XXX
SG_ HVLM_Ist current : 17|9@1+ (1,-255) [-255|254] "Unit_Amper" Motor_MED17_SIMOS8_PlugIn_PAG_PF
SG_ HVLM_Ist mode_02 : 26|2@1+ (1,0) [0|3] "" Motor_MED17_SIMOS8_PlugIn_PAG_PF
SG_ HVLM conditioning request : 28|1@1+ (1,0) [0|1] "" Motor_MED17_SIMOS8_PlugIn_PAG_PF
SG_ HVLM_charging request : 29|3@1+ (1,0) [0|7] "" Motor_MED17_SIMOS8_PlugIn_PAG_PF
SG_ HVLM Plug Status : 32|2@1+ (1,0) [0|3] "" BMS_PlugIn,Motor_MED17_SIMOS8_PlugIn_PAG_PF
SG_ HVLM Target Current HV : 34|10@1+ (0.2,-102) [-102|102.2] "Unit_Amper" Vector__XXX
SG_ HVLM_MaxVoltage_HV : 44|10@1+ (1,0) [0|1021] "Unit_Volt" Vector__XXX

[Mitchy]

DBC file addresses are in Decimal
so the 1382 is 566 in hex

Depending on the type board you have, you'll likely need to adjust the CAN send/receive function to one suitable for whatever STM32 chip is on it, but other than that, Damien's code should port right over if you use Ardunio for stm32.

[RetroZero]

Question regarding the charger needing to see BMS voltage value.......i don't have a BMS yet, so would I need to configure my prius adapter board for comms over CAN and then somehow get the charger to see the DC Bus voltage?

[Mitchy]

When testing on the bench, you can just mirror back the same value as the charger sends out as its output voltage.
So in the sequence, if charging is active, Damien's code has it that the charger HV Voltage reading is sent back to the charger as the BMSvolts. (Scaling is different, hence the *4.

Code: Select all

BMSVolts=(charger_status.HVVoltage)*4;

Of course when implemented in a vehicle, this will need to be actual BMS volts, but for bench testing, the hack works great.
Its likely possible you can lean on a similar method when in the vehicle, but it's a good safeguard to cross check the voltage at another device.

[RetroZero]

Seems the Nucleo board I have is THE ONE that is not supported by arduino. I get an error when compiling Researching alternatives... Teensy 4.1 comes at a price.

[RetroZero]

I have a Nucleo-F334R8 board that will not even upload a test blinking LED through Arduino .
@mitchy, i assume you uploaded the sketch on your Teensy using Arduino?

[Mitchy]

You'll need to use Damien's sketch for the charger version you have, I'm pretty sure the version you have would be considered the same as what damien proved out.
I think he had it written for a Arduino due, but you could likely use even a ESP32.
the major difference is just how it sends the canbus data. if using the ESP32, you'll just use the TWAI interface, along with one of the canbus transceiver chips.
One library you may be able to use is: https://github.com/handmade0octopus/ESP32-TWAI-CAN This should use similar references to the canbus messages as what due_can library which Damien used.
It'll take a bit more porting, but it's possible without too much modification.
(You'll need to delete the duetimer library, and any reference to CAN1)


For the MLBevo charger sketch, I used a Teensy 4 with the Flexcan_t4 library.
I did something similar, Used Damien's framework, ported to the Teensy, and just kept adding what was needed for the added signals.

[RetroZero]

Thanks for the info. Code and everything software related is out of my knowledge base. Thanks to Claude AI, I'm limping about and discovering.
This is not how I would like to continue. I've wasted weeks trying so many different permutations, but the options are limited (along with the budget).Boards, laptops, wifi extenders, Arduino and STM IDE along with VCDS have all had me bashing my head against a wall .
I do believe these chargers are well worth the while to get to a viable 'plug and play ' stage, so I'll chug along.....
Maybe an arduino due is what I need to simplify things...
I have a ESP32S3 Pico. I'll see if its compatible in Arduino, but doubt it.
The Nucleo got as far as Uploading the sketch, but then there was an error message during Debug. That took me 2 weeks where I had 2 full days trying different installs/un-installs etc etc.

Edit - doing some researching, the Arduino Uno would be a good contender no? All we're trying to do is interface between the charger and a control unit that receives and sends CAN messages?

[evMacGyver]

Is anyone familiar with VAG parts, cooling connections are Normaquick NW12 which is not so easy to find. VAG might have part number to connector by itself or hose with connector for sure. Maybe I haven't found good spare part diagram to find part number.

[RetroZero]

The connector is part of the hose. I have found damaged hoses and recuperated the connectors and fitted hose clamps.