11KW MLBevo charger group hack 5QE915684BJ possible

[LRBen]

Thought I would make a new thread dedicated to the number of chargers sent out by Lars recently, then we can keep the main charger threads a little clearer.

They are 11kw chargers, possibly "5QE915684BJ", these particular units seem to come from a StreetScooter stock. It is unknown if there are any differences between these and the stock chargers in terms of coding.

I have mine on the bench. Currently powers up for 10 seconds then goes back to sleep. With application of x570 DLC8 0xFF 0x00 0x00 0x00 0x00 0x00 0x00 on PT CAN at 1 sec intervals I get the following messages in response.

0x611
0x612
0x613
0x614
0x1B000044

Then charger then still goes to back to sleep. This wake up call is the same as the Seat Mii Charger that Damien had.

I have tried to hook up ODIS software using a mongoose adaptor as per the previous thread but had not reponse. Annoyingly my PIWIS vm is lagging out at the moment so I haven't been able to try the PIWIS software on it which worked with my Cayenne Charger.

I also need to get another canbus sniffer so I can read the hybrid can a the same time as the PT can. Will work on that this weekend.

[LRBen]

Little bit further today on the hybrid can also with a socket setup as well. This time focusing on hybrid can.

Charger wakes up when an EVSE is plugged in or taken out. With the application of the Charger workout script that Mitchy write on the hybrid can I get the same messages on hybrid can as was on the PT can above.
Working with TomDB yesterday on the Cayenne charger we found that 0x1B000044 contains a car wake up message, so that makes sense.

Charger still goes back to sleep and doesn't send out any useful data on the can such as EVSE amps etc. So as expected I think there needs to be some coding done on this to get it working stand alone.

I tried again with ODIS with no success, so I am going to assume this is from a Taycan and will need PIWIS in order to code it. So I'll focus now on getting that working.

Once it is I think it will work the same way as the Cayenne charger, so the module Im writing for Zombie to run the Cayenne charger should run these as well.

[LRBen]

Ok have some sort of communication with ODIS. However it doesn't recognise it as a known variant.

image.png (9.1 KiB) Viewed 1167 times

With this my Mongoose is sending the following can ids:

The charger then replies with the usual can ids as above. This is on the hybrid can. Charger doesn't go to sleep with these IDs sending.

[Jacobsmess]

Sorry I'm not much help here, I'm busy with other aspects of the project and I'm still learning a lot about how to interface with canbus. If there is anything I can help with I'm happy to however. Otherwise, I'm watching from the sidelines in great anticipation and awe.

[LRBen]

Last night I managed to get my PIWIS vm to behave, unfortunately it doesn't have support for the Taycan on it so I couldn't connect with that.
Might have hit a little bit of a wall with that until I can find a more up to date PIWIS version.
I will keep messing with both ODIS and PIWIS for now though.

If there is anything I can help with I'm happy to however.

Will be good to have another charger to test with once we work out a (hopefully) easily repeatable process to code these.

[uhi22]

You could try to read the coding data with uds service hex 22 06 00. Does the ODIS show the coding data and maybe parametrization date? Does it show identification data like part number, software version?

[LRBen]

You could try to read the coding data with uds service hex 22 06 00

I think I managed to figure out sending that in ODIS, here is the response.

I can't get much from ODIS at all, it can connect and pull some data, but nothing like coding parameters etc.

[uhi22]

This means: the response of the "read coding 22 0600" is 6 bytes with value zero. Nothing coded. We either need a description, which is the meaning of each coding byte, or to read out a correctly coded unit, or, in worst case, just write random bits and see what happens.
Writing of the coding should be possible with "write data by identifier", in this case 2E 06 00 112233445566. Most likely needs some preconditions like extended session, security access and writing the workshop code.

[Aragorn]

Mitchys thread has the coding details already does it not?

viewtopic.php?t=3529

[uhi22]

To sort it a little bit better: Which part number and which vehicle type we are talking here? The headline says MEB, but I also read "Taycan" which is MLBevo, not MEB, afaik.

[crasbe]

From the numbers and description in the Wiki it looks very much like a "5QE915684BJ", but these particular units seem to come from a StreetScooter stock: viewtopic.php?p=66858#p66858

I'm not sure if they had a custom software or not for the StreetScooters, but since they seem to react to the same CAN IDs, it doesn't seem that way.

[Aragorn]

To sort it a little bit better: Which part number and which vehicle type we are talking here? The headline says MEB, but I also read "Taycan" which is MLBevo, not MEB, afaik.

MEB is ID3/ID4/Enyaq etc, i dont think i've seen any work at all on those chargers.

Folks seem to be calling the older eGolf and associated hybrids "MEB", but those arent MEB, they are MQB.

