Neues Layout für die Leistungsbrücke

Endlich habe ich wieder etwas zu berichten.

Oberseite der neuen Leistungsbrücke

Unterseite der Leistungsbrücke

Wie man an den Bildern sieht habe ich mein Design von diesem Post noch einmal revidiert. Ich brauchte einfach mehr Platinen Fläche. Deshalb bin ich jetzt bei einem ein phasigen Design gelandet, dass gestapelt wird. Auf die freigestellten Kupferflächen auf der Oberseite kommen immer noch 6x3mm Kupferschienen. Jedoch soll jetzt eine 3mm Aluplatte als Basis dienen auf der die Platine mit den FETs und isolierender Wärmeleitfolie dazwischen geschraubt wird. Auf die Kupferschienen kommt dann wiederum Folie und 3mm Alu und dann folgt die nächste Phase usw. Bis das Sandwich wieder durch eine 3mm Alu Plate geschlossen wird.

Der Stecker an der Seite ist ein 26poliger har-flex THR von HARTING (ACHTUNG Productplacement: Die haben mich auf der letzten SPS Drives angelacht und Harting hat mir ein Kit mit den gewinkelten und geraden Steckern/Buchsen zugeschickt.).

An der Seite des Sandwiches mit den Steckern kommt dann eine Verteilerplatine. An der dann auch das Controllerboard angesteckt wird, Und das Controllerboard sitzt dann wieder auf dem Sandwich.

Die Aluplaten zwischen den Phasen können so wahlweise etwas überstehen und "Kühlrippen" bilden oder in einem Kühlkörper mit Wärmeleitpaste verschraubt werden. Und da die har-flex auch als wire-to-board-Verbinder verkauft werden kann das Ganze auch komplett verteilt aufgebaut werden.


Die KiCad Daten sind wieder auf bitbucket.org zu finden.

Kleines Update zum Beobachterthema

Demnächst ist wieder das PRAXISFORUM ELEKTRISCHE ANTRIEBSTECHNIK und in den angekündigten Vorträgen finden sich einige sehr schöne Themen. Für mich ist zum Beispiel der Vortrag:

"Herausforderungen und Lösungsansätze für die geberlose Regelung von Synchronmaschinen: aktuelle Probleme in der Anwendung und Lösungen u.a. mittels Quadratinjektion, die eine sehr recheneffiziente Anisotropiedetektion ermöglicht"

sehr interessant. Für reine Hobbyzwecke ist mir jedoch die Teilnahme-Gebühr etwas hoch. Aber die Ausgründung Bitflux der TUM liefert auf ihrer Seite ein paar nähere Infos. Zum Beispiel unter der Rubrik: Team :)  den CEO und CFO kann man gleich in den Skat drücken aber die beiden CTOs haben gegebenenfalls schöne Veröffentlichungen geschrieben. Google ist hier sehr hilfreich.

So findet man z.B. dieses Paper: Silent and parameter independent Hybrid SensorlessControl for SPMSM based on Current Oversampling  oder noch besser die Dissertation des Herrn Dr.-Ing. Peter Landsmann Sensorless Control of Synchronous Machines byLinear Approximation of Oversampled Current.

Gerade die Dissertation werde ich mir mal zu Gemüte führen und anschließend Matlab Simulink drauf ansetzten, Dann kann ich sicherlich mehr berichten!

Direct Flux Control

Ich bin kürzlich auf einen aktuelleren Beobachteransatz für permanent erregte Synchronmaschinen gestoßen. Der Ansatz wird in dieser Publikation als Direct Flux Control beschrieben.

Rotorlage beobachten im Stillstand

Das größte aktuelle Problem im Bereich sensorloser Regelung von Synchronmaschinen ist der Stillstand. Hier lassen sich ohne weiteres keine Signale erfassen die einen Rückschluss auf die Rotorlage erlauben. Viele gerade nichtlineare Beobachter wie ich sie auch einsetze, hoffen im Stillstand darauf nicht grundsätzlich falsch zu liegen mit ihrer aktuellen Einschätzung der Lage. Wird die Maschine dann bestromt sollte ein ausreichendes Drehmoment erzeugt werden, sodass der Rotor sich zu drehen beginnt. Und dann muss der Beobachter nur genügend schnell auf die Rotorlage konvergieren, die er anhand der induzierten Gegenspannung (BEMF) schätzt. Was ist aber wenn die Rotorwelle blockiert ist oder eine Positionsregelung erfolgen soll und man dennoch möglichst effizient den Strom in Drehmoment umwandeln will?

Dann kommen Beobachter-Verfahren ins Spiel die spezielle Signale in die Statorwicklungen einprägen und anhand der Übertragungseigenschaften der Wicklungen auf die Rotorlage schließen.

