Prototyping in der IoT-Produktentwicklung
Der Prototyp soll beweisen, dass die Architektur im Feld funktioniert, bevor in die Fertigung investiert wird. Wir entwerfen schon in dieser Phase eine eigene Leiterplatte — statt Entwicklungsboards zusammenzustecken —, damit Messungen zu Reichweite, Stromverbrauch und Zuverlässigkeit für das spätere Produkt aussagekräftig sind.
Projektbeispiel – CoachLink: ein LoRa-Nachrichtensystem aus einem ESP32-Gateway und einem batteriebetriebenen Remote-Knoten mit OLED-Display und mobiler App. Wir haben beide Leiterplatten und die Firmware entwickelt; der Prototyp hat Echtzeit-Nachrichten von einem Sender an mehrere Knoten demonstriert – ohne Internet und ohne SIM-Karte. Zur Fallstudie (auf Englisch).
Industrialisierung: vom Prototyp zur fertigungsreifen Baugruppe
Industrialisierung heißt, die Leiterplatte so aufzubereiten, dass ein Bestückungsdienstleister sie ohne Rückfragen fertigen kann: beim Bestücker verfügbare Bauteile, eine saubere Stückliste (BOM), Bestückungsdaten (Pick-and-Place), eingehaltene DFM-Regeln und ein Prüfablauf für die bestückte Baugruppe.
Projektbeispiel – ESP32-Motor- und Servo-Steuerplatine: in EasyEDA rund um ein ESP32-WROOM-32E-Modul entworfen, mit Motortreiber, Servo-Ausgängen, doppelter Stromversorgung über USB-C und Hohlstecker mit Eingangssicherung sowie Spannungsregelung auf der Platine. Wir haben die Bauteile aus der Bestückungsbibliothek von JLCPCB ausgewählt, Stückliste und Pick-and-Place-Dateien erstellt, die Platine bei JLCPCB fertigen und bestücken lassen und die bestückte Baugruppe getestet. Zum Portfolio.
Forschung und Entwicklung (F&E) für IoT-Produkte
In der IoT-Produktentwicklung bedeutet F&E vor allem, früh die technischen Entscheidungen zu treffen, deren spätere Korrektur teuer wäre: Funktechnologie, Netzwerktopologie, Energiebudget und Wahl des Mikrocontrollers.
Projektbeispiel – CoachLink: Für Standorte ohne WLAN und ohne zuverlässiges Mobilfunknetz haben wir uns für eine direkte LoRa-Punkt-zu-Punkt-Verbindung statt LoRaWAN entschieden, weil sie weder Netzwerkinfrastruktur noch einen externen Netzwerkserver benötigt und für eine kleine Anzahl von Knoten gut geeignet ist. Der Entwurf berücksichtigt die reale Reichweite, die gesetzlichen Sendezeitbegrenzungen, Empfangsbestätigungen und eine Verschlüsselung auf Anwendungsebene.