Von der Idee zum zertifizierten LoRaWAN-Gerät

Du hast eine Idee für ein IoT-Gerät. Sensordaten sollen drahtlos übertragen werden, batteriebetrieben, Reichweite mehrere Kilometer, möglichst wartungsfrei. LoRaWAN klingt perfekt. Auf GitHub gibt es Stacks, Arduino-Libraries, Tutorials. Wie schwer kann es sein?

Schwerer als es aussieht — aber nicht wegen der Technologie. Wegen der Entscheidungen, die man am Anfang trifft, ohne zu wissen, dass man sie trifft.

Die drei Entscheidungen, die alles bestimmen

1. Welcher Stack?

Es gibt mehrere LoRaWAN-Implementierungen für Mikrocontroller. Die bekanntesten in der Arduino/Maker-Welt sind sx126x-Arduino und RadioLib. Beide funktionieren für Prototypen und Experimente gut.

Aber: sx126x-Arduino implementiert MAC 1.0.2 und hat seit Jahren zwei bekannte Bugs im Join-Handling — Geräte, die im Labor zuverlässig joinen, versagen im Feld sporadisch, ohne klare Fehlermeldung. RadioLib ist eine hervorragende Abstraktion für den direkten Zugriff auf den Radio-Chip, aber kein vollständiger LoRaWAN-Stack. Duty-Cycle-Management, ADR, Class-C-Unterstützung — das alles muss man selbst bauen oder ignorieren.

Für ein Produkt, das in Serie gehen soll, gibt es eine rationale Wahl: Semtech's LoRa Basic Modem (LBM). Es ist der offizielle Stack des Chip-Herstellers selbst, implementiert MAC 1.0.4 vollständig und ist die Referenzbasis für die LoRa Alliance Zertifizierung. Das bedeutet: Was LBM tut, ist per Definition konform — nicht weil man es hofft, sondern weil Semtech damit die eigenen Chips zertifiziert.

Der Haken: LBM ist keine Arduino-Library. Die Integration kostet ein paar Tage Arbeit. Für ein Produkt ist das eine einmalige Investition, die sich an jedem Tag im Feld amortisiert.

2. Welche Hardware-Basis?

Eval-Kits und fertige Module sind für die Entwicklung nützlich. Für die Produktion meistens nicht — aus mehreren Gründen:

• Kosten: Fertige Module mit integriertem LoRa-Chip kosten ein Vielfaches einer eigenen Schaltung. Bei hundert Geräten fällt das auf.
• Abhängigkeit: Ein Modul, das heute verfügbar ist, kann in zwei Jahren abgekündigt sein. Eine eigene Schaltung auf Basis des SX1262 lässt sich jederzeit mit einem alternativen Bestücker oder einer überarbeiteten Platine weiterproduzieren.
• Zertifizierung: Ein Modul mit eigenem CE-Zeichen vereinfacht die Zulassung, schränkt aber gleichzeitig die Freiheit bei Antenne, Gehäuse und Schaltungsumgebung ein. Wer die volle Kontrolle will, zertifiziert die eigene Hardware — mit LBM als Stack ist das der direkteste Weg.

3. Zertifizierung: wann darüber nachdenken?

Am besten von Anfang an. Die häufigsten teuren Fehler passieren nicht kurz vor der Zertifizierung — sie passieren Monate früher, bei der Stack-Wahl, beim Schaltungsdesign, beim Frequenzplan.

Konkret: Ein LoRaWAN-Gerät für den europäischen Markt muss ETSI EN 300 220 einhalten. Das betrifft Duty-Cycle-Limits, Sendeleistung, Kanalnutzung. Wer einen Stack verwendet, der das nicht korrekt implementiert, erfährt das spätestens im Prüflabor — und dann ist die Korrektur teuer. LBM implementiert all das korrekt, weil Semtech damit die eigenen Chips zertifiziert.

Was "custom Hardware" wirklich bedeutet

