VW Mild Hybrid Starter Alternator

bananaman · Post by **bananaman** » Sat Sep 06, 2025 9:19 pm

This should be every signal it extracts for what I'm calling the "main handler" (nr 3 in the table I posted earlier). These have not yet been double-checked so maybe there are mistakes.
Other messages are handled by different handlers with much more logic.

I cross-referenced with the vw_mqb.dbc and the dbc files posted here: viewtopic.php?t=3152
I've added naming and comments from the .dbc files with translations where possible.
Some signals are out of order.
I also attach a .dbc file with these signals.
The vw_mqb.dbc and MLBEvo .dbc files have more signals for some messages, but these are ignored by the BSG.

0x40:
- 40_CHECKSUM: start 0, length 8. Checksum.
- 40_COUNTER: start 8, length 4. Sequence counter.
- 40_signal1: start 42, length 3. "AB_Deaktivierung_HV" "Deaktivierung des HV-Systems und der HV-Teilnehmer im Crash (u.a. Hybrid- und Elektrofahrzeuge)" Deactivation of the HV system and the HV participants in the event of a crash: 0 = OK, 1–6 = deactivation, 7 = fault.

0xA8:
- A8_signal1: start 48, length 16. "MO_Drehzahl_01" Engine speed.

0xEE:
- EE_signal1: start 54, length 10. Not found in DBC.

0xFD:
- FD_signal1: start 32, length 16. "ESP_v_Signal" Vehicle speed.

0x151:
- 151_signal1: start 12, length 4. Not found in DBC.
- 151_signal2: start 48, length 8. Not found in DBC.
- 151_signal3: start 31, length 12. Not found in DBC.
- 151_signal4: start 56, length 7. Not found in DBC.
- 151_CHECKSUM: start 0, length 8. Checksum.
- 151_COUNTER: start 8, length 4. Sequence counter.

0x152:
- 152_signal1: start 12, length 11. Not found in DBC.
- 152_signal2: start 23, length 11. Not found in DBC.
- 152_signal3: start 34, length 4. Not found in DBC.
- 152_signal4: start 40, length 16. Not found in DBC.
- 152_signal5: start 56, length 8. Not found in DBC.
- 152_CHECKSUM: start 0, length 8. Checksum.
- 152_COUNTER: start 8, length 4. Sequence counter.

0x18D:
- 18D_signal1: start 24, length 8. "BMS_MV_IstSpannung" - "actual voltage of the battery / Momentanwert: Batteriespannung" Actual battery voltage.

0x3A3:
- 3A3_signal1: start 16, length 10. "MVEM_IstStrom_MVVerbraucher" Actual current MV consumers.
- 3A3_signal2: start 56, length 8. "MVEM_EMG_MaxGenSpannung" "max. Spannung des 48V-RSG im generatorischen Betrieb" Max. voltage of the 48V BSG in generator mode.

0x3C0:
- 3C0_signal1: start 17, length 1. "ZAS_Kl_15" Ignition on.
- 3C0_signal2: start 19, length 1. "ZAS_Kl_50" Starter on.

0x504:
- 504_signal1: start 33, length 1. "MV_Bordnetz_aktiv" "Signalisiert ein aktives MV-Bordnetz. MV-Schütze geschlossen. Im Fehlerfall wird das Bit nicht gesetzt.(Klemmende Schütze)" Signals an active MV on-board network. MV contactors closed. In the event of a fault, the bit is not set. (Stuck contactors).

0x585:
- 585_signal1: start 10, length 1. "SI_NWDF" "Netzwerk-Diagnose Freigebe zur zentralen Aktivierung der Netzwerkdiagnose" Network diagnostics. Release for central activation of network diagnostics.
- 585_signal2: start 11, length 1. "SI_NWDF_gueltig" "Gültigkeitsbit zu SI_NWDF gemäß Lastenheft: Zentrale Aktivierung Netzwerkdiagnose" Validity bit for SI_NWDF according to specifications: Central activation of network diagnostics.

0x641:
- 641_signal1: start 14, length 2. "MO_Hybridfahrzeug" Hybrid vehicle flag/type?
- 641_signal2: start 57, length 2. "MO_Abgastyp_EOBD" "Abgastyp OBD" Exhaust type OBD.
- 641_signal3: start 36, length 4. "MO_Kraftstoffart" "Primärkraftstoff zum Antrieb des Fahrzeugs" Primary fuel for powering the vehicle.
- 641_signal4: start 32, length 4. "MO_Anzahl_Zyl" "Zylinderzahl des Verbrennungsmotors" Number of cylinders.

0x6B2:
- 6B2_signal1: start 0, length 8. "DGN_Verlernzaehler" "wrap around 254 --> 0" Reset counter?
- 6B2_signal2: start 8, length 20. "KBI_Kilometerstand" Odometer reading.
- 6B2_signal3: start 28, length 7. "UH_Jahr" Year.
- 6B2_signal4: start 35, length 4. "UH_Monat" Month.
- 6B2_signal5: start 39, length 5. "UH_Tag" "0x0: reserviert bei VW" Day (0x0 reserved at VW).
- 6B2_signal6: start 44, length 5. "UH_Stunde" "0x18 - 0x1F = Werte ungültig" Hour (0x18–0x1F invalid).
- 6B2_signal7: start 49, length 6. "UH_Minute" "0x3C- 0x3f = Werte ungültig" Minutes (0x3C–0x3F invalid).
- 6B2_signal8: start 55, length 6. "UH_Sekunde" "0x3C- 0x3f = Werte ungültig" Seconds (0x3C–0x3F invalid).

