COM.LoRaWAN Modul für den M5Stack

Das COM.LoRaWAN ist nun das dritte Modul für den M5Stack, mit dem ihr den M5Stack an das TTN anbinden könnt. Daneben gibt es noch das LoRaWAN, welches EOL ist und das noch verfügbare LoRa 868. Das Modul ist EU868 only, jedenfalls im LoRaWAN Modus. Ich habe mir das Modul mal genauer angeschaut und zeige euch hier meine bisherigen Erfahrungen.

Aufbau des COM.LoRaWAN Moduls

Das COM.LoRaWAN kommt in einer Pappschachtel und beinhaltet das Modul, eine Antenne mit SMA Anschluss und das notwendige Pigtail. Somit habt ihr alles was ihr braucht und benötigt erst mal keine weiteren Dinge.

Das Modul nutzt den COM.X Unterbau. Dieser hat den Vorteil den M5 Stack mit 5V oder 12V von extern versorgen zu können. Zusätzlich kann über einen DIP-Schalter die GPIOs für den seriellen Port gewählt werden. Somit muss nicht mehr zum Lötkolben gegriffen werden und ihr könnt die Einstellungen schnell anpassen. Für TX stehen die GPIOs 17, 0 und 13 zur Verfügung, für RX 16,5 und 15. Nutzer eines M5Stack Fire, sollten 17 und 16 nicht verwenden, da diese Ports für den PSRAM verwendet werden, oder ihr schaltet diesen ab.

• 

• 

• 

Über zwei vorgestanzte Löcher, könnt ihr die SMA-Buchse einbauen. Entweder führt ihr den Anschluss nach oben hinaus oder zur linken Seite.

Nutzung des COM.LoRaWAN Moduls

Die Nutzung ist relativ einfach und es brauch auch nicht viele Befehle um das Modul zum Sende zu bewegen. Das COM.LoRaWAN ist fest auf EU868 eingestellt und somit entfallen hier notwendige Anpassungen. Alle mögliche AT Befehle, findet ihr im AT Command User Manual. Das Modul legt sich nach dem Senden immer wieder schlafen, daher müsst ihr es mit einem Befehl wieder wecken. Was ihr dabei sendet ist egal, beachtet jedoch das der Befehl nicht ausgeführt wird.

Die Keys müsst ihr nur einmalig setzen, danach sind sie gespeichert. Es ist aber jederzeit möglich neue zu speichern oder das Modul auf Werkseinstellungen zurückzusetzen.

Einen ersten Ansatz zum Konfigurieren mittels Arduino IDE, bietet das M5 Stack eigene Beispiel.

Ansonsten kann ich euch noch folgende Beispiele empfehlen. Danke nochmals an Beide für die Vorarbeit.

• M5Stack COM.LoRaWAN Using UIFlow
• M5Stack COM.LoRaWAN Using Arduino IDE

Default Einstellungen

Hier seht ihr die Default Einstellungen des Moduls, diese sind aktiv wenn es auf Werkseinstellungen zurückgesetzt wird:

+AutoLPM=1

+LORAWAN=1

+KeepNet=0
+OTAA=1
+Class=A
+ADR=1
+IsTxConfirmed=1
+AppPort=2
+DutyCycle=15000
+ConfirmedNbTrials=4
+ChMask=0000000000000000000000FF
+DevEui=2232330000888802(For OTAA Mode)
+AppEui=0000000000000000(For OTAA Mode)
+AppKey=88888888888888888888888888886601(For OTAA Mode)
+NwkSKey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx(For ABP Mode)
+AppSKey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx(For ABP Mode)
+DevAddr=xxxxxxxx(For ABP Mode)

Man sieht hier folgendes:

• Der Automatische Stromsparmodus ist aktiv (AutoLPM=1)
• LORAWAN ist aktiv (LORAWAN=1)
• OTAA wird genutzt (OTAA=1)
• ADR ist aktiv (ADR=1)
• Bestätigte Uplinks sind aktiv (IsTxConfirmed=1)
• Port 2 wird per Default genutzt (AppPort=2)
• Wird kein ACK empfangen, versucht es das Modul vier weitere Mal; dabei wird alle zwei versuche der SF angehoben (ConfirmedNbTrials=4)

Gerade mit dem letzte Punkt verletzt ihr schnell die Fair Access Policy, also überlegt euch was ihr macht.

Befehle für ABP

Die allgemeinen Einstellungen braucht ihr nur einmalig machen, da diese im Chip gespeichert werden. Nach einem Reset braucht es nur einen Join und ihr könnt Daten verschicken.

