feat: Add contribution guidelines and hardware config
- Adds CONTRIBUTING.md and a German translation to establish commit message conventions. - Creates a Hardware/ directory with a .gitignore for KiCad projects. - Refactors and improves the power supply documentation.
This commit is contained in:
parent
3057968c85
commit
f01077cf75
|
|
@ -0,0 +1,44 @@
|
|||
# Richtlinien für Beiträge (Contribution Guidelines)
|
||||
|
||||
Um eine konsistente und lesbare Git-Historie zu gewährleisten, folgt dieses Projekt der [Conventional Commits](https://www.conventionalcommits.org/) Spezifikation.
|
||||
|
||||
**Wichtiger Hinweis:** Alle Commit-Nachrichten müssen auf **Englisch** verfasst werden. Dieses Dokument dient nur dem deutschsprachigen Verständnis der Regeln.
|
||||
|
||||
## Format der Commit-Nachricht
|
||||
|
||||
Jede Commit-Nachricht besteht aus einem **Header**, einem **Body** und einem **Footer**.
|
||||
|
||||
```
|
||||
<type>[optional scope]: <description>
|
||||
|
||||
[optional body]
|
||||
|
||||
[optional footer]
|
||||
```
|
||||
|
||||
### Type (Typ)
|
||||
|
||||
Der Typ ist eine Kennzeichnung, die am Anfang der Betreffzeile steht und den Inhalt des Commits klassifiziert. Er muss einer der folgenden sein:
|
||||
|
||||
* **feat**: Eine neue Funktion für den Benutzer (a new feature).
|
||||
* **fix**: Eine Fehlerbehebung für den Benutzer (a bug fix).
|
||||
* **docs**: Änderungen an der Dokumentation.
|
||||
* **style**: Änderungen, die die Bedeutung des Codes nicht beeinflussen (Formatierung, Leerräume, fehlende Semikolons usw.).
|
||||
* **refactor**: Eine Code-Änderung, die weder einen Fehler behebt noch eine Funktion hinzufügt.
|
||||
* **perf**: Eine Code-Änderung, die die Leistung verbessert.
|
||||
* **test**: Hinzufügen oder Korrigieren von Tests.
|
||||
* **chore**: Änderungen am Build-Prozess oder an Hilfswerkzeugen und Bibliotheken (z.B. Dokumentationsgenerierung).
|
||||
* **build**: Änderungen, die das Build-System oder externe Abhängigkeiten betreffen.
|
||||
* **ci**: Änderungen an CI-Konfigurationsdateien und Skripten.
|
||||
|
||||
### Description (Beschreibung)
|
||||
|
||||
Die Beschreibung ist eine kurze Zusammenfassung der Code-Änderungen. Sie sollte im Imperativ und Präsens verfasst sein (z.B. "add feature" anstatt "added feature" oder "adds feature").
|
||||
|
||||
### Breaking Changes (Wichtige Änderungen)
|
||||
|
||||
Ein Commit, der eine inkompatible API-Änderung einführt, muss im Footer mit `BREAKING CHANGE:` beginnen. Ein "BREAKING CHANGE" kann Teil jedes Commit-Typs sein.
|
||||
|
||||
---
|
||||
|
||||
*Dieses Dokument ist eine Zusammenfassung. Weitere Details finden Sie in der [offiziellen Conventional Commits Spezifikation](https://www.conventionalcommits.org/en/v1.0.0/).*
|
||||
|
|
@ -0,0 +1,42 @@
|
|||
# Contribution Guidelines
|
||||
|
||||
To ensure a consistent and readable git history, this project adheres to the [Conventional Commits](https://www.conventionalcommits.org/) specification.
|
||||
|
||||
## Commit Message Format
|
||||
|
||||
Each commit message consists of a **header**, a **body**, and a **footer**.
|
||||
|
||||
```
|
||||
<type>[optional scope]: <description>
|
||||
|
||||
[optional body]
|
||||
|
||||
[optional footer]
|
||||
```
|
||||
|
||||
### Type
|
||||
|
||||
The type must be one of the following:
|
||||
|
||||
* **feat**: A new feature for the user.
|
||||
* **fix**: A bug fix for the user.
|
||||
* **docs**: Changes to the documentation.
|
||||
* **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc).
|
||||
* **refactor**: A code change that neither fixes a bug nor adds a feature.
|
||||
* **perf**: A code change that improves performance.
|
||||
* **test**: Adding missing tests or correcting existing tests.
|
||||
* **chore**: Changes to the build process or auxiliary tools and libraries such as documentation generation.
|
||||
* **build**: Changes that affect the build system or external dependencies.
|
||||
* **ci**: Changes to our CI configuration files and scripts.
|
||||
|
||||
### Description
|
||||
|
||||
The description is a short summary of the code changes. Use the imperative, present tense: "change" not "changed" nor "changes".
|
||||
|
||||
### Breaking Changes
|
||||
|
||||
A commit that has a footer beginning with `BREAKING CHANGE:` introduces a breaking API change. A BREAKING CHANGE can be part of any type of commit.
|
||||
|
||||
---
|
||||
|
||||
*This document provides a summary. For more details, please refer to the [official Conventional Commits specification](https://www.conventionalcommits.org/en/v1.0.0/).*
|
||||
|
|
@ -0,0 +1,54 @@
|
|||
# KiCad
|
||||
# Ignore backup files
|
||||
*.bak
|
||||
*.bck
|
||||
*~
|
||||
#*
|
||||
.#*
|
||||
*.kicad_pcb-bak
|
||||
*.kicad_pro.bak
|
||||
*.kicad_sch.bak
|
||||
|
||||
# Ignore automatically generated files
|
||||
*.erc
|
||||
*.net
|
||||
*-cache.lib
|
||||
*-rescue.lib
|
||||
*.dcm
|
||||
*.lib
|
||||
*.mod
|
||||
*.cmp
|
||||
*.gbr
|
||||
*.drl
|
||||
*.pos
|
||||
*.rpt
|
||||
*.log
|
||||
*.zip
|
||||
*.pdf
|
||||
*.svg
|
||||
*.png
|
||||
*.json
|
||||
*.html
|
||||
*.xml
|
||||
*.csv
|
||||
*.txt
|
||||
*.bom
|
||||
*.kicad_wks
|
||||
*.kicad_dru
|
||||
*.kicad_sym
|
||||
*.kicad_mod
|
||||
*.fpc
|
||||
*.kicad_prl
|
||||
|
||||
# Project local settings files and backups
|
||||
*.kicad_prl
|
||||
|
||||
# macOS specific files
|
||||
.DS_Store
|
||||
._*
|
||||
|
||||
# Windows specific files
|
||||
Thumbs.db
|
||||
|
||||
# Editor/OS fluff
|
||||
*.swp
|
||||
|
|
@ -84,32 +84,32 @@ graph TD;
|
|||
## Detailbeschreibung
|
||||
### Externe Quellen
|
||||
#### USB-C Port
|
||||
Das Gerät verfügt über einen USB-C-Port, der sowohl der Datenübertragung als auch der Energieversorgung dient. Das Gerät kann sowohl an einem PC/Laptop als auch an gängigen Netzteilen (Handy-Ladegerät, USB-C Laptop-Netzteil etc.) geladen werden. Dabei muss der jeweils verfügbare Strom beachtet werden. Mehr dazu unter [Lader](#lader).
|
||||
Das Gerät verfügt über einen USB-C-Port, der sowohl der Datenübertragung als auch der Energieversorgung dient. Es kann an einem PC/Laptop sowie an gängigen Netzteilen (Handy-Ladegerät, USB-C Laptop-Netzteil etc.) geladen werden. Dabei muss der jeweils verfügbare Strom beachtet werden. Mehr dazu unter [Lader](#lader).
|
||||
|
||||
#### Debug Port
|
||||
Damit das Gerät auch bei ausschließlich gesteckter Debug-Verbindung funktioniert, können 5V auf den Debug-Port eingespeist werden. Bei den meisten Debug-Adaptern ist der verfügbare Strom begrenzt, weshalb von diesem Eingang maximal 300mA bezogen werden dürfen.
|
||||
|
||||
### Batterien
|
||||
#### Li-Ion-Akku
|
||||
Als Akku sind zwei parallelgeschaltete 18650-Zellen vorgesehen. Diese werden mittels Nickelstreifen verschweißt, mit einem NTC-Temperatursensor versehen und eingeschrumpft. Die Verbindung zur Schaltung ist vierpolig ausgeführt, da die [Akkuschutzschaltung](#akkuschutz) auf der Hauptplatine (PCB) und nicht im Akku selbst integriert ist. Würde die Schutzschaltung die Minus-Verbindung trennen, wäre der NTC ohne definiertes Potenzial (floatend). Wenn in diesem Zustand eine externe Versorgung angeschlossen wird, würde der [Lader](#lader) den NTC nicht erkennen und den Ladevorgang verweigern. Die Verbindung ist daher als `BAT+`, `BAT-`, `NTC` und `GND` ausgeführt.
|
||||
Als Akku sind zwei parallelgeschaltete 18650-Zellen vorgesehen. Diese werden mittels Nickelstreifen verschweißt, mit einem NTC-Temperatursensor versehen und eingeschrumpft. Die Verbindung zur Hauptplatine ist vierpolig (`BAT+`, `BAT-`, `NTC`, `GND`), da sich die [Akkuschutzschaltung](#akkuschutz) auf der Hauptplatine befindet. Diese trennt im Fehlerfall die `BAT-` Leitung vom Rest der Schaltung (`GND`). Wäre der NTC-Temperatursensor nur zwischen `BAT+` und `BAT-` angeschlossen, hätte er nach einer Trennung kein definiertes Potenzial mehr (floating). Ein an `GND` referenzierter Messeingang am [Lader](#lader) könnte die Temperatur nicht mehr korrekt erfassen. Durch die separate `GND`-Verbindung für den NTC wird dieses Problem umgangen.
|
||||
|
||||
#### Akkuschutz
|
||||
Als Akkuschutz wird ein **FM2113** verbaut. Dieser steuert zwei N-Kanal-MOSFETs (für Laden und Entladen), die in einer Common-Drain-Schaltung zwischen `BAT-` und `GND` platziert sind. Der Baustein schützt vor *Überladung*, *Tiefentladung* und *Überstrom*.
|
||||
Als Akkuschutz kommt ein **FM2113** zum Einsatz. Dieser steuert zwei N-Kanal-MOSFETs (für Laden und Entladen), die in einer Common-Drain-Schaltung zwischen `BAT-` und `GND` platziert sind. Er schützt den Akku vor *Überladung*, *Tiefentladung* und *Überstrom*.
|
||||
|
||||
#### Fuel Gauge
|
||||
Als Fuel Gauge wird der **BQ27441-G1** von Texas Instruments eingesetzt. Der ursprünglich vorgesehene **BQ27427** ist nur für einen Dauerstrom von 2A ausgelegt, womit die vollen Möglichkeiten des [Laders](#lader) und des [Li-Ion-Akkus](#li-ion-akku) nicht ausgenutzt werden könnten.
|
||||
Zur Strommessung ist ein `0.01Ω` Shunt-Widerstand vorgesehen. Hierbei ist vor allem die Temperaturstabilität maßgeblich, da der genaue Widerstandswert im BQ27221 konfiguriert/kalibriert werden kann.
|
||||
Die Verlustleistung am Widerstand ist relativ gering:
|
||||
$$
|
||||
Als Fuel Gauge wird der **BQ27441-G1** von Texas Instruments eingesetzt. Der ursprünglich vorgesehene **BQ27427** ist nur für einen Dauerstrom von 2A ausgelegt, wodurch das Potenzial des [Laders](#lader) und des [Li-Ion-Akkus](#li-ion-akku) nicht ausgenutzt werden könnte.
|
||||
Zur Strommessung ist ein `0.01Ω` Shunt-Widerstand vorgesehen. Hierbei ist die Temperaturstabilität des Widerstands wichtiger als sein exakter Wert, da dieser in der Fuel Gauge kalibriert werden kann.
|
||||
Die Verlustleistung am Widerstand ist mit 90mW bei 3A gering:
|
||||
$$
|
||||
\begin{align}
|
||||
P &= R \cdot I^2 \\
|
||||
&= 0.01\text{Ω} \cdot (3\text{A})^2 \\
|
||||
&= 0.09\text{W}
|
||||
P &= R \cdot I^2 \\
|
||||
&= 0.01\text{Ω} \cdot (3\text{A})^2 \\
|
||||
&= 0.09\text{W}
|
||||
\end{align}
|
||||
$$
|
||||
Obwohl diese Verlustleistung von 90mW bereits ein 0603-SMD-Widerstand verkraften würde, wird hier ein Widerstand der Bauform 1206 vorgesehen, um eine saubere 4-Leiter-Messung (Kelvin-Verbindung) zu ermöglichen.
|
||||
$$
|
||||
Obwohl diese Verlustleistung bereits ein 0603-SMD-Widerstand verkraften würde, wird hier ein Widerstand der Bauform 1206 vorgesehen, um eine saubere 4-Leiter-Messung (Kelvin-Verbindung) zu ermöglichen.
|
||||
Die Konfiguration der Fuel Gauge kann über die TI-Software und einen entsprechenden Adapter erfolgen. Dazu kann der Adapter an einen externen I²C-Anschluss (z.B. OLED- oder Tasten-Controller-Anschluss) angeschlossen werden. Dabei ist sicherzustellen, dass auf dem Mikrocontroller keine Software aktiv ist, die einen I²C-Master implementiert.
|
||||
Dieser IC bietet nicht die Möglichkeit, die Temperatur über einen NTC zu messen, er kann nur die interne Temperatur messen oder die Temperatur über I²C erhalten. Deshalb wird die Temperatur während des Betriebs und einer gewissen Nachlaufzeit vom Mikrocontroller beim Ladechip abgefragt und dann an die Gauge weitergeleitet. Wenn das System ausgeschaltet ist und der Akku thermisch stabil, dann wird auf die interne Messung umgeschaltet. Die Temperatur der Gauge und des Akkus sollten dann nicht allzu sehr voneinander abweichen.
|
||||
Da der BQ27441-G1 keine NTC-Schnittstelle besitzt, wird eine alternative Methode zur Temperaturerfassung genutzt. Im Betrieb liest der Mikrocontroller die Akkutemperatur vom [Lader](#lader) aus und leitet sie per I²C an die Fuel Gauge weiter. Im Ruhezustand, wenn von einer thermischen Stabilität auszugehen ist, wird auf den internen Temperatursensor der Fuel Gauge zurückgegriffen.
|
||||
```mermaid
|
||||
stateDiagram-v2
|
||||
[*] --> Betrieb
|
||||
|
|
@ -128,7 +128,7 @@ Eine CR1220-Knopfzelle dient als Backup-Versorgung für die RTC. Die Batterie wi
|
|||
|
||||
### Energiewandlung
|
||||
#### Lader
|
||||
Als Ladechip ist der **BQ25672** vorgesehen. Dieser bietet einige Funktionen, die für das Projekt besonders interessant sind:
|
||||
Als Ladechip ist der **BQ25672** vorgesehen. Dieser bietet einige für das Projekt interessante Funktionen:
|
||||
- Erkennung von zwei externen Spannungsquellen und Auslösung von Interrupts bei deren Anschluss oder Trennung.
|
||||
- Einstellbarer Ladestrom von bis zu 3A (in 10mA-Schritten über I²C).
|
||||
- Einstellbare Eingangsstrombegrenzung (über I²C).
|
||||
|
|
@ -138,7 +138,7 @@ Als Ladechip ist der **BQ25672** vorgesehen. Dieser bietet einige Funktionen, di
|
|||
- "Shipping Mode", um den Stromverbrauch auf ein absolutes Minimum zu reduzieren. Dieser Modus kann nur durch Anschließen einer externen Versorgung beendet werden.
|
||||
- Integrierte FETs.
|
||||
|
||||
Eine direkte Erkennung der über USB-C verfügbaren Stromstärken ist damit jedoch nicht möglich. Das ist aber kein Problem, da die CC-Leitungen des USB-C-Steckers einfach über den ADC des Mikrocontrollers ausgewertet werden können. Der geplante Ablauf in der Firmware ist wie folgt:
|
||||
Eine direkte Erkennung der über USB-C verfügbaren Stromstärken ist damit jedoch nicht möglich. Dies stellt jedoch kein Problem dar, da die CC-Leitungen des USB-C-Steckers über den ADC des Mikrocontrollers ausgewertet werden können. Der geplante Ablauf in der Firmware ist wie folgt:
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[START] -->|Anstecken erkannt| B{CC-Leitungen messen}
|
||||
|
|
@ -164,7 +164,7 @@ graph TD;
|
|||
Der "Shipping Mode" kann dazu genutzt werden, ein Wiedereinschalten des Geräts bei niedrigem Akkustand (z.B. `< 3V`) zuverlässig zu verhindern. Zudem ist ein "Lagermodus" vorgesehen, bei dem das Gerät möglichst wenig Energie aus dem Akku entnehmen soll.
|
||||
|
||||
#### 3.3V Buck-Boost-Wandler (DC/DC-Wandler)
|
||||
Der DC/DC-Wandler ist die Hauptenergieversorgung der Schaltung. Da die Spannung des Li-Ion-Akkus von 3V bis 4.2V variieren kann, ist ein Buck-Boost-Design notwendig. Die Wahl fällt dabei auf den **TPS63020**. Die Argumente dafür sind:
|
||||
Der DC/DC-Wandler ist die Hauptenergieversorgung der Schaltung. Da die Spannung des Li-Ion-Akkus von 3V bis 4.2V variieren kann, ist ein Buck-Boost-Wandler notwendig. Die Wahl fiel auf den **TPS63020**, der folgende Vorteile bietet:
|
||||
- Sehr hohe Effizienz
|
||||
- Integrierte FETs
|
||||
- Hohe Schaltfrequenz, was kleine Induktivitäten ermöglicht
|
||||
|
|
@ -175,20 +175,43 @@ Der DC/DC-Wandler wird, wann immer möglich, ausgeschaltet. Weckquellen sind:
|
|||
- RTC
|
||||
- Lader (wenn eine externe Versorgung angeschlossen wird)
|
||||
|
||||
Zusätzlich wird ein GPIO des Mikrocontrollers mit dem ENABLE-Eingang verbunden, damit dieser den DC/DC-Wandler eingeschaltet lassen kann. Dabei müssen die Signale invertiert werden, da sie active-low sind. Die Signale werden über Dioden zusammengefasst und anschließend mit einem N-Kanal-MOSFET invertiert, um Bauteile zu sparen. Somit reichen zwei Doppel-Dioden und ein N-FET, was 3 SOT-323-Gehäusen entspricht.
|
||||
Da die Wecksignale aktiv-low sind, werden sie über Dioden zu einem Wired-OR-Gatter zusammengefasst. Ein nachgeschalteter N-Kanal-MOSFET invertiert das Signal für den aktiv-high Enable-Eingang des Wandlers. Diese Logik stellt zudem sicher, dass der Mikrocontroller den Wandler selbst aktiv halten kann (Latching).
|
||||
|
||||
#### SD Schalter
|
||||
Die SD-Karte hat auch im Ruhezustand einen relativ hohen Stromverbrauch. Um die Energieeffizienz zu erhöhen, wird die Versorgung des Micro-SD-Slots bei Bedarf über einen P-Kanal-MOSFET durch den Mikrocontroller eingeschaltet.
|
||||
Eine SD-Karte kann auch im Ruhezustand einen signifikanten Strom verbrauchen. Um die Energieeffizienz zu erhöhen, wird die Versorgung des Micro-SD-Slots bei Bedarf über einen P-Kanal-MOSFET durch den Mikrocontroller geschaltet.
|
||||
|
||||
#### 3.3V LDO
|
||||
Der 3.3V LDO dient dazu, die RTC und den `VBAT`-Eingang des Mikrocontrollers mit Spannung zu versorgen, wenn der [DC/DC-Wandler](#3-3v-buck-boost-wandler-dc-dc-wandler) ausgeschaltet ist. Die Wahl fällt auf den **XC6206P332MR-G** von Torex, der einen Eigenverbrauch von lediglich 1µA aufweist. Bei einer Akkuspannung unter 3.3V leitet er die Eingangsspannung direkt durch (mit sehr geringem Spannungsabfall). Dies könnte jedoch dazu führen, dass die I²C-Kommunikation mit der RTC problematisch wird. Aus diesem Grund wird ein [Power-MUX](#power-mux) eingesetzt, der die Versorgung vom DC/DC-Wandler priorisiert, wenn diese aktiv ist. Damit ist sichergestellt, dass alle Geräte den gleichen Spannungspegel verwenden, wenn I²C aktiv ist.
|
||||
Der 3.3V LDO versorgt die RTC und den `VBAT`-Eingang des Mikrocontrollers, wenn der [DC/DC-Wandler](#3-3v-buck-boost-wandler-dc-dc-wandler) ausgeschaltet ist. Die Wahl fiel auf den **XC6206P332MR-G** von Torex, der einen Eigenverbrauch von lediglich 1µA aufweist. Fällt die Akkuspannung unter 3.3V, arbeitet er im Dropout-Bereich und die Ausgangsspannung folgt der Eingangsspannung abzüglich eines geringen Spannungsabfalls. Dies kann zu Pegel-Inkompatibilitäten bei der I²C-Kommunikation führen, da der Rest der Schaltung mit stabilen 3.3V vom DC/DC-Wandler versorgt wird. Um dies zu verhindern, schaltet ein [Power-Mux](#power-mux) die Versorgung der RTC auf den `VDD`-Zweig um, sobald dieser aktiv ist. Dadurch wird ein einheitlicher Spannungspegel für die Kommunikation sichergestellt.
|
||||
|
||||
#### Power-Mux
|
||||
Ein **TPS2116** wird als Power-Multiplexer eingesetzt. An den Eingängen werden der DC/DC-Wandler (priorisiert) und der LDO angeschlossen. Am Ausgang stellt er die `VRTC`-Spannung zur Verfügung.
|
||||
|
||||
## Dimensionierungen
|
||||
Im folgenden werden die wesentlichen Dimensionierungen behandelt.
|
||||
Im Folgenden werden die wesentlichen Dimensionierungen behandelt.
|
||||
|
||||
### N-FETs
|
||||
An mehreren Stellen werden im Hauptstrompfad N-FETs benötigt (Charge- und Discharge-FETs beim Batterieschutz, SHIP-FET beim Lader, Input Selector beim Lader). Ich habe zuerst zum **AO3400A** tendiert, ein Basic-Part bei jlcpcb und mein erster Gedanke, wenn ich Logic-Level-N-FET höre.
|
||||
Sehen wir uns die Rahmenbedingugen an. Worst Case sind die Batterieschutz-Transistoren, denn sie kriegen die kleinste ```VGS``` ab, wenn der Li-Ion-Akku entladen ist. Die FETs, welche vom Lader angesteuert werden, erhalten ihre Gatespannung von einer Charge Pump, sie ist sicher so immer um die 5V höher als die Source-Spannung. Gehen wir also von einem tiefentladenen Akku aus. Die Spannung wird dann so um die 2.5V liegen (natürlich wird bei dieser Spannung der Lader nicht mit vollem Strom laden, für eine Worst-Case-Betrachtung ist das aber ideal, da Rds für 2.5V im Datenblatt des AO3400A angegeben ist). Rds bei VGS von 2.5V ist laut Datenblatt <48m
|
||||
An mehreren Stellen im Hauptstrompfad werden N-FETs benötigt (Charge- und Discharge-FETs beim Batterieschutz, SHIP-FET beim Lader, Input Selector beim Lader). Eine erste Überlegung galt dem **AO3400A**, einem gängigen Logic-Level N-FET.
|
||||
|
||||
Die kritischste Anwendung sind die Batterieschutz-Transistoren, da sie bei entladenem Akku die geringste Gate-Source-Spannung (VGS) erhalten. Die vom Lader angesteuerten FETs werden über eine interne Ladungspumpe mit einer ausreichend hohen Gatespannung versorgt.
|
||||
|
||||
Für die Worst-Case-Betrachtung wird ein tiefentladener Akku mit einer Spannung von 2.5V angenommen. Laut Datenblatt des AO3400A beträgt der Rds(on) bei einer VGS von 2.5V maximal 48mΩ. Bei einem angenommenen Laststrom von 3A würde dies zu folgenden Konsequenzen führen:
|
||||
|
||||
- **Spannungsabfall:**
|
||||
$$
|
||||
\begin{align}
|
||||
V_{drop} &= R_{ds(on)} \cdot I \\
|
||||
&= 0.048\Omega \cdot 3A \\
|
||||
&= 0.144V
|
||||
\end{align}
|
||||
$$
|
||||
|
||||
- **Verlustleistung:**
|
||||
$$
|
||||
\begin{align}
|
||||
P_{loss} &= R_{ds(on)} \cdot I^2 \\
|
||||
&= 0.048\Omega \cdot (3A)^2 \\
|
||||
&= 0.432W
|
||||
\end{align}
|
||||
$$
|
||||
|
||||
Diese Verlustleistung ist nicht unerheblich und muss bei der Auslegung des PCB-Layouts (Wärmeabfuhr) und im Hinblick auf die Gesamteffizienz berücksichtigt werden. Es könnte sinnvoll sein, einen FET mit einem niedrigeren Rds(on) bei 2.5V VGS zu evaluieren.
|
||||
|
|
|
|||
Loading…
Reference in New Issue