0x1A555480 (extended ID):
- 1A555480_signal1: start 32, length 8. "MVEM_Umax_Rueckspeisung" "Systeme, die rückspeisefähig sind, müssen vor Erreichen der oberen Spannungsgrenze ihren Leistungsbedarf dynamisch abregeln" Systems that are capable of regenerating energy must dynamically regulate their power requirements before the upper voltage limit is reached.
- 1A555480_signal2: start 40, length 8. "MVEM_Umin_Funktionsgruppe_C" "Systeme der Funktionsgruppe C müssen bei Unterschreitung der Spannungsgrenze ihren Leistungsbedarf dynamisch abregeln." Systems in functional group C must dynamically reduce their power requirements when the voltage falls below the limit.
- 1A555480_signal3: start 48, length 8. "MVEM_Umin_Funktionsgruppe_B" "Systeme der Funktionsgruppe B müssen bei Unterschreitung der Spannungsgrenze ihren Leistungsbedarf dynamisch abregeln." Systems in functional group B must dynamically reduce their power requirements when the voltage falls below the limit.

squidopolis · Post by **squidopolis** » Mon Jan 19, 2026 5:27 am

Got this working, below is my python script:

#send_msg
# The CANlib library is initialized when the canlib module is imported. To be
# able to send a message, Frame also needs to be installed.
from canlib import canlib, Frame
import time

#CAN
ch_a = canlib.openChannel(channel=0)
ch_a.setBusParams(canlib.canBITRATE_500K)
ch_a.busOn()

#IGNITION MSG
IGN_counter = 0
IGN_DLC = 4
IGN_data_array = bytearray(4)
IGN_MSG_ID = (0x03C0 & 0xFFFF)

#MSG_EMG_01 MSG
EMG_01_counter = 0
EMG_01_DLC = 8
EMG_01_data_array = bytearray(8)

EMG_01_MSG_ID = (0x0151 & 0xFFFF)
MO_EMG_OperationModeReq = ( 1& 0xF)
MO_EMG_SpeedReq = (2048&0x7FFF)
MO_EMG_MaxTorqueGradient = (0x01&0x7F)
MO_EMG_Clamp15 = 1
MO_EMG_Deactivate_HV = 1

MO_EMG_MaxVoltage = (4&0xFF)

#MSG EMG_02 MSG
EMG_02_counter = 4
EMG_02_DLC = 8
EMG_02_data_array = bytearray(8)
EMG_02_MSG_ID = (0x0152 & 0xFFFF)

MO_EMG_MaxCurrent = (1027&0x7FF)
MO_EMG_MinCurrent = (1023&0x7FF)
MO_EMG_MinVoltage = (106&0xFF)
MO_EMG_TorqueReq = (32781&0xFFFF)

#Constant Bytes

# VAG MB 0 1 2 3 4 5 6 7 8 9 A B C D E F
MB0151 = bytearray([ 0x42, 0x7E, 0xB4, 0x01, 0x0A, 0x91, 0xDF, 0x10, 0xA1, 0x73, 0x59, 0x05, 0xF6, 0x79, 0x0B, 0xDE])
MB0152 = bytearray([ 0x58, 0x61, 0xCF, 0x30, 0x69, 0x6A, 0xC4, 0xC6, 0xB2, 0x53, 0x22, 0xB6, 0xEC, 0x95, 0xCA, 0xF8])
MB03C0 = bytearray([ 0xC3, 0xC3, 0xC3, 0xC3, 0xC3, 0xC3, 0xC3, 0xC3, 0xC3, 0xC3, 0xC3, 0xC3, 0xC3, 0xC3, 0xC3, 0xC3])

#Calculate the CRC checksum for VAG CAN Messages
def vw_crc_calc(byte_array: bytearray, DLC: byte, MSG_ID: int):
poly = 0x2F
xor_output = 0xFF
crc = 0XFF
magic_byte = 0x00
counter = byte_array[1]&0x0F

if MSG_ID == 0x151:
magic_byte = MB0151[counter]
elif MSG_ID == 0x152:
magic_byte = MB0152[counter]
elif MSG_ID == 0x3C0:
magic_byte = MB03C0[counter]

for i in range(1, DLC + 1):
if i<DLC:
crc ^= byte_array;
else:
crc ^= magic_byte;

for j in range(8):
if (crc&0x80):
crc = (crc << 1) ^ poly
else:
crc = (crc << 1);

crc ^= xor_output;
byte_array[0] = crc&0xFF

# Send command messages ~1ms for ~10seconds
for i in range(50000):

