Projekt: IP- gesteuerter MOSFET Treiber für RGBW- LED Strips

In diesem Beitrag möchte ich mein jüngstes Projekt vorstellen, das ich „netled“ getauft habe. Hierbei handelt es sich um einen MOSFET- Treiber für RGB(W)- LED Strips, wie sie praktisch überall erhältlich sind. Die Besonderheit des netled ist, dass die Farbmischung per Ethernet gesteuert wird, weshalb es prinzipiell mit jeder Netzwerkgebundenen Steuerung betrieben kann.

Zunächst einige Eckdaten:

• Mikrocontroller: Atmel ATmega328p
• Ethernet Controller: WizNet W5500 mit selbst entwickeltem, zweckoptimierten Treiber
• Materialkosten pro Einheit ca. 50€
• Theoretische Ausgangsleistung: 36 Watt pro Farbkanal

Folgende Kombination von LED Streifen sind theoretisch möglich:

• 1x Standard RGB, vierpolig
• 1x RGB + Warmweiß, fünfpolig
• 4x Warmweiß LED Streifen, jeweils zweipolig

Ich habe das Design am 17. März 2021 begonnen und habe zum Zeitpunkt der Beitragserstellung (15. April 2021) die Funktionalität der Hardware am ersten Aufbau feststellen können. Zur Fertigstellung des Projektes steht also „nur“ noch die Softwareentwicklung aus.

Parallel dazu möchte ich hier sukzessiv den Designprozess, Inbetriebnahme- und Troubleshooting der Hardware, persönliche Erfolge und Kentnissgewinne, als auch die sog. „lessons learned“ dokumentieren. Dieser Beitrag wird möglichst hochfrequent aktualisiert.

Designprozess

Obiges Bild stellt den topologischen Aufbau des netled dar. Das Herzstück ist der Mikrocontroller („MICRO“ Block). Dieser übernimmt sowohl die Erzeugung der pulsweitenmodulierten Steuersignale für die MOSFET Transistoren, als auch die Verarbeitung der Netzwerkkommunikation ab der Anwendungsschicht (OSI Layer 4). Ich habe hierfür den ATmega328p Mikrocontroller des Herstellers Atmel gewählt.

Die Netzwerkkommunikation unterhalb des Layer 4 – sprich IP, MAC und physical Layer – wird vom w5500 IC des Herstellers WizNet übernommen und wird per SPI Bus an den Mikrocontroller angebunden. Dessen Dokumentation ist meiner Meinung nach leider nur „ausreichend“, jedoch sind mit der Verwendung dieses Chips beide ICs dieser Schaltung mit dem Arduino Ecosystem kompatibel, wodurch mir dieses als Fallbackstrategie bleibt, sollte die Entwicklung der Software nicht so klappen wie ich es mir vorstelle. Und immerhin habe ich ja bereits einen zweckoptimierten Treiber für diesen IC geschrieben 😉 (Beitrag folgt).

Die MOSFET Stufe besteht aus vier N-Kanal Mosfets des Typs BSP250 von Phillips Semiconductors. Die Wahl fiel im Grunde nur durch die Verfügbarkeit, da für den PWM Betrieb keine besonderen Anforderungen wie für einen Betrieb im Linearbereich bestehen. Die PWM- Frequenz ist durch den Mikrocontroller variierbar und mit 3 Ampere Nennstrom sollte mehr als genug Leistung für einige Meter LED Strips zur Verfügung stehen. Von daher ein no- brainer.

Schließlich gibt es die durch die „VREG“ Blöcke dargestellte Power Sektion, welche die 12 Volt Versorgungsspannung in zwei Stufen auf 5 und 3,3 Volt herabregelt. Hierzu später mehr.

Schaltung und Layout

Pic 3 zeigt die Beschaltung der Mikrocontroller und MOSFET Sektion. Die Pin Header J3 und J6 stellen eine ISP Schnittstelle für die Programmierung und eine serielle UART Schnittstelle zum Debuggen am PC dar. Der ATmega Controller U3 ist neben Schwingquarz und Bypasskondensatoren mit den Boardsignalen verbunden, welche als Fahnen an den Pins dargestellt sind. Die Signale OC0A, OC0B, OC1A und OC1B Führen die PWM Signale, generiert durch die Timer im Mikrocontroller, zu den jeweiligen Gate- Kontakten der MOSFET Transistoren Q1 bis Q4. Das Widerstandsnetzwerk RN2 ist zum Abbau der Gateladungen im Low- Cycle vorgesehen.

Die Signale ‚MOSI‘, ‚MISO‘ und ‚SCLK‘ gehören zum SPI Bus und sind mit der ISP Schnittstelle J3 und dem W5500 Ethernet Controller verbunden. ‚CSn‘ ist das Chip- Select Signal zum Ethernet Controller und ‚INT0_PCINT18‘ ist mit dem Externen Interrupt des selbigen verbunden. Das Reset- Signal ‚RST‘ wird ebenfalls von allen ICs und der ISP Schnittstelle geteilt.