Zum Einen kann auf der d-Achse ein sinusförmiger Strom mit ca. 1kHz eingeprägt werden und der sich ergebende Strom auf der q-Achse beoachtet werden. Dafür braucht man aber einen sehr scharfen Bandpass für die Frequenz mit der der Strom eingeprägt wird. Sonst hat man die Signale der Drehmomentregelung mit in der Lageschätzung.

Eine andere Variante bietet INFROM. Mit dieser Methode werden gezielt Stromimpulse in die Wicklungen eingeprägt und es werden die Stromänderungen ausgewertet. Die Stromänderung $\frac{dI}{dt}$ auf grund einer eingeprägten Spannung ergibt eine Induktivität. Und dann sind wir auch wieder beim Knackpunkt der ganzen Methoden. Diese Verfahren funktionieren nur wenn die Induktivitäten $L_d$ und $L_q$ genügend verschieden sind.

Direct Flux Control

Leider ist auch die DFC abhängig von der sog. Achsigkeit der Induktivitäten. Aber im Gegensatz zu INFORM muss hier für die Strommessung nicht in der Lage sein mit hoher Auflösung innerhalb von 1-3µs 2 Samples auf allen drei Phasen aufzunehmen, sondern es ist nur eine schnelle Spannungsmessung notwendig. Aber leider soll hier die Spannung des Sternpunktes der Maschine gemessen werden. Und dafür muss fast jeder Antrieb umgebaut werden....
Ein interessantes Verfahren ist es trotzdem.

Toolchain für Cortex-M7 mit FPUs für einfache und doppelte Genauigkeit.

Auf dem Weg zum uclinux auf dem STM32H7xx stolperte ich zuerst über die Toolchain. Emcraft benutzt einen GCC von 2010. In Buildroot ist nur eine Konfiguration für dem F429 ohne hard float support vorhanden. Die GNU ARM GCC Toolchain, die ich sonst immer benutze ist leider gegen newlib gelinkt und newlib ist zwar schön klein für Bare-Metal-Implementierungen aber für Linux Applikationen brauche ich anscheinend ein recht vollständiges glibc Derivat. Im restlichen Netz war auch nix zu finden was mir passte. Da bleibt nur selber bauen.

OpenADK

Um direkt alles aus den Sourcen zubauen habe ich keine Zeit und Lust, deshalb habe ich mir ein Buildsystem alla Buildroot, Yocto und Konsorten gesucht. Dabei bin ich auf OpenADK gestoßen. Wie bei Buildroot gibt es hier auch nur die STM32F429 Konfiguration mit soft float aber der Cortex M7 war bereits in der Konfiguration eingefügt. Außerdem bringt OpenADK bereits alle notwendigen Tools mit um sich selbst zu bauen. Es läuft quasi out of the box. 

Ich hab mir also erstmal einen Fork auf github gemacht und anschließend das Target st-stm32f429 kopiert und in st-stm32f769 umbenannt. Dabei kam dann erstmal diese minimal Konfiguration raus.

config ADK_TARGET_SYSTEM_ST_STM32F769
 bool "STMicroelectronics STM32F769"
 depends on ADK_EXPERIMENTAL
 depends on ADK_TARGET_LITTLE_ENDIAN
 select ADK_TARGET_CPU_ARM_CORTEX_M7
 select ADK_TARGET_HARD_FLOAT_DP
 select ADK_TARGET_ARCH_ARM_WITH_THUMB
 select ADK_TARGET_WITH_SERIAL
 select ADK_TARGET_UCLINUX
 select ADK_TARGET_KERNEL_XIPIMAGE
 help
   STMicroelectronics STM32F769

Die wesentlichen Änderungen betreffen die Namen und die CPU. Die Namensänderungen sind selbst erklärend, deshalb mache ich gleich mal weiter mit den CPU Einstellungen. Die Einstellung select ADK_TARGET_CPU_ARM_CORTEX_M7 spricht ebenfalls für sich selbst. Jedoch musste ich die verschiedenen FPUs des Cortex-M7 irgend wie unterscheiden. Dafür dient das Setting select ADK_TARGET_HARD_FLOAT_DP, damit kann ich zwischen der "fpv5-sp-d16" und der "fpv5-d16" wählen. Die "fpv5-sp-d16" ist die FPU die nur einfache Genauigkeit unterstützt und die "fpv5-d16" kann einfache und doppelte Genauigkeit. Da der auf dem Board verwendete STM32F769 und auch mein geplanter STM32H743 die "fpv5-d16" haben muss die Einstellung gesetzt sein, wenn ich die FPU auch vollständig nutzen will. Ein angenehmer Nebeneffekt ist, das die uclibc-ng gleich mit der Verwendung der FPU gebaut wird, was hoffentlich dem Math-Library zu gute kommt.

