IoT Multiboard Parametrierungsanleitung€¦ · Das IoT Multiboard ist ein elektronisches Gerät,...

Kommunikationstechnik

IoT Multiboard Parametrierungsanleitung

DB Kommunikationstechnik GmbH

Engineering

Stand 10/2020

Version 2020_1.1

Manual

Parametrierungsanleitung IoT Multiboard Version 2020_1.1 Seite 2 von 41 Copyright 2020 DB Kommunikationstechnik GmbH - Irrtümer und Änderungen vorbehalten

Inhaltsverzeichnis

1 IoT Multiboard – Eine kurze Einführung 3

1.1 Sicherheitsanweisungen 4

1.2 Systemüberblick 5

1.2.1 Erforderliche Parameter in einem LoRaWAN-Netz 6

1.2.2 Payload-Struktur des IoT Multiboards 9

1.3 Parametrierung 11

1.3.1 Herstellung einer Verbindung mit einem PC 11

1.3.2 Parametrierungsmöglichkeiten 12

1.3.3 Parametrierung über Parameterdateien 31

1.4 Parsing der Payload in einem LoRaWAN-Netz 35

1.5 Änderung oder Aktualisierung der Firmware 37

1.6 CE-Konformitätserklärung 41


1 IoT Multiboard – Eine kurze Einführung

Das IoT Multiboard ist ein kompaktes Telemetriemodul zur Fernüberwachung technischer Anla-gen. Es erlaubt die Aufschaltung örtlicher Alarm- oder Meldungskontakte unterschiedlicher Bau-weisen oder den Anschluss handelsüblicher Sensoren für nahezu alle physikalischen Größen. Auf diese Weise können die verschiedensten – auch älteren - technischen Anlagen einfach und wirtschaftlich fernüberwacht werden. Zur Übertragung der gesammelten Informationen kommt der LoRaWAN-Funkstandard zum Ein-satz, der es erlaubt, auch unter schwierigen funktechnischen Bedingungen (z.B. Keller) sichere und kostengünstige Funkübertragungen zu ermöglichen. Das IoT Multiboard kann in öffentlichen und privaten LoRaWAN-Netzen eingesetzt werden.

Das IoT Multiboard wurde erfolgreich nach DIN EN 50155 zertifiziert und darf somit – aufgrund nachgewiesener Betriebssicherheit und Robustheit - auch in Schienenfahrzeugen eingesetzt wer-den. Dadurch eignet sich das Modul auch für den professionellen Einsatz in Industrie und Hand-werk.

Im vorliegenden Dokument erhalten Sie alle erforderlichen Informationen zur Parametrierung und Konfiguration des IoT Multiboards. Die Vorgehensweise zur Montage und Bedienung ist im Do-kument „Gebrauchsanweisung IoT Multiboard“ beschrieben. Zur vereinfachten Parametrierung kann auch das Zusatztool „Professional Configurator“ genutzt werden. Dieses Tool ermöglicht über ein einfaches User-Interface die schnelle und übersichtliche Parametrierung des IoT Multi-boards.

Alle technischen Dokumentationen und das Zusatztool stehen unter der folgenden Internet-Ad-resse in ihrer jeweils aktuellsten Version zum Download bereit:

https://www.dbkommunikationstechnik.de/downloads Obwohl alle Dokumente mit großer Sorgfalt erstellt wurden, können Druckfehler nicht ausge-schlossen werden. Änderungen in der Beschreibung, des Aussehens und der technischen Daten des IoT Multiboards oder des „Professional Configurators“ bleiben vorbehalten. Hersteller: DB Kommunikationstechnik GmbH Caroline-Michaelis-Straße 5 – 11 10115 Berlin Internet: www.dbkommunikationstechnik.de

Telefon: 0800 – 3346340

https://www.dbkommunikationstechnik.de/downloads

http://www.dbkommunikationstechnik.de/


1.1 Sicherheitsanweisungen

▪ Das IoT Multiboard ist ein elektronisches Gerät, dass ausschließlich durch qualifiziertes Personal mit einer Berufsausbildung im elektrotechnischen oder elektronischen Bereich montiert, in Betrieb gesetzt und instandgehalten werden darf. Es ist nicht zum Einbau und zur Nutzung durch private Endanwender vorgesehen oder geeignet.

▪ Reparaturen oder Veränderungen am Gerät dürfen nur durch - vom Hersteller - autori-sierte Werkstätten vorgenommen werden. Mit jeder Veränderung des Gerätes erlischt jeg-licher Gewährleistungs- und Haftungsanspruch. Dies gilt auch wenn Beschädigungen auf äußere Einflüsse zurückzuführen sind.

▪ Das IoT Multiboard verwendet zur Fernübertragung der ermittelten Daten das Funkproto-koll LoRaWAN. Dieses Protokoll beinhaltet eine gewisse Latenzzeit im Rahmen der Da-tenübertragung. Ebenso kann es bei der Nutzung lizenzfreier Funkfrequenzen zu Störun-gen durch andere Nutzer kommen. Es ist somit möglich, dass einzelne Datenübertragun-gen verzögert übertragen werden, bzw. im Extremfall auch verloren gehen können. Aus diesem Grund ist der Einsatz des IoT Multiboards für die Übertragung sicherheitsrelevan-ter Informationen nicht zulässig (ggf. Nutzung als Ergänzung zu einem zugelassenen Ver-fahren).

▪ Beim Anschluss des IoT Multiboards an die Spannungsversorgung und bei der Aufschal-tung der kundeneigenen Kontakte auf das Multiboard ist auf polungsrichtigen Anschluss und den korrekten Spannungsbereich der jeweiligen Ein- und Ausgänge zu achten. Die Nichtbeachtung kann zu Funktionsstörung oder Beschädigungen am Multiboard oder an der Kundenanlage führen.

▪ Die Spannungsversorgung des Multiboards muss über eine ausreichende Überstrom-schutzeinrichtung (Sicherung), die im Fehler- und Kurzschlussfall eine Beschädigung oder unzulässige Erhitzung der Spannungsversorgung und Zuleitungen verhindert. Die Dimen-sionierung der Spannungsversorgung und der Überstromschutzeinrichtung ist abhängig von der angeschlossenen Last. Hierzu sind durch den Errichter und Anwender unbedingt die Dimensionierungshinweise im Dokument „Gebrauchsanweisung IoT Multiboard“ zu beachten.

▪ Beim Anschluss einer USB-Powerbank (externes Zubehör) zur Ersatzstromversorgung ist auf den bestimmungsgemäßen Gebrauch der Powerbank zu achten (z.B. max. zulässige Umgebungstemperatur, Erschütterungen). Es gelten die Vorgaben des jeweiligen Herstel-lers. Bei der Auswahl der Powerbank ist auf das Vorhandensein von Konformitätserklä-rungen – insbesondere zur Produktsicherheit – zu achten. Die Nutzung beschädigter oder nicht geprüfter Powerbanks (z.B. aus Grauimporten) kann Brände oder Explosionen ver-ursachen. Die Nutzung eines IoT Multiboards gemeinsam mit einer Powerbank in einem Schienenfahrzeug ist aus zertifizierungstechnischen Gründen nicht zulässig.

▪ Für einen bestimmungsgemäßen Gebrauch dürfen nur die beschriebenen Zubehörteile verwendet werden.

▪ Das Produkt hat eine Zertifizierungsprüfung nach DIN EN 50155 durchlaufen und darf daher im Geltungsbereich der europäischen Union als elektronische Einrichtung auf Schienenfahrzeugen verwendet werden. Sofern der Einbau in Schienenfahrzeuge erfolgt, müssen beim Einbau, dem Betrieb und der Instandhaltung besondere Vorgaben beachtet werden, damit die Gültigkeit der Zertifizierung erhalten bleibt. Diese Hinweise sind in die-ser Gebrauchsanweisung und allen zugehörigen Einbauanleitung gesondert gekenn-zeichnet:

Sicherheitshinweis zum Einbau in Schienenfahrzeuge

Für den Einsatz in Schienenfahrzeugen werden die Module mit einem fes-ten Parameterdatensatz konfiguriert, der ohne vorherige Abstimmung mit dem verantwortlichen Betreiber nicht verändert werden darf.


1.2 Systemüberblick

Das IoT Multiboard ist ein Telemetriemodul zur Übertragung von externen und internen Sensor-daten über das Funkprotokoll LoRaWAN.

Es verfügt über folgende Merkmale:

▪ Eingangsspannungsbereich von 6-32V DC. Nennspannung 24V DC

▪ Lagerfähigkeit im Bereich -30°C bis +70°C Betriebstemperaturklasse: -40°C bis +70°C (OT 4). Max. Höhenlage: bis 1400m ü Meeresspiegel (EN 50125-1:2014, Tabelle 1 A1)

▪ Gehäuse IP20 für Hutschienen- und Wandmontage. Abmessungen: Breite 72mm / Höhe 90mm / Tiefe 48mm.

▪ Leistungsaufnahme: 250mW/400mW (Ruhe / Senden ohne externe Sensoren und ohne Powerbank)

▪ 3 galvanisch entkoppelte Digitaleingänge (0-32V DC)

▪ 2 digitale Eingänge (0-32V DC)

▪ 4 digitale Ein- oder Ausgänge (parametrierbar). Als Ausgang mit je max. 50mA belast-bar. Ansteuerung der Ausgänge über LoRaWAN-Steuerbefehl oder einstellbare Grenz-wertüberschreitungen an den analogen Eingängen möglich.

▪ 4 analoge Eingänge (0-10V DC)

▪ 1 UART-Schnittstelle zur Anbindung von Datenschnittstellen einer Kundenanlage

▪ 2 USB-Anschlüsse zur Parametrierung und den Anschluss einer USB-Powerbank als Ersatzstromversorgung bei Spannungsausfall. Ladestrom für Powerbank max. 1,5A.