#load Ignition Frame
IGN_counter += 1
if IGN_counter>0xF:
IGN_counter = 0
#Load Data (Constant 0x23 Value)
IGN_data_array[1]=IGN_counter&0xF
IGN_data_array[2] = 0x2
#IGN_data_array[3] = 0x03
#Modify CRC byte[0]
vw_crc_calc(IGN_data_array, IGN_DLC, IGN_MSG_ID)
#Send Igniton CAN FRAME
frame = Frame(IGN_MSG_ID, IGN_data_array, flags=canlib.MessageFlag.STD )
ch_a.write(frame)

#load EMG_01 Frame
EMG_01_counter += 1
if EMG_01_counter>0xF:
EMG_01_counter = 0
#load Data
EMG_01_data_array[1]=((MO_EMG_OperationModeReq<<4)&0xF0)+(EMG_01_counter&0xF)
EMG_01_data_array[2]=(MO_EMG_SpeedReq&0xFF)
#EMG_01_data_array[3]=((MO_EMG_SpeedReq>>8)&0x7F)+((MO_EMG_Clamp15<<7)&0x80)
#EMG_01_data_array[4]= ((MO_EMG_Deactivate_HV<<2)&0x1C)
EMG_01_data_array[4]=0xFF;
EMG_01_data_array[5]=0x01;
#EMG_01_data_array[4]= 0x26;
#EMG_01_data_array[5]= (MO_EMG_MaxVoltage&0x1)
#=

EMG_01_data_array[7]=(MO_EMG_MaxTorqueGradient&0x7F)
#Modify CRC byte[0]
vw_crc_calc(EMG_01_data_array, EMG_01_DLC, EMG_01_MSG_ID)
#Send EMG 01 CAN FRAME
frame = Frame(EMG_01_MSG_ID, EMG_01_data_array, flags=canlib.MessageFlag.STD )
ch_a.write(frame)

#load EMG_02 Frame
EMG_02_counter += 1
if EMG_02_counter>0xF:
EMG_02_counter = 0
#load Data
EMG_02_data_array[1] = ((MO_EMG_MaxCurrent<<4)&0xF0)+(EMG_02_counter&0xF)
EMG_02_data_array[2] = ((MO_EMG_MaxCurrent>>4)&0x7F)+((MO_EMG_MinCurrent<<7)&0x80)
EMG_02_data_array[3] = ((MO_EMG_MinCurrent>>1)&0xFF)
# EMG_02_data_array[4] = ((MO_EMG_MinCurrent>>9)&0x3)
EMG_02_data_array[4] = 0x3D
EMG_02_data_array[5] = (MO_EMG_TorqueReq&0xFF)
EMG_02_data_array[6] = ((MO_EMG_TorqueReq>>8)&0xFF)
EMG_02_data_array[7] = (MO_EMG_MinVoltage&0xFF)
#Modify CRC byte[0]
vw_crc_calc(EMG_02_data_array, EMG_02_DLC, EMG_02_MSG_ID)
#Send EMG 01 CAN FRAME
frame = Frame(EMG_02_MSG_ID, EMG_02_data_array, flags=canlib.MessageFlag.STD )
ch_a.write(frame)

#Constants
B000_const = bytearray ([0x76,0x40,0x01,0x05,0x02,0x00,0x00,0x00])
frame = Frame(0x1B000076, B000_const, flags=canlib.MessageFlag.EXT)
ch_a.write(frame)

B504_const = bytearray ([0xC4,0x09,0x00,0x00,0x26,0x19,0x14,0x51])
frame = Frame(0x504, B504_const, flags=canlib.MessageFlag.STD )
ch_a.write(frame)

B3A3_const = bytearray ([0x17,0x9C,0xFB,0x41,0x42,0x3F,0xFE,0xCC])
frame = Frame(0x3A3, B3A3_const, flags=canlib.MessageFlag.STD )
ch_a.write(frame)

B18B_const = bytearray ([0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00])
frame = Frame(0x18B, B18B_const, flags=canlib.MessageFlag.STD )
ch_a.write(frame)

B18D_const = bytearray ([0x00,0xF0,0x7F,0xC1,0x00,0x80,0x26,0x2])
frame = Frame(0x18D, B18D_const, flags=canlib.MessageFlag.STD )
ch_a.write(frame)

B171_const = bytearray ([0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00])
frame = Frame(0x171, B171_const, flags=canlib.MessageFlag.STD )
ch_a.write(frame)

BEE_const = bytearray ([0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00])
frame = Frame(0xEE, BEE_const, flags=canlib.MessageFlag.STD )
ch_a.write(frame)

if i % 2 == 0:
B040_const = bytearray ([0x07,0x0E,0x00,0x00,0x80,0x00,0x20,0x62])
frame = Frame(0x040, B040_const, flags=canlib.MessageFlag.STD )
ch_a.write(frame)
else:
B040_const = bytearray ([0x4B,0x0F,0x00,0x00,0x80,0x00,0x20,0x64])
frame = Frame(0x040, B040_const, flags=canlib.MessageFlag.STD )
ch_a.write(frame)

if i % 2 == 0:
B0FD_const = bytearray ([0x23,0xE0,0x3F,0x00,0x00,0x00,0x00,0x00])
frame = Frame(0x0FD, B0FD_const, flags=canlib.MessageFlag.STD )
ch_a.write(frame)
else:
B0FD_const = bytearray ([0x29,0xE1,0x3F,0x00,0x00,0x00,0x00,0x00])
frame = Frame(0x0FD, B0FD_const, flags=canlib.MessageFlag.STD )
ch_a.write(frame)