Und läuft

Um zu Testen ob die Toolchain auch den erwarteten Code generiert habe ich ein simpel Beispiel ohne Optimierung gebaut und siehe da der Compiler nutzt die FPU Instruktionen wie "vadd.f64" für doubles und "vadd.f32" für floats.

ucLinux oder wie nutze ich übrige Rechenzeit

Ich habe mir über den Jahreswechsel viele Gedanken zu der Software des neuen Umrichters gemacht. Dabei spielte meine Abneigung gegen das Schreiben von Protokoll-Stacks zur Kommunikation eine große Rolle. Denn ansich brauche ich für den Umrichter kein RTOS oder einen Scheduler oder ähnliches Konstrukt. Aber ich und ggf. auch mal andere Leute müssen das Ding ja bedienen.

Das fängt schon mit der Anbindung an externe System an, die Sollwerte liefern sollen. Üblicherweise nimmt man dafür einen Feldbus. CAN braucht nur einen Tranceiver und los gehts. Aber so einfach ist das dann doch nicht. Denn dann bin ich wieder bei der Frage was für ein Protokoll läuft denn dadrauf usw..

Mit geringem Hardware Aufwand ließe sich z.B. CAN oder CAN-FD als Physik für die Kommunikation bereitstellen. Nur dann brauche ich z.B. einen CANOpen-Stack damit der Umrichter eine halbwegs einheitliche Schnittstelle bekommt.

Wenn ich dann weiter gehe und mir über die generelle Inbetriebnahme und Parametrierung Gedanken mache bin ich ganz schnell bei USB. Klar USB-CDC bietet ST fertig an auch ChibiOS-RT, das ich aktuell verwende hat bereits USB implementiert. Aber auch hier muss in irgendeiner Weise ein Protokoll drauf laufen. Klar das kann ich selber definieren und dann auch programmieren... kotz.

Also muss was anderes her. Und da will ich gleich mit der Gießkanne dimensionieren, denn der F7xx hat bei der aktuellen Implementierung meiner Regelung ca. 50% Freizeit. Die Sleep-Modes in der restlichen Rechenzeit zu nutzen ist totaler Humbug, also kann man die Rechnenzeit auch mehr oder weniger sinnvoll verbraten. Gerade im Hinblick auf den Pinkompatiblen H7xx muss für die restliche Rechenzeit eine gescheite Lösung her.

ucLinux

Durch den CCC der über den Jahreswechsel gerade in Hamburg war, durch neue Kontakte und auch durch meine Arbeit bin ich immer weiter gedanklich in den Unix/Linux Bereich vor gedrungen. Und dann stieß ich auf ucLinux. Eine Portierung des Linux-Kernel auf Architekturen ohne MMU, wie den Cortex-Mx und Cortex-Rx. Die Portierung ist sogar bereits in der Mainline des Kernel enthalten, es lässt sich also ein Linux Kernel für das STM32F429-Discovery bauen ohne weitere Anpassungen. Dazu gibts auch YT-Videos usw. 

Dieser Talk vom dies jährigen CCC https://media.ccc.de/v/33c3-7946-console_hacking_2016 ist übrigens Schuld :).

Das Thema ucLinux schien aber unter den Linux-Entwicklern etwas eingeschlafen zu sein und erst in letzter Zeit tut sich an der Front wieder mehr. Ich habe mir Deshalb zum Testen des Ganzen und auch für ein anderes Projekt das 32F769I-Discovery gekauft. Dieses Board ist jetzt mein erstes Opfer für meine Einarbeitung in die Linux-Entwicklung und die Portierung des Kernel auf eben dieses Boards. Da ich in dem Bereich quasi keine Erfahrung habe wird das sehr interessant für mich. Meinen Fortschritt werde ich dann hier zu gegebener Zeit veröffentlichen. 

Architektur

Noch kurz zu dem was ich eigentlich vorhabe. Die Cortex-M7 haben einen sog. TCM (tightly coupled memory). Dieser RAM Bereich hängt direkt an dem 64Bit breiten Hauptbus des Prozessorkerns. Der Speicher ist quasi genauso schnell wie der Cache der CPU. In diesen Speicher lädt ein Linux Treiber den Code des Reglers. Ein hoch priorisierter IRQ führt dann immer die Funktion aus. Da man beim Cortex-M die Interrupts nesten kann und hoch priore Interrupts gezielt aktiv gelassen werden können, auch wenn Linux in einer Critical-Section ist, hat der IRQ keine zusätzliche Latenz außer die Normale die auch im Bare Metal Betrieb da sein würde (9-11 Takte oder so). 

