Nach langer Zeit wieder ein Post ..
Am Wochenende hab ich endlich mal die LoRa Hardware die bei mir herumgelegen ist zum Laufen gebracht.
LoRa? laut https://www.lora-alliance.org/ :
"LoRaWAN™ is a Low Power Wide Area Network (LPWAN) specification intended for wireless battery operated Things in a regional, national or global network. LoRaWAN targets key requirements of Internet of Things such as secure bi-directional communication, mobility and localization services."
TheThingsNetwork (TTN) https://www.thethingsnetwork.org/ hat das Ziel ein community Netzwerk aufzubauen wo private Leute Gateways ins Netz stellen und dadurch connectivity zur Verfügung stellen. Verwendet wird dafür das offene ISM band um 868 MHz in Europa.
Gateway Hardware:
Ein IMST iC880 8 Kanal LoRa GW (SX1301 concentrator + 2x SX1257 radios) in Verbindung mit einem Raspberry 3.
Auf dem Raspi läuft raspbian-lite und der lora forwarder. Die infos sind von https://github.com/ttn-zh/ic880a-gateway/wiki. Der setup hat soweit gut funktioniert nur das Konfigurationsfile welches per default installiert wurde musste angepasst werden auf die settings for TTN. https://github.com/TheThingsNetwork/gateway-conf/blob/master/EU-global_conf.json hat dann auf anhieb funktioniert.
Die TTN web console ist etwas strange - funktioniert nicht immer so wie sie sollte hab ich das gefühl. Das anlegen des Gateways hat aber funktioniert.
Am Wochenende hab ich endlich mal die LoRa Hardware die bei mir herumgelegen ist zum Laufen gebracht.
LoRa? laut https://www.lora-alliance.org/ :
"LoRaWAN™ is a Low Power Wide Area Network (LPWAN) specification intended for wireless battery operated Things in a regional, national or global network. LoRaWAN targets key requirements of Internet of Things such as secure bi-directional communication, mobility and localization services."
TheThingsNetwork (TTN) https://www.thethingsnetwork.org/ hat das Ziel ein community Netzwerk aufzubauen wo private Leute Gateways ins Netz stellen und dadurch connectivity zur Verfügung stellen. Verwendet wird dafür das offene ISM band um 868 MHz in Europa.
Gateway Hardware:
Ein IMST iC880 8 Kanal LoRa GW (SX1301 concentrator + 2x SX1257 radios) in Verbindung mit einem Raspberry 3.
Auf dem Raspi läuft raspbian-lite und der lora forwarder. Die infos sind von https://github.com/ttn-zh/ic880a-gateway/wiki. Der setup hat soweit gut funktioniert nur das Konfigurationsfile welches per default installiert wurde musste angepasst werden auf die settings for TTN. https://github.com/TheThingsNetwork/gateway-conf/blob/master/EU-global_conf.json hat dann auf anhieb funktioniert.
Die TTN web console ist etwas strange - funktioniert nicht immer so wie sie sollte hab ich das gefühl. Das anlegen des Gateways hat aber funktioniert.
Auf dem Raspberry läuft der packet forwarder welcher das IMST board mit dem TTN verbindet (https://github.com/TheThingsNetwork/packet_forwarder/tree/legacy). Im install script von ttn-zh wird die legacy branch gecloned - welche den poly_pkt_forwarder einhält welcher auf dem Rapi läuft (Unterschiede von master zu legacy branch muss noch gecheckt werden)
End-Node testing ...
Zum testen hab ich ein RF95 Module (basierend auf SX127x) von Adafruit (https://learn.adafruit.com/adafruit-rfm69hcw-and-rfm96-rfm95-rfm98-lora-packet-padio-breakouts/overview) und ein Arduino UNO verwendet - wollte eigentlich den STM32 mit SX1272 module verwenden - das teil mag jedoch noch nicht so ganz bei mir. Auf dem Arduino läuft die LMIC (LoraMac in C) library (https://github.com/matthijskooijman/arduino-lmic).
Hatte auch noch andere libraries am Radar - RadioHead RFxx library (http://www.airspayce.com/mikem/arduino/RadioHead/) die arduino-device-lib von TTN (https://github.com/TheThingsNetwork/arduino-device-lib) - die RadioHead library ist eher generisch für das senden über Lora und die arduino-device-lib macht TTN aber dafür muss der Radioteil angepasst werden - die LMIC library war am einfachsten für einen ersten Test.
Als basis für den test habe ich folgende source verwendet:
Dort müssen die NWKSKEY / APPSKEY und DEVADDR eingetragen werden welche beim anlegen des devices in der Console retour kommen. Das Beispiel liefert den Wert vom ADC0 als message retour.
Der Aufbau hat jedoch nicht auf anhieb funktioniert - es hat sich rausgestellt das DIO0 (G0) und DIO1(G1) von dem RF95 Modul zum Arduino gehen "müssen" damit es funktioniert. Ohne die DIO1 Leitung hat der Arduino kein response bekommen das die Übermittlung erfolgt ist (Interrupt) - es ist zwar aus dem sourcecode nicht ganz klar was da passiert (braucht noch etwas Jungend Forscht)
Zum debuggen musste in "src/lmic/config.h" noch zwei defines gesetzt werden
#define LMIC_DEBUG_LEVEL 2 (war 0)
#define LMIC_PRINTF_TO Serial
#define LMIC_PRINTF_TO Serial
Mit der DIO1 Leitung verbunden hat der Node dann daten geschickt - hier war nur der interessante Punkt das es im ABP mode laufen muss - da die over-the-air authentication von der LMIC library noch nicht voll unterstützt wird.
Starting...
Debugging turned on in config.h ...
RXMODE_RSSI
216: engineUpdate, opmode=0x808
639: TXMODE, freq=868100000, len=15, SF=7, BW=125, CR=4/5, IH=0
Sending uplink packet...
66077: RXMODE_SINGLE, freq=868100000, SF=7, BW=125, CR=4/5, IH=0
128865: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
380708: EV_TXCOMPLETE (includes waiting for RX windows)
380753: engineUpdate, opmode=0x800
Debugging turned on in config.h ...
RXMODE_RSSI
216: engineUpdate, opmode=0x808
639: TXMODE, freq=868100000, len=15, SF=7, BW=125, CR=4/5, IH=0
Sending uplink packet...
66077: RXMODE_SINGLE, freq=868100000, SF=7, BW=125, CR=4/5, IH=0
128865: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
380708: EV_TXCOMPLETE (includes waiting for RX windows)
380753: engineUpdate, opmode=0x800
Der End-Node ist in ABP mode konfguriert - d.h. das device speicher die keys (NWKS, APPS)
im ABP mode werden die Keys über das Portal erzeugt - dazu muss das device im web interface editiert werden um von OTAA auf ABP umzuschalten ..
Das Thema OTAA muss ich noch weiter anschauen - vorallem was es da alles braucht damit es funktioniert - die Network und Session key im End-Node zu speichern sind eher suboptimal aus security Gründen.
OTAA und ABP müssen auch gecheckt werden bzgl den FrameCountern - wie in https://www.thethingsnetwork.org/wiki/LoRaWAN/Security ist ein Teil der security (replay protection) das Frames die einen kleiner FrameCounter haben als der max(empfange_frames) nicht verwendet werden - bei neustart vom end-node geht der frame counter auf 0 - und mit ABP kann der counter nicht "ausgehandelt" werden - mit OTAA geht das.
Bis Frame 54 ist GW beim letzten Test gelaufen .. beim nächsten Test hat das Device in der Konsole erst ab dem 55ten Frame wieder reagiert .. alle anderen hat das GW bekomen aber das backend hat nichts damit gemacht ..
Mit dem schicken von Messages kam dann auch die Frage "wieviel darf man schicken" - dafür gibt es die Fair Access Policy von TTN (https://www.thethingsnetwork.org/forum/t/limitations-data-rate-packet-size-30-seconds-uplink-and-10-messages-downlink-per-day-fair-access-policy/1300)
Dort heisst es "An average of 30 seconds uplink time on air, per day, per device." und "At most 10 downlink messages per day, including the ACKs for confirmed uplinks." die "time on air" ist noch interessant - wenn man die Messages die geschickt werden auf der Console anschaut dann sieht man in den Details zB 35ms air time ..
Die AirTime ist quasi die Zeit in der ein Datenpacket einen Channel "blockiert" und somit für andere nicht nutzbar macht. Aus der Technologie, Bandbreiten und anderen Punkt ergeben sich die Parameter - wenn zB ein Node weit weg ist und daher mit niedriger Bandbreite schicken muss und dann noch ein grosses Packet schickt - dann braucht er viel airtime.
Basis ist gebaut für weiter Tests .. mal sehen was die LoRa Sachen hergeben .. ich möchte auch noch das SX1272 STM32 modul zum Laufen bringen und mal ein paar Reichweitentest machen. Auch mal ein test über ein "anderes" GW wäre interessant ..
Weiter links:
---