starte gerade die ersten Gehversuche mit der rc library und hätte da mal eine grundsätzliche Frage:
Wenn ich viele Befehle "gleichzeitig" senden möchte, muss ich mir dann..
a) eine eigene Routine programmieren, die die zu sendenden Befehle mit sinnvollen Abständen nacheinender der RC Bibliothek "übergibt", damit es nicht zu Datenstau und/oder Fehlübertragungen kommt?
b) bzgl. der unter a) beschriebenen Problematik keine Gedanken machen, da die Bibliothek, die an sie übergebenen Befehle automatisch in der Reihenfolge und in sinnvollen Abständen zueinander ausgibt, in der sie mit ihnen gefüttert wurde?
Gruß Chris
PS: Mit "gleichzeitig" meine ich z.B., dass sich fünf Funksteckdosen mit einem "Knopfdruck" so gleichzeitig wie technisch mit der rc library möglich ausschalten, während ich parallel andere Funksteckdosen wahlweise ein- und ausschalten kann, ohne dass Befehle verschluckt werden.
Die RCSwitch-Library macht da nichts für dich. Die baut nur das Protokoll auf, die Versendung der einzelnen Schaltbefehle musst du selbst in die richtige Reihenfolge bringen.
Das bedeutet für dich die einzelnen Schaltbefehle, egal ob ein oder ausschalten, nacheinander abarbeiten.
Naja, es ist noch zu überlegen, was "gleichzeitig" tatsächlich bedeuten muss.
Oder anders: was passiert, wenn "gleichzeitig" eine Verzögerung von z.B. 1 ms bedeutet?
Klaus_ww:
Naja, es ist noch zu überlegen, was "gleichzeitig" tatsächlich bedeuten muss.
Oder anders: was passiert, wenn "gleichzeitig" eine Verzögerung von z.B. 1 ms bedeutet?
Das ist ehr weniger das Problem, sondern vielmehr die Tatsache das ich befürchte, dass ich während dem senden von mehreren Befehlen nicht "gleichzeitig" zuverlässig das senden eines weiteren Befehls einleiten kann, ohne mir hierfür ein Fifo-Konstrukt aufbauen zu müssen, wenn ich sichergehen will, dass immer alle Befehle zuverlässig abgearbeitet werden.
Whandall:
Das Senden erfolgt synchron/blockierend, während des Sendens gibt es 'gleichzeitig' höchstens etwas das im IRQ Kontext läuft.
Meinst Du damit, dass während dem Senden eines Befehls mein kompletter Code wie bei einem delay() stehen bleibt?
Der Kode wird unter CPU Kontrolle gesendet, während der Zeit kann sie nichts anderes machen.
Die verwendeten delays werden zum Erzeugen der Signalform (Modulation) verwendet
(wenn ich mich recht erinnere).
Miss doch einfach mal wie lange das Senden bei deinen Codes dauert.
Chris72622:
Meinst Du damit, dass während dem Senden eines Befehls mein kompletter Code wie bei einem delay() stehen bleibt?
Da ich kürzlich mit dem selben Problem zu kämpfen hatte:
Ja, während des Sendens, wir der Sketch blockiert.
Ich habe dazu einen ATtiny85 verwendet, der die RCSwicht bedient.
Dieser wurde dann von meinem "Hauptcontroller" Atmega328 angesteuert.
Der Atmega konnte während des Sendens normal weiter werkeln.
Klaus_ww:
Naja, es ist noch zu überlegen, was "gleichzeitig" tatsächlich bedeuten muss.
Oder anders: was passiert, wenn "gleichzeitig" eine Verzögerung von z.B. 1 ms bedeutet?
Das Senden dauert erheblich länger. Bei mehreren Steckdosen kommen da schnell einige Sekunden zusammen.
Da werden also 4 Steckdosen der Reihe nach eingeschalten.
(RCSwitch und Arduino UNO)
Hast du die Steckdosen auch tatsächlich geschaltet, oder läuft der Sketch ohne Steckdosen ?
Ich frage deswegen, da ich festgestellt habe, je weiter die Steckdosen vom Sender entfernt sind und je mehr Steckdosen es sind (speziell wenn die dicht beieinander montiert sind), desto kritischer wird das.
Da kann mann nur mit mehrfach Aussendung des Funkcodes das Problem umgehen.
Leider stören sich diese Dinger gegenseitig, wenn die zu dicht beieinander sind.
HotSystems:
Hast du die Steckdosen auch tatsächlich geschaltet, oder läuft der Sketch ohne Steckdosen ?
Ich habe die 4 Steckdosen tatsächlich geschaltet.
Die Testbedingungen:
Entfernung zwischen Sender und Steckdosen etwa 5 Meter (freie Sicht, also keine Wände dazwischen). Das ist also "nicht gar so weit entfernt".
Die Steckdosen sind direkt nebeneinander. Die gegenseitige Störung dürfte sich also in Grenzen halten.
Am Sender habe ich natürlich eine "Antenne" montiert (Draht ca. 17,4 cm).
Es sind "Brennenstuhl" Funksteckdosen. Mit denen habe ich bisher recht gute Erfahrungen gemacht.
Es gibt ja auch eine sehr breite Palette an Funksteckdosen und die Empfänger dürften durchaus unterschiedlich sein. Hab bisher schon mehrere unterschiedliche Funksteckdosen verwendet und die Erfahrungen waren "ebenso unterschiedlich"
Mit wachsender Entfernung nimmt natürlich auch die Empfangssicherheit ab. Wenn es dann noch mehrere "Störsender" in der Nähe gibt, wie etwa Wetterstationen mit Aussensensoren* etc., dann nimmt die "Schaltunsicherheit" zu. Großer Unterschied auch, ob man in dicht verbautem Gebiet agiert oder im Einfamilienhaus "allein auf weiter Flur".
Die Empfängssicherheit kann man dadurch etwas steigern, indem etwa der Code nach kurzer Zeit noch einmal wiederholt wird. Aber natürlich ist das auch keine Garantie, dass der gewünschte Schalvorgang wirklich stattgefunden hat. Das gäbe es nur mit einem "Rückkanal" bzw. einer Rückmeldung. Das ist ja durchaus üblich bei Funkschaltsystemen im mittleren/höheren Preissegment.
*) Hatte eine Wetterstation gekauft. Habe zuerst die Batterie in die "Basisstation" eingelegt und war recht überrascht, dass ich sofort Daten vom "Aussensensor" bekam, obwohl ich in den ncoh gar keine Batterie eingelgt hatte ??? . Es stellet sich heraus, dass anscheinend einer meiner Nachbarn die gleiche/ähnliche Wetterstation hat und ich die Signale seines Aussensensors empfange - ich habe viele Nachbarn.
Chris72622:
Dafür gibts dann mySwitch.setRepeatTransmit(x), oder?
Gruß Chris
Normal schon, aber ich habe das getestet und es reicht nicht immer.
Daher sende ich den Code zusätzlich mehrfach aus. Siehst du später auch im Sketch.
@uxomm
Ja, mit den Brennstuhl bzw. von Pollin (baugleich) habe ich auch sehr gute Erfahrungen gemacht. Andere leider weniger gut.
Da haben sich die Empfänger schon im Abstand von 1 Meter gegenseitig gestört.
Chris72622:
Dafür gibts dann mySwitch.setRepeatTransmit(x), oder?
Das ist möglich, ich kenne aber die RCSwitch-Library jetzt nicht in jedem Detail, sondern nur was ich für meine Projekte so benötige.
Ich würde das aber einfach "per Hand" machen, also kurze Zeit ("ein paar Sekunden später") noch einmal senden.
Aber es kommt natürlich immer auf die Anwendung an.
Wenn ein Mensch z.B. einen Taster betätigt und eine direkte Rückmeldung hat (z.B. Licht geht an), dann ist so etwas ohnehin nicht nötig, denn wenn das Licht aufgund von Störungen etc. NICHT angeht, dann wird dieser Mensch den Taster wohl gleich noch einmal betätigen.
Eine ganz andere Situation zum Beispiel: Pumpe für Rasenbewässerung soll zu bestimmter Uhrzeit ein- bzw. ausgeschaltet werden. Das könnte Probleme machen, wenn die Pumpe aufgrund von Störungen der Funkstrecke nicht ein- oder ausgeschalten wird. Irgendeine Form von Rückmeldung wäre da schon von Vorteil
HotSystems: @uxomm
Ja, mit den Brennstuhl bzw. von Pollin (baugleich) habe ich auch sehr gute Erfahrungen gemacht. Andere leider weniger gut.
Da haben sich die Empfänger schon im Abstand von 1 Meter gegenseitig gestört.
Oh, das sich die Emfänger gegenseitig stören können hatte ich bisher gar nicht so "auf dem Schrim". Aber das könnte einige Probleme erklären...
Und da kommen dann auch wieder Erinnerungen vom Amateurfunk-Kurs (lang, lang ist's her) an die Oberfläche