▪ Interne Spannungsausgänge zur Versorgung extern angeschlossener Sensorik (3,3V/max. 100mA, 5V/max. 100mA und 6-32V DC)

▪ Eingebauter Lichtstärkesensor, Temperatursensor und Feuchtigkeitssensor.

▪ LoRaWAN™-Network Protocol ab V1.02 oder höher Device-Class: A oder C (einstellbar / muss vom LoRaWAN-Netz unterstützt werden) ADR abschaltbar Frequenzband 868 MHz (863 – 870 MHz) mit 14dBm Sendeleistung.

▪ Umfangreiche Parametriermöglichkeiten des Abfrage- und Sendeverhaltens und einer Schaltlogik.

Sicherheitshinweis zum Einbau in Schienenfahrzeuge

Für den Einsatz in Schienenfahrzeugen werden die Module mit einem fes-ten Parameterdatensatz konfiguriert, der ohne vorherige Abstimmung mit dem verantwortlichen Betreiber nicht verändert werden darf.

▪ Zertifiziert nach DIN EN 50155 (Bahnanwendungen – Elektronische Einrichtungen auf Schienenfahrzeugen). Zulassung für den Einbau in Schienenfahrzeuge. Hierbei gilt insbesondere die Berücksichtigung / Einbeziehung folgender Normen: EN 50121-3-2 Elektromagnetische Verträglichkeit EN 50125-1 Umweltbedingungen für Betriebsmittel EN 45545-2 Brandschutz

▪ CE-Kennzeichnung - Konformität mit: EU-Richtlinie 2011/65/EU (RoHs) EU-Richtlinie 2014/35/EU (Niederspannungsrichtlinie) EU-Richtlinie 2014/30/EU (EMV) EU-Richtlinie 2014/53/EU (RED)


1.2.1 Erforderliche Parameter in einem LoRaWAN-Netz

Der LoRaWAN-Standard wird durch die LoRa-Alliance entwickelt und festgeschrieben. Der zum Druckzeitpunkt aktuelle LoRaWAN-Standard ist die Version 1.1. Das IoT Multiboard wird in allen LoRaWAN-Netzen ab dem LoRaWAN-Standard 1.02 unterstützt. Die Wahl des LoRaWAN-Net-zes ist beliebig, jedoch muss eine sogenannte Personalisierung und Aktivierung im gewünschten Netz erfolgen. Die wichtigsten Parameter werden im folgenden Teil beschrieben. Bitte beachten Sie, dass die Implementierung des LoRaWAN-Standards in den zu nutzenden Netzen unter-schiedlich und z.T. versionsabhängig erfolgt. Hieraus resultiert auch ggf. ein unterschiedlicher Funktionsumfang des Netzes. Es wird empfohlen, das Vorhandensein benötigter Features (z.B. Unterstützung Class C-Device) vorab mit dem Netzbetreiber zu klären.

1.2.1.1 Personalisierung - Schlüssel und Adressen in einem LoRaWAN-Netz

Zur Personalisierung des IoT Multiboards werden folgende Parameter verwendet:

Art Parameter Erklärung

Adresse

DevEUI

Weltweit eindeutige Adresse (64 Bit-Kennung) des IoT Multiboards, die im Produktionsprozess (noch vor der Aktivierung) fest im Gerät gespeichert wird (vergleichbar mit MAC-Adresse). Die DevEUI ist fest mit der Seriennummer verknüpft. Die DevEUI kann im Rahmen der Parametrierung nicht verändert werden.

Hinweis: Die DevEUI ist an jedem IoT Multiboard im Klartext und als QR-Code angebracht (EUI):

AppEUI

Eindeutige ID (64 Bit-Kennung) der Anwendung (z.B. eine AppEUI für alle IoT Multiboards in Schienenfahrzeugen der DB). Diese ID wird im Produktionsprozess ebenfalls fest im Gerät gespeichert, sie kann jedoch über die Parametrierungsebene verändert werden. Dies kann notwendig werden, wenn der LoRaWAN-Netzbetreiber geän-dert wird. Meist bestehen aber in der Administrationsebene des Lo-RaWAN-Netzes Möglichkeiten die bereits implementierte AppEUI zu übernehmen. In LoRaWAN-Netzen ab Version 1.1 wird eine sogenannte JoinEUI vergeben. Diese entspricht in Endgeräten vor der Version 1.1 der AppEUI (z.B. Anmeldung eines IoT Multiboards im TTN-Netz V3-Stack).

IoT MultiboardLoRaWAN-Telemetriemodul

Betriebsspannung: 6-32V DCLeistungsaufnahme: 1,3W (No Charger)

DIN EN 50155 cer tified

X3

1 2 3 4 1 2 3 4

5 6 7 85 6 7 8

X4USB USB

X21 2 3 41 2 3 4

5 6 7 8 5 6 7 8

X1

ChargerMax. 1,5A

EUI: 70B4D58FA003A5EB

SN: 00034311

DB Kommunikationstechnik GmbHCaroline-Michaelis-Str. – Berlin

https://lora-alliance.org/

https://lora-alliance.org/resource-hub/lorawanr-specification-v11

https://lora-alliance.org/resource-hub/lorawanr-specification-v102


DevAddr

Die DevAddr ist eine Adresse (32 Bit) innerhalb des genutzten LoRa-WAN-Netzes, die nicht weltweit eindeutig sein muss (nur innerhalb des LoRaWAN-Netzes). Sie ist vergleichbar mit einer – von einem DHCP-Server - zugewiesenen IP-Adresse in einem LAN. Wichtig: Bei der Aktivierung über das OTAA-Verfahren, wird die DevAddr im Aktivierungsverfahren vergeben. Bei der Aktivierung über das ABP-Verfahren muss die DevAddr vorab im IoT Multiboard hinterlegt wer-den (vorherige Generierung im LoRaWAN-Netz erforderlich). Sollte später der LoRaWAN-Netzbetreiber geändert werden, kann es prob-lematisch werden, das Multiboard ohne erneute Parametrierung in das neue Netz einzubinden. Die DevAddr lässt sich in vielen Netzen nicht frei vergeben. Die DevAddr kann im Rahmen der Parametrie-rung verändert werden.

Key

AppKey

Der Application Key ist ein applikationsspezifischer Key, der nur dem IoT Multiboard und dem Applikationsbetreiber bekannt ist. Der App-Key kann für jedes Gerät einzeln und individuell erzeugt werden, oder für eine Gruppe von Geräten gemeinsam verwendet werden. Im OTAA-Aktivierungsverfahren dient er der Generierung von NwkS-Key und AppSKey. Aus diesem Grund ist es sicherheitstechnisch empfehlenswert, für jedes Gerät einen eigenen AppKey zu verwen-den. Der AppKey kann im Rahmen der Parametrierung verändert werden.

NwkSKey

Der NwkSKey wird zur Verschlüsselung der gesamten Information auf dem Übertragungsweg vom Gerät zum Network-Server verwen-det (Integritätscheck). Im Rahmen der OTAA-Aktivierung wird der NwkSKey aus DevEUI, AppEUI und AppKey gebildet. Jeder Neu-start des IoT Multiboards erzeugt einen neuen NwkSKey. Der Key wird zu keiner Zeit in LoRaWAN übertragen.

Im ABP-Aktivierungsverfahren, wird der NwkSKey zuvor im Netz ge-neriert und dann im IoT-Multiboard fest abgespeichert. Er kann über die Parametrierung verändert werden. Der NwkSKey kann bei ABP im Rahmen der Parametrierung verän-dert werden.

AppSKey

Der AppSKey wird zur Verschlüsselung der reinen Payload (Nutzda-ten) auf dem Übertragungsweg vom Gerät zum Application-Server verwendet (Verschlüsselung der Nutzdaten). Im Rahmen der OTAA-Aktivierung wird der AppSKey aus DevEUI, AppEUI und AppKey ge-bildet. Jeder Neustart des IoT Multiboards erzeugt einen neuen AppSKey. Der Key wird zu keiner Zeit in LoRaWAN übertragen.

Im ABP-Aktivierungsverfahren, wird der AppSKey zuvor im Netz ge-neriert und dann im IoT-Multiboard fest abgespeichert. Er kann über die Parametrierung verändert werden.

Abbildung 1: Parameter in einem LoRaWAN-Netz


1.2.1.2 LoRaWAN – Sendezeitbegrenzung durch Duty-Cycle-Verfahren

Um allen Devices in einem LoRaWAN-Netz einen gleichberechtigten Zugriff auf die Transport-ressourcen des Netzes gewähren, verhindert der Standard, dass ein Device die verfügbaren Ka-näle zu lange belegen kann. LoRaWAN nutzt hierzu das Duty-Cycle-Verfahren (Duty Cycle 1%) um die max. Sendedauer eines Devices zu begrenzen. Der Duty Cycle von 1% bedeutet: Wenn ein Device über einen Zeitraum von 0,5s gesendet hat, steht ihm erst nach 49,5s ein erneutes Sendezeitfenster zu Verfügung.

Die Sendedauer eines Devices wird durch folgende Faktoren beeinflusst:

▪ Gute/Schlechte Empfangsqualität der Funkübertragung und damit niedrige/hohe Spreiz-faktoren (SF 7- SF12). Dies bewirkt eine kurze oder längere Übertragungsdauer einer bestimmten Datenmenge. → Durch Aufbauort und Netzressourcen (Anzahl Gateways) zu beeinflussen.

▪ Zu übertragene Datenmenge (Payload) je Sendevorgang. →Fest im IoT Multiboard festgelegt (32 Byte).

▪ Häufigkeit der Sendevorgänge. → Durch Parametrierung zu beeinflussen

▪ Gesicherte / Ungesicherte Übertragung: Bei gesicherten Übertragungen werden verloren-gegangene Übertragungen wiederholt, bis die Bestätigung aus dem Netz erfolgt. → Durch Parametrierung zu beeinflussen

