openinverter forum

bigmotherwhale wrote: ↑Fri Sep 29, 2023 2:25 pm 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.

Kperformance wrote: ↑Sun May 12, 2024 8:31 pm 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

Kperformance wrote: ↑Sun May 12, 2024 8:31 pm 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 wrote: ↑Mon May 13, 2024 3:09 pm There are existing modules you can buy on aliexpress to just cut and solder on, instead of making your own.

golfdubcrazy wrote: ↑Wed Apr 16, 2025 1:59 pm 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

golfdubcrazy wrote: ↑Wed Apr 16, 2025 1:59 pm 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

skr wrote: ↑Wed Aug 20, 2025 12:28 am Just came across this guy on fb, thought maybe worth a share ( https://www.facebook.com/profile.php?id=61561233521299 ):
image.pngimage.png

• 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

• 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?

• 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 wrote: ↑Fri Aug 29, 2025 6:28 am 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 wrote: ↑Thu Aug 28, 2025 8:40 pm 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.

• 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 wrote: ↑Sat Aug 30, 2025 7:14 pm 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 wrote: ↑Sun Aug 31, 2025 11:12 pm 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 wrote: ↑Mon Sep 01, 2025 3:14 pm 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 wrote: ↑Mon Sep 01, 2025 8:03 pm 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

gluttony wrote: ↑Mon Sep 01, 2025 7:38 pm 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

bananaman wrote: ↑Mon Sep 01, 2025 10:49 pm 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?

bananaman wrote: ↑Mon Sep 01, 2025 10:43 pm 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?