Das Problem dabei ist, der Regler darf auf keine Strukturen des Linux Bereiches zugreifen zu keiner Zeit. Denn ein Zugriff durch den Regler, wenn Linux nicht damit rechnet führt im schlimmsten Fall zum crash. Deshalb muss ich einen RAM Bereich für Parameter zum Regler auf dem der Regler nur ließt und einen RAM Bereich auf dem Linux nur ließt definieren. Außerdem sind die Daten auf 32Bit Breite Typen begrenzt, weil die vom Prozessor grundsätzlich in einer Instruktion gesetzt werden können. 

Interessant wird auch wie sich der Prozessor verhält wenn Linux eine Exception, wie einen Hard-Fault haben sollte, läuft dann der IRQ für den Regler noch? Kann Linux ggf. den verursachenden Prozess killen und der Umrichter läuft weiter? Das wäre ein Träumchen aber wir werden sehen.

Aber bis ich das so hin habe vergeht noch viel Zeit :) ist ja Hobby.

Schaltverluste verringern

Bei meinem letzten Post kam ich rechnerisch auf ca. 45W Schaltverluste. Um diese Wärme abzuführen kommt man, um aktive Kühlung nicht herum. Jedoch stellt sich die die Frage, wie kann man diese Verluste verringern? Ganz klar mit einer geringeren Schaltfrequenz. Geht man von 24kHz auf 8kHz so bleiben nur 15W Schaltverluste übrig. Aber 8kHz sind nicht schön anzuhören und die Regelfrequenz ist auf höchstens 16kHz begrenzt. Was kann man also tun um die Verluste elektrotechnisch runter zu bekommen?

Und hier gehe ich auf dünnes Eis. Deshalb sind die nach folgenden Infos als meine derzeitige Meinung anzusehen. 

Also warum entstehen Schaltverluste? Der Strom bleibt durch die Wicklungsinduktivität weit gehend konstant und die über den FETs abfallende Spannung steigt an im Schaltmoment. Wenn in diesem Umschaltmoment ein anderes Bauteil den Strom übernimmt während die FETs Umschalten so reduziert das massiv die Schaltverluste. Weil diese proportional zu dem von den FETs geführten Strom sind.

Zur Erklärung gehe ich von einem einzigen Schaltvorgang aus. Es sei die Highside gerade aktiv und die Lowside soll einschalten.
Außerdem sei ein Kondensator mit einer hohen Impulsstromfestigkeit von der Phase zur Lowside respektive GND eingebaut.
Dieser Kondensator ist auf $U_{BAT}$ geladen. Durch die Phase fließt ein Strom von 82A in eine stark induktive Last.

Jetzt schaltet die Highside ab. Der Strom will auf Grund der Induktivität der Last konstant bleiben. Da der Widerstand zur $U_{BAT}$ durch das Abschalten der Highside steigt, muss der Kondensator zwischen der Phase und GND den Strom weiter tragen. Das kann der Kondensator solange wie er genügend Ladung hat. Aber so lange sind die FETs quasi Stromlos und können ohne Verluste umschalten.

Snubber

Bei Umrichtern mit hoher Leistung verwendet man gern sogenannte Snubberglieder. Der Kondensator zwischen Phase und GND von dem ich schrieb ist quasi so ein Snubber. Jedoch werden Snubber eigentlich dafür eingesetzt um die Spannungsspitze, welche entsteht wenn während der Totzeit der High- und Lowside kein FET leitend ist, abzufangen bzw. zu dämpfen. 

Bei den Spannungen bei denen ich hier arbeite habe ich jedoch keine allzu lange Totzeit. Allein schon deshalb weil ich die FETs sehr schnell umschalten kann, ohne das mein dV/dt an der Phase weit über 400V/µs steigt. was wiederum die EMV auf einem vernünftigen Maß hält. 

Eine Frage ist aber noch offen. Wie dimensioniere ich so einen Kondensator. Ich wähle hier einen Kerko mit hoher Spannungsfestigkeit und sehr geringem Innenwiderstand (Große Bauform bei wenig Kapazität).

$\cfrac{dU}{dt} = \cfrac{I}{C} = \cfrac{\approx 100V}{200ns} = 400V/µs $

$\cfrac{I}{\cfrac{dU}{dt}} = C = \cfrac{82A}{400V/µs} = 205nF$

Um den Strom durch die FETs mit einer flacheren Spannungskurve abzufangen brauche ich einen 200nF Kondensator an jeder Phase jeweils gegen GND für den Schaltvorgang High -> Low und von der Phase gegen $U_{BAT}$. 

In der Realität ist das alles natürlich nicht so einfach aber es ist eine schöne Vorstellung. 