Die Parametrierung eines IoT Multiboards sollte daher immer das Ziel verfolgen, die mindestens erforderlichen Daten auf dem ressourcenschonendsten Weg im LoRaWAN-Netz zu übertragen.

1.2.1.3 Aktivierung eines IoT Multiboards in einem LoRaWAN-Netz

Es existieren zwei Methoden der Aktivierung in einem LoRaWAN-Netz, die im Rahmen der Pa-rametrierung festzulegen sind:

Over The Air Activation (OTAA):

▪ OTAA nutzt die AppEUI, die DevEUI und den AppKey zur Generierung des NwkSKey des AppSKey und der DevAddr. Die DevAddr wird vom Netzwerk zugewiesen, die Verschlüs-selungskeys werden im Gerät und Netzwerk abgeleitet, ohne je übertragen zu werden. OTAA ist das am häufigsten genutzte Aktivierungsverfahren, da es Sicherheitsvorteile durch die regelmäßige Neugenerierung der Verschlüsselungskeys und in der Provisionie-rung bietet. Mit LoRaWAN-Standard 1.1 ermöglicht OTAA auch Roaming.

Activation By Personalization (ABP):

▪ Hier ist die DevAddr, der NwkSKey und der AppSKey bereits fest im Device hinterlegt. Das Device ist somit bereits fest in einem spezifischen LoRaWAN-Netz angemeldet.

Nach der Aktivierung sind in jedem Gerät immer folgende Informationen gespeichert:

▪ DevAddr (Device Adress)

▪ AppEUI (Application Identifier)

▪ NwkSKey (Network Session Key)

▪ AppSKey (Application Session Key)

Bei OTAA-Geräten werden DevAddr, NwkSKey und AppSkey bei jedem neuen Einschalten/Re-set des Gerätes neu generiert (Aktivierungsprozess). Werden die Informationen gehackt, ist im-mer nur das eine Gerät kompromittiert. Daher wird aus sicherheitstechnischen Erwägungen das OTAA-Verfahren eindeutig empfohlen.


1.2.1.4 LoRaWAN Device-Classes

Im LoRaWAN-Standard unterscheidet man drei verschiedene Endgeräteklassen (Class A, B und C). Über diese Klassen wird festgelegt, ob und zu welchen Zeitpunkten ein Endgerät (Multiboard) in der Lage ist, Mitteilungen aus dem Netz zum Endgerät (Downlink) zu empfangen. Das jeweilige Verhalten bestimmt unmittelbar auch den Energiebedarf, sodass die Wahl der Spannungsversor-gung (Batterie oder feste Versorgungsspannung) eine Auswirkung auf die zu wählende Device-Class hat. Das IoT Multiboard unterstützt die Klassen A und C:

▪ Class A: Besonders energiesparender Modus für batteriebetriebene Endgeräte. Das End-gerät ist nur dann zum Empfang von Downlinks in der Lage, wenn es zuvor selbst eine Mitteilung gesendet hat. Nach jedem Sendevorgang öffnet sich ein kurzes, definiertes Empfangszeitfenster, in dem Downlinks empfangen werden können. Hierdurch sind Downlinks zum Teil nur in zufallsabhängigen Zeiten möglich (von Parametrierung abhän-gig).

▪ Class C: Höherer Energiebedarf (nicht für Dauerbetrieb batteriebetriebener Endgeräte ge-eignet) durch ständige Empfangsbereitschaft. Zustellung von Downlinks ist permanent möglich. Für den Regelbetrieb des IoT Multiboards an einer permanenten Spannungsver-sorgung wird die Nutzung des Class C-Modus empfohlen.

1.2.2 Payload-Struktur des IoT Multiboards

Die reine Nutzdateninformation einer LoRaWAN-Übertragung des IoT Multiboards besteht aus 32 Byte. Die Byte-Folge entspricht „Little Endian“.

Abbildung 2: Payload Select und Digital Inputs

Bytes Select: Die Select-Bytes können zur Übertragung weiterer Informationen (z.B. für Funktionen der seriel-len Schnittstelle) verwendet werden. Im Standard steht der Wert auf 0x0001 Bytes Digital Inputs: Die Bits für D1 bis D9 werden je nach Eingangszustand des Eingangs geschaltet: Wert Logisch „0“: Kein Kontakt (D1-D6: Spannung < 3V / D7-D9: Spannung < 5V) am Eingang. Wert Logisch „1“: Kontakt (D1-D6: Spannung >3V / D7-D9: Spannung > 5V) am Eingang. Hinweise:

▪ Die Ausgabe der Inputs kann auch über Parameter-ID 58 je Eingang invertiert werden. ▪ Die Ausgabe der Inputs kann über Parameter-ID 59 abgeschaltet werden. ▪ D1 bis D4 können über Parameter-ID 60 auch als Ausgänge geschaltet werden.

Abbildung 3: Payload Versorgungsspannung und Analog 1

Bytes Versorgungspannung X4-2/3: Der gemessene elektrische Spannungswert der Versorgungsspannung an der Klemme X4-2/3. Ganzzahl im Bereich 0-65.535 (Wert in mV). Bytes Analog 1: Der gemessene elektrische Spannungswert am analogen Eingang 1 (Klemme X3-2) Ganzzahl im Bereich 0-10.000 (Wert in mV).

D8 D7 D6 D5 D4 D3 D2 D1 0 0 0 0 0 0 0 D9

Select Digital Inputs

Byte 0 (LSB) Byte 1 (MSB) Byte 2 (LSB) Byte 3 (MSB)

im Standard 0x0001

Byte 6 (LSB) Byte 7 (MSB)

Versorgungspannung X4-2/3 Analog 1


Zahl 0-65.535 (in mV) Zahl 0-10.000 (in mV)


Abbildung 4: Payload Analog 2 und Analog 3

Bytes Analog 2: Der gemessene elektrische Spannungswert am analogen Eingang 2 (Klemme X3-3) Ganzzahl im Bereich 0-10.000 (Wert in mV). Bytes Analog 3: Der gemessene Wert am analogen Eingang 1 (Klemme X3-4) Ganzzahl im Bereich 0-10.000 (Wert in mV).

Abbildung 5: Payload Analog 4 und Temperatur

Bytes Analog 4: Der gemessene elektrische Spannungswert am analogen Eingang 1 (Klemme X3-6) Ganzzahl im Bereich 0-10.000 (Wert in mV). Bytes Temperatur: Der gemessene Wert am internen Temperatursensor mit 0,1°C pro LSB

Abbildung 6: Payload Relative Feuchte und Lichtstärke

Bytes Relative Feuchte: Der gemessene Wert am internen Feuchtesensor mit 0,1% rel. Feuchte pro LSB Bytes Helligkeit: Der gemessene Wert am internen Lichtsensor mit 1 Lux pro LSB

Abbildung 7: Payload Firmware- und Parametrierungsversion

Bytes Firmware- und Parametrierungsversion: Parameter-Zähler: Eindeutige ID einer bestimmten Funktionsparametrierung Parameter-Version: Versionsnummerierung innerhalb des Parameter-Zählers Firmware-Zähler: Eindeutige ID einer bestimmten funktionalen Firmwarevariante Firmware-Version: Versionsnummerierung innerhalb des Firmware-Zählers

Abbildung 8: Payload Reserve

Bytes Reserve: Noch nicht definiert (Reserve für zukünftige Anwendungen)

Analog 2


Analog 3


Zahl 0-10.000 (in mV) Zahl 0-10.000 (in mV)

Analog 4


Temperatur

Zahl 0-10.000 (in mV) 0.1°C pro LSB


Relative Feuchte Helligkeit

0.1% rel. Feuchte pro LSB 1 Lux pro LSB

Byte 20 (LSB) Byte 21 Byte 22 Byte 23 (MSB)

Firmware- und Parametrierungsversion

Firmware-VersionParameter-Zähler Parameter-Version Firmware-Zähler

Byte 25Byte 24 (MSB) Byte 26 Byte 27 (LSB)

Reserve

Reserve, noch nicht definiert


Abbildung 9: Payload Zeit

Bytes Zeit: Unix-Zeitstempel in Sekunden nach dem 1.1.1970. Durch die vorzeichenlose Implementierung entsteht kein Problem durch den Jahr-2038-Überlauf.

1.3 Parametrierung

Im Rahmen der Parametrierung kann das IoT Multiboard funktional auf die individuellen Erfor-dernisse der Kundenanwendung eingestellt werden.

1.3.1 Herstellung einer Verbindung mit einem PC

Zur Durchführung einer Parametrierung ist das Multiboard zunächst komplett freizuschalten (Ab-ziehen aller Stecker von den Anschlussklemmen). Anschließend wird das Multiboard über die Micro USB-Buchse mit einem geeigneten USB-Kabel an einen PC oder ein Notebook ange-schlossen. Die Stromversorgung des Multiboards erfolgt in dieser Situation über den USB-An-schluss.

USB-KabelUSB Typ A-Stecker auf

Micro USB Typ B-Stecker

PC / Notebook IoT Multiboard(untere Anschlussseite)

AnschlussMicro USB (Konsole)

Abbildung 10: Verbindung Multiboard mit PC

Anschließend wird auf dem PC ein Terminalprogramm gestartet (z.B. Hyperterminal, TeraTerm oder PuTTY). Alternativ kann die Parametrierung auch mit dem Tool „Professional Configurator“ vereinfacht durchgeführt werden.

Zeit

Byte 28 (MSB) Byte 29 Byte 30 Byte 31 (LSB)

Sekunden nach 1.1.1970 (als Unsigned - Kein Jahr 2038-Überlauf)


Die Datenübertragung des Terminalprogramms wird auf folgende Werte eingestellt: Geschwindigkeit: 115200 Baud Parität: None Data: 8 Stop: 1 Sobald die Verbindung hergestellt wurde kann die Parametrierung auf zwei verschiedenen We-gen erfolgen:

