VW Mild Hybrid Starter Alternator

[Kperformance]

Bodge completed however I want to have a good look over the gate driver again to see if all the transistors are OK before its powered up.

Hi Bigmotherwhale,

Mind sharing the pcb/schematics?
I also suffered from the dead-alternator message today!

Would be great to see details and or find a working solution

[ama]

Hi Bigmotherwhale,

Mind sharing the pcb/schematics?
I also suffered from the dead-alternator message today!

Would be great to see details and or find a working solution

There are existing modules you can buy on aliexpress to just cut and solder on, instead of making your own.

[bigmotherwhale]

Hi Bigmotherwhale,

Mind sharing the pcb/schematics?
I also suffered from the dead-alternator message today!

Would be great to see details and or find a working solution

Sure, i will see if I can dig them out, I could send you a board if you can populate it yourself.

[jrbe]

There are existing modules you can buy on aliexpress to just cut and solder on, instead of making your own.

Are they any good / last?

[ama]

I believe so, at least some of them should be similar or better than original.

I did some research in Chinese, the repair guys seems to really like this as they do not fail again as often compare to if you just put another OEM one back in.

[golfdubcrazy]

hi has anyone made progress on this, im building an autonomous Ami and can control the motor but need help with the CRC check as this is causing some problems



it uses an IBSG just like the vw/audi

messages are send to address 0x3c0, byte 0 is CRC byte 1 is cyclic for the first half of the byte (0 to F) and the is enable signal byte 6 is forward/reverse (3f/40) and byte 7 is throttle 0-100 for forward and 100-0 for reverse.

this is known values motor idling

26 01 00 00 3f fe 3f ff
eb 11 00 00 3f fe 3f ff
a1 21 00 00 3f fe 3f ff
6c 31 00 00 3f fe 3f ff
35 41 00 00 3f fe 3f ff
f8 51 00 00 3f fe 3f ff
b2 61 00 00 3f fe 3f ff
7f 71 00 00 3f fe 3f ff
00 81 00 00 3f fe 3f ff
cd 91 00 00 3f fe 3f ff
87 A1 00 00 3f fe 3f ff
4a B1 00 00 3f fe 3f ff
13 C1 00 00 3f fe 3f ff
de D1 00 00 3f fe 3f ff
94 E1 00 00 3f fe 3f ff
59 F1 00 00 3f fe 3f ff

hopefully someone can help with figuring how the checksum CRC is calcuted

[bigmotherwhale]

Nice, im glad someone has made progress, there is always the problem of finding a can log from a working car. I have a Valeo one from a different model, i wonder if the message structure is the same. What does the unit transmit over CAN when powered?
the one i have sends these messages:
00000190 8 10 92 a0 48 04 70 00 09
00000192 8 00 00 00 00 00 00 00 6a
00000193 8 00 00 00 00 00 00 00 6a

[LRBen]

For others looking, the low voltage connector part number is 1J0973714

More details on it here
https://transistor-man.com/audi_48v.html

[ama]

hi has anyone made progress on this, im building an autonomous Ami and can control the motor but need help with the CRC check as this is causing some problems



it uses an IBSG just like the vw/audi

messages are send to address 0x3c0, byte 0 is CRC byte 1 is cyclic for the first half of the byte (0 to F) and the is enable signal byte 6 is forward/reverse (3f/40) and byte 7 is throttle 0-100 for forward and 100-0 for reverse.

this is known values motor idling

26 01 00 00 3f fe 3f ff
eb 11 00 00 3f fe 3f ff
a1 21 00 00 3f fe 3f ff
6c 31 00 00 3f fe 3f ff
35 41 00 00 3f fe 3f ff
f8 51 00 00 3f fe 3f ff
b2 61 00 00 3f fe 3f ff
7f 71 00 00 3f fe 3f ff
00 81 00 00 3f fe 3f ff
cd 91 00 00 3f fe 3f ff
87 A1 00 00 3f fe 3f ff
4a B1 00 00 3f fe 3f ff
13 C1 00 00 3f fe 3f ff
de D1 00 00 3f fe 3f ff
94 E1 00 00 3f fe 3f ff
59 F1 00 00 3f fe 3f ff

