Tesla SDU board out of stock

[mane2]

Tesla SDU board is out of stock in openinverter shop. Any idea when it's back on stock?

[johu]

Due to the many problems SDUs have had in the past, compared to all other drive units, I decided to not sell this board anymore to new customers.

However I will stock some boards for existing customers who know what they're doing.

[mane2]

Oh ok. Would like to hear what kind of issues people have had?

Also interested to hear what would be the best alternative option if not using this board.

[johu]

Fried inverters. Either before commissioning or 3 years after, i.e. it'd run fine for 3 years and many kilometer and then suddenly break. Not the kind of stuff I enjoy dealing with.

[johu]

Now I got a few messages of people asking about the SDU boards.

I have now decided to continue selling it with an extended disclaimer:
a) the SDU inverters are relatively prone to failure with the OI board in comparison to other inverters
b) Absolutely no personal support, you're on your own/the forum
Also I won't be sourcing connectors or current sensors. I do have a couple of 100 6-pole connectors for the encoder left, so that one IS included.

On my next JLC order I will add in a few boards.

[Jack Bauer]

So just a little preview of a long overdue upgrade to the SDU board and if proves successful I will also apply these changes to the LDU board. The Model 3 project thought me a lot. The changes are (in no particular order)

-Move to Kicad from Designspark PCB. A guy did this some time ago and posted a few videos but never made the design public so I had to reinvent the wheel as usual.

-Power supply updated to the same as the M3 (XL1509) with Terminal 15 control. No more uncontrolled shutdowns.

-All input pins have TVS protection.

-Gate driver section now has hardware enforced minimum deadtime and anti shootthrough protection.

-5V throttle output protected by a polyfuse.

-Contactor drivers removed. There is no need these days to drive contactors from an inverter.

-Gate driver powerup and enable now under control from the STM32.

-Wifi module changed to Wemos D1

-Current sensor filters updated to M3 design.

-Canbus now has dedicated TVS protection.

-PCB mounting holes now hard connected to the GND plane as M3 board.

Attached a very rough schematic showing the work so far. Not shown here but will be on the final PCB is a kind contribution from my old friends at Arch Enemy Motors in the form of a 3d printable retainer for the Melexis hall sensors.

I don't have an SDU anymore but was donated a failed inverter and OEM logic boards for development and testing. I can't give a timeline on this as yet so please don't ask but it is being worked on as much as I can given other projects. Once I have something resembling a board layout I will add the Kicad project to the SDU repo on GitHub.

Finally , I THINK I know what is causing the failures but until I get some hard proof I don't want to speculate as its mostly just gut feeling. During my research I can across this website which has some very useful info for both SDU and M3 : https://ohm.ninja/tesla-traction-inverter-gate-drive/

[johu]

That's a great update.
Some folks use the positive contactor output for fan control, maybe you could leave the TO footprint and traces intact?

One pattern with the failures was they usually happen during slow takeoff and not at full or at speed. Hope that fits you theory.

[bewo]

Hi guys, based on the actual situation regarding the SDU drop-in board we're really unsure how to deal with that. As I wrote in an other thread we are planing to jump from a 150V to a 400V environment in our EV conversion. As you can imagine we planned to use the OI board for the FDU, but with the actual situation we don't know how to deal with that. It seems that there is no known configuration with which the inverter is not at risk, or did we overread something?
We know that there are other commercial possibilities like AMV EV, T-2C, ESDI or Dynam Labs, but that's not our preferred solution.
Comments are expressly welcome

[johu]

Basically the situation is the same as before, we just acknowledge the fact that SDU inverters broke at an over-proportional number with the OI board. I can't really put a percentage on it but over the years I sold 350 SDU boards and read perhaps about 20 IGBT failures. That would be 5%, not counting boards that were sold by someone else or manufactured from the files.
And also not counting silent failures that were never reported or boards that were never commissioned.

