TOP
SSV Software Systems Registrieren  Registrieren
Einloggen, um private Nachrichten zu lesen  Einloggen, um private Nachrichten zu lesen
Startseite FAQ Suchen Mitglieder Profil  Login 
SSV Support-Forum
NB-IoT …

 
Neues Thema eröffnen   Neue Antwort erstellen    SSV-Forum Foren-Übersicht >>> RMG/941
<<< Vorheriges Thema - Nächstes Thema >>>  
Beiträge der letzten Zeit anzeigen:   
Autor Nachricht
kdw



Anmeldedatum: 05.05.2006
Beiträge: 1287

BeitragVerfasst am: 04.03.2020, 18:20    Titel: NB-IoT … Antworten mit Zitat

Hallo Forum.

Das RMG/941 wird in der Variante „RMG/941N“ mit einem internen NB-IoT-Modem ausgeliefert. Auch eine 1NCE-SIM-Karte ist vorinstalliert, so dass der Anwender ohne weitere Kosten die nächsten 10 Jahre insgesamt 500 MByte Daten übertragen kann, ohne dass irgendwelche Mobilfunkkosten entstehen.

NB-IoT ist keine rein deutsche Angelegenheit, sondern ein offizieller Standard, der weltweit gültig ist. Insofern ist ein RMG/941N auch in vielen anderen Ländern nutzbar. Auf der Website der GSMA findet man einen Überblick zum weltweiten Ausbau der NB-IoT-Netze:



Quelle: https://www.gsma.com/iot/deployment-map/#deployments

VG KDW
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
kdw



Anmeldedatum: 05.05.2006
Beiträge: 1287

BeitragVerfasst am: 18.03.2020, 18:52    Titel: NB-IoT-Netzverfügbarkeit … Antworten mit Zitat

Hallo Forum.

Bzgl. des T-Mobil-Netzes kann man über eine interaktive Karte im Internet für einen beliebigen Standort in Deutschland die NB-IoT-Verfügbarkeit prüfen:

Siehe https://t-map.telekom.de/TMAP4/jsp/nbiot.jsp

Durch die vorinstallierte 1NCE-SIM-Karte bucht sich ein RMG/941N innerhalb Deutschlands in das T-Mobil-Netz ein.

VG KDW
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
kdw



Anmeldedatum: 05.05.2006
Beiträge: 1287

BeitragVerfasst am: 19.03.2020, 07:22    Titel: GPRS Fallback ... Antworten mit Zitat

Hallo Forum.

Sollte an einem bestimmten Standort kein NB-IoT-Netz verfügbar sein, bucht sich ein RMG/941 mit 1NCE-SIM-Karte automatisch in das T-Mobil-GPRS-Net ein.



Das jeweils benutze Netz ist in der Web-basierten Benutzerschnittstelle (SSV/WebUI) unter dem Menüpunkt Network => Mobil sichtbar - siehe erste Abbildung.

Die hier folgende Abbildung zeigt die typische GPRS Latency eines RMG/941N für einen einfachen ping im T-Mobile-Netz mit 1NCE-SIM-Karte.



VG KDW
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
kdw



Anmeldedatum: 05.05.2006
Beiträge: 1287

BeitragVerfasst am: 24.03.2020, 15:26    Titel: NB-IoT Latency ... Antworten mit Zitat

Hallo Forum.

Sehr viel ungünstiger sieht es mit der NB-IoT Latency aus (siehe die Zeiten für den ping in der hier folgenden Abbildung).



VG KDW
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
kdw



Anmeldedatum: 05.05.2006
Beiträge: 1287

BeitragVerfasst am: 25.03.2020, 07:17    Titel: MQTT per NB-IoT ... Antworten mit Zitat

Hallo Forum.

Auch MQTT-Verbindungen sind mit einem RMG/941N möglich. Zum Ausprobieren reicht der einfache Node-RED-Flow aus der folgenden Abbildung und die Verbindung zu einem frei zugänglichen Test-Broker im Internet:



Code:
MQTT-Konfiguration für den my_test Node:

Broker: mqtt.eclipse.org
Port..: 1883
Topic.: my_test