hopefully someone can help with figuring how the checksum CRC is calcuted

Wow this is good progress. I’ve been busy with life and haven’t gotten a chance to mess with it much.

[uhi22]

messages are send to address 0x3c0, byte 0 is CRC byte 1 is cyclic for the first half of the byte (0 to F) and the is enable signal byte 6 is forward/reverse (3f/40) and byte 7 is throttle 0-100 for forward and 100-0 for reverse.
...
hopefully someone can help with figuring how the checksum CRC is calcuted

If we have more data with different content of the same message, it should be not to difficult to find out and verify the CRC calculation. I did this recently for two tesla and one VW message
https://github.com/uhi22/tesla-crc
and most likely the 3c0 follows the same schema just with other magic bytes.

[skr]

Just came across this guy on fb, thought maybe worth a share ( https://www.facebook.com/profile.php?id=61561233521299 ):

[ama]

Just came across this guy on fb, thought maybe worth a share ( https://www.facebook.com/profile.php?id=61561233521299 ):
image.pngimage.png

Seems to be more on the repair/testing side, but maybe it's easy to pay him to get some logs from the car.

[bananaman]

I was looking into the firmware to see which CAN IDs it expects. From the filtering it looks like the messages are going into 4 main handlers, and from there other handlers are called. I assume the main ones are for different purposes (diagnostics, normal communication, …).

I didn’t go very deep yet, work is keeping me busy, but I noticed some parts where signals are taken from specific messages. Also, not every ID here was in the log from bigmotherwhale, so maybe some are only active in special cases.

Code: Select all

CAN ID       Handler   Log   Notes
-----------------------------------------
0x7DF        2                 OBD-II? Diag?
0x703        2                 UDS? Diag?
0x700        2                 UDS? Diag?
0x1BFC2F00   4                 SAE J1939?
0x6B2        3
0x1A555480   3
0x641        3
0x17FC0085   2                 Diag?
0x585        3
0x3C0        3         Y
0x3A3        3         Y
0x18D        3         Y
0x152        3         Y
0x151        3         Y
0xFD         3         Y
0xEE         3         Y
0xA8         3         Y
0x40         3         Y
0x1B0000??   1         Y      Matches 00–FF
0x17FC0285   2                 Diag?
0x504        3
0x1BFC2F00   4                 SAE J1939?

The board I have has broken IGBTs, so I cannot test much at the moment. I wait for a new one, then I will try running the motor and maybe cut down which parts of the messages are really used. From what I see, some bytes that have values in the logs are actually ignored.

[bananaman]

I had a quick look at some message handlers to see which signals they pull. Cross-checked with vw_mqb.dbc from opendbc when possible.
All little endian, start/len in bits:

• 0x40: lots of bit operations, skipped for now. In DBC it looks like many airbag status/crash flags. Seems plausible.

• 0xA8:
  • A8_Signal1: start 48, length 16. Matches "MO_Drehzahl_01" in DBC (engine RPM)

• 0xEE:
  • EE_Signal1: start 54, length 10. Not found in DBC

• 0xFD:
  • FD_signal1: start 32, length 16. Matches "ESP_v_Signal" in DBC (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

• 0x18D:
  • 18D_signal1: start 24, length 8. Not found in DBC

• 0x3A3:
  • 3A3_signal1: start 16, length 10. Not found in DBC
  • 3A3_signal2: start 56, length 8. Not found in DBC

• 0x504:
  • 504_signal1: start 32, length 1. Not found in DBC

• 0x152: looks similar to 0x151

• 0x3C0: not checked in detail, but I think this is pretty well known (ignition status). Seems plausible

Have not looked in detail, but from what I saw:

• A8_Signal1 (RPM) and FD_Signal1 (speed) are used either as upper limit checks, or to check if they are above a minimum value, in certain places.

• EE_Signal1 is stored like (value – 511) * 16. If value is 1022 or 1023 it’s forced to 511, so after conversion it becomes 0. Could be some setpoint or sensor value that can go positive/negative. Maybe torque or battery current?

Extra notes on checksums:

• Only 0x40, 0x151 and 0x152 do CRC + sequence checks (frame order, missed frames). Probably the most important ones.

• CRC matches the default AUTOSAR polynomial (same as in the magic byte cracking script). I tested with 0x151 and it matches. Some sequence numbers missing in the log though.

[RetroZero]

I had "broken down" mqb_dbc data for BO_168 = 0X0A8 as per the below.Hope it helps clear the way.....There is a counter with magic bytes in this message from what I gathered.

// Data structure for Motor_12 message
struct Motor_12_t {
uint8_t Motor_12_CRC; // 8 bits, CRC checksum [0-255]
uint8_t Motor_12_BZ; // 4 bits, message counter [0-15]
int16_t MO_Mom_neg_verfuegbar; // 9 bits, available negative torque [-509 to 0] Nm
uint16_t MO_Mom_Begr_stat; // 9 bits, static torque limit [0-509] Nm
int16_t MO_Mom_Begr_dyn; // 10 bits, dynamic torque limit [-509 to 509] Nm
uint8_t MO_Momentenintegral_02; // 7 bits, torque integral [0-100] %
uint8_t MO_QBit_Drehzahl_01; // 1 bit, RPM quality bit [0-1]
float MO_Drehzahl_01; // 16 bits, RPM [0-16383] 1/min

[bananaman]

I had "broken down" mqb_dbc data for BO_168 = 0X0A8 as per the below.Hope it helps clear the way.....There is a counter with magic bytes in this message from what I gathered.

// Data structure for Motor_12 message
struct Motor_12_t {
uint8_t Motor_12_CRC; // 8 bits, CRC checksum [0-255]
uint8_t Motor_12_BZ; // 4 bits, message counter [0-15]
int16_t MO_Mom_neg_verfuegbar; // 9 bits, available negative torque [-509 to 0] Nm
uint16_t MO_Mom_Begr_stat; // 9 bits, static torque limit [0-509] Nm
int16_t MO_Mom_Begr_dyn; // 10 bits, dynamic torque limit [-509 to 509] Nm
uint8_t MO_Momentenintegral_02; // 7 bits, torque integral [0-100] %
uint8_t MO_QBit_Drehzahl_01; // 1 bit, RPM quality bit [0-1]
float MO_Drehzahl_01; // 16 bits, RPM [0-16383] 1/min

Thanks!
From what I've seen, the BSG doesn't seem to actually check the message counter and checksum for this one, it just simply extracts the RPM signal.
From the handlers I checked until now, it only checks the checksum and counter for 0x40, 0x151, and 0x152, so think it cares most about those?

[bananaman]

I had a quick look at some message handlers to see which signals they pull. Cross-checked with vw_mqb.dbc from opendbc when possible.
All little endian, start/len in bits:

• 0x40: lots of bit operations, skipped for now. In DBC it looks like many airbag status/crash flags. Seems plausible.

• 0xA8:
  • A8_Signal1: start 48, length 16. Matches "MO_Drehzahl_01" in DBC (engine RPM)

• 0xEE:
  • EE_Signal1: start 54, length 10. Not found in DBC

• 0xFD:
  • FD_signal1: start 32, length 16. Matches "ESP_v_Signal" in DBC (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

• 0x18D:
  • 18D_signal1: start 24, length 8. Not found in DBC

• 0x3A3:
  • 3A3_signal1: start 16, length 10. Not found in DBC
  • 3A3_signal2: start 56, length 8. Not found in DBC

• 0x504:
  • 504_signal1: start 32, length 1. Not found in DBC

• 0x152: looks similar to 0x151

• 0x3C0: not checked in detail, but I think this is pretty well known (ignition status). Seems plausible

Have not looked in detail, but from what I saw:

• A8_Signal1 (RPM) and FD_Signal1 (speed) are used either as upper limit checks, or to check if they are above a minimum value, in certain places.

• EE_Signal1 is stored like (value – 511) * 16. If value is 1022 or 1023 it’s forced to 511, so after conversion it becomes 0. Could be some setpoint or sensor value that can go positive/negative. Maybe torque or battery current?

Extra notes on checksums:

• Only 0x40, 0x151 and 0x152 do CRC + sequence checks (frame order, missed frames). Probably the most important ones.

• CRC matches the default AUTOSAR polynomial (same as in the magic byte cracking script). I tested with 0x151 and it matches. Some sequence numbers missing in the log though.

Small update:

• 0x40: lots of bit operations, but in the end only seems to use this:
  • 40_signal1: start 42, length 3. Matches "AB_Deaktivierung_HV" in the vw_mqb.dbc. This seems to make sense ("deactivation HV"). According to what I found online, 0 means OK, 1-6 are different deactivations, 7 means failure. I saw checks like != 7 so seems plausible.

• 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

• 0x3C0:
  • 3C0_signal1: start 17, length 1. "ZAS_Kl_15" in DBC, should mean ignition on
  • 3C0_signal2: start 19, length 1. "ZAS_Kl_50" in DBC, should mean starter on?

[gluttony]

Hey bananaman, I'm also currently on the mission to figure out the CAN signals.
I have the 48V BSG 4N0903028R, but the replay that works for others hasn't worked for mine. I hear a click of a relay and increase in current consumption on 12V, but no rotation whatsoever.
Do you have a firmware dump available and wouldn't mind to share? Can I support on your route maybe? At the moment I have been trying to open all available logs here, read from my BSG, change parameters and see the effect.

[golfdubcrazy]

im tempted to buy one of the following and reverse engineering it.

https://www.onlyda.com/product-p26807141.html

or

https://www.botongautoelectronics.com/p ... alternator

or

http://ebay.co.uk/itm/405899320374

might be abit quicker. from one of the videos iv seen is you can connect the alternator to VCDS to read data so will try that hopefully this week

[bananaman]

Hey bananaman, I'm also currently on the mission to figure out the CAN signals.
I have the 48V BSG 4N0903028R, but the replay that works for others hasn't worked for mine. I hear a click of a relay and increase in current consumption on 12V, but no rotation whatsoever.
Do you have a firmware dump available and wouldn't mind to share? Can I support on your route maybe? At the moment I have been trying to open all available logs here, read from my BSG, change parameters and see the effect.

Sorry, I don't think I can share the firmware dump as that would violate copyright. As I understand it there is some room for reverse engineering when it’s for interoperability, so writing down the protocol and sharing that is OK. But sharing the actual code (like the firmware) is not. I just try to be a bit careful here. (If I am wrong someone please correct me.)

About your unit could it be that an IGBT is broken? I didn’t see any relay inside the BSG itself. Maybe what you hear is the windings energizing, or a relay in your PSU? Do you notice any current draw on the 48 V side?

[gluttony]

im tempted to buy one of the following and reverse engineering it.

https://www.onlyda.com/product-p26807141.html

or

https://www.botongautoelectronics.com/p ... alternator

or

http://ebay.co.uk/itm/405899320374

might be abit quicker. from one of the videos iv seen is you can connect the alternator to VCDS to read data so will try that hopefully this week

I was also about to do the same but from mysupercarexpert.com - I'm surprised how many types there are.

Interestingly, going throughthe logs from bigmotherwhale Aug 30, 2023, not sure which test platform he used, but I can see in the logs clearly, that there seem to be at least two different types of motors on the bus (a 28N and 28R,is published on ID 0x1A555510).

And interestingly two motors behave differently. One you can see in the two cyclical messages that are sent on 0x1A0, that one motor is spooling up, while the other does not move. Later the other does also starts to move. But I see also that the voltage goes up, so I guess after 3 seconds they just switched the 48V supply for the other. But I haven't yet figured out the scaling of the voltage bytes, will do that tomorrow.

It also seems that the messages sent by the platform, might stem from two different "control signals". I feel like that because the timing between the messages is not very cyclical, but seems like two offset cyclical messages that also differ in content on some IDs.

[gluttony]

Sorry, I don't think I can share the firmware dump as that would violate copyright. As I understand it there is some room for reverse engineering when it’s for interoperability, so writing down the protocol and sharing that is OK. But sharing the actual code (like the firmware) is not. I just try to be a bit careful here. (If I am wrong someone please correct me.)

About your unit could it be that an IGBT is broken? I didn’t see any relay inside the BSG itself. Maybe what you hear is the windings energizing, or a relay in your PSU? Do you notice any current draw on the 48 V side?

Thanks for the reply!
On the firmware okay, thats sad, haven't checked the law yet. Might also depend on the jurisdiction. May I asked did you dump it yourself off the board via JTAG or was advanced voltage glitching or so required to bypass security?

You didn't hear a click when replaying the logs? Did your unit spool up?
So I see the following behavior:
With 12V and 48V connected, when starting the replay I hear the click and see the 12V current rise ca. 20 mA, the 48V current drops around 50uA
I don't hear the click or the change of currents with 48V disconnected though.
When I start the replay and enable the 48V after a bit, I see the 12V current rise ca 20mA immediately and the click come just a second later (and slighter).
This indeed seems to me, not to be a relay, or the click and 20mA current rise would coincide. On the other handy winding energizing would increase the current draw. Not sure.

On one hand I'd be happy that the issue is with the unit and not myself/the CAN replay, on the other I'm a bit frustrated to have wasted so much time on a defect unit again Anyways, the hunt for the CAN signals goes on.
Thanks everyone for the help so far! If I get new details, I'll share them. I'm sure we'll crack the code soon, I'm hungry for it hehe

[bananaman]

Thanks for the reply!
On the firmware okay, thats sad, haven't checked the law yet. Might also depend on the jurisdiction. May I asked did you dump it yourself off the board via JTAG or was advanced voltage glitching or so required to bypass security?

You didn't hear a click when replaying the logs? Did your unit spool up?
So I see the following behavior:
With 12V and 48V connected, when starting the replay I hear the click and see the 12V current rise ca. 20 mA, the 48V current drops around 50uA
I don't hear the click or the change of currents with 48V disconnected though.
When I start the replay and enable the 48V after a bit, I see the 12V current rise ca 20mA immediately and the click come just a second later (and slighter).
This indeed seems to me, not to be a relay, or the click and 20mA current rise would coincide. On the other handy winding energizing would increase the current draw. Not sure.

On one hand I'd be happy that the issue is with the unit and not myself/the CAN replay, on the other I'm a bit frustrated to have wasted so much time on a defect unit again Anyways, the hunt for the CAN signals goes on.
Thanks everyone for the help so far! If I get new details, I'll share them. I'm sure we'll crack the code soon, I'm hungry for it hehe

Yes, I dumped it via JTAG (and can also debug). These microcontrollers have a way of locking the JTAG with a password, but it was unlocked, so nothing special needed.

Mine has blown IGBTs so I can't spin it up. I have another driver board on the way though so I will try then.

50uA on the 48V bus seems very low?

[bananaman]

I was also about to do the same but from mysupercarexpert.com - I'm surprised how many types there are.

Interestingly, going throughthe logs from bigmotherwhale Aug 30, 2023, not sure which test platform he used, but I can see in the logs clearly, that there seem to be at least two different types of motors on the bus (a 28N and 28R,is published on ID 0x1A555510).

And interestingly two motors behave differently. One you can see in the two cyclical messages that are sent on 0x1A0, that one motor is spooling up, while the other does not move. Later the other does also starts to move. But I see also that the voltage goes up, so I guess after 3 seconds they just switched the 48V supply for the other. But I haven't yet figured out the scaling of the voltage bytes, will do that tomorrow.

It also seems that the messages sent by the platform, might stem from two different "control signals". I feel like that because the timing between the messages is not very cyclical, but seems like two offset cyclical messages that also differ in content on some IDs.
image.png

Yes I noticed this too, if you look at 1A0 for example, the second byte has a sequence counter, it seems to be two interleaved?

[gluttony]

Yes I noticed this too, if you look at 1A0 for example, the second byte has a sequence counter, it seems to be two interleaved?

Yeah right, that is also the giveaway for at least two motors being on the bus imho

Yes, I dumped it via JTAG (and can also debug). These microcontrollers have a way of locking the JTAG with a password, but it was unlocked, so nothing special needed.

Mine has blown IGBTs so I can't spin it up. I have another driver board on the way though so I will try then.

50uA on the 48V bus seems very low?

Oh that is interesting! I unfortunately don't wanna open mine just yet, but great to know.
Let me clarify: the 48V Bus has idle power consumption for me of around 1.3 mA, just after starting the replay and hearing the click it rose 50 µA.
Good luck with the repair.