B0A8_const = bytearray ([0x00,0xE0,0x3F,0x57,0x7F,0x64,0x00,0x00])
frame = Frame(0x0A8, B0A8_const, flags=canlib.MessageFlag.STD )
ch_a.write(frame)

# Example: print first 5 rows of data
#print(f"{msgID_INT:04x}: ,{d0_INT:04x},{d1_INT:04x},{d2_INT:04x},{d3_INT:04x},{d4_INT:04x},{d5_INT:04x},{d6_INT:04x},{d7_INT:04x}")
#print(i)
time.sleep(0.01)

# Lastly, close all channels with close() to finish up.
ch_a.close()
#ch_b.close()

CuriousCat · Post by **CuriousCat** » Thu Feb 12, 2026 11:16 am

Hello everyone,

I hope some people are still around on this subject, I've got myself into reusing on of these iBSG alternators from Valeo as the main motor for a small EV.
I've got my hand on a 415005 / IBSG4W025 starter-alternator from Valeo (official product link : https://www.valeoservice.com/en-com/tec ... country=DE). The package seems to say that this was mounted on a MHEV Jaguar XE X760 1.5.

I've also found a DBC shared on this blog which seems to be used on a university project on a very similar motor : https://openinverter.org/forum/viewtopic.php?t=6549. (The DBC can be found here : https://github.com/hgrasman/toucan/blob ... Client.dbc)

I've managed (I think) to decrypt the DBC and reverse engineer some ways to construct the right frames to control the motor but I'm struggling to make sense of the values it is sending me back and I'm stuck with a bunch of CAN frames, some values that I think I'm decrypting correctly but I have nothing to make sure of it.

My current setup is made with PeakCAN adapters and I'm using custom written codes to try to discuss with it. I'm getting replies and I think I can modify some torque limits in the drive but I can't seem to find a way to make it really work.

Would someone would have some suggestions on how to handle this ? I can provide some code and stuff depending on what's useful.

Thanks in advance !

uhi22 · Post by **uhi22** » Thu Feb 12, 2026 7:05 pm

I only have a general thought. Usually the critial messages are secured by end-to-end (E2E) protection. This means, they contain a message counter and a CRC. The receiver checks that the counter counts in the expected cycle time, and that the CRC is correct. Sending two messages with wrong CRC usually leads to "Safe state permanent" which could mean: No movement until next sleep or ignition cycle.
So your sender code needs to consider this.

bananaman · Post by **bananaman** » Sun Feb 15, 2026 6:08 pm

CuriousCat wrote: ↑Thu Feb 12, 2026 11:16 am Hello everyone,

I hope some people are still around on this subject, I've got myself into reusing on of these iBSG alternators from Valeo as the main motor for a small EV.
I've got my hand on a 415005 / IBSG4W025 starter-alternator from Valeo (official product link : https://www.valeoservice.com/en-com/tec ... country=DE). The package seems to say that this was mounted on a MHEV Jaguar XE X760 1.5.

I've also found a DBC shared on this blog which seems to be used on a university project on a very similar motor : https://openinverter.org/forum/viewtopic.php?t=6549. (The DBC can be found here : https://github.com/hgrasman/toucan/blob ... Client.dbc)

I've managed (I think) to decrypt the DBC and reverse engineer some ways to construct the right frames to control the motor but I'm struggling to make sense of the values it is sending me back and I'm stuck with a bunch of CAN frames, some values that I think I'm decrypting correctly but I have nothing to make sure of it.

My current setup is made with PeakCAN adapters and I'm using custom written codes to try to discuss with it. I'm getting replies and I think I can modify some torque limits in the drive but I can't seem to find a way to make it really work.

Would someone would have some suggestions on how to handle this ? I can provide some code and stuff depending on what's useful.

Thanks in advance !

That's a great find! The same github repo seems to contain code to control the iBSG, you should be able to use this as a starting point. What programming language are you using?

uhi22 wrote: ↑Thu Feb 12, 2026 7:05 pm I only have a general thought. Usually the critial messages are secured by end-to-end (E2E) protection. This means, they contain a message counter and a CRC. The receiver checks that the counter counts in the expected cycle time, and that the CRC is correct. Sending two messages with wrong CRC usually leads to "Safe state permanent" which could mean: No movement until next sleep or ignition cycle.
So your sender code needs to consider this.

Yes, I looked quickly at the code in the linked github (only at the code related to torque command) and at least that one has a CRC.

CuriousCat · Post by **CuriousCat** » Wed Feb 18, 2026 7:59 am

Thanks to uhi22 and bananaman for your returns

So yes, the CRC has been implemented and I think it works (at least for some frames) as I can change torque limits in the motor. One difference with the code proposed by squidopolis is that theirs uses another "magic byte" to add another calculation on the CRC for some message IDs, which I don't have. This is still fine as I'm basing my approach on the DBC file found in the toucan project from the Git, and more than the DBC, there is a full Arduino project that uses the simple CRC as described in the initial DBC. (Hope this is clear)