Ein eigenes Board zu entwickeln klingt nach grossem Aufwand. In der Praxis ist der Schritt von einem Eval-Kit zu einer eigenen Schaltung für einen erfahrenen Elektronikentwickler überschaubar: SX1262-Referenzschaltung nach Datenblatt, ARM Cortex-M als Host-Controller, Antenne, fertig.

Was den Unterschied macht, ist nicht die Schaltung — die ist dokumentiert. Es ist das Drumherum: Welche Testpunkte braucht man für die Produktion? Was bedeutet das Gehäuse für die Antenne? Welche Schutzklasse ist nötig? Wie wird das Gerät im Feld geflasht und konfiguriert?

Und vor allem: der Stromverbrauch. Nicht der Sendestrom — den kennt jeder aus dem Datenblatt. Sondern der Leakage Current aller Bauteile im Schlafzustand. Eine TVS-Diode mit 50 µA Leckstrom, ein FET der nicht sauber sperrt, ein LDO der im Standby mehr zieht als angegeben — das summiert sich. Wer das erst auf dem fertigen Board misst, hat möglicherweise das gesamte Batteriebudget falsch kalkuliert. Ein PMIC, der nicht sorgfältig ausgewählt wurde, kann ein Design, das auf zwei Jahre Batterielaufzeit ausgelegt war, auf sechs Monate reduzieren — und das ohne einen einzigen Fehler in der Firmware.

Das sind Fragen, die man am besten beantwortet, bevor man das erste PCB bestellt — nicht danach.

Die Stolperstellen, die niemand dokumentiert

Ein paar Dinge, die in keinem Tutorial stehen und trotzdem Wochen kosten können:

• Der Stack schweigt, wenn etwas falsch ist. LBM und ähnliche Stacks geben bei Konfigurationsfehlern oft keinen Fehler zurück — sie funktionieren einfach nicht. Ein falscher Compiler-Define, und Class C wird lautlos wegkompiliert. Ein vergessener SPI-Initialisierungsaufruf, und alle Chip-Reads liefern 0xFF ohne Fehlermeldung. Man sucht tagelang an der falschen Stelle.
• ChirpStack und LoRaWAN-Klassen vertragen sich nicht automatisch. Wer auf ChirpStack ein Geräteprofil mit "allow class C" aktiviert, erlebt, dass der Server das Gerät automatisch auf Class C umschaltet — ab bestimmten Versionen bereits beim Join. Ein Stack, der das nicht erwartet, empfängt danach keine Downlinks mehr. Das ist kein Bug, das ist ein Zusammenspiel zweier korrekter Implementierungen, die unterschiedliche Annahmen machen.
• Duty-Cycle und Sleep vertragen sich nicht ohne Handarbeit. Auf dem SAMD21 stoppt der System-Timer im Tiefschlaf. Der LoRaWAN-Stack berechnet das Duty-Cycle-Budget anhand dieser Zeit — schläft das Gerät, denkt der Stack, keine Zeit sei vergangen, und das Budget stimmt nach dem Aufwachen nicht mehr. Das führt zu Geräten, die im Labor funktionieren und im Feld das Duty-Cycle-Limit verletzen.
• Flash-Speicher löscht mehr als man denkt. Der SAMD21 löscht Flash immer 1 KB auf einmal. Wer NVM-Kontexte naiv schreibt, überschreibt dabei Nachbardaten — und das Gerät hat nach einem Reset die Netzwerkkeys verloren.

Was das bedeutet

Ein LoRaWAN-Gerät zu bauen ist lösbar. Die Technologie ist ausgereift, die Chips sind gut dokumentiert, die Infrastruktur existiert.

Was es braucht, ist jemand, der die Fallstricke kennt — nicht aus einem Tutorial, sondern aus echten Projekten. Der weiss, welcher Stack für welches Ziel sinnvoll ist. Der die Hardware selbst entwickelt, bestückt und testet. Und der den Weg durch CE- und LoRaWAN-Zertifizierung gerade geht — mit allem, was dazugehört.

Das ist unser Alltag bei Wholestack.