Die Beschaltung von w5500 IC und RJ45 Buchse, zu sehen in Pic 4 und Pic 5, habe ich im Wesentlichen aus der Referenzschaltung des Herstellers übernommen. Hinzu kam lediglich das Wiederstandsnetzwerk RN3, welches als Dämpfungsglied für die Signale des SPI Bus dienen soll. Da Mikrocontroller und Ethernet Controller mit verschiedenen Spannungen arbeiten ist zu erwarten, dass die Eingangs- und Ausgangspins der ICs unterschiedliche Impedanzen aufweisen. Dies kann zu elektromagnetischen Reflexionen auf den Signalleitungen führen und hat in einem meiner FPGA Projekte tatsächlich schon zu Problemen geführt. Daher hielt ich es in jedem Fall für Sinnvoll an dieser Stelle einen Footprint vorzusehen, um im Zweifelsfall nicht die Leiterbahnen der Platine auftrennen zu müssen.

Des Weiteren habe ich mich für eine RJ45 Buchse mit integriertem Transformator entschieden. Dies spart zum Einen Platz auf der Platine ein, zum Anderen bedarf es für eine etwaige Serienfertigung eine Bauteilspule weniger auf der Fertigungsmaschine.

Das Design der Spannungsversorgung werde ich im Troubleshooting Abschnitt erläutern, da hier der erste „lessons learned“ Fall eintrat.

Pic 6 und Vid 1 zeigen das mit KiCad erstellte Platinenlayout des netled. Obwohl nicht zwingend notwendig, habe ich mich für ein 4- Lagen Design entschieden. Die inneren zwei Kupferlagen sind großflächig für die Verteilung von Versorgungsspannung und Masse gedacht, wodurch die oberste und unterste Lage lediglich aus Signalleitungen besteht. Dadurch sind die Signalwege auch von außen sichtbar, was das Analysieren der Schaltung auf der Werkbank sehr erleichtert.

Aufbau und Troubleshooting

Pic 7 zeigt die Spannungsversorgung des Boards. Vorgesehen war hier zunächst ein Buck- Converter, bestehend aus einem LM2575 Schaltregler U1, dem Ladekreis aus L1 und C2 und der Flybackdiode D1. Ein Fehler im Platinenlayout führte jedoch dazu, dass der Diodenstrom auf die „5V_rail“ Leiterbahn eingekoppelt wurde. Dies hatte zur Folge, dass der Mikrocontroller durch unregelmäßige „Brown-outs“ die Testprogrammierung nicht nachvollziehbar abarbeitete. Demnach war ich gezwungen, den Schaltregler U1 durch einen 7805 Linearregler zu ersetzen, der eine glatte Ausgangsspannung unter Inkaufnahme einer größeren Abwärme lieferte. Lesson learned: Augen auf beim Leiterbahnverlauf (oder so ähnlich).

Ein weiterer Fehler betraf das 3,3 Volt Analognetz ‚3V3A‘. Obwohl der Gleichstromwiderstand der Induktivität L2 nur wenige Ohm beträgt, reichte dies aus um die Spannung auf etwa 2,4 Volt zu reduzieren. Im Betrieb äußerte sich dies durch regelmäßiges Aufblinken der „Link“ LED an der RJ45 Buchse. Weder das Datenblatt, noch das Herstellerforum liefert konkrete Tabellen für die Blinkcodes des Chips, was meine Bewertung der Dokumentation des selbigen nochmals unterstreicht. Um die Funktion des Ethernet Controllers herzustellen wurde die Induktivität schließlich durch eine Leiterbrücke ersetzt.

Einen kleinen „Schönheitsfehler“ gibt es noch. Beim Entwurf der Schaltung habe ich übersehen, dass die „Link“ und „Activity“ LED Signale des Ethernet Controllers Low- aktiv sind, ich habe sie jedoch als High- aktiv verbunden. Dies führt dazu, dass die LEDs bei Inaktivität aufleuchten (und das Titelbild dieses Beitrages schöner aussehen lassen 🙂 ), bei Aktivität jedoch dunkel bleiben. Kein Beinbruch, sollte in künftigen Revisionen aber korrigiert werden. Lesson learned: Augen auf beim Stromverlauf (das mit den Sprüchen sollte ich auch sein lassen…).

für eine Revisionierung würde ich mir ebenfalls vornehmen:

• Optimierung des Platinenlayouts, 2- Lagen Design
• Überarbeiten der Spannungsversorgung unter Berücksichtigung der Abführung thermischer Energie und EMI- Verträglichkeit
• Überstromsicherung und Verpolungsschutz
• Ersetzen der Schraubanschlüsse durch Steckkontakte
• Reduzierung redundanter Bauteile und verschiedener Bauteilwerte (BOM- Optimierung)

Fazit

Im Gesamten bezeichne ich den Hardwareaufbau als Erfolg, besonders was die Fertigung in SMD – Bauweise im Heimlabor angeht. Bisher habe ich in meinen Projekten darauf verzichtet, da mir in dieser Hinsicht die Übung, vor allem aber die Mittel fehlten. Das Design weist Fehler im Detail auf, die ich als Erkenntnisgewinn für kommende Revisionen des netled – aber auch zukünftige Projekte – bewerte.

Von daher genügt das Hardwaredesign einem Prototypen und als „proof of concept“, als auch zur Verwendung zu Hause. Für eine kommerzielle Produktentwicklung ist jedoch in mehreren Aspekten weiteres Engineering nötig.

Im nächsten Beitrag zum netled werde ich die Entwicklung der Software erläutern, welche womöglich zusätzliche Hardwareoptimierungen- und Ergänzungen aufzeigt.

Kommentare, Fragen, Anregungen und Kritik zu diesem Beitrag dürfen gerne in die Kommentarsektion geschrieben werden und ich werde mich zeitnah um eine Antwort bemühen 🙂