bananaman : I'm using Python on my PC to control my PCAN-USB interfaces.

bananaman · Post by **bananaman** » Mon Feb 23, 2026 6:49 pm

CuriousCat wrote: ↑Wed Feb 18, 2026 7:59 am Thanks to uhi22 and bananaman for your returns

So yes, the CRC has been implemented and I think it works (at least for some frames) as I can change torque limits in the motor. One difference with the code proposed by squidopolis is that theirs uses another "magic byte" to add another calculation on the CRC for some message IDs, which I don't have. This is still fine as I'm basing my approach on the DBC file found in the toucan project from the Git, and more than the DBC, there is a full Arduino project that uses the simple CRC as described in the initial DBC. (Hope this is clear)

bananaman : I'm using Python on my PC to control my PCAN-USB interfaces.

Are you manually packing/unpacking the can messages? Or are you using the cantools library at all? What issues are you having exactly?
Can you maybe share your python code and a recording of the can data? For example from PCAN-view or with candump if you are on linux.

Adrianbb · Post by **Adrianbb** » Thu Feb 26, 2026 11:27 pm

Hello, I' m New here... I have working 4n0903028 unit and today i've tryed to spin it replaying log posted few pages before. Motor working as on the video that posted another user. But here I stopped...
I Can say that can adresses needed for motor spin are: 0x0EE, 0x151, 0x152, 0x3C0 and 0x504. Voltage in 48v side must be relative strong and within 40-52v. Over this values motor not start. With this conditions, motor after few attemps spin to really high revs and maybe reach some interval FW limits. Next attemp for spin can be done after resetting 12v supply. Maybe this Can help anyone.

CuriousCat · Post by **CuriousCat** » Fri Feb 27, 2026 5:35 pm

bananaman wrote: ↑Mon Feb 23, 2026 6:49 pm Are you manually packing/unpacking the can messages? Or are you using the cantools library at all? What issues are you having exactly?
Can you maybe share your python code and a recording of the can data? For example from PCAN-view or with candump if you are on linux.

I am manually encoding the messages but unpacking using cantools and the DBC. Here are my two python files for setting the parameters and packing them. (You can check the attachement)

For the recording, I'll have to do it again, looks like I've done too much cleaning in my files ...

The exact issue I have is that I'm sending a bunch of messages to the motor. The messages are explicitly declared in the encoder file shared. But I'm not getting any results : no spinning, the inverter doesn't seem to turn on HIGH side and the reply I get from the motor don't help me much.

The questions I have are :
- Am I sending the right messages ?
- Am I listening to the correct parameters ?
- Did I miss something about the messages or does the motor need more environment messages (such as BMS, motor ECU, ...) on the bus to turn on ?

bigmotherwhale · Post by **bigmotherwhale** » Fri Feb 27, 2026 8:00 pm

As its designed for being spun by the engine, try spinning it and see if it responds to a torque request? Or try "EngineStartTorque"?

Adrianbb · Post by **Adrianbb** » Fri Feb 27, 2026 10:30 pm

I may have thought of something stupid, but hasn't anyone thought about the alternative of using an openverter mini controller board instead of an oem MCU? Or if anyone has any other ideas...? Because from a realistic point of view, this playing with CAN won't hurt anyone, but it's a huge waste of time that no one will pay for or we can use it more effectively. If we want to use it as a compact motor with a regeneration function, then with a little skill, maybe we could use a lot of the original HW like gate drivers, encoder, current sensors... The power stage doesn't look completely useless, but maybe I'm wrong. And with a little luck, the compactness and functionality would be preserved with the benefit of easy control and some functions on top, such as the ability to operate at slightly higher voltage and current. Yes, I know, the 63V capacitor is the limit, and I don't know the current. No one has any idea what kind of oem transistors are used there.

If this is off-topic, I apologize

jrbe · Post by **jrbe** » Fri Feb 27, 2026 11:00 pm

Turn key vs lots of mods.

Adrianbb · Post by **Adrianbb** » Fri Feb 27, 2026 11:19 pm

I understand that. I'm more concerned with the use of this starter-generator. This discussion started five years ago. To this day, no one knows how to use it for purposes other than OEM. It's one thing to be able to test it on the bench, but we can't use it for what we want

jrbe · Post by **jrbe** » Sat Feb 28, 2026 12:16 am

Adrianbb wrote: ↑Fri Feb 27, 2026 11:19 pm I understand that. I'm more concerned with the use of this starter-generator. This discussion started five years ago. To this day, no one knows how to use it for purposes other than OEM. It's one thing to be able to test it on the bench, but we can't use it for what we want

I understand, but both directions are challenging. You're welcome to contribute to either route.

CuriousCat · Post by **CuriousCat** » Sat Feb 28, 2026 5:27 pm

bigmotherwhale wrote: ↑Fri Feb 27, 2026 8:00 pm As its designed for being spun by the engine, try spinning it and see if it responds to a torque request? Or try "EngineStartTorque"?

That's ... actually ... a good idea ... Yeah it is supposed to be spinning from the motor but it can also be used as a drive for electric only (I think, unsure about this). But worth exploring, thanks !

