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."
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.
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.
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?
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.
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...
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
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.
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.
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.
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?
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.
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.
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.
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.
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.
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?
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
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.
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.
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.
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.
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)
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.
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.
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!
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.