Durch die relativ geringe NB-IoT Latency ist die Publish-Subscribe-Verzögerung der MQTT-Nachricht deutlich wahrnehmbar. Nach dem Publish-Trigger durch das Betätigen der Schaltfläche des Inject Node dauert es schon etwas, bevor die Nachricht im Node-RED-Debug-Fenster angezeigt wird.

VG KDW
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
kdw



Anmeldedatum: 05.05.2006
Beiträge: 1287

BeitragVerfasst am: 26.03.2020, 07:32    Titel: Ungünstiger Standort … Antworten mit Zitat

Hallo Forum.

Meine NB-IoT-Tests mit einem RMG/941N und der 1NCE-SIM-Karte laufen besser, als ich erwartet hatte. Ich habe inzwischen einen ersten Verbindungstest an einem relativ ungünstigen Standort durchgeführt (kleines Dorf am Stadtrand von Hannover, Kellerraum eines 1-Familienhaus mit solidem Mauerwerk, kleine Magnetfußantenne einfach auf den Fußboden gestellt).

Die Verbindungsqualität ist von der Tageszeit abhängig. Morgens zwischen 07:00 und 08:00 Uhr hatte ich 2 ASU, -109 dBm (6%). Ein Ping-Test liefert 11% Paketverlust. Der MQTT-Test funktioniert aber problemlos. Abends zwischen 22:00 und 23:00 Uhr waren es nur noch 1 ASU, -111 dBm (3%), siehe folgende Abbildung.



Der Ping-Test mit dieser suboptimalen Verbindung ergab 46% Paketverlust (siehe folgende Abbildung). Aber der MQTT-Test funktioniert immer noch. Man kann also nach wie vor kleine Datenmengen an einen Server im Internet senden.



Bei 46% Paketverlust und dem Einsatz von TCP (MQTT nutzt TCP) muss man allerdings die Auswirkungen auf den Verbrauch des NB-IoT-Datenvolumens der 1NCE-SM-Karte bedenken. Würde man NB-IoT in einem Batterie-betriebenen Sensor nutzen, hätte der ungünstige Paketverlust-Prozentsatz auch noch erhebliche Auswirkungen auf die Batterielebensdauer.

VG KDW
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
kdw



Anmeldedatum: 05.05.2006
Beiträge: 1287

BeitragVerfasst am: 29.03.2020, 18:40    Titel: MQTT Byte Count … Antworten mit Zitat

Hallo Forum.

Für die Nutzung einer NB-IoT-Verbindung mit geringer Bandbreite und begrenztem Datenvolumen ist es schon recht hilfreich, wenn man ein möglichst präzises Fingerspitzengefühl dafür entwickelt, mit welchem Datenvolumen in Abhängigkeit von Transport- und Applikationsprotokoll sowie Byte-Anzahl der Nutzdaten (Payload) man es genau zu tun hat. Deshalb hier ein Beispiel für einen MQTT-Publish.

MQTT benutzt bekanntlich TCP als Transportprotokoll. Der Protokoll-Overhead von TCP ist schon recht hoch, aber dafür liefert das Protokoll eine Zustellgarantie für den Payload.

Das folgende Szenario zeigt die Details für einen MQTT-Publish der Nutzdaten „1585481311411“ (ASCII-String mit 13 Bytes). Als Ausgangssituation sind für die „ppp0“-Schnittstelle eines RMG/941N folgende Werte vorgegeben (ppp0 ist die NB-IoT-Schnittstelle eines RMG/941N innerhalb des Linux-Betriebssystems): RX = 1.883 Bytes / TX = 10.332 Bytes vor der MQTT-Datenübertragung (aktive Verbindung zum MQTT-Broker war vorhanden).



Es werden insgesamt 13 Bytes Nutzdaten übertragen. Ein Node-RED-Timestamp als Zeichenfolge, zum Beispiel „1585481311411“.



Durch den MQTT-Publish wird ein Paket (siehe TX packets) mit 76 Bytes gesendet und ein Paket (siehe RX packets) mit insgesamt 40 Bytes empfangen. Die 76 + 40 = 116 Bytes zeigen, dass wir es mit einem Protokoll-Overhead von insgesamt 103 Bytes zu tun haben, um 13 Bytes Nutzdaten „1585481311411“ zu übertragen.



VG KDW
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
kdw