CuriousCat · Post by **CuriousCat** » Sat Feb 28, 2026 5:30 pm

Adrianbb wrote: ↑Fri Feb 27, 2026 10:30 pm I may have thought of something stupid, but hasn't anyone thought about the alternative of using an openverter mini controller board instead of an oem MCU? Or if anyone has any other ideas...? Because from a realistic point of view, this playing with CAN won't hurt anyone, but it's a huge waste of time that no one will pay for or we can use it more effectively. If we want to use it as a compact motor with a regeneration function, then with a little skill, maybe we could use a lot of the original HW like gate drivers, encoder, current sensors... The power stage doesn't look completely useless, but maybe I'm wrong. And with a little luck, the compactness and functionality would be preserved with the benefit of easy control and some functions on top, such as the ability to operate at slightly higher voltage and current. Yes, I know, the 63V capacitor is the limit, and I don't know the current. No one has any idea what kind of oem transistors are used there.

If this is off-topic, I apologize

I'm certainly not an expert on this but I've explored the possibility to remove the electronics. I don't think you can replace part of the electronics as the MCU as everything is mounted on a PCB and is drowned in epoxy/gel stuff to keep it waterproof. You would have to reverse engineer the PCB and make patches to use the transistors so not worth at all. But you could remove all the electronics and pair the motor part with an external inverter but you would have to find all the motor characteristics and probably add an encoder so lots of work but interesting.

Adrianbb · Post by **Adrianbb** » Sat Feb 28, 2026 6:15 pm

I had some time today, so I looked at the board. I think the processor could be replaced... I unsoldered the processor and measured the functionality of the drivers, current sensors and encoder. More later

bananaman · Post by **bananaman** » Sun Mar 01, 2026 2:16 am

CuriousCat wrote: ↑Fri Feb 27, 2026 5:35 pm I am manually encoding the messages but unpacking using cantools and the DBC. Here are my two python files for setting the parameters and packing them. (You can check the attachement)

For the recording, I'll have to do it again, looks like I've done too much cleaning in my files ...

The exact issue I have is that I'm sending a bunch of messages to the motor. The messages are explicitly declared in the encoder file shared. But I'm not getting any results : no spinning, the inverter doesn't seem to turn on HIGH side and the reply I get from the motor don't help me much.

The questions I have are :
- Am I sending the right messages ?
- Am I listening to the correct parameters ?
- Did I miss something about the messages or does the motor need more environment messages (such as BMS, motor ECU, ...) on the bus to turn on ?

The firmware on the github looks like it's for an ESP32 with MCP2515 CAN transceivers. I'm going to try running it and comparing the CAN messages with ones I get from your code. It will likely take a few days though.

bananaman · Post by **bananaman** » Sun Mar 01, 2026 2:28 am

Adrianbb wrote: ↑Fri Feb 27, 2026 10:30 pm I may have thought of something stupid, but hasn't anyone thought about the alternative of using an openverter mini controller board instead of an oem MCU? Or if anyone has any other ideas...? Because from a realistic point of view, this playing with CAN won't hurt anyone, but it's a huge waste of time that no one will pay for or we can use it more effectively. If we want to use it as a compact motor with a regeneration function, then with a little skill, maybe we could use a lot of the original HW like gate drivers, encoder, current sensors... The power stage doesn't look completely useless, but maybe I'm wrong. And with a little luck, the compactness and functionality would be preserved with the benefit of easy control and some functions on top, such as the ability to operate at slightly higher voltage and current. Yes, I know, the 63V capacitor is the limit, and I don't know the current. No one has any idea what kind of oem transistors are used there.

If this is off-topic, I apologize

That's indeed another valid approach, just replacing the whole board may be easier than replacing the processor though. I was also wondering if it would be possible to flash custom firmware on the stock board. I could not really find any open source motor controller projects that support AC induction motors though. I was looking at the VESC and found this: https://vesc-project.com/node/872 but have not looked at it further.

Adrianbb wrote: ↑Sat Feb 28, 2026 6:15 pm I had some time today, so I looked at the board. I think the processor could be replaced... I unsoldered the processor and measured the functionality of the drivers, current sensors and encoder. More later

audi startergenerator.jpg

It may be interesting to also keep track of which pins on the processor those connect to. You should be able to find the datasheet with pinout by searching SPC564A70L7

bigmotherwhale · Post by **bigmotherwhale** » Sun Mar 01, 2026 3:14 pm

CuriousCat wrote: ↑Sat Feb 28, 2026 5:27 pm That's ... actually ... a good idea ... Yeah it is supposed to be spinning from the motor but it can also be used as a drive for electric only (I think, unsure about this). But worth exploring, thanks !

I can see "enginestarttorque" used in the code that i briefly looked at, i was considering the possibility they use this to get it moving before using a torque request.

bigmotherwhale · Post by **bigmotherwhale** » Sun Mar 01, 2026 3:20 pm

Adrianbb wrote: ↑Sat Feb 28, 2026 6:15 pm I had some time today, so I looked at the board. I think the processor could be replaced... I unsoldered the processor and measured the functionality of the drivers, current sensors and encoder. More later