▪ Eingabe einzelner Parametrierungsbefehle über das Terminalprogramm.

▪ Übertragung einer Parameterdatei im txt- oder csv-Format (siehe 1.3.3).

1.3.2 Parametrierungsmöglichkeiten

Das Multiboard erlaubt die Parametrierung der LoRaWAN- und Funktionseinstellungen über AT-Kommandos und Parameter-IDs.

Es stehen folgende AT-Kommandos für Befehle und Zustandsabfragen zur Verfügung:

▪ r CR(Carriage Return): read – Ausgabe des vollständigen Parametrierungsdatensatzes (Kontrolle der Einstel-lungen und Datenübernahme). Ausgabe als Bildschirmanzeige. Die Bildschirmanzeige (vom ersten bis zum letzten Parametersatz) kann markiert, kopiert und als txt-Datei ab-gespeichert werden. Die txt-Datei kann dann als Backup der Parametrierung später wie-der eingespielt werden. Beispiel (Teilausschnitt):

▪ e CR(Carriage Return): environment – Ausgabe der Daten der internen Sensoren für Temperatur, rel. Luft-feuchte, Beleuchtungsstärke und Spannungsversorgung. Beispiel:


▪ a CR(Carriage Return): analog – Ausgabe der aktuell eingelesenen analogen Eingangswerte. Die gemessenen Werte werden in folgender Reihenfolge ausgegeben:

Beispiel:

▪ d CR(Carriage Return): digital - Ausgabe der aktuell eingelesenen digitalen Portstatus (0 oder 1). Die Status werden in folgender Reihenfolge ausgegeben:

Beispiel:

D1 und D4 im Status Logisch „1“

▪ wPARAMETER-ID,PARAMETERWERT CR(Carriage Return): write – Schreibbefehl für Parametersatz. Parameter-ID und Parameterwert werden durch Komma getrennt. Jedem Befehl folgt ein CR (Carriage Return). Achtung: Das permanente Speichern der Parameter in den nichtflüchtigen Speicher er-folgt erst mit dem f-Befehl. Ohne diesen Speichervorgang geht der gesetzte Parameter-wert bei einem Neustart des Multiboards verloren.

▪ f CR(Carriage Return): flash – Speichervorgang des kompletten, zuvor eingegebenen, Parametersatzes in den nichtflüchtigen Flash-Speicher des Multiboards. Empfehlung: Erst alle erforderlichen Parameterwerte setzen und am Schluss mit dem f-Befehl in den Flash-Speicher abspeichern. Die Ausführung des f-Befehls ist nur im Admin-Modus möglich. Beispiel (im Admin-Modus):

Befindet man sich nicht im Admin-Modus erfolgt keine Bestätigung „Parameter flashed“

0.000V 0.000V 0.000V 0.000V

Analog 1 Analog 2 Analog 3 Analog 4

0 0 0 0 0 0 0 0 0

Digital 9 Digital 8 Digital 7 Digital 6 Digital 5 Digital 4 Digital 3 Digital 2 Digital 1


▪ c CR(Carriage Return): Neustart des IoT Multiboards innerhalb von 5s nach Eingabe (Durchführung verzögert). Achtung: Nicht gespeicherte Parameter gehen beim Neustart verloren. Beispiel:

▪ i CR(Carriage Return): intern – Ausgabe der wichtigsten LoRaWAN-Netzparameter bei einem im Netz einge-buchten IoT Multiboard. Beispiel:

▪ j CR(Carriage Return): join – Join Network (Erzwungene Durchführung einer Abmeldung und (Neu-)Anmeldung im LoRaWAN Netz – Vorherige Parametrierung der LoRaWAN-Parameter erforderlich)

▪ p CR(Carriage Return): Passwort – Innerhalb der ersten 60s nach einem Neustart/Reboot kann der p-Befehl ein-gegeben werden. Er führt zu einer Abfrage des Admin-Passworts. Nach korrekter Eingabe des Passworts wird der Admin-Modus aktiviert und man erhält Zugriff auf den f-Befehl zum permanenten Abspeichern von Parametern im Flash-Speicher. Bei Aufruf des i-Be-fehls wird die Aktivierung des Admin-Modus angezeigt. Beispiel:


i-Befehl (im Admin-Modus):

▪ obD4D3D2D1 CR(Carriage Return):

Output – Die ggf. als Ausgang parametrierten digitalen I/O D1 bis D4 können über eine binäre (b) Maske direkt angesteuert werden. Beispiel: ob1010 schaltet die Ausgänge D4 und D2 ein und die Ausgänge D3 und D1 aus (Achtung: EIN schaltet Masse/GND).


1.3.2.1 LoRaWAN-Parametrierungsbereiche

Die erforderlichen LoRaWAN-Einstellungen erfolgen über folgende Parameter-IDs:

Abbildung 11: Parametertabelle LoRaWAN mit Beispielen

Parameter-ID Parameterwert (Beispiel) Beschreibung

1 x0AF035717CC1CB3C5FD92376315849A8

ApplicationKey (OTAA) oder ApplicationSessionKey (ABP)

Hier wird - je nach Aktivierungsart - der ApplicationKey (OTAA)

oder der ApplicationSessionKey (ABP) mit führendem x als 8 Byte-

Hexadezimalwert eingegeben.

2 x0BF035717DC3CB3C5FD92376315849A7

NetworkSessionKey (nur bei ABP).

Hier wird bei ABP der NetworkSessionKey mit führendem x als 8

Byte-Hexadezimalwert eingegeben.

Bei OTAA wird diese ID nicht verwendet.

3 xC3ED1DC58CE16DA8

ApplicationEUI (OTAA) oder DevAddr (ABP)

Hier wird bei OTAA die ApplicationEUI und bei ABP die

DeviceAdress mit führendem x als 4 Byte-Hexadezimalwert

eingetragen.

7 2

LoRa Aktivierungsmethode:

0 = LoraInactive (LoRa ist deaktiviert) - Dezimale Ganzzahl

1 = ABP - Dezimale Ganzzahl

2 = OTAA - Dezimale Ganzzahl

8 1

DataTransmission:

0 = Unreliable (ungesicherte Übertragung ohne Netz-

Empfangsbestätigung)

1 = Reliable (gesicherte Übertragung mit Netz-

Empfangsbestätigung)

65 3600

TXIntervall Keep-Alive in Sekunden

Einstellung eines Mindest-Sendeintervalls wenn kein

Sendevorgang getriggert wurde

Gültiger Wertebereich:

0 = Keine Keep-Alive-Sendung

1 bis 65535 (Dezimale Ganzzahl in s)

66 30

TXFirst - Einschaltverzögerung in Sekunden

Einstellung einer Verzögerung des erstes Sendens nach dem

Einschalten


0 = Keine Einschaltverzögerung


75 5

Einstellung Device Class und Adaptive Data Rate (ADR)

0 = Class A ohne ADR

1 = Class A mit ADR (default)

4 = Class C ohne ADR

5 = Class C mit ADR

76 3

Einstellung Spreizfaktor (SF) als Fixfaktor (bei abgeschaltetem

ADR) oder Startfaktor (bei eingeschaltetem ADR)

0 = SF12

1 = SF11

2 = SF10

3 = SF9 (default)

4 = SF8

5 = SF7


Abbildung 12: Parametrierung LoRaWAN (Überblick)

Empfehlungen:

▪ Security: Die Aktivierung über OTAA ist immer zu bevorzugen.

▪ Security: Der ApplicationKey sollte für jedes Device separat generiert werden (z.B. über Zufallsgenerator). Nach Möglichkeit nicht für eine ganze Gruppe von Geräten denselben ApplicationKey verwenden.

▪ Sendehäufigkeit: Um die Belegung des LoRaWAN-Netzes möglichst zu reduzieren, ist die Wahl der DataTransmission anwendungsbezogen abzuwägen. Jede Empfangsbestäti-gung einer Übertragung belegt zusätzliche Netzressourcen. Empfangsbestätigungen soll-ten daher nur bei sinnvollem Bedarf aktiviert werden (z.B. Daten mit hoher Priorität oder Geräte, die nur äußerst selten senden). Siehe hierzu 0.

▪ Sendehäufigkeit: Die Keep-Alive-Sendung (Parameter-ID 65) sollte so selten wie möglich erfolgen und so oft wie erforderlich eingestellt werden (z.B. einmal alle 24h/48h).

▪ Einschaltverzögerung (Parameter-ID 66): Werden regelmäßig örtlich eng nebeneinander liegende Devices gleichzeitig eingeschaltet, empfiehlt es sich, die Erstsendungen der De-vices zeitlich zu verteilen, damit nicht gleichzeitig viele Devices den LoRaWAN-Anmelde-vorgang initiieren (ggf. gegenseitige, temporäre Blockade). Variierende Zeitwerte auf den einzelnen Devices können diese Problematik entzerren.

▪ Bei einem Betrieb an einer permanenten Spannungsversorgung und der Erfordernis zur Fernschaltung der digitalen Ausgänge über LoRaWAN ist die Device Class C einzustellen.

▪ Es wird empfohlen, die Adaptive Data Rate (ADR) zu aktivieren um eine bestmögliche, an den Übertragungsweg angepasste, Übertragungsgeschwindigkeit zu erzielen. Nur bei Problemen (oder permanent konstanten Bedingungen) kann ADR deaktiviert werden.

1.3.2.2 Einstellung Abtastraten