Und deshalb hoffe ich jetzt, dass das funktioniert. :)

Berechnen der Schaltverluste einer dreiphasigen Brücke

Auch dieser Beitrag basiert wieder auf der App-Note "Calculating Motor Driver Power Dissipation" von TI. Bei allen verwendeten Daten beziehe ich mich ebenfalls wieder auf mein letztes Brücken-Design.

• Betriebsparameter
• $U_{BAT} = 4,2V \cdot 18 = 75,6V$
• $I_{BAT} = 100A$ 
• PWM Frequenz: 24kHz 
• MosFETs
• $R_{DS(ON)_{MAX}}  = 4,5m\Omega$
• $Q_g = 58nC$
• 8 x FETs parallel

Treiberleistung

Der Vollständigkeit halber will ich auch kurz auf den Leistung- bzw. Strombedarf des Treibers eingehen. Dabei beziehe ich mich auf das Wiki von mikrocontroller.net zu MosFet-Treibern. Dort wird die Treiberleistung wie folgt berechnet.

$P_{Drv} = f_{sw} \cdot Q_{g_{Gesamt}} \cdot U_{Drv}$

Die Spannung $U_{Drv}$ ist hier die Spannungsversorgung des Treibers und damit die Spannung auf die die Gates umgeladen werden. Das die Highside noch 0,7V über die Bootstrap-Diode einbüßt vernachlässige ich in den folgenden Rechnungen. 

Die Ladung $Q_{g_{Gesamt}}$ steht hier für die Total-Gate-Charge $Q_g$ aller mit der PWM Frequenz $f_{sw}$ geschalteten FETs. In meinem Fall also $48 \cdot 58nC = 2784nC$. 

$P_{Drv} = f_{sw} \cdot Q_{g_{Gesamt}} \cdot U_{Drv} = 24kHz \cdot 2784nC \cdot 12V = 0,8W$

Daraus lässt sich dann auch der Strombedarf für den Treiber mit $I_{Drv} = \cfrac{P_{Drv}}{U_{Drv}} = \cfrac{0,8W}{12V} = 67mA$ berechnen.

Schaltverluste

Wirklich zubuche schlagen aber die eigentlichen Schaltverluste während des Umschaltens zwischen Low- und Highside.

Dafür setzt man üblicherweise eine linear steigende/fallende Spannung bei konstantem Strom voraus. Die Fläche des Spannungsdreiecks bestimmt damit die eigentliche Schaltverlustleistung. TI gibt deshalb pro Phase folgende Gleichung an:

$P_{sw_{Ph}} = 0,5 \cdot U_{BAT} \cdot  I \cdot t_{rf} \cdot f_{sw}$

Bis auf die Anstiegs- bzw. Fallzeit der Spannung sind alle benötigten Werte bereits bekannt. Für eine halbwegs gute Näherung setze ich einfach mal an, das der LM5101A 3A in die Gates von 8 FETs schiebt. Um die Gateladung der FETs mit 3A auf 12V zu laden braucht er:

$t_{rf} = \cfrac{8 \cdot Q_g}{3A} = \cfrac{8 \cdot 58nC}{3A} = 154ns$

Ja dabei vernachlässige ich bewusst die Abflachung des Anstiegs je höher die Spannung steigt. Aber im Grunde muss der FET ja auch nur über seinen Threshold und das ist bei 63% von 12V auf jeden Fall so. Zur Sicherheit nehme ich $t_{rf} =200ns$ an.

$P_{sw} = 3 \cdot 0,5 \cdot U_{BAT} \cdot  I \cdot t_{rf} \cdot f_{sw} = 1,5 \cdot 75,6V \cdot 82A \cdot 200ns \cdot 24kHz = 44,6W$

Gesamtverluste der Brücke

Alles in allem komme ich so auf eine Verlustleistung $P_v = 11,4W + 0,8W + 44,6W = 56,8W$. Wenn die Brücke bei dieser Verlustleistung bei 30°C Umgebungstemperatur nicht die zulässige Sperrschichttemperatur der FETs von 150°C übersteigen soll dann muss der thermische Widerstand der Kühlung unter $\cfrac{150°C - 30°C}{56,8W} = 2\cfrac{K}{W}$ liegen. 

Da ist es goldwert 48 FETs zuhaben. Denn ein FET allein hat bereits einen thermischen Widerstand von der Sperrschicht zum Gehäuse von $\approx1\cfrac{K}{W}$. Dieser reduziert sich glücklicherweise bei 48 FETs die doppelseitig an einen Kühlkörper angebunden sind auf  $\approx1/96\cfrac{K}{W}$ sprich $\approx0,01\cfrac{K}{W}$. Nichts desto trotz sind Kühlkörper mit weniger als $2\cfrac{K}{W}$ nicht gerade klein geschweige den leicht.