audi startergenerator.jpg

Many of these are dying because the mosfet stage fails, if your replacing the mosfets and the controller it might be better to start with an external controller, Keely induction motor controllers would probably run this motor with the addition of only an encoder.

bananaman · Post by **bananaman** » Mon Mar 02, 2026 7:42 am

CuriousCat wrote: ↑Fri Feb 27, 2026 5:35 pm I am manually encoding the messages but unpacking using cantools and the DBC. Here are my two python files for setting the parameters and packing them. (You can check the attachement)

For the recording, I'll have to do it again, looks like I've done too much cleaning in my files ...

The exact issue I have is that I'm sending a bunch of messages to the motor. The messages are explicitly declared in the encoder file shared. But I'm not getting any results : no spinning, the inverter doesn't seem to turn on HIGH side and the reply I get from the motor don't help me much.

The questions I have are :
- Am I sending the right messages ?
- Am I listening to the correct parameters ?
- Did I miss something about the messages or does the motor need more environment messages (such as BMS, motor ECU, ...) on the bus to turn on ?

bananaman wrote: ↑Sun Mar 01, 2026 2:16 am The firmware on the github looks like it's for an ESP32 with MCP2515 CAN transceivers. I'm going to try running it and comparing the CAN messages with ones I get from your code. It will likely take a few days though.

Quick update, I tried building the code from the github on PC and comparing the data I get with PrepareFHybrid (C++) and your prepare_pcm_pmz_f_hybrid (Python). I also made Python bindings from the C++ code and used them in Python (ValeoExt). I get this (with 0 for every signal):

Code: Select all

C++     : 5f 00 00 00 3f fe 3f fe
Python  : 8b 00 00 1f ff 3f ff 00
ValeoExt: 5f 00 00 00 3f fe 3f fe

You can see that the C++ code and bindigns match (as I would expect), but your Python code is different.
Checking with different signal values and looking at which parts change, it looks like there is something wrong with your Python code as signals end up in the wrong "spots".

I have not tried other messages yet.

If you want to visualize where signals should end up in the payload, you can use this online DBC editor: https://www.csselectronics.com/pages/db ... s-database (click "CAN signal preview")

bananaman · Post by **bananaman** » Tue Mar 03, 2026 1:05 am

bananaman wrote: ↑Mon Mar 02, 2026 7:42 am Quick update, I tried building the code from the github on PC and comparing the data I get with PrepareFHybrid (C++) and your prepare_pcm_pmz_f_hybrid (Python). I also made Python bindings from the C++ code and used them in Python (ValeoExt). I get this (with 0 for every signal):
Code: Select all
C++     : 5f 00 00 00 3f fe 3f fe
Python  : 8b 00 00 1f ff 3f ff 00
ValeoExt: 5f 00 00 00 3f fe 3f fe
You can see that the C++ code and bindigns match (as I would expect), but your Python code is different.
Checking with different signal values and looking at which parts change, it looks like there is something wrong with your Python code as signals end up in the wrong "spots".

I have not tried other messages yet.

If you want to visualize where signals should end up in the payload, you can use this online DBC editor: https://www.csselectronics.com/pages/db ... s-database (click "CAN signal preview")

I just checked with one set of signal values for each message, and it looks like there is at least a similar issue with prepare_pcm_pmz_u_mhev:

Code: Select all

prepare_pcm_pmz_f_hybrid
Python  : 8b 00 00 1f ff 3f ff 00
ValeoExt: 5f 00 00 00 3f fe 3f fe

prepare_pcm_pmz_w_mhev
Python  : bc 00 14 2f 78 0a 0c 37
ValeoExt: bc 00 14 2f 78 0a 0c 37

prepare_pcm_pmz_u_mhev
Python  : 30 f1 83 7f fc 00 00 bb
ValeoExt: 00 03 f1 83 7f f8 00 a6

prepare_pcm_pmz_t_mhev
Python  : 00 01 67 c7 0c 36 00 00
ValeoExt: 00 01 67 c7 0c 36 00 00

prepare_bcm_pmz_a_from_cfg
Python  : 06 80 00 00 02 0a 00 00
ValeoExt: 06 80 00 00 02 0a 00 00

prepare_gwm_pmz_h_from_cfg
Python  : 00 00 00 00 00 00 00 00
ValeoExt: 00 00 00 00 00 00 00 00

bananaman · Post by **bananaman** » Tue Mar 03, 2026 3:03 am

CuriousCat wrote: ↑Fri Feb 27, 2026 5:35 pm I am manually encoding the messages but unpacking using cantools and the DBC. Here are my two python files for setting the parameters and packing them. (You can check the attachement)

For the recording, I'll have to do it again, looks like I've done too much cleaning in my files ...

The exact issue I have is that I'm sending a bunch of messages to the motor. The messages are explicitly declared in the encoder file shared. But I'm not getting any results : no spinning, the inverter doesn't seem to turn on HIGH side and the reply I get from the motor don't help me much.

The questions I have are :
- Am I sending the right messages ?
- Am I listening to the correct parameters ?
- Did I miss something about the messages or does the motor need more environment messages (such as BMS, motor ECU, ...) on the bus to turn on ?

