Ja Servus zusammen, ein neues Thema: Ich muss zwei Arduinos kommunizieren lassen, ein einfacher Austausch von einer 10-stelligen Zahl in beide Richtungen ca. alle 10-20 Sekunden. Problem: Die beiden sind ca 50 -100 m auseinander und dazwischen ist eine Menge Beton und Stahl. (So 4 Stockwerke). Was ich habe ist eine 230V Stromleitung. Weitere Kabel kann ich nicht legen. Was ich schon - mit mäßigem Erfolg - probiert habe ist das KQ330 Modul. Das geht super in die eine, jedoch mit viel Datenverlust in die andere Richtung. Das Ganze soll auch nicht größer als so ein Modul sein, weil das in ein kleines Wandgehäuse untergebracht werden muss. Gibt es so bare-bone D-LAN adapter? Habt ihr schon einmal mit den Lo-Range Funk gearbeitet? Kann man damit durch 4 Stockwerke hindurch kommunizieren? Ansonsten bin ich etwas ratlos. VG Willythecat P.S. Ich kenne die Diskussionen über "Powerline KOmmunikation und die damit verbundenen THemen, Netzleitung, SIgnalverschmutzungen etc."
:
Bearbeitet durch User
Uwe S. schrieb: > Ansonsten bin ich etwas ratlos. Ich auch ..... wenn du mir "Lo-Range Funk" um die Ohren haust. Muss man das kennen? Uwe S. schrieb: > Habt ihr schon einmal mit den Lo-Range Funk gearbeitet?
Uwe S. schrieb: > Habt ihr schon einmal mit den Lo-Range Funk gearbeitet? Kann man damit > durch 4 Stockwerke hindurch kommunizieren? Du meinst LoRa? Ja, das kann funktionieren und ist genau für so etwas gedacht.
Es gibt Uart zu Netzwerk Module, die Uart Nachrichten über IP verschicken können, wenn Du das mit einem DLan Adapter verbindest müsste das funktionieren.
Sebastian R. schrieb: > Uwe S. schrieb: >> Habt ihr schon einmal mit den Lo-Range Funk gearbeitet? Kann man damit >> durch 4 Stockwerke hindurch kommunizieren? > > Du meinst LoRa? > Ja, das kann funktionieren und ist genau für so etwas gedacht. Ein Bekannter hat LoRa über 10 Stockwerke Stahlbeton im Einsatz, mit den 100mW Modulen auf 868MHz.
Uwe S. schrieb: > Kann man damit durch 4 Stockwerke hindurch kommunizieren? Warum brauchst du die "beste Lösung", wenn es nur darum geht, über 4 Stockwerke zu kommunizieren? Reicht es nicht, wenn die Verbindung zuverlässig genug funktioniert? 100% Zuverlässigkeit wirst du mit Funk nicht erreichen, aber die Fehlerrate lässt sich durch ein geeignetes Übertragungsprotokoll stark reduzieren.
Uwe S. schrieb: > alle 10-20 Sekunden. Mit LoRa könnte das schon durchaus gehen. Kann aber sein dass man die Datenrate ziemlich runter stellen muss (d.h. hohen Spreading Factor auswählen). Aufgrund der gesetzlichen Vorgaben zum Duty Cycle kann es dann schon sein dass die 10-20 Sekunden nicht einzuhalten sind, eventuell eher alle 1-2 Minuten. Muss man ausprobieren.
Wenn du das Kabel vom Stromnetz trennen kannst, dann bieten sich RS485 Transceiver an. Die kosten nur ein paar Cent und können direkt seriell übertragen. Wichtig ist, dass die Abschlusswiderstände ungefähr dem Wellenwiderstand des Kabels entsprechen. Wenn du uns erzählst welches Kabel das genau ist, oder ein Foto machst, kann bestimmt irgendwer hier die passenden Widerstände empfehlen. Ansonsten versuche 100 Ohm.
:
Bearbeitet durch User
Rainer W. schrieb: > Uwe S. schrieb: >> Kann man damit durch 4 Stockwerke hindurch kommunizieren? > > Warum brauchst du die "beste Lösung", wenn es nur darum geht, über 4 > Stockwerke zu kommunizieren? > > Reicht es nicht, wenn die Verbindung zuverlässig genug funktioniert? > > 100% Zuverlässigkeit wirst du mit Funk nicht erreichen, aber die > Fehlerrate lässt sich durch ein geeignetes Übertragungsprotokoll stark > reduzieren. Bitte keine Wortklauberei. 100% gibt es nie, das ist mir auch bewusst. Ich lebe ja heute schon mit ziemlichen Unsicherheiten. Mit einer Übertragung von einer 7-stelligen Zahl klappt das mit dem KQ330 zufriedenstellend,(zu 70%), aber bei 10 Stellen kommt nur noch jede 20.-30. Übertragung zustande. Besser ausgedrückt, welche Lösungen gibt es überhaupt für diese Problemstellung?
Uwe S. schrieb: > Mit einer Übertragung von einer 7-stelligen Zahl klappt das mit dem > KQ330 zufriedenstellend,(zu 70%), aber bei 10 Stellen kommt nur noch > jede 20.-30. Übertragung zustande. Viel besser wird das mit Funk auch nicht. Verwende eine Forward Error Correction, dann können auch leicht kaputte Datenpakete dekoriert werden. Z.B. Sende ein Parity Bit mit oder wiederhole die Nachricht einfach mehrfach. Prüfsumme mitschicken.
Also, das 230V Kabel wird benötigt, das kann ich nicht einfach trennen. Das ist also nicht die Lösung. Übertragung mit 9600 oder 4800 baud sind in Ordnung. Es soll nur alle 10 Sekunden die 10-stellige Zahl übertragen werden. Das mit dem LoRa werde ich mir mal genauer anschauen, wenn das über 10 Stockwerke ging. Gibt es hier Efahrungen mit dem KQ330 bzw KQ130? Vielleicht mache ich ja damit was falsch? Setup: Ein ESP32 mit Pegelwandler auf 5V -> / <- Mega. Mit einer direkten Verbindung über 9600 klappt das alles super. Klemme ich die KQ330 dazwischen, Sendet und empfängt der Mega nahezu perfekt, der ESP32 empfängt nur noch zu 5-10% korrekt, die Zahlen werden verschluckt und mit "Garbage" vermischt. Ich habe unterschiedliche KOmmiunikationsprotokolle (fürs Empfangen) verwendet. Von einem einfachen "Parse.Int" bis hin zu dem Beispiel "RecWithStartEndMarkers", also <1234567890> senden.
:
Bearbeitet durch User
Uwe S. schrieb: > Ich habe unterschiedliche KOmmiunikationsprotokolle (fürs Empfangen) > verwendet. Von einem einfachen "Parse.Int" bis hin zu dem Beispiel > "RecWithStartEndMarkers", also <1234567890> senden. ich bin ja sonst ein Freund von Human-Readable, Debug-Freundlichen Protokollen auf Seriellen Verbindungen... Aber hier: Mathe ist dein Freund. Ein wenig Reed-Solomon-Fehlerkorrektur drübergesprinkelt, und deine Ziffern kommen richtig an, auch wenn unterwegs ein Drittel der Bit kippt... Was für die Kommunikation mit den Voyager-Sonden reicht, sollte für deine paar Stockwerke gerade gut genug sein... https://de.wikipedia.org/wiki/Reed-Solomon-Code Beispiel für Arduino: https://github.com/simonyipeter/Arduino-FEC (Vorsicht, ist keine allzu schöne Implementierung. Und könnte am AVR von etwas "PROGMEM" etc profitieren. Gibt sicher auch andere..)
Uwe S. schrieb: > Mit einer Übertragung von einer 7-stelligen Zahl klappt das mit dem > KQ330 zufriedenstellend,(zu 70%), aber bei 10 Stellen kommt nur noch > jede 20.-30. Übertragung zustande. Du könntest die Bits besser nutzen. 10 Stellen dezimal sind 10 Zeichen, also 80 Bit. Es sind aber nur 35 Bit Information drin. Binär wären es nur 5 Zeichen. Wenn du 6 Zeichen überträgst wird es besser als mit deiner 7-stelligen Zahl und du hast 13 Bit frei für Niklas G. schrieb: > Verwende eine Forward Error Correction, dann können auch leicht kaputte > Datenpakete dekoriert werden.
Niklas G. schrieb: > Z.B. Sende ein Parity Bit mit oder wiederhole die Nachricht einfach > mehrfach. Prüfsumme mitschicken. Blindes Wiederholen ist die ineffektivste Art, die Daten sicherer zu übertragen. Es gibt genug Codes, die Mehrfachbitfehler erkennen und teilweise korrigieren können (Stichwort Hammingabstand der Codeworte, Blockcodes). Ein zusätzliches Parity Bit pro Zeichen erhöht den Hammingabstand auf 2, d.h. auch damit ist noch keine Fehlerkorrektur möglich. Uwe S. schrieb: > einfacher Austausch von einer 10-stelligen Zahl Wie überträgst du die? Bei ASCII-Übertragung wäre die Telegrammlänge gegenüber dem Informationsgehalt mehr als verdoppelt, ohne dass vernünftige Fehlerkorrektur möglich ist (minimaler Hammingabstand von 1 zwischen gültigen Codeworten), d.h. ASCII erhöht die Fehlerwahrscheinlichkeit, ohne dass alle Fehler sicherer erkannt werden.
:
Bearbeitet durch User
Uwe S. schrieb: > Mit einer Übertragung von einer 7-stelligen Zahl klappt das mit dem > KQ330 zufriedenstellend,(zu 70%), aber bei 10 Stellen kommt nur noch > jede 20.-30. Übertragung zustande. > Besser ausgedrückt, welche Lösungen gibt es überhaupt für diese > Problemstellung? Reed-Solomon wurde ja bereits genannt. Wenn es gerne auch ein besonders einfach zu implementierendes Protokoll sein soll, übertrage die Ziffern einzeln in einem 4/7 Hamming-Code. So simpel, kann man auch als Anfänger implementieren.
Ich wuerd powerline verwenden. Die Daten auf's Netz modulieren.
Purzel H. schrieb: > Ich wuerd powerline verwenden. Die Daten auf's Netz modulieren. Wäre auch mein Vorschlag. Und dann redundant, mehrfach senden. Die Bandbreite sollte ausreichen. Anderer Vorschlag: beim Ölbohren wird über die Wassersäule mittels Druckschwankungen kommuniziert. 10 Bit/sek sind möglich, Abstand mehrere Kilometer. Vielleicht gibt es im Haus ja eine Wasserleitung?
Purzel H. schrieb: > Ich wuerd powerline verwenden. KQ330 IST Powerline und überträgt aktuell offensichtlich nur mit immenser Fehlerrate. Uwe S. schrieb: > ... bei 10 Stellen kommt nur noch jede 20.-30. Übertragung zustande Peter schrieb: > Wäre auch mein Vorschlag. Und dann redundant, mehrfach senden. Unsinniger Ansatz - Codes für Fehlererkennung und -korrektur wurden bereits erfunden. Was soll überhaupt genau übertragen werden? Zeig doch mal Beispiele.
:
Bearbeitet durch User
Rainer W. schrieb: > KQ330 IST Powerline und überträgt aktuell offensichtlich mit immensen > Fehlerraten. Alle Übertragungsverfahren haben Fehlerraten, nur manche mehr und manche weniger. Aber damit kann man umgehen. LoRa verwendet eine Art Hamming Code und Prüfsummen. Das kann man beim KQ330 auch nutzen. Rainer W. schrieb: > Peter schrieb: >> Wäre auch mein Vorschlag. Und dann redundant, mehrfach senden. > > Unsinniger Ansatz - Codes für Fehlererkennung und -korrektur wurden > bereits erfunden. Mehrfach senden ist halt die einfachste Möglichkeit für Redundanz. Klar ist es ineffizient, aber da der aktuelle Ansatz ja auch schon technisch sehr schlicht ist (ASCII Übertragung), wäre das die nächstbeste Möglichkeit. Manche existierende Verfahren nutzen auch simple Mehrfachübertragung, z.B. SigFox. Uwe S. schrieb: > So 4 Stockwerke Ist es ein Bürogebäude? Wenn überall WLAN vorhanden ist könnte man auch einfach zwei ESP32 nehmen und per WLAN/Internet miteinander reden lassen.
Niklas G. schrieb: > Ist es ein Bürogebäude? Wenn überall WLAN vorhanden ist könnte man auch > einfach zwei ESP32 nehmen und per WLAN/Internet miteinander reden > lassen. Aber nur, wenn man es nutzen darf.
Niklas G. schrieb: > LoRa verwendet eine Art Hamming Code und Prüfsummen. Nein - LoRa ist ein Spread Spectrum Modulationsverfahren und definierten die Bitübertragung (physical layer im OSI Schichtenmodell). Das sagt überhaupt nichts über die höheren Schichten, also Art der übertragenen Daten und verwendete Datensicherungsmethoden und Protokolle aus. Semtech AN1200.22 LoRa™ Modulation https://web.archive.org/web/20190718200516/https://www.semtech.com/uploads/documents/an1200.22.pdf Das kann man beim KQ330 auch nutzen. Schrieb ich doch oben. Die Art der Datensicherung ist unabhängig vom Übertragungsmedium (andere Schicht), reine ASCII Übertragen ist denkbar ungeeignet, wenn der Übertragungsweg nennenswert gestört ist.
:
Bearbeitet durch User
Rainer W. schrieb: > . Das sagt überhaupt nichts über die höheren Schichten, also Art der > übertragenen Daten und verwendete Datensicherungsmethoden und Protokolle > aus Der modifizierte Hamming-Code ist Teil des LoRa-Patents. Er wird über die Coding Rate konfiguriert. Alle LoRa-Transceiver unterstützen diesen Code. Man kann ihn nur abschalten indem man CR=4/4 einstellt.
In gewisser Weise benötigst Du so was wie WSPR über die Stromleitung. Uwe S. schrieb: > Das geht super in die eine, jedoch mit viel Datenverlust in die andere > Richtung. D.h. der Empfänger, der zu wenig empfängt sitzt in einem Bereich mit vielen Störungen durch Schaltnetzteile im Teilnetz des Stockwerkes.
Niklas G. schrieb: > Alle LoRa-Transceiver unterstützen diesen Code. Man kann ihn nur > abschalten indem man CR=4/4 einstellt. Klar, das setzt aber schon auf der LoRa Modulationsart auf. Und da LoRa explizit für gestörte Übertragungswege entwickelt wurde, ist natürlich klar, dass im Patent auch gleich Sicherungsmethoden mit abgedeckt werden. Ein LoRa-Transceiver ohne Implementation einer Sicherungsschicht macht wenig Sinn, wenn man den Kram nicht immer wieder in der Applikation einbauen will. Sinn so eines Transceivermoduls ist doch gerade, dass man es als Black Box in einer Anwendung verwenden kann, ohne sich um solche Details zu kümmern. Das ändert aber nichts daran, dass LoRa die Modulationsart bezeichnet. Niklas G. schrieb: > Mehrfach senden ist halt die einfachste Möglichkeit für Redundanz. Klar > ist es ineffizient, aber da der aktuelle Ansatz ja auch schon technisch > sehr schlicht ist (ASCII Übertragung), wäre das die nächstbeste > Möglichkeit. Nicht die "nächstbeste", sondern die "nächstprimitivste". Wie oft willst du denn ein Datenpaket senden, dass mit nur 3..5% Wahrscheinlichkeit heil übertragen wird, damit du sicher sein kannst, dass es richtig beim Empfänger ankommt und der Empfänger auch diagnostizieren kann, dass er das Paket richtig empfangen hat?
:
Bearbeitet durch User
Uwe S. schrieb: > Was ich habe ist eine 230V Stromleitung. > Weitere Kabel kann ich nicht legen. > > Was ich schon - mit mäßigem Erfolg - probiert habe ist das KQ330 Modul. Ist as eine Stichleitung ohne weitere Abzweigungen? Wenn die meisten Störungen über die Einspeisung oder die angeschlossenen Verbraucher kommen, dann helfen vielleicht Filter, die die Leitung von Störungen im Frequenzbereich des KQ330 (120-135kHz) freihält.
Das Ganze betrifft eine Installation in südlichen Ländern und hier in typischen Wohnkomplexen. Also 10- 50 Wohneinheiten mit Kalt und Warmwassertanks auf dem Dach. Für eine Dusche ist der Wasserdruck dann eher schwach, weil nur Gravitation. Was gerne eingesetzt wird ist eine Druckerhöhungspumpe. Es existiert jedoch meist nur eine Leitung von den Wohnungen zu den Warmwassertanks zwecks elektrischer Zuheizung in den kälteren Jahreszeiten. Diese gilt es zu nutzen wenn Powerline eingesetzt werden soll. Mit einem Paar geht das auch zufriedenstellend, problematischer wird es wenn mehrere Einheiten diese Powerline Adapter nutzen. Der KQ330 soll eine Reichweite von 1,6 km haben und das funktioniert auch über die Stromzählergrenzen hinaus. Darum jetzt die 10 stellige Zahl, wovon 3 Stellen einen eindeutigen Code für das jeweilige Paar bilden. Dann werden 3 Stellen für Status-Meldungen und Fehlercodes verwendet. Und zum Schluss die Außen und Warmwassertemperatur mit jeweils 2 stellen
:
Bearbeitet durch User
Uwe S. schrieb: > wenn mehrere Einheiten diese Powerline Adapter nutzen Es sind also viele Paare? Dann würde ich vielleicht doch darüber nachdenken ein zentrales LoRaWAN-Gateway aufzustellen, einzelne Knoten an die Tanks anbringen und den Leuten eine App zur Verfügung zu stellen. Dann kann man es per Smartphone bedienen und braucht kein eigenes Gerät am anderen Ende. Und man kann später viele weitere Dinge hinzufügen und vernetzen.
Niklas G. schrieb: > Dann kann man es per Smartphone bedienen und braucht kein eigenes Gerät > am anderen Ende. Und man kann später viele weitere Dinge hinzufügen und > vernetzen. Mitm Smartphone unter die Dusche? Naja... Man könnte auch einen Sensor mit einem LoRa-Client ausrüsten, der sich bei Wasserabnahme beim Host meldet, dass er die Pumpe anschmeißen soll. IoT lässt grüßen. Für sowas ähnliches verwendet man in Deutschland Zirkulationsleitungen.
Uwe S. schrieb: > Darum jetzt die 10 stellige Zahl, wovon 3 > Stellen einen eindeutigen Code für das jeweilige Paar bilden. Da würde ich als allererstes ganz dringend über die Kodierung nachdenken. Wenn du wirklich 10 stellige Zahlen direkt mit 8/N/1 als ASCII überträgst, reicht schon ein einziges fehlerhaftes Bit, um z.B. bei einer Außentemperatur von 30°C am Empfänger einen Wert von 10°C ankommen zu lassen, ohne dass dies als fehlerhaft erkannt werden kann.
Rainer W. schrieb: > Da würde ich als allererstes ganz dringend über die Kodierung > nachdenken. Wenn du wirklich 10 stellige Zahlen direkt mit 8/N/1 als > ASCII überträgst, reicht schon ein einziges fehlerhaftes Bit, um z.B. > bei einer Außentemperatur von 30°C am Empfänger einen Wert von 10°C > ankommen zu lassen, ohne dass dies als fehlerhaft erkannt werden kann. Die einfachste Fehlererkennung doch wäre eine XOR-Prüfsumme (NMEA-0183 benutzt sowas). Je "wichtiger" die Übertragenen Daten sind, umso größer müsste man den Aufwand treiben.
Rahul D. schrieb: > Rainer W. schrieb: >> Da würde ich als allererstes ganz dringend über die Kodierung >> nachdenken. Wenn du wirklich 10 stellige Zahlen direkt mit 8/N/1 als >> ASCII überträgst, reicht schon ein einziges fehlerhaftes Bit, um z.B. >> bei einer Außentemperatur von 30°C am Empfänger einen Wert von 10°C >> ankommen zu lassen, ohne dass dies als fehlerhaft erkannt werden kann. > > Die einfachste Fehlererkennung doch wäre eine XOR-Prüfsumme (NMEA-0183 > benutzt sowas). > Je "wichtiger" die Übertragenen Daten sind, umso größer müsste man den > Aufwand treiben. Wenn ich doch schon in vornherein WEISS das die Übertragung störanfällig ist, dann muss ich Vorsorge für Korrektur tragen, nicht nur für Erkennung. Also (7,4)Hamming oder (8,4)Extended Hamming. Und zwar interlaced. Das schafft sogar ein kleiner 8bit Controller nahezu ohne Aufwand. Und es korrigiert vorzüglich mehrere Bitfehler wenn vernünftig implementiert. Im Falle von (7,4)Hamming würde man 14 Bytes (zwei 7 Byte Blöcke) übertragen und könnte vierzehn Ziffern [0…F] übermitteln. Erlaubt und korrigierbar wären pro Block ein dicker Burst Error (oder mehrere verteilte Bitfehler)
Uwe S. schrieb: > Darum jetzt die 10 stellige Zahl, wovon 3 > Stellen einen eindeutigen Code für das jeweilige Paar bilden. Dann > werden 3 Stellen für Status-Meldungen und Fehlercodes verwendet. Und zum > Schluss die Außen und Warmwassertemperatur mit jeweils 2 stellen Wozu soll dieser komplette Datensatz bei einem trägen System wie einem Wasserspeicher alle 10-20 s übertragen werden? Die Information über Wasserentnahme kann ein Durchflusssensor innerhalb von Bruchteilen einer Sekunde schneller liefern, ohne dass man Befehle zum Starten einer Pumpe senden muss.
Rainer W. schrieb: > Wozu soll dieser komplette Datensatz bei einem trägen System wie einem > Wasserspeicher alle 10-20 s übertragen werden? > Die Information über Wasserentnahme kann ein Durchflusssensor innerhalb > von Bruchteilen einer Sekunde schneller liefern, ohne dass man Befehle > zum Starten einer Pumpe senden muss. Darum geht es nicht, sonder ich möchte feststellen, wie lange eine Pumpe läuft. Und wenn die länger als 20 min läuft, dann icht höchstwahrscheinlich eine Leitung abgefazt (doe bereits geschehen, und das Nacht über wurde das Dach geflutet....). Wenn also länger als 20 min, dann soll die Pumpe abgeschaltet werden und unten in der Wohnung eine Warnung kommen. Das klappt auch super.
So aber ich habe jetzt noch mit KQ330 weiter experimentiert. Die 10 stellige Zahl wird in ca. 2 Sekunden übertragen. Das ist die Reaktion, wenn ich beide Arduinos über KQ330 verbinde und einfach mal wechselseitig Infos schicke. Dads klappt jetzt, weil ich bei einem Arduino ein Timeout gesetzt habe. Also ich schicke alle 15 Sekunden eine Nachricht von oben nach unten und umgekehrt. Wenn ich innhalb von 46 Sekunden keine nachrichten mehr bekomme, dann gehe ich von einer Kollision aus und verschiebe mittels timeout und einem Shift Faktor von 3 Sekunden das senden. Damit habe ich quasi eine Kollisionserkennung und einen Sendeversatz geschaffen, der groß genug ist, damit ich problemlos weiter arbeiten kann. Gestern sind auch 2x LoRa Module gekommen, die nehme ich mir dann später vor.
Sinnvollerweise implementiert man ein Master-Slave-Protokoll. Bedeutet der Slave quittiert jedes Packet, oder sendet sogar Daten als Antwort. Bedeutet, der Master repetiert bis eine Antwort kommt.
Purzel H. schrieb: > Sinnvollerweise implementiert man ein Master-Slave-Protokoll. Das schöne an LoRaWAN ist dass das alles schon fertig ist, auch so dass es mit dem Shared Medium funktioniert. Man ruft nur noch ein API auf mit den gewünschten Nutzdaten, und es kommt dann (früher oder später) auf dem Server an und kann z.B. per MQTT weiterverarbeitet werden.
> Das schöne an LoRaWAN ist dass das alles schon fertig ist, auch so dass > es mit dem Shared Medium funktioniert. Man ruft nur noch ein API auf mit Das Problem ist bei sowas nur das die vielleicht in 3-5Jahren mal die API aendern und dann dein Geraet zurueckweisen weil es nicht mehr auf dem neuesten Stand ist und dir sagen, aber du haettest doch Firmwareupdate machen muessen! Man kann aber auch einfach nur Lora machen und sein eigenes Netz aufbauen. Das funktioniert auch sehr gut. Ich hab das mal ausgetestet. Selbst mit falschen Antennen, hatte nur 2.4Ghz anstatt 8xxMhz Stoepsel da, hat das mit nur 0dBm Sendeleistung auf meinem Grundstueck ueberall problemlos funktioniert, selbst aus dem Keller raus durch drei Waende. Das ist wesentlich besser als Wlan! Vanye
Vanye R. schrieb: > Das ist wesentlich besser als Wlan! Das kommt drauf an, ob du die Qualität anhand der Datenrate oder der Reichweite misst.
:
Bearbeitet durch User
HC-12 sollte doch mit großer Antenne kein Problem sein, hmm
Vanye R. schrieb: >> Das schöne an LoRaWAN ist dass das alles schon fertig ist, auch so dass >> es mit dem Shared Medium funktioniert. Man ruft nur noch ein API auf mit > > Das Problem ist bei sowas nur das die vielleicht in 3-5Jahren mal > die API aendern und dann dein Geraet zurueckweisen weil es nicht mehr > auf dem neuesten Stand ist und dir sagen, aber du haettest doch > Firmwareupdate machen muessen! Jetzt geht das schon wieder los. Nein, das stimmt nicht. LoRaWAN ist ein Netzwerkprotokoll, das auf LoRa als Übertragungsschicht aufsetzt. Geräte, die das LoRaWAN-Protokoll korrekt implementieren, dürften auch auf lange Zeit zuverlässig laufen, mir wäre nicht bekannt, dass alte Protokollversionen nicht mehr unterstützt werden würden. Wenn man die Infrastruktur von einem Netzbetreiber betreiben lässt, muss man sich natürlich auf dessen Vorgaben einlassen, man kann die aber auch bequem selbst betreiben. > Man kann aber auch einfach nur Lora machen und sein eigenes Netz > aufbauen. Das funktioniert auch sehr gut. Ich hab das mal ausgetestet. > Selbst mit falschen Antennen, hatte nur 2.4Ghz anstatt 8xxMhz Stoepsel > da, > hat das mit nur 0dBm Sendeleistung auf meinem Grundstueck ueberall > problemlos funktioniert, selbst aus dem Keller raus durch drei Waende. > Das ist wesentlich besser als Wlan! Der Trick daran, ein fertiges Netzwerkprotokoll zu verwenden, ist doch einfach, dass alles bereits fertig ist. Man nutzt die entsprechenden Libraries im Device-Code, setzt den Zugangsknoten auf und dann funktioniert alles einfach. Keine zusätzlichen Codierungs-Überlegungen, keine zusätzlichen Absicherungs-Überlegungen, keine zusätzlichen Adressierungs-Überlegungen, keine zusätzlichen Device-Registry-Überlegungen, bei LoRaWAN hat sich dazu und zu viel mehr jemand schon sinnvolle Gedanken gemacht. Ob man da jetzt TTN nimmt, einen kommerzielleren Netzbetreiber (der einen aber wahrscheinlich mit dem gebastelten Device gar nicht reinlässt), oder das selber aufzieht (z.B. mit Chirpstack), ist hauptsächlich eine Frage der Ansprüche und des Zeitaufwands.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.