Wie ich das gekühlt bekomme werden ich sehen wenn der elektrische Aufbau steht.

Soweit erstmal die mathematische Auslegung. 

Die Tücken der Verlustleistung

Gleich vorweg der ganze Beitrag basiert auf der App-Note "Calculating Motor Driver Power Dissipation" von TI. Bei allen verwendeten Daten beziehe ich mich auf mein letztes Brücken-Design.

• Betriebsparameter
• $U_{BAT} = 4,2V \cdot 18 = 75,6V$
• $I_{BAT} = 100A$ 
• MosFETs
• $R_{DS(ON)_{MAX}}  = 4,5m\Omega$
• $Q_g = 58nC$
• 8 x FETs parallel

Durchlassverluste

Die App-Note geht hier zwar von einem DC Motor aus, aber das lässt sich ja auf Drehstrom übertragen. Für DC setzt TI folgende Gleichung an:

$P = (R_{DS(ON)_{HS}} \cdot I^2) + (R_{DS(ON)_{LS}} \cdot I^2)$

Der Strom fließt also aus der Highside in die Lowside und passiert bei einer DC-Vollbrücke genau zweimal einen FET. Bei einer dreiphasigen Maschine fließt in allen 3 Phasen der Strom. Deshalb passiert der Strom eine Lowside und zwei Highsides oder umgekehrt. Da nie die Highside und die Lowside einer Phase gleichzeitig aktiv sind (sein sollen) und die Thermodynamik langsam ist sieht die Gleichung für dreiphasenige System so aus:

$P_v = 3 \cdot (R_{DS(ON)} \cdot I^2)$

Ich habe hier gleich die $R_{DS(ON)}$ zusammen gefasst, weil alle gleich sind.

Jetzt ist aber noch eine Frage offen für die Berechnung der Verlustleistung. Wie hoch ist $I$ eigentlich? Da setze ich einfach mal den Energieerhaltungssatz an. Die Energie die rein geht muss auch wieder raus. Wenn man jetzt noch annimmt, dass der Wirkungsgrad des Umrichters $\approx1$ ist. Gehen schlanke $ U_{BAT} \cdot I_{BAT} = P_{BAT} = 75,6V \cdot 100A = 7560W$ von der Batterie in den Umrichter. Und die müssen ja auch wieder raus, aber da wird es dann auch wieder knifflig.

Warum? Weil der Innenwiderstand der Motoren so niedrig ist wird die Länge des Spannungsvektors nahezu allein durch die Drehzahl der Maschine bestimmt. (EMK Spannung) Der Spannungsabfall über dem Wicklungsinnenwiderstand kann vernachlässigen. Das Problem ist also wie sieht die Betriebsdrehzahl des Antriebs aus. Für ein Traktionsantrieb, also Fahrrad, KFZ usw. ist die Leerlaufdrehzahl der Maschine kein normaler Betriebspunkt. Da wird sich die Drehzahl im Mittel auf 50% der Leerlaufdrehzahl der Maschine belaufen. Bei einem Propellerantrieb, hingegen ist eine Betrieb nahe der Leerlaufdrehzahl sehr wahrscheinlich.

Langer Rede kurzer Sinn: Niedrige Drehzahlen bedeuten mehr Strom und damit ist der Antrieb als auch der Umrichter in einem ungünstigeren Betriebspunkt. ABER: Das soll ja eine Abschätzung sein und deshalb nehmen wir einfach einen Betriebspunkt und zwar Leerlaufdrehzahl und volle Lotte Strom. Bei voller Leerlaufdrehzahl muss der Umrichter den längst möglichen Spannungsvektor fahren.

Stern oder Dreieck

Egal. Zumindest für den Umrichter. Für die Rechnung nicht. Und um diese möglichst "einfach" zu halten nehme ich Stern an. Weiterhin sage ich an dem Motor liegt ein gültiger Spannungsvektor von $[1; 0,5; 0]$ an. Phase A ist hierbei fest auf $U_{BAT}$, Phase B bekommt eine 50% PWM und Phase C liegt fest auf $GND$. In dem Fall sehen die Spulen A und C eine Spannung von $0,5 \dot U_{BAT}$. Bei geschickter Modulation (SVPWM) lassen sich ca. 15% mehr Spannungshub rausholen. Deshalb sieht jede Spule im Stern maximal $1,15 \cdot 0,5 \cdot U_{BAT}$. 

Für die Leistungsberechnung ist aber nicht der Spitzenwert, welchen wir jetzt berechnet haben , interessant sondern der RMS Wert. Somit ergibt sich eine wirksame Spannung von