bananaman wrote: ↑Tue Mar 03, 2026 1:05 am I just checked with one set of signal values for each message, and it looks like there is at least a similar issue with prepare_pcm_pmz_u_mhev:

Code: Select all

prepare_pcm_pmz_f_hybrid
Python  : 8b 00 00 1f ff 3f ff 00
ValeoExt: 5f 00 00 00 3f fe 3f fe

prepare_pcm_pmz_w_mhev
Python  : bc 00 14 2f 78 0a 0c 37
ValeoExt: bc 00 14 2f 78 0a 0c 37

prepare_pcm_pmz_u_mhev
Python  : 30 f1 83 7f fc 00 00 bb
ValeoExt: 00 03 f1 83 7f f8 00 a6

prepare_pcm_pmz_t_mhev
Python  : 00 01 67 c7 0c 36 00 00
ValeoExt: 00 01 67 c7 0c 36 00 00

prepare_bcm_pmz_a_from_cfg
Python  : 06 80 00 00 02 0a 00 00
ValeoExt: 06 80 00 00 02 0a 00 00

prepare_gwm_pmz_h_from_cfg
Python  : 00 00 00 00 00 00 00 00
ValeoExt: 00 00 00 00 00 00 00 00

In prepare_pcm_pmz_f_hybrid, the packing should be:

Code: Select all

    data[0] = crc & 0xFF
    data[1] = ((counter_encoded & 0x0F) << 4) | (mode_encoded & 0x0F)
    data[2] = (voltage_encoded >> 8) & 0x03
    data[3] = voltage_encoded & 0xFF
    data[4] = (speed_encoded >> 8) & 0x7F
    data[5] = speed_encoded & 0xFF
    data[6] = (torque_encoded >> 8) & 0x7F
    data[7] = torque_encoded & 0xFF

In prepare_pcm_pmz_u_mhev:

Code: Select all

    data[0] = 0
    data[1] = (counter << 0) & 0x0F
    data[2] = (tmin >> 2) & 0xFF
    data[3] = ((tmin << 6) & 0xC0) | ((tmax >> 4) & 0x3F)
    data[4] = ((tmax << 4) & 0xF0) | ((dmin >> 6) & 0x0F)
    data[5] = ((dmin << 2) & 0xFC) | ((dmax >> 8) & 0x03)
    data[6] = dmax & 0xFF
    data[7] = crc & 0xFF

There are some small differences with rounding. I had to add 0.1 to some signals to make them match, otherwise they would be 1 bit off, but now I get:

Code: Select all

prepare_pcm_pmz_f_hybrid
Python  : 8b 00 00 00 3f fe 3f ff
ValeoExt: 8b 00 00 00 3f fe 3f ff

prepare_pcm_pmz_w_mhev
Python  : bc 00 14 2f 78 0a 0c 37
ValeoExt: bc 00 14 2f 78 0a 0c 37

prepare_pcm_pmz_u_mhev
Python  : 00 03 f1 83 7f fc 00 bb
ValeoExt: 00 03 f1 83 7f fc 00 bb

prepare_pcm_pmz_t_mhev
Python  : 00 01 67 c7 0c 36 00 00
ValeoExt: 00 01 67 c7 0c 36 00 00

prepare_bcm_pmz_a_from_cfg
Python  : 06 80 00 00 02 0a 00 00
ValeoExt: 06 80 00 00 02 0a 00 00

prepare_gwm_pmz_h_from_cfg
Python  : 00 00 00 00 00 00 00 00
ValeoExt: 00 00 00 00 00 00 00 00

CuriousCat · Post by **CuriousCat** » Tue Mar 03, 2026 4:56 pm

Wow, THANKS for the feedback and all the testing @bananaman !

I'll look into it, I've actually had several issues making sure the frames were right and apparently, missed something.

I'll post once I've tried this!

VW Mild Hybrid Starter Alternator

Re: VW Mild Hybrid Starter Alternator

Re: VW Mild Hybrid Starter Alternator

Re: VW Mild Hybrid Starter Alternator

Re: VW Mild Hybrid Starter Alternator

Re: VW Mild Hybrid Starter Alternator

Re: VW Mild Hybrid Starter Alternator

Re: VW Mild Hybrid Starter Alternator

Re: VW Mild Hybrid Starter Alternator

Re: VW Mild Hybrid Starter Alternator

Re: VW Mild Hybrid Starter Alternator

Re: VW Mild Hybrid Starter Alternator

Re: VW Mild Hybrid Starter Alternator

Re: VW Mild Hybrid Starter Alternator

Re: VW Mild Hybrid Starter Alternator

Re: VW Mild Hybrid Starter Alternator

Re: VW Mild Hybrid Starter Alternator

Re: VW Mild Hybrid Starter Alternator

Re: VW Mild Hybrid Starter Alternator

Re: VW Mild Hybrid Starter Alternator

Re: VW Mild Hybrid Starter Alternator

Re: VW Mild Hybrid Starter Alternator

Re: VW Mild Hybrid Starter Alternator

Re: VW Mild Hybrid Starter Alternator

Re: VW Mild Hybrid Starter Alternator

Re: VW Mild Hybrid Starter Alternator