[uhi22]

To find out what we are talking about, it could help to read some identification data from the unit,
22 F187: spare part number
22 F189: software version number
22 F191: spare part number of the hardware
22 F19E: identification for the diagnostic data base
22 F1A2: the version of the above
22 F1A3: hardware version number

[uhi22]

Mitchys thread has the coding details already does it not?

viewtopic.php?t=3529

In viewtopic.php?p=55623#p55623 he lists 8 bytes coding information, but here we have only 6 bytes in the response 2E 0600. So there seem to be differences.

[Edit] A six-byte-coding is also mentioned here: https://www.goingelectric.de/wiki/Codie ... passungen/ for Adr BD 12E 915 022 AB, where they change the max current for charging from 16A to 32A. It could be worth a try to use the coding data which is mentioned there.

[LRBen]

**duplicate post**

[LRBen]

Sorry for the confusion on part names etc. Updated the first post to be more specific. I just call everything VAG related on the charger and battery front MEB at the moment, which doesn't help.

I'll get that data from the charger tonight and report back.

[LRBen]

image.png (10.62 KiB) Viewed 870 times

image.png (2.13 KiB) Viewed 870 times

Not allot of data coming from it.

[LRBen]

I also sent out the hex to change single phase charging to 32AMP and got the following reply

image.png (10.82 KiB) Viewed 868 times

[uhi22]

Funny. These responses are definitely not from an official control unit of the VW group. Because: Sending "empty" responses for the basic identification data is a no-go. They normally spending a lot of effort to get each of these responses correctly filled, and if the service would not be supported, the control unit would need to send a negative response. But here we see positive responses, with just zero bytes. This looks like the manufacturer just took a VW group software, kicked out some content, but did not care for the now "unused" diagnostic services. With the data what we see, also ODIS/PIWIS I guess have no chance to see anything.

Regarding writing the coding string: You got a negative response. 7F means "negative response", for service "CA", with the negative response code 0x11, which is "Service not supported" (a list is available e.g. here: https://piembsystech.com/negative-respo ... -protocol/) This is normal, because the request was not like intended. The "CA 0D 04 04 00 00" is the coding data itself. To write it to the control unit, we need to use the command "write data by identifier", which is 2E, followed by the identifier for coding, which is usually 0600. So the complete PDU for writing the coding would be
2E 06 00 CA 0D 04 04 00 00
This normally (in the VW world) would return a negative response code like "service not supported in active session" or "security access denied" or "request sequence error". Let's see, what they kept from the original software...

[Edit] At least the software version is reported as 39 30 30 35, which is "9005".

[LRBen]

image.png (10.31 KiB) Viewed 852 times

Also after further messing around with ODIS I can send code strings to the charger on the usual coding window

image.png (11.18 KiB) Viewed 852 times

data in here will successfully be coded to the charger, well it looks like it works at least. However it is different to the other MLBevo chargers as we have previous seen in that it uses 6 bytes and not 8. So I cant send the same coding line as per the other threads.

[uhi22]

And if you write any coding data, does it show up when you afterwards read it back using 22 06 00? Also after power-cycle? This would be a good sign, that the charger accepts and stores the coding data.

[Edit] The 7F 2E 7F means "negative response, the service writeDataByIdentifier is not supported in active session". This perfectly makes sense, because normally at least the extended session is needed to write anything. When coding via the normal ODIS way, the ODIS cares for the session (and tester present), so even better.

[LRBen]

And if you write any coding data, does it show up when you afterwards read it back using 22 06 00? Also after power-cycle? This would be a good sign, that the charger accepts and stores the coding data.

Unfortunately not, seems to read blank again after coding.

[uhi22]

Maybe the ODIS does not even correctly write anything. A CAN log of the coding activities would be nice.
And maybe also the coding identifier (22 0600) is also only a "dummy" like the others, and the "real coding" is done on a completely different way.

[Edit] And a completely different approach: If the chargers are from Streetscooter, maybe they are so kind to provide the specification. According to https://de.wikipedia.org/wiki/Streetscooter the company is back at his original founder, a professor of RWTH Aachen, and he seems to be a fan of sustainability. So with the argument "we want to use the chargers for a second life" maybe he could organize the necessary data. This is the contact: https://guenther-schuh.com/de/kontakt/

[LRBen]

Attached is a canlog of the coding process.

I was also thinking of just asking Street scooter as well. Costs nothing to ask.

[LRBen]

I also wonder if they might simply work with the right canbus messages. Given it's a much smaller company using them, and the background firmware is a bit sparse, maybe it requires far less information to work than the VAG variants.

I emailed Street Scooter directly tonight, lets see what they say.