$U_L = \cfrac{1,15 \cdot 0,5 \cdot 75,6V}{\sqrt(2)} = 30,74V$

pro Phase. Weil wir drei Phasen haben die mit $P = U \cdot I$ zusammen auf $7560W$ kommen sollen, muss noch etwas umgestellt werden und siehe da:

$I = \cfrac{ P_{BAT}}{3 \cdot U_L} = \cfrac{7560W}{3 \cdot 30,74V} = 82A$

Es fließt also ein Strom mit dem Effektivwert von $82A$ durch jede Phase und damit durch jeden aktiven $R_{DS(ON)}$

$P_v = 3 \cdot (R_{DS(ON)} \cdot I^2) = 3 \cdot (\cfrac{4,5m\Omega}{8} \cdot 82A^2 = 11,4W$

Und spätesten die $11,4W$ sollten jedem klar machen, dass dieses Brücken Design mit 65x85mm echt klein ist. Ich bin gespannt. 

Die Schaltverluste kommen Morgen im nächsten Post.

Leistungsbrücke: "Monster MK II"

Als die CPU feststand habe ich erst einmal überlegt, wie ich eine deutlich leistungsfähigere Brücke, als die des TDC bauen kann.

Die Schlüsselerkenntnis aus dem TDC ist für mich: Leiterbahnen haben einen NICHT zu vernachlässigenden Widerstand :).

Aber mehr als 70µm Kupferauflage ist für Einzelstücke quasi nicht zu bezahlen, bzw. will ich nicht allein für die unbestückte Platine 500€ ausgeben. Deshalb musste eine einfache Platine mit 4 Lagen a 70µm Kupfer reichen. Wirklich Strom bekommt man da aber nur mit mehr Fläche durch. Oder ....

Leiterquerschnitt erhöhen

Bei günstiger Leistungselektronik sieht man immer wieder aufgelötete massive Kupferdrähte, die den leitenden Querschnitt einer Leiterbahn erhöhen sollen. Aber dafür muss ich viele Kupferdrähte ziehen, zuschneiden und auflöten was ziemlich fummelig ist und dafür bringt es immer noch zu wenig Querschnitt. Da hilft nur richtig massives Material. Deshalb habe ich mir 6x3mm Flachkupfer Stäbe auf ebay bestellt. Die kann ich hochkant auf die Platine löten und komme so auf mehr als 18mm² Querschnitt (es kommt ja noch die Bahn darunter mit dazu). Nach VDE Norm kann ein 16mm² Leiter frei in der Luft verlegt 98A bei einer Umgebungstemperatur von 30° ab.

Ich bin gespannt wie sich die Temperatur bei meinem Aufbau verhlt. Aber da die Flachkupferstangen stehend verlötet sind bilden sie quasi "Kühlrippen" und ich erhoffe mir jetzt einfach mal, dass das etwas bringt 😉.

Die FETs

Da mache ich keine großen Experimente. Ich bleibe bei SO-8 ähnlichen Gehäusen nur braucht es bei dem Strom ein paar mehr. Meine Wahl fiel auf die TPW4R50ANH. 

Absolute Maximum Ratings

Characteristics	Symbol	Rating	Unit
Drain current	ID	92	A
Power Dissipation	PD	142	W
Drain-Source voltage	VDSS	100	V
Gate-Source voltage	VGSS	+/-20	V

Electrical Characteristics

Characteristics	Symbol	Condition	Value	Unit
Input capacitance (Typ.)	Ciss	-	4000	pF
Total gate charge (Typ.)	Qg	-	58	nC
Drain-Source on-resistance (Max)	RDS(ON)	|VGS|=10V	0.0045	Ω

Mit einer Spannungsfestigkeit bis 100V ist dann auch gleich der Spannungsbereich fix. Für 18 - 20S (72V) sollten diese FETs hobbytaublich Dimensioniert sein. 60V Batteriespannung sollten aber sicher problemlos möglich sein. 

Außerdem war für mich das DSOP-Gehäuse der FETs ein wichtiges Auswahlkriterium. Denn das Gehäuse führt den Source Kontakt an der Gehäuseoberseite flächig nach außen.

Toshiba nennt das dann "double sided cooling". Das Prinzip ist aber ähnlich wie bei den Directfets von Infineon/IR.

Nur kosten die 1/3 von dem was ein vergleichbarer Directfet kostet. 

Die Frage ist jetzt noch wie viele von den FETs schaltet man parallel. Antwort: Soviele wie möglich 😁