Anmeldedatum: 05.05.2006
Beiträge: 1287

BeitragVerfasst am: 08.04.2020, 13:26    Titel: MQTT Keep Alive … Antworten mit Zitat

Hallo Forum.

Zwischen einem MQTT-Broker als Server und einem MQTT-Client wird eine TCP-Verbindung benutzt. TCP-Verbindungen müssen zunächst vom Client ausgehend aufgebaut werden, bevor eine Datenübertragung vom Client zum Server oder in umgekehrter Richtung möglich ist. Eine aktive TCP- und somit auch eine MQTT-Verbindung kann jederzeit sowohl vom Client als auch vom Server wieder beendet werden.

Soll zum Beispiel ein RMG/941N per MQTT-Publish jederzeit eine Nachricht empfangen können, muss das betreffende System eine dauerhaft aktive MQTT- bzw. TCP-Verbindung zum jeweiligen Broker aufrechthalten. Zur Steuerung des Zeitverhaltens ist das MQTT Keep Alive Timeout vorgesehen. Gemäß MQTT-Protokoll kann der Client nach Ablauf des Timeouts einen Ping-Request (PINGREQ Message) an den Broker senden, den dieser mit einer Ping-Response (PINGRESP Message) beantwortet und damit angezeigt bekommt, dass die Verbindung weiterhin bestehen soll. Auf diese Art und Weise lässt sich eine MQTT-Verbindung praktisch dauerhaft aufrechterhalten. Die folgende Abbildung zeigt die MQTT-Keep-Alive-Timeout-Einstellung unter Node-RED für ein RMG/941N (Broker: mqtt.eclipse.org):



Bei dem Eclipse.org-Broker lässt sich mit dieser Einstellung (210 Sekunden) eine dauerhafte Verbindung erzeugen. Auch kleinere Werte sind selbstverständlich möglich. Man muss allerdings berücksichtigen, dass durch die jeweilige Keep-Alive-Timeout-Einstellung auch mehr Daten für den Austausch der PINGREQ- und PINGRESP-Message je Verbindungsstunde verursacht werden. Die folgende Übersicht zeigt einige Beispiele zur Keep-Alive-Timeout-Einstellung und die dazu passenden Messwerte bzgl. der Datenübertragung zum Aufrechthalten der dauerhaften Verbindung:

Code:
MQTT Keep Alive Timeout = 120 Sekunden: ca. 8.325 Bytes je Stunde
MQTT Keep Alive Timeout = 180 Sekunden: ca. 4.318 Bytes je Stunde
MQTT Keep Alive Timeout = 210 Sekunden: ca. 4.594 Bytes je Stunde


Welche Einstellung mit welchem Broker jeweils am besten funktioniert, muss für jedes Projekt sorgfältig ermittelt werden. Ohne eine optimierte Keep-Alive-Timeout-Einstellung wird die Verbindung immer wieder beendet und dann von Client sofort neu aufgebaut, um die Empfangsbereitschaft für den MQTT-Publish zu gewährleisten. Durch den Verbindungsabbau und Wiederaufbau fallen ebenfalls unnötige Datenmengen an. Diese können die durch den Keep Alive verursachte Datenmenge überschreiten.

VG KDW
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Beiträge der letzten Zeit anzeigen:   
Neues Thema eröffnen   Neue Antwort erstellen    SSV-Forum Foren-Übersicht >>> RMG/941 Alle Zeiten sind GMT + 1 Stunde
Seite 1 von 1

 
Gehe zu:  
Sie können keine Beiträge in dieses Forum schreiben.
Sie können auf Beiträge in diesem Forum nicht antworten.
Sie können Ihre Beiträge in diesem Forum nicht bearbeiten.
Sie können Ihre Beiträge in diesem Forum nicht löschen.
Sie können an Umfragen in diesem Forum nicht teilnehmen.

SSV Software Systems GmbH

Dünenweg 5
30419 Hannover

Fon: +49(0)511 / 40 000-0
Fax: +49(0)511 / 40 000-40

sales@ssv-embedded.de

 

Impressum    ·    Datenschutz    ·    AGB

© 2018 SSV Software Systems GmbH. Alle Rechte vorbehalten.

ISO 9001:2015