Auch für ABP muss ein Join ausgeführt werden, dieses ist zwar nur ein pseudo Join, aber ansonsten könnt ihr keine Daten senden. Der große Nachteil ist die Payload des Joins, denn diese ist gleich der zuletzt versendeten Payload. Somit solltet ihr das erste Paket im ABP Muds verwerfen. Leider könnt ihr den Spreading Factor nicht anpassen, somit bleibt das Modul auf SF7 kleben. Es kann sein, das sich der SF bei aktivem ADR auch verändert, das habe ich aber bisher nicht getestet. Wenn ihr Confirmed Uplinks verwendet, wird der SF erhöht, sobald kein ACK empfangen wird. Dieses geschieht beim 3. , 5. und 7. Versuch. Somit kommt ihr maximal auf einen SF von 10. Dafür müsst ihr aber den Parameter ConfirmedNbTrials auf mindestens 7 setzen.

Aus meiner Sicht eignet sich das Modul jedoch nicht für ABP Anwendungen, da hier die nötige Kontrolle über die Einstellungen, wie Spreading Factor, fehlt.

//Weckt das Modul auf
AT+XXX
//Aktiviert den LoRaWAN Modus
AT+LORAWAN=1
//Deaktiviert OTAA und aktiviert somit ABP
AT+OTAA=0
//Setzen der Keys
AT+NwkSKey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
AT+AppSKey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
AT+DevAddr=xxxxxxxx
//Baut die erste Verbindung auf
AT+Join=1

//Senden
AT+XXX
AT+SendHex=ABCD

Befehle für OTAA

Auch hier muss die Grundkonfig nur einmalig erfolgen, anschließend reicht ein Join.

//Weckt das Modul auf
AT+XXX
//Aktiviert den LoRaWAN Modus
AT+LORAWAN=1
//Aktiviert OTAA
AT+OTAA=1
//Setzen der Keys
AT+DevEui=kkkkk
AT+AppEui=kkkkk
AT+AppKey=kkkkk
//Join
AT+Join=1

//Senden
AT+XXX
AT+SendHex=ABCD

AT+ ConfirmedNbTrials=?

Mit dem Befehl AT+ ConfirmedNbTrials= , könnt ihr anpassen wie viele Versuche das LoRaWAN Modul unternimmt für eine Übertragung mit Bestätigun. Ihr könnt hier einen Wert zwischen 1 und 8 nutzen. Bei 1 wird also nur ein Sendeversuch unternommen und bei 8 ist es ein Versuch und maximal sieben Wiederholungen. Sollte der Node vorher einen ACK empfangen, wird er keinen weiteren Versuch unternehmen. Es wird bei jeder zweiten Wiederholung der Spreading Factor erhöht. Leider wird auf der Konsole darüber nichts ausgegeben, auch bei deaktiviertem LowPower Mode.

Sendeversuch	Spreading Factor
1	SF
2	SF
3	SF+1
4	SF+1
5	SF+2
6	SF+2
7	SF+3
8	SF+3

AT+ADR=?

Damit könnt ihr die Nutzung von Adaptive Data Rate aktivieren oder deaktivieren. Wenn ihr ADR aktiviert, sendet des Backend nach 64 Paketen ein ADR Paket. Wenn der Node dieses nicht empfängt, wird er ab dem 97. Paket den SF um eins erhöhen. Das ganze Spiel beginnt dann wieder von Vorne. Das Backend kann aber den Node auch anweisen seinen SF wieder zu verringern. Somit soll sichergestellt werden, das der Node einen minimalen SF benutzt und so auch Strom spart.

Vor- und Nachteile

Kommen wir erst zu den Vorteile. Hier finde ich die neue COM.X Base sehr durchdacht. Die Zuordnung zu den GPIOs für die Serielle Schnittstelle, ist hier durch den DIP-Switch, sehr einfach händelbar. Lötarbeiten entfallen komplett und eine Maximum an Flexibilität ist gegeben. Das Modul ist dadurch zwar dicker, für mich spielt das aber keine Rolle. Ebenfalls sehr gut ist die Möglichkeit, die SMA Buchse direkt am Modul zu befestigen. Dadurch entfallen Adapter und es sieht insgesamt stimmiger aus. Die Antenne hat einen festen Platz. Aufgrund der AT Befehle, kommt man auch schnell zum Ziel und hat seinen ersten Erfolge ohne großen Aufwand erzielt.

Was auf der einen Seite ein Vorteil ist, wird aber auch schnell zum Nachteil. Die AT-Befehle decken leider nicht den kompletten Konfigurationsumfang ab und so können gewisse Einstellungen nicht getätigt werden. Die fehlende Möglichkeit den Spreading Factor vorzugeben, ist eine davon.

Ich finde das Modul gut. Es ist zwar nicht direkt für mein Projekt geeignet, aber für andere ist es sicherlich eine einfache Möglichkeit den M5Stack an das TTN anzubinden. Für mich bleibt jedoch das LoRa 868 das Modul der Wahl.

Da meine Versuche noch in den Anfängen stecken, werde ich den Beitrag hier wohl noch um weitere Erkenntnisse erweitern innerhalb der nächsten Wochen.

Vorteile	Nachteile
COM.X Base	Nur AT Befehle
Integrierter SMA Buchse	Keine volle Konfigurationsmöglichkeit
Wenig Konfigurationsaufwand