Mit den folgenden Parameter-ID lassen sich die Abtastzyklen der Zustands-/Messwerterfassun-gen an digitalen I/O, analogen Eingängen und internen Sensordaten (Temperatur, rel. Luft-feuchte, Beleuchtungsstärke und Spannungsversorgung) festlegen. Die Einstellung der Abtast-raten beeinflusst, wie schnell das IoT-Multiboard Zustandsänderungen erkennen kann. Im Zu-sammenhang mit den Triggerkriterien und der Sendeverzögerung lässt sich so die Häufigkeit der LoRaWAN-Übertragung steuern. Im Zusammenspiel aller senderelevanten Faktoren ist darauf zu achten, die Belegung des LoRaWAN-Netzes auf das mindestens erforderliche Maß zu redu-zieren, da ansonsten durch den LoRaWAN-Standard Zwangssendepausen (Stichwort Duty-Cycle-Verfahren) entstehen. Siehe hierzu Abschnitt 1.2.1.2.

OTAA ABP

1 ApplicationKey ApplicationSessionKey

2 nicht verwendet (leer) NetworkSessionKey

3 ApplicationEUI DevAddr

7 2 1

7

8

Parameter-IDParameterwert je Aktivierungsmethode

0 (ungesichert) oder 1 (gesichert)

0 (LoRa deaktiviert)


Abbildung 13: Parametertabelle Abtastzyklen

Hinweis: Wird die Funktion des Filters für schwankende analoge Werte genutzt (siehe Kapitel 1.3.2.9), hat die Einstellung der Abtastraten für die analogen Eingänge und die internen Sensoren (Para-meter-ID 5 und 6) eine unmittelbare Auswirkung auf die Filterfunktion. Diese Einstellungen sind dann stets in die Bestimmung der Filter Parameterwerte einzubeziehen.

1.3.2.3 Einstellung der Kriterien für Sendevorgänge

Die jeweiligen Eingänge und internen Umweltsensoren werden gem. der in festgelegten Zeitin-tervalle abgefragt. Über einen zuschaltbaren Filter können vor der Bewertung stark schwankende Messwerte geglättet werden (Tiefpass 1. Ordnung). Die Auslösung eines Sendevorgangs kann dann über zwei Methoden ausgelöst werden:

▪ Der aktuell gemessene Zustand / Messwert über-/unterschreitet einen festgelegten obe-ren oder unteren Grenzwert (intern und analog) oder ändert seinen Status (digital).

und / oder

▪ Es wird eine Zustands- oder Messwertänderung gegenüber dem letztmalig zuvor gemessenen Wert festgestellt (logischer Wechsel an digitalem Eingang oder Delta-Abwei-chung eines internen oder analogen Messwertes).

Abbildung 14: Schaltlogik "Kriterien für Sendevorgänge"


4 1

Abtastrate Digitale I/O in Sekunden


0 = Abtastung ausschalten


5 1

Abtastrate Analogeingänge in Sekunden




6 60

Abtastrate interne Sensoren in Sekunden




Abtastung Eingänge/Interne

Sensoren(gem. Abtastrate 4,5

und 6)

Delta-Abweichung zum vorherigen Wert

UNDParameterwert

ungleich 0?

LoRaWAN-Sendevorgang

Übertragung der abgetasteten Werte

Oberer Grenzwert

überschritten UND

Parameterwert ungleich 0?

Unterer Grenzwert

unterschritten UND

Parameterwert ungleich 0?

TtS ungleich 0

TtS ungleich 0

TtS ungleich 0

OR

Parameterwert = 0 bricht Bewertung und

Sendevorgang ab(Ausnahme Temperatur)

TtS = 0Bricht

Sendevorgangimmer ab

Filter Tiefpass

1. Ordnung

Parameterwert = 0 schaltet Filter aus


1.3.2.4 Trigger „Delta-Abweichung“ und “Time to Send”

Durch die Einstellung der Parameter „Delta-Abweichung“ wird nach der Abtastung interner oder analoger Werte bewertet, ob der vorherige Abtastwert vom aktuellen Abtastwert um das einge-stellte Delta abweicht. Falls ja, gilt dies als Trigger-Kriterium für einen Sendevorgang, der dann nach Ablauf der eingestellten Verzögerung „Time to Send (TtS)“ erfolgt.

Abbildung 15: Parametertabelle Delta (Abweichung vom vorherigen Wert)

Hinweis: Wird bei den Delta-Parametern eine 0 (Null) als Parameterwert eingetragen, erfolgt keine Del-tabewertung und somit auch kein potentieller Trigger für einen Sendevorgang. Soll die Delta-Abweichung als Sendetrigger für sich langsam ändernde analoge oder interne Werte genutzt werden, ist darauf zu achten, die Einstellung des Deltas in Kombination mit dem Abtastintervall so zu setzen, dass zwischen den Abtastungen auch ein hinreichend großes Delta als Trigger erreicht werden kann.


9 2400

Delta Versorgungsspannung in mV

Festlegung der maximalen Abweichung vom vorher gemessen

Wert, die einen Sendevorgang auslöst.


0 = Kein Sendevorgang durch Abweichung

1 bis 32000 (Dezimale Ganzzahl in mV)

10 200

Delta Analog1 in mV






11 200

Delta Analog2 in mV






12 200

Delta Analog3 in mV






13 200

Delta Analog4 in mV






14 100

Delta Temperatur in 0.1°C





1 bis 1000 (Dezimale Ganzzahl in 0.1°C)

15 200

Delta Lichtstärke in Lux





1 bis 65535 (Dezimale Ganzzahl in Lux)

16 100

Delta rel. Luftfeuchtigkeit in 0,1%





1 bis 950 (Dezimale Ganzzahl in 0.1% rel. Luftfeuchtigkeit)


Abbildung 16: Parametertabelle Time to Send bei Delta-Abweichung

Hinweis: Das Setzen des jeweiligen „Time to Send (TtS)“-Parameterwertes legt die Verzögerungszeit von der Feststellung des Trigger-Kriteriums bis zum Sendevorgang fest. Die Verzögerung ist von 1 bis 65535 Sekunden einstellbar (entspricht max. 1092,25 Minuten oder 18,204 Stunden). Wird eine 0 (Null) gesetzt, erfolgt bei der Feststellung des Trigger-Kriteriums grundsätzlich kein Sen-devorgang.


33 60

TtS Delta Versorgungsspannung in Sekunden

Time to Send - Festlegung der zeitlichen Verzögerung zwischen

dem Auslösen des Triggerereignisses bis zum Sendevorgang.


0 = Kein Sendevorgang


34 60

TtS Delta Analog1 in Sekunden






35 60







36 60







37 60







38 60

TtS Delta Temperatur in Sekunden






39 60

TtS Delta Lichtstärke in Sekunden






40 60

TtS Delta rel. Luftfeuchtigkeit in Sekunden







1.3.2.5 Trigger “Unterer Grenzwert” und “Time to Send”

Durch die Einstellung der Parameter „Unterer Grenzwert“ wird nach der Abtastung interner oder analoger Werte bewertet, ob der aktuelle Abtastwert den eingestellten unteren Grenzwert unter-schreitet. Falls ja, gilt dies als Trigger-Kriterium für einen Sendevorgang, der dann nach Ablauf der eingestellten Verzögerung „Time to Send (TtS)“ erfolgt.

Abbildung 17: Parametertabelle Unterschreitung untere Grenzwerte

Hinweis: Wird bei den „Unterer Grenzwert“-Parametern eine 0 (Null) als Parameterwert eingetragen, er-folgt keine Unterschreitungsbewertung und somit auch kein potentieller Trigger für einen Sende-vorgang. Die einzige Ausnahme ist hierbei der Temperaturparameter (22). Hier kann auch der untere Grenzwert 0° C zur Bewertung gesetzt werden. Soll jedoch bei Unterschreitung des unte-ren Grenzwertes trotzdem kein Sendevorgang ausgelöst werden, ist im zugehörigen TtS-Para-meter (46) eine 0 (Null) zu setzen.


17 20000

Unterer Grenzwert Versorgungsspannung in mV

Festlegung eines unteren Grenzwertes, der bei Unterschreitung

einen Sendevorgang auslöst.


0 = Kein Sendevorgang durch Grenzwertunterschreitung


18 4800

Unterer Grenzwert Analog1 in mV






19 500







20 4800







21 500







22 -100

Unterer Grenzwert Temperatur in 0.1°C



Gültiger Wertebereich (ggf. mit negativem Vorzeichen):

-400 bis 850 (Dezimale Ganzzahl in 0.1°C)

23 0

Unterer Grenzwert Lichtstärke in Lux






24 0

Unterer Grenzwert rel. Luftfeuchtigkeit in 0.1%







Abbildung 18: Parametertabelle Time to Send bei Unterschreitung unterer Grenzwerte



41 60

TtS Unterer Grenzwert Versorgungsspannung in Sekunden






42 60

TtS Unterer Grenzwert Analog1 in Sekunden






43 60







44 60







45 60







46 60

TtS Unterer Grenzwert Temperatur in Sekunden






47 60

TtS Unterer Grenzwert Lichtstärke in Sekunden






48 60

TtS Unterer Grenzwert rel. Luftfeuchtigkeit in Sekunden







1.3.2.6 Trigger “Oberer Grenzwert” und “Time to Send”

Durch die Einstellung der Parameter „Oberer Grenzwert“ wird nach der Abtastung interner oder analoger Werte bewertet, ob der aktuelle Abtastwert den eingestellten oberen Grenzwert über-schreitet. Falls ja, gilt dies als Trigger-Kriterium für einen Sendevorgang, der dann nach Ablauf der eingestellten Verzögerung „Time to Send (TtS)“ erfolgt.

Abbildung 19: Parametertabelle Überschreitung obere Grenzwerte

Hinweis: Wird bei den „Obere Grenzwert“-Parametern eine 0 (Null) als Parameterwert eingetragen, erfolgt keine Überschreitungsbewertung und somit auch kein potentieller Trigger für einen Sendevor-gang. Die einzige Ausnahme ist hierbei der Temperaturparameter (30). Hier kann auch der obere Grenzwert 0° C zur Bewertung gesetzt werden. Soll jedoch bei Überschreitung des oberen Grenz-wertes trotzdem kein Sendevorgang ausgelöst werden, ist im zugehörigen TtS-Parameter (54) eine 0 (Null) zu setzen.