Leider gibt es Grenzen. Damit die FETs in den Genuss von doppelseitiger Kühlung kommen, müssen alle auf die selbe Platinenseite. Sonst würden sich die FETs gegenseitig erwärmen. Denn die Lötseite des DSOP-Gehäuses ist immer noch, die mit dem besten Wärmewiderstand. Wenn jetzt aber alle FETs auf eine Seite kommen, darf auf der Seite auch kein höheres Bauteil bestückt werden, wenn ich einen unbearbeiteten Kühlkörper verwenden will. Da ist dann 0402 angesagt. (Die FETs sind 0,8mm hoch, 0402 ist 0,5mm hoch)

Ausgehend vom TDC der mit 2 ungekühlten FETs ca. 20A dauerhaft fahren kann und ich auf 100A kommen will brauche ich schlanke 10 FETs in parallel...puhhh. Aber die Kühlung ist ja besser 😉

macht also 8 FETs. Außerdem klingt 48 auch besser als 60 FETs. Das macht dann lumpige 464nC Total Gate Charge insgesamt. Eigentlich kein schlechter Wert. 2 Dicke D²-PAK-7 FETs haben mehr.

Der Gate-Treiber

Eigentlich wollte ich meinen Feld, Wald und Wiesen Treiber den IR2186 nehmen, doch dann hatte ich kurzzeitig die Schnapsidee einen isolierten Gatetreiber zu verwenden. Da ich dafür 4 separate isolierte 12V DC/DC Wandler bräuchte fällt das gleich flach. Aber beim recherchieren nach isolierten Treibern ist mir ein Kennwert aufgefallen, der bei unisolierten Treiber quasi nicht erwähnt wird. Die Propagation Time, also die Zeit zwischen logischem Eingang auf High und dem High am Ausgang des Treibers. Und da ist der Steinzeit IR2186 auf dem Niveau eines normalen isolierten Treibers. Der braucht dafür 170ns!!! Folglich habe ich mich mal auf die Suche nach einem neuen Treiber begeben und ich bin bei TI fündig geworden. Der LM5101A hat einen Propagation Delay von nur 25ns und ist auch noch in fast allen anderen Werten besser. Einziger Haken ist er kann nur 100V ab. Was mich aber nicht stört, mehr können die FETs auch nicht. 

Die Strommessung

Wenn ich die Leitfähigkeit der Bahnen erhöhe dann muss ich mir auch die Strommessung als solches vornehmen. Aber meine aktuelle Lieblingstechnologie bietet auch hier Linderung. Der AMC1304M05 hat einen Eingangsspannungsbereich von +/-50mV bei einem SNR von 80dB typisch.

(20dB  entsprechen Faktor 10, da dB eine logarithmische Einheit ist bedeutet eine Addition von 20dB + 20dB = 40dB  = 10x10 = 100, bei 80dB SNR ergibt sich ein Signal zu Rauschabstand von 1 zu 10000, 20dB x 4 => 4 Nullen hinter der 1) 

Er löst also auf ca. 5µV effektiv auf 😎. Als Shunt passt da wunderbar der WSLP5931 von Vishay mit 0,3mR. Damit bin ich bei einer absoluten Messbereichsgrenze von 216A und einer linearen Messung von +/-166A. Außerdem kann der AMC1304M05 über die Bootstrap Spannung der High Side FETs versorgt werden, den er hat einen internen LDO. Leider merkt man dass auch am Gehäuse Wide Body SOIC-16. 

Das Board

KiCAD Daten: https://bitbucket.org/thunderdrive/power_bridge

STM32F767 oder STM32H743 mit Delta Sigma Demodulatoren

Nach dem mich ein stiller Mitleser daran erinnert hat, dass den Blog vllt. doch jemand ließt schreibe ich wieder. Zumal ich meine Gedanken mal wieder nieder Schreiben muss, sonst drehe ich gedanklich noch 5 Runden nur im vor den selben Entscheidungen zustehen.

In meinem letzten Post habe ich zwischen den XMC4xxx von Infineon und dem ADSP-CM4xx von Analog geschwankt. Der XMC war mir zu langsam allein von den Daten her. Der ADSP-CM4xx ist schlecht erhältlich  und es existiert quasi kein GCC portierter Code für den Prozessor. Alle Libs von Analog sind für IAR. Drum habe ich mich sehr über die STM32F76x Prozessoren mit Delta Sigma Demodulatoren gefreut. Dabei habe ich die Ankündigung für den STM32H743 gesehen, den es auch noch in LQFP100 gibt.

Da der STM32H743 und die STM32F76x pinkompatibel sein sollen habe ich mich auf den STM32F767 in LQFP festgelegt. Mit der Option später auf einen STM32H7 upgraden zu können. Außerdem bietet der STM32H743 noch eine HRPWM, die vllt. noch eine Möglichkeit ist um die Systemgenauigkeit weiter zu erhöhen.