In comparison I sold 220 LDU boards and had perhaps 5-10 failures which also puts it in the 2.5-5% ball park. The difference to SDU inverters is they died from "mistreatment" such as P.S. Mangelsdorf rather than during slow takeoff/maneuvering.
Nissan boards I sold 110 and remember one failure due to over voltage during regen. Call it a 0 failure rate.

All failure numbers are "felt" combined from support calls and forum posts (dubbed SDU overcurrent). If someone can improve on that it would be welcome.

[jrbe]

So is it an overvoltage event that triggers igbt failure which gives the overcurrent error?
Some of the newer Tesla induction motors look to have a gas discharge tube between 2 phases (a guess on my part). I'm wondering if they added this to help with inductive collapse energy / regen transitions/ control.

I think catphish may have also struggled with this around regen with the firmware he developed.

Purely speculation on my part, just sharing my theory.

[johu]

The explosive disconnects two phases (Beatbuzzer made a video about it) and only on PM motors

[Jack Bauer]

By popular demand the current work in progress of the Kicad SDU board is now shared on GitHub :
https://github.com/damienmaguire/Tesla- ... U_Kicad_V1

Updates will be on the repo as I go.

[Jack Bauer]

Getting some time on this project again. Parts placed. Tracking begins.

[Jack Bauer]

[modellfan]

For me driving the SDU in my Porsche 986 the missing emergency off Hard wire would be the biggest thing to add . I worried around it by letting my emergency button put my sdu into neutral via r d wires. But on software side this can never be used to also cut the HV contactors after the motor is in a safe state .

Very simple change as discussed here :

https://openinverter.org/forum/viewtopi ... 4&start=25

Edit: Just saw the full video . I am really looking forward to implement the updates in my car. One more idea: any diagnostics to be implemented on it? The STM32 should have enough free pins.

[MoonUnit]

This is not a criticism, just a question - why is the contactor control being removed from the new Kicad board? Related to this question is the need to have tripmode set so that the contactors don't open on "overcurrent" to protect the inverter - maybe that's no longer expected to be a requirement? But if it is, does an "overcurrent" event detected on the board get propagated back up to Zombie or other VCU via CANbus?

[modellfan]

I didn’t notice. In my car BMS is in charge of contactor control. I want states (charging , conditioning) where HV should be active but not the SDU. I currently have BMS and SDU parallel connected to the contractors , where SDU is just a failsave holding contactors in case BMS resets , to not break my SDU .

[johu]

I wanted to add something. I'm currently at a workshop and they run the SDU with stock firmware and top secret CAN magic. I noticed the PWM frequency is well hearable even with my bad hearing. I'm guessing in the 7-10 kHz range.

Back when the first SDU boards came out we had lots of inverter failures. We figured, among other possible culprits, that inductance of the SDU stator was so low that 8.8 kHz was saturating. With the experience with different motors over the last years and this first hand experience I'm starting to doubt that we drew the right conclusions. Maybe the 17.6 kHz that we run it on now contributes to the frequent failures?

The question is, who is willing to test their drive unit with pwmfrq 8.8 kHz? The parameter is hidden, so with the UART connected ESP web interface you need to issue "flag pwmfrq !hidden" command to show it.
On CAN ESP module that command isn't supported so you have to type "set pwmfrq 1" instead

[Proton]

Did anybody kept notes on what board version of software version were the boards that failed?

[modellfan]

The question is, who is willing to test their drive unit with pwmfrq 8.8 kHz? The parameter is hidden, so with the UART connected ESP web interface you need to issue "flag pwmfrq !hidden" command to show it.
On CAN ESP module that command isn't supported so you have to type "set pwmfrq 1" instead

Is there a way to test the 8.8 kHz simulative without frying a car for it?

Should I implement the unhide feature in CAN Webinterface?

One more feature I would like to see for the SDU:
Add a eeprom? I would really like to implement freeze frames into ZombieVerter universe. This would make debugging of rare problems so much easier