25 30000

Oberer Grenzwert Versorgungsspannung in mV

Festlegung eines oberen Grenzwertes, der bei Überschreitung



0 = Kein Sendevorgang durch Grenzwertüberschreitung


26 6000

Oberer Grenzwert Analog1 in mV






27 6000







28 6000







29 6000







30 300

Oberer Grenzwert Temperatur in 0.1°C



Gültiger Wertebereich (ggf. mit negativem Vorzeichen):

-400 bis 850 (Dezimale Ganzzahl in 0.1°C)

31 0

Oberer Grenzwert Lichtstärke in Lux






32 700

Oberer Grenzwert rel. Luftfeuchtigkeit in 0.1%







Abbildung 20: Parametertabelle Time to Send bei Überschreitung oberer Grenzwerte



49 60

TtS Oberer Grenzwert Versorgungsspannung in Sekunden






50 60

TtS Oberer Grenzwert Analog1 in Sekunden






51 60







52 60







53 60







54 60

TtS Oberer Grenzwert Temperatur in Sekunden






55 60

TtS Oberer Grenzwert Lichtstärke in Sekunden






56 60

TtS Oberer Grenzwert rel. Luftfeuchtigkeit in Sekunden







1.3.2.7 Parametrierungsmöglichkeiten digitaler I/O (DIO)

Digitale I/O werden mit einer Abtastrate (Parameter-ID 4) auf Veränderungen zum vorherigen Status abgetastet. Bei Veränderungen wird dies als Trigger-Kriterium für einen Sendevorgang (mit TtS-Verzögerung) gewertet.

Digitale I/O besitzen jedoch noch weitere Parametriermöglichkeiten:

1.3.2.7.1.1. Logische Invertierung digitaler Eingänge

Abbildung 21: Parametrierung Logische Invertierung

Die logische Invertierung ermöglicht für jeden einzelnen digitalen Eingang eine Anpassung der Payload-Ausgabe an die Eingangsgröße. Ein High-Pegel am Eingang kann somit wahlweise als Logische 1 oder 0 in der Payload ausgegeben werden (oder umgekehrt). Der Parameterwert (Zahl) ergibt sich aus der Bitmaske von 2 Bytes (siehe Abbildung). Beispielbefehl: 58,b010111110000001 bedeutet logische Invertierung von D7 und D5.

1.3.2.7.1.2. Aktivierung/Deaktivierung digitaler I/O

Abbildung 22: Parametrierung Aktivierung/Deaktivierung digitaler I/O

Die Maske „Abschaltung I/O-Port“ ermöglicht die Ein- oder Abschaltung jedes einzelnen digitalen I/O. Abschaltung bedeutet, dass der digitale Eingang für den Trigger eines Sendevorgangs igno-riert wird. Der Parameterwert (Zahl) ergibt sich aus der Bitmaske von 2 Bytes (siehe Abbildung). Beispielbefehl: 58,b100111110000001 bedeutet Abschaltung von D7 und D6.

1.3.2.7.1.3. Funktionsfestlegung Eingang/Ausgang D1 – D4

Abbildung 23: Parametrierung der Funktion Eingang/Ausgang D1 bis D4

Die Maske „Definition I/O als Ausgang“ ermöglicht für die digitalen I/O D1 bis D4 die individuelle Festlegung der Funktion als Eingang oder Ausgang. Die als Ausgänge parametrierten Ports kön-nen über zwei – sich gegenseitig ausschließende - Wege angesteuert werden:

▪ Unmittelbare Ansteuerung über Grenzwerttrigger-Kriterien aus den analogen Eingängen (GWMap Parameter-ID 61 bis 64).

▪ Ansteuerung über LoRaWAN-Steuerbefehl.


58 0

DI Polarität (Logische Invertierung)

Bit an Dx = 0 bedeutet High-Pegel ist Logisch 1

Bit an Dx = 1 bedeutet High-Pegel ist Logisch 0


0 bis 511 (Bitmaske über 2 Byte)

D8 D7 D6 D5 D4 D3 D2 D1 0 0 0 0 0 0 0 D9


59 x1FF

DI Maske Abschaltung I/O-Port

Bit an Dx = 1 bedeutet Eingang wird abgefragt

Bit an Dx = 0 bedeutet Eingang wird ignoriert



D8 D7 D6 D5 D4 D3 D2 D1 0 0 0 0 0 0 0 D9


60 x0

DO Maske Definition I/O als Ausgang (D1 bis D4)

Bit = 1 bedeutet Ausgang

Bit = 0 bedeutet Eingang



0 0 0 0 D4 D3 D2 D1


Der Parameterwert (Zahl) ergibt sich aus der Bitmaske von einem Byte (siehe Abbildung – höchst-möglicher Zahlenwert ist dezimal 15 = D1 bis D4 als Ausgang geschaltet). Beispielbefehl: 60,b00000101 bedeutet D1 und D3 sind als Ausgang geschaltet.

1.3.2.7.1.4. TtS – Sendeverzögerung nach Zustandsänderungen an digitalem Eingang

Abbildung 24: Parametrierung Time to Send bei Änderung digitaler I/O

Hinweis: Das Setzen des jeweiligen „Time to Send (TtS)“-Parameterwertes legt die Verzögerungszeit von der Feststellung des Trigger-Kriteriums bis zum Sendevorgang fest. Die Verzögerung ist von 1 bis 65535 Sekunden einstellbar (entspricht max. 1092,25 Minuten oder 18,204 Stunden). Wird eine 0 (Null) gesetzt, erfolgt bei der Feststellung des Trigger-Kriteriums grundsätzlich kein Sen-devorgang. Die Verzögerungszeit wird für alle aktiven digitalen Eingänge gemeinsam festgelegt.

1.3.2.8 Einstellung der Sendeverzögerung nach Trigger (TtS)

Über die Zeiteinstellung in Sekunden des jeweiligen TtS-Parameters wird die Verzögerungszeit zwischen dem Zeitpunkt des Trigger-Ereignisses und dem LoRaWAN-Sendevorgang eingestellt.

Siehe Parameter-Tabellen:

▪ Abbildung 16: Parametertabelle Time to Send bei Delta-Abweichung

▪ Abbildung 18: Parametertabelle Time to Send bei Unterschreitung unterer Grenzwerte

▪ Abbildung 20: Parametertabelle Time to Send bei Überschreitung oberer Grenzwerte

▪ Abbildung 24: Parametrierung Time to Send bei Änderung digitaler I/O


57 15

TtS DI Änderung des Zustands an einem digitalen Eingang







1.3.2.9 Filter für schwankende analoge Werte setzen

Die Werte der analogen Eingänge 1 bis 4 und der internen Sensoren für Temperatur, Beleuch-tungsstärke, relative Luftfeuchtigkeit und Versorgungsspannung können – in Abhängigkeit vom Einsatzgebiet – ggf. stark schwanken (z.B. Wert eines Schwimmers in einem bewegten Wasser-tank). Diese schwankenden Werte können die gesetzten Trigger für Delta-Abweichungen oder obere/untere Grenzwerte temporär überschreiten. Das in solchen Fällen auch ein Sendevorgang ausgelöst wird, ist oftmals nicht gewünscht. Es ist daher möglich, die Eingangswerte zu bedämp-fen, damit sich schwankende Messwerte „beruhigen“ können, bevor eine Sendeentscheidung ge-troffen wird. Die Dämpfung ist als digitaler IIR-Filter (Infinite Impulse Response) realisiert, der wie ein analoger Tiefpass 1. Ordnung funktioniert. Über die Parametrierung kann – bei gesetzter ana-loger Abtastrate (siehe 1.3.2.2) – die Grenzfrequenz des Filters und somit die Dämpfungswirkung eingestellt werden.

Abbildung 25: Parametertabelle digitale Dämpfungsfilter

Die Berechnungsformeln zur Bestimmung des zu setzenden Parameterwertes können aus der Frequenzsicht oder aus der Zeitsicht betrachtet werden:

Formel Erläuterung

𝑎 = [1 − e (−𝑓0

𝑓𝑠)] ∗ 65536

a = Errechneter Parameterwert f0 = Grenzfrequenz des Filters in [Hz] fs = Eingestellte Abtastfrequenz/Abtastrate aus 1.3.2.2 in [Hz]

𝑎 = [1 − e (−𝑡𝑠

𝑡0)] ∗ 65536

a = Errechneter Parameterwert t0 = Dämpfungszeit des Filters in [s] ts = Eingestellte Abtastzeit/Abtastrate aus 1.3.2.2 in [s]

Abbildung 26: Berechnungsformeln digitale Filter


67 0

Filter Versorgungsspannung


0 = Keine Filterfunktion/Dämpfung

1 bis 65535 (1 = max. Dämpfung / 65535 min. Dämpfung)

68 18

Filter Analog1




69 18

Filter Analog2




70 18

Filter Analog3




71 18

Filter Analog4




72 1092

Filter Temperatur




73 1092

Filter Lichtstärke




74 1092

Filter rel. Luftfeuchtigkeit





Grundsätzlich bedeutet dies, dass bei festgelegter Abtastrate der analogen Eingänge / internen Sensoren eine größere Dämpfungszeit, bzw. eine kleinere Grenzfrequenz eine höhere Dämp-fungswirkung des Filters bewirken. Der Parameterwert 0 bewirkt eine Abschaltung des jeweiligen Filters. Hinweise:

▪ Immer die eingestellte Abtastrate in die Berechnung einbeziehen. ▪ Je kleiner der Parameterwert (minimal 1), desto größer wird die Dämpfungswirkung.

Als Hilfe eine exemplarische Berechnung verschiedener Parameterwerte bei einer gesetzten Ab-tastrate von 1s und 10s:

Dämpfungszeit Zu setzender Parameterwert (a)

Abtastrate 1s Abtastrate 10s

2 s 25786 65094

3 s 18577 63198

4 s 14497 60156

5 s 11880 56667

6 s 10061 53158

7 s 8724 49830

8 s 7701 46760

9 s 6892 43962

10 s 6237 41427

15 s 4227 31889

20 s 3196 25786

25 s 2570 21606

30 s 2149 18577

40 s 1618 14497

50 s 1298 11880

60 s 1083 10061

70 s 930 8724

80 s 814 7701

90 s 724 6892

100 s 624 6237

120 s 544 5240

180 s 363 3542

200 s 327 3196

220 s 297 2912

240 s 272 2675

300 s 218 2149

360 s 182 1795

500 s 131 1298

720 s 91 904

1000 s 66 652

2000 s 33 327

3600 s 18 182

10800 s 6 61

65535 s 1 10 Abbildung 27: Parameterbeispiele digitale Filter


1.3.2.10 Direkte Ansteuerungen digitaler Ausgänge über analoge Eingänge

Jeder als Ausgang geschaltete digitale I/O DO1 bis DO4 kann über die Trigger-Bewertung jedes einzelnen analogen Eingangs bei Unterschreitung des unteren Grenzwertes (AxuG) oder der Überschreitung des oberen Grenzwertes (AxoG) direkt angesteuert werden. Der Trigger kann individuell von jedem analogen Eingang auf jeden Ausgang gesetzt oder abgeschaltet werden.

Achtung: Wird auf einem Ausgang ein Grenzwerttrigger gesetzt, kann dieser Ausgang nicht über LoRaWAN-Steuerbefehle (siehe 0) geschaltet werden (gegenseitiger Ausschluss).

Abbildung 28: Parametrierung Ansteuerung digitale Ausgänge über analoge Eingänge

Diese Funktion ermöglicht dem IoT Multiboard autarke, zustandsabhängige Schaltaktionen, un-abhängig von einer LoRaWAN-Übertragung. Beispiel: An einem analogen Eingang wird ein externer Temperaturfühler angeschlossen. Bei Überschrei-tung eines oberen Temperatur-Grenzwertes wird über den zugeordneten digitalen Ausgang ein Klimagerät eingeschaltet (z.B. über ein externes Schaltrelais). Achtung: Wird für einen digitalen Ausgang mind. ein Grenzwerttrigger gesetzt, kann dieser nicht über LoRaWAN-Steuerbefehle angesteuert werden (gegenseitiger Ausschluss).


61 0

GWMap DO1

Bit = 1 bedeutet Trigger gesetzt

Bit = 0 bedeutet kein Trigger



Bit 7 Bit 0

A4oG A4uG A3oG A3uG A2oG A2uG A1oG A1uG

62 0

GWMap DO2





Bit 7 Bit 0


63 0

GWMap DO3





Bit 7 Bit 0


64 0

GWMap DO4





Bit 7 Bit 0



1.3.2.11 Direkte Ansteuerungen digitaler Ausgänge über LoRaWAN

Wird ein digitaler I/O als Ausgang geschaltet und zugleich für diesen Ausgang kein Grenzwertt-rigger (siehe 1.3.2.5 und 1.3.2.6) gesetzt, kann der Ausgang über einen LoRaWAN-Steuerbefehl aus der Ferne angesteuert werden. Die Eingabemöglichkeit des Steuerbefehls (sogenannter Downlink) kann je nach gewähltem LoRaWAN-Netz unterschiedlich sein. Im Beispiel wurde der Befehl über das TTN-Netz abgesetzt.

Hierbei sind die niederwertigsten 4 Bits vom 3. Byte der Payload relevant. Die Eingabe im LoRa-Netz erfolgt i.d.R. hexadezimal:

Abbildung 29: Hexadezimale LoRaWAN-Steuerbefehle für Ausgänge

Im folgenden Beispiel werden im TTN-Netz über die Eingabe von 00 00 0C (mit Drücken des Buttons Send abschließen) die Ausgänge D4 und D3 aktiviert. D2 und D1 werden deaktiviert.

Abbildung 30: Beispiel Ansteuerung 0C im TTN-LoRaWAN-Netz

Sollten in der Bitmaske des Steuerbefehls versehentlich auch Ports angesprochen werden, die als Eingänge parametriert sind, hat dies keine Auswirkungen. Es werden nur die Bits der als Ausgänge geschalteten Ports zur Steuerung verwendet.

D4 D3 D2 D1

00 00 00 0 0 0 0

00 00 01 0 0 0 1

00 00 02 0 0 1 0

00 00 03 0 0 1 1

00 00 04 0 1 0 0

00 00 05 0 1 0 1

00 00 06 0 1 1 0

00 00 07 0 1 1 1

00 00 08 1 0 0 0

00 00 09 1 0 0 1

00 00 0A 1 0 1 0

00 00 0B 1 0 1 1

00 00 0C 1 1 0 0

00 00 0D 1 1 0 1

00 00 0E 1 1 1 0

00 00 0F 1 1 1 1

0=Aus / 1=Aktiv

Zustand AusgangSteuerbefehl LoRaWAN

(untere 4 Bit hexadezimal)


Wichtig: Die Reaktionszeit der Ausgänge auf den jeweiligen Steuerbefehl hängt von der ausgewählten LoRaWAN-Device-Class des Multiboards ab (über LoRaWAN-Standard festgelegt):

▪ Class A: Der Steuerbefehl wird erst empfangen und umgesetzt, wenn das Multiboard selbst eine Sendung veranlasst. Nach jeder Sendung ist das Multiboard für eine kurze Zeit zum Empfang der Befehle aus dem Netz bereit. Hierdurch kann es zu einem zufalls-bedingten Zeitverzug zwischen Aussendung und Umsetzung des Steuerbefehls kommen. Dieser Zeitverzug kann ggf. durch geeignete Einstellungen des Keep-Alive-Intervalls (Pa-rameter-ID 65) in ein festes maximales Intervall gebracht werden. Hierbei ist jedoch darauf zu achten, dass die Sendehäufigkeit nicht unnötig erhöht wird.

▪ Class C: Das Multiboard ist permanent empfangsbereit und kann jederzeit Steuerbefehle empfangen und mit geringer Latenz umsetzen.

Ebenso muss das genutzte LoRaWAN-Netz die jeweilige Device-Class unterstützen.

1.3.2.12 Passwort und Parameterversion setzen

Die schreibenden Parametrierungskommandos können mit einem Passwort gegen Fehlbedie-nung oder Missbrauch geschützt werden. Mit der Parameter ID 97 lässt sich das voreingestellte Passwort (admin) auf ein individuelles Passwort aus 32 Zeichen ändern.

Nach jedem Neustart kann innerhalb von 10s über die Eingabe des Passwortes Zugang zum Admin-Modus erlangt werden. Nur im Admin-Modus ist es möglich, den f-Befehl (Abspeichern von Parametereintragungen) auszuführen.

ACHTUNG: Bitte bei der Eingabe des neuen Passwortes auf die gewünschte Schreibweise achten. Es erfol-gen keine weiteren Sicherheitsabfragen beim Setzen des neuen Passwortes.

Mit den Parameter ID 98 und 99 lassen sich ein Parameterzähler und eine Parameterversion setzen (siehe auch Payload-Struktur des IoT Multiboards). Der Parameterzähler ist eine eindeu-tige ID einer bestimmten Funktionsparametrierung (z.B. spezifische Einstellungen der Wasser-tanküberwachung Kunde xy) im Wertebereich 0 bis 255. Die Parameterversion nummeriert inner-halb des zugehörigen Parameterzählers die verschiedenen Versionen der Funktionsparametrie-rung durch (Wertebereich ebenfalls 0-255).

Hinweis: Zur Vermeidung der doppelten Verwendung einer Kombination aus Parameterzähler und Para-meterversion muss die Vergabe von Zähler- und Versionsnummern strikt zentral erfolgen.

Abbildung 31: Passwort und Parameterversion

1.3.3 Parametrierung über Parameterdateien

Als Alternative zur zeilenweisen Parametrierung gem. der o.g. Bedienungshinweise kann für ein Multiboard auch eine Konfigurationsdatei im txt- oder csv-Format mit allen erforderlichen Para-meterzeilen vorbereitet werden. Dies bietet sich an, wenn eine größere Anzahl von Multiboards mit identischen Parametern (LoRa-Parameter ausgenommen) konfiguriert werden soll. In der Pa-rameterdatei werden alle zu setzenden Parametersätze (Parameter-ID und Parameterwert durch


97 adminFestlegung des Passwortes mit 32 Zeichen

Voreinstellung: admin

98

Parameter-Zähler: Nummerierung verschiedener Varianten

innerhalb einer funktionalen Parameter-Version


0 bis 255 (Dezimale Ganzzahl)

99

Parameter-Version: Eindeutige ID einer bestimmten

Funktionsparametrierung


0 bis 255 (Dezimale Ganzzahl)


Komma getrennt) zeilenweise editiert. Der Wechsel von einem Parametersatz zum nächsten Pa-rametersatz erfolgt mit dem Enter-Befehl (CR). Es entsteht eine Datei mit folgendem Beispielaufbau (Teilausschnitt):

Somit müssen für die einzelnen Multiboards nur die Zeilen mit den LoRaWAN-Parametern „indi-vidualisiert“ werden. Die Parametrierung über die Parameterdatei erfolgt dann über ein geeigne-tes Terminalprogramm über die serielle Schnittstelle.

Im folgenden Beispiel wurde das Freeware-Programm AccessPort® verwendet:

Abbildung 32: Bildschirmansicht AccessPort®

http://www.sudt.com/en/ap/index.html


Nach dem Programmstart erscheint die o.a. Bedienoberfläche.

Abbildung 33: Ansicht der Bedienreihenfolge zur Dateiübertragung

Nacheinander die Schritte / Menüpunkte 1 bis 3 durchgehen:

Schritt 1: Einstellung des COM-Ports und der Übertragungsparameter (115200Baud/N/8/1).

Schritt 2: Mit den Schnittstellenparametern eine Verbindung zum Multiboard herstellen.

Schritt 3: Parameterdatei zur Übertragung auf das Multiboard auswählen.

Abbildung 34: Ansicht Transferfenster

Über den Button „Select File“ den Speicherort der Parameterdatei öffnen.

Abbildung 35: Ansicht Dateiauswahl für Transfer

Die gewünschte Parameterdatei auswählen und öffnen. Es erscheint das Transferfenster.

1 2 3


Abbildung 36: Ansicht Transferfenster vor dem Senden

Über den Button „Send“ den Start der Dateiübertragung auf das Multiboard starten. Die Übertra-gung erfolgt Zeilenweise und wird im Monitor dargestellt (siehe folgende Abbildung).

Abbildung 37: Ansicht Durchlauf Dateiübertragung

Nach erfolgter Übertragung (100%) mit dem Button „Complete“ den Übertragungsvorgang been-den.

Ggf. kann nun mit dem r-Befehl überprüft werden, ob die Parameterübertragung wie gewünscht erfolgt ist. Hinweis: Nur über die anschließende Eingabe des f-Befehls wird die Parametrierung dauerhaft abgespei-chert. Ohne f-Befehl geht die Parametrierung beim nächsten Neustart verloren.


1.4 Parsing der Payload in einem LoRaWAN-Netz

Das Parsing (Dekodierung) der übertragenen Payload kann auf folgendem Weg durchgeführt werden:

function Decoder(bytes, port) {

// Decode an uplink message from a buffer

// (array) of bytes to an object of fields.

if (port === 1) {

decoded = {

select : bytes[0] + bytes[1]*0x100,

digIn : bytes[2] + bytes[3]*0x100,

uBat : (bytes[4] + bytes[5]*0x100)/1000,

analog1: (bytes[6] + bytes[7]*0x100)/1000,




temp : (bytes[14] + bytes[15]*0x100)/10,

humi : (bytes[16] + bytes[17]*0x100)/10,

lux : (bytes[18] + bytes[19]*0x100),

time : (bytes[28] + bytes[29]*0x100),

digIn01: bytes[2] & 0x01,

digIn02: (bytes[2] & (1<<1)) >> 1,

digIn03: (bytes[2] & (1<<2)) >> 2,

digIn04: (bytes[2] & (1<<3)) >> 3,

digIn05: (bytes[2] & (1<<4)) >> 4,

digIn06: (bytes[2] & (1<<5)) >> 5,

digIn07: (bytes[2] & (1<<6)) >> 6,

digIn08: (bytes[2] & (1<<7)) >> 7,

digIn09: (bytes[3] & 0x01)

};

}

return decoded;

}

Der o.a. blaue Textblock kann beispielsweise im TTN-Netz in der Applikationsverwaltung (Pay-load Formats / Decoder) eingefügt werden und erlaubt dann bereits auf der Networkserver-Ebene die Dekodierung der Payload (siehe Abbildung 38: Beispiel-Parsing im TTN-Netz).


Abbildung 38: Beispiel-Parsing im TTN-Netz


1.5 Änderung oder Aktualisierung der Firmware

Die Firmware (FW) ist das zentrale Betriebssystem des IoT Multiboards. Eine Änderung oder Aktualisierung dieser Firmware kann erforderlich werden für folgende Punkte:

▪ Beseitigung von Fehlern oder Systemoptimierungen

▪ Ergänzung von Funktionen oder Leistungsmerkmalen

▪ Anpassung an neue Anforderungen

Zur Änderung oder Aktualisierung der Firmware werden folgende Komponenten zusätzlich benö-tigt:

▪ PC oder Notebook mit mind. 2 USB-Schnittstellen

▪ 1 USB-Kabel (USB Typ A-Stecker auf Micro USB Typ B-Stecker) zur Stromversorgung des Multiboards während der FW-Einspielung.

▪ 1 USB auf RS-422-Programmieradapter mit einem Anschlussstecker der Fa. Würth Electronic (WR-TBL Serie 3043C 4-polig). Der Stecker wird gem. folgendem Anschlussbild an den RS-422-Ausgang des Program-mieradapters angeschlossen (Montage siehe Gebrauchsanweisung):

Würth Elektronik WR-TBL Serie 3043C 4-polig

Artikelnummer 691304300004

Draufsicht

FrontseiteKlemme X1 – bis 8

RS-422-Adapter

USB

Txb

T+

Txa

T-

Rxb

R+

Rxa

R-

5 6 7 8

PC

Gemeinsame Masse über USB

Abbildung 39: Anschlussbild für RS422-Adapter

▪ Auf dem PC installierte Software „STM32CubeProgrammer (STM32CubeProg)“ der Fa. STMicroelectronics. Es gelten die Nutzungsbedingungen der Fa. STMicroelectronics. Hinweis: Die DB Kommunikationstechnik GmbH kann keine Gewährleistung für den Zu-gang und den Funktionsumfang dieser externen Software gewährleisten. Ebenso können sich die Ansichten und Funktionen der Benutzeroberfläche jederzeit verändern, ohne dass die DB Kommunikationstechnik GmbH hierauf Einfluss hätte.

▪ Die aktuelle FW-Version (Datei im .hex-Format), die einzuspielen ist.

https://www.st.com/en/development-tools/stm32cubeprog.html


1.5.1.1 Anschluss des Multiboards

Zur Durchführung einer FW-Änderung ist das Multiboard zunächst komplett freizuschalten (Ab-ziehen aller Stecker von den X-Anschlussklemmen). Anschließend wird das Multiboard über die Micro USB-Buchse mit einem geeigneten USB-Kabel an einen PC oder ein Notebook ange-schlossen. Die Stromversorgung des Multiboards erfolgt in dieser Situation über den USB-An-schluss. Zusätzlich wird der RS422-Programmieradapter ebenfalls an einen USB-Anschluss des PCs angeschlossen. Die RS-422-Seite des Adapters wird gem. Anschlussbild auf einen Würth-Stecker aufgelegt und in die obere Anschlussbuchse des X1-Anschlusses eingesteckt. Die erfor-derliche gemeinsame Masse der beiden Anschlüsse wird über die USB-Anschlüsse automatisch hergestellt. Siehe Anschlussbild:

USB-KabelUSB Typ A-Stecker auf

Micro USB Typ B-SteckerSpannungsversorgung und

gemeinsame Masse

PC / Notebook

IoT Multiboard(untere Anschlussseite)

Programmier-

adapter RS-422USB-Kabel (Typ A)

R+T+

Zusätzlicher Anschluss bei FW-Änderung/Aktualisierung

T- R-

AnschlussMicro USB(Konsole)

IoT Multiboard(obere Anschlussseite)

Abbildung 40: Anschlussbild FW-Änderung/Aktualisierung

Hinweis: Durch das Einstecken der beiden USB-Kabel werden üblicherweise im PC auch zwei COM-Ports generiert. Für die weitere Programmiertätigkeit muss darauf geachtet werden, dass nur der COM-Port des RS422-Programmieradapters im weiteren Verlauf genutzt wird.


1.5.1.2 Durchführung FW-Änderung/Aktualisierung

Zunächst werden die in Abbildung 40 erforderlichen Verbindungen zum IoT Multiboard herge-stellt. Die microUSB-Verbindung dient hierbei nur der Spannungsversorgung und Schaffung ei-ner gemeinsamen Masse.

Anschließend wird die SW STM32CubeProgrammer (STM32CubeProg) gestartet:

Abbildung 41: STM32CubeProgrammer im Modus Memory & File edition

Die SW startet im Modus „Memory & File edition“. Durch Klick auf das zweite Symbol (links oben) wird in den Modus „Erasing & Programming gewechselt“.

Abbildung 42: STM32CubeProgrammer im Modus Erasing & Programming

Zunächst die neue Firmware-Datei (Endung .hex) unter File path (Button Browse) auswählen und die Haken unter „Verify programming“ und „Run after programming“ setzen. Danach wird eine Verbindung mit dem Multiboard hergestellt (Button Connect). Hierzu wird das

1

2 4

3


Multiboard zunächst für einige Sekunden stromlos gemacht und wieder eingeschaltet (Abziehen der USB-Verbindung). Innerhalb der nächsten 30s ist der sogenannte Bootloader-Modus aktiv. In dieser Zeit verbindet man das Multiboard mit der SW gem. Abbildung 42 Schritt 3. Sollten beim ersten Verbindungsversuch Fehlermeldungen erscheinen, ist der Verbindungsaufbau zu wieder-holen (hierbei auch darauf achten, dass der korrekte COM-Port des RS422-Programmieradapters ausgewählt ist). Nach erfolgreichem Verbindungsaufbau erscheint rechts oben die Connected-Mitteilung.

Danach den Button „Start Programming“ drücken und die einzelnen Einblendungen der u.a. Mel-dungen abwarten und mit „OK“ bestätigen (Programmierdurchlauf kann bis zu 60s dauern).

Abbildung 43: STM32CubeProgrammer - Programming Meldung 1





Nach dem kompletten Durchlauf ist die Änderung der FW komplett. Ggf. ist das IoT Multiboard durch Abtrennen und Aufstecken der Verbindungen (Spannungsversorgung) neu zu starten.


1.6 CE-Konformitätserklärung

IoT Multiboard Parametrierungsanleitung€¦ · Das IoT Multiboard ist ein elektronisches Gerät,...

Documents

Transcript of IoT Multiboard Parametrierungsanleitung€¦ · Das IoT Multiboard ist ein elektronisches Gerät,...