Handhabung & Technik RaspEasyFire - RaspberryPi Funkmodul für El Fueradoro Zündanlage

Dieses Thema im Forum "Effekte, Feuerwerkskörper, Technik, Hilfsmittel" wurde erstellt von Newan, 4. August 2018.

  1. Mal was ganz anderes: Fehlende Slaves ignorieren

    Was bedeutet das genau und was hat das für Folgen.
    Mir ist schon klar, dass ich eine Show nur starten kann wenn alle Slaves gefunden werden oder ich "Fehlende Slaves ignorieren" wähle. Ändert sich dadurch auch was in der Funkübertragung?
    Vielleicht geringere Zündzuverlässigkeit, da dem Sender egal ist wenn der Empfänger die Zündung nicht zurückmeldet?

    Wäre schön, wenn mich mal jemand schlau machen könnte.

    Gruß

    Tobias
     
  2. Die Funktion Slaves ignorieren nehme Ich nur wenn Ich ein Musikfeuerwerk übertragen habe und Ich dieses einmal am Sender durchlaufen lassen möchte. Somit muss Ich nicht immer alle Empfänger einschalten.

    Danach würde Ich das aber wieder zur Sicherheit deaktivieren, nicht das man etwas vergisst und der sender sagt dann Egal ;-) Das wäre nicht so gut.
     
  3. Eine Rückmeldung der Zündung gibt es nie. Der Sender schickt den Zündbefehl fünfmal hintereinander raus, wobei die Nummer der Wiederholung mitgeschickt wird (5, 4, 3, 2, 1), um dem Empfänger zu sagen, wie lange er bis zur tatsächlichen Zündung warten muss. Während der Show wird ausschließlich unidirektional kommuniziert, damit niemand dem Sender reinredet.

    Die Rückmeldung hatte ich zunächst eingeplant, es stellte sich aber die Frage nach ihrem Nutzen und den Problemen die dadurch entstehen, so dass ich mich dagegen entschieden habe: Eine Rückmeldung bzw. mehrere, wenn es mehrere Teilnehmer mit gleicher Slave-ID gibt, blockiert den Kanal für eine geraume Zeit, wodurch der jetzige minimale Abstand zwischen den Zündungen nicht mehr zu halten wäre. Solange der Sender versuchen würde, den nicht angekommenen Befehl erneut zu senden, kann er keinen anderen schicken, der in der zeitlichen Abfolge womöglich fällig wäre. Weiter wäre zu überlegen, wie lange es der Sender erneut versuchen sollte, den Befehl zu schicken, bevor er aufgibt? Sollte eine Box während der Show die Grätsche machen und somit nie zurückmelden, würde das unter Umständen den kompletten Ablauf komplett crashen.

    Um die eigentliche Frage zu beantworten: Diese Einstellung ist eine reine Debugging-Einstellung, die ich z.B. beim Programmieren verwende, wenn ich irgendwelche Dinge in der Show testen will, ohne dabei ein ganzes Arsenal an Empfängern aufzubauen. Sie bedeutet einzig und alleine, dass eine fehlgeschlagene Überprüfung, ob alle verwendeten Slave-IDs auch tatsächlich vorhanden und scharf sind, nicht dazu führt, den Start der Show zu verhindern.
     
  4. Schon klar - aber was passiert in der Sender-SW?
    Wie funktioniert die Übertragung und die Rückmeldung der Empfänger.
    Was passiert, wenn ein Empfänger mal einen Befehl nicht mitbekommt?
    Oder der Sender die Rückmeldung nicht mitbekommt?
    Darum geht es mir hier...
     
  5. @zuendlER84 wäre es dann mit der Rückmeldung dann in etwa wie bei der Slave suche ? Je mehr Empfänger desto länger die Rückmeldungen der Boxen? Oder wäre das dann ein fester Wert wie bei dem Zündabstand?

    Das Problem wäre ja dann aber trotzdem, wenn das System merkt das was nicht gezündet hat, und er es nachzünden würde, dann wäre es bei einem Musikfeuerwerk nicht mehr Synchron zur Musik.
     
  6. Bei der Slave-Suche ist das recht einfach: Da sagt der Sender, dass sich Anwesende bitte melden sollen und dann gibt es für jede einzelne Unique-ID einen Zeitslot von 125 ms, in dem sie sprechen darf. Bei einer maximalen Anzahl von 50 Boxen habe ich also 50 Zeitslots, weshalb die Slavesuche eben auch einige Sekunden dauert. In der Show hat man diese Zeit nicht, da müsste es deutlich schneller gehen. Jede Box müsste wissen, wie viele weitere Boxen es mit ihrer ID gibt, anhand der Unique-IDs müsste man eine Reihenfolge festlegen, in der Boxen mit gleicher ID antworten. Bei vier Boxen mit gleicher ID wäre das also schon einmal eine halbe Sekunde, in der kein weiterer Zündbefehl gesendet werden könnte.

    Ein großes Problem wäre es aber auch, wenn die Box den Befehl bekommt, zündet, die Rückmeldung schickt, aber das beim Sender nicht ankommt. Dann sagt der Sender, die Box solle noch einmal zünden, die denkt sich aber, dass doch gerade alles bestens war und zündet nicht (was vielleicht auch gut ist, wenn an dem Kanal z.B. ein Stepper hängt, der bei jeder Zündung den nächsten Kanal feuert), was den Sender durchdrehen lässt, weil er nie seine Bestätigung bekommt.

    Aus diesem Grund gibt es ja jetzt die Möglichkeit, manuell über die Buttons auf dem Display nachzuzünden oder sich Backups anzulegen, wenn mal was nicht hochgeht.
     
  7. Ich dachte so an 150ms für alle Boxen, aber bei 500ms nur für die Rückmeldung das ist dann außer Frage eindeutig zu lange.
    Und wenn die Boxen dann anfangen Ping Pong zu spielen, dann ist eh alles vorbei, abgesehen davon könnte es dann eventuell während der Show zu hängern kommen, weil ständig nur noch gefunkt und empfangen wird.


    Wie verhält sich das dann eigentlich mit dem RSSI Wert. Der wird ja im Grunde nur im Sender geändert, aber für die Rückantwort der Boxen ja nicht. Was ja eigentlich bei dem jetzigen System nicht tragisch ist, aber bei einer Rückmeldung müsste der Wert ja auch in den Boxen geändert werden.
     
  8. Vielen Dank Felix, für die mal wieder gute und sachliche Erklärung. Ich hoffte dass könnte der Fehler gewesen sein, warum ein paar Zündungen bei meinem Test-Feuerwerk nicht funktioniert hatten. Schade.
    Ich habe die Anzünder, die während des FW nicht funktioniert haben heute nochmals angeschlossen und die Show (mit den stehengebliebenen Anzündern) nochmals laufen lassen - die haben heute alle gezündet...
    Wäre für mich eben eine gute Erklärung gewesen, dass ich einen Fehler gemacht hätte. Aber daran lag es dann offenbar nicht.
    Schade. Dann muss ich weiter forschen.
     
  9. Das Verhalten hatte ich letztes Jahr auch in meinem Feuerwerk. Zwei Zündungen nicht geklappt, bei späterem manuellen Versuch dann ohne Probleme. Hatte es auf mögliche Verbindungestörungen geschoben und nicht weiter verfolgt.
     
  10. #660 pyro-michel, 22. November 2020
    Zuletzt bearbeitet: 22. November 2020
    Meine Gewichtung zu dem Thema ist folgendes. Wir schießen jedes Jahr ein Abschlussfeuerwerk nach der Kirmes. Gezündet wurde die letzen Jahren mit einer Explo, jedoch ging im letzten Jahr im Rack eine ganze Reihe 125er Kugelbomben nicht los, warum? Das wusste keiner! Ein paar Tage später hatten wir die Zünder getestet und die gingen dann. Daher das warum, bleibt oft ein Rätsel. Eventuell war auch ein Draht nicht richtig gesteckt, und durch die Vibrationen hatte es keinen richtigen Kontakt mehr.
    Es ist immer ärgerlich, egal mit welcher Anlage auch immer geschossen wird, aber Ich denke bei jedem Pyrotechniker ist schon einmal das ein oder andere stehen geblieben.

    Ist jetzt zwar keine Lösung zu dem Problem, aber man sieht auch mit anderen Systemen kann einem so etwas passieren, jedoch die Frage wird immer bleiben "warum"

    ich habe bei meinem ersten Testfeuerwerk auch etwas seltsames gehabt, und zwar beim runterzählen kann eine Singleshot nicht und dann mit der letzten Zündung bei runterzählen 2 Singleshots. Da habe bis heute keine Ahnung warum.

    Hier mal der Link:

    https://www.youtube.com/watch?v=eVr1DXJ4Wac

     
  11. #661 zuendlER84, 23. November 2020
    Zuletzt bearbeitet: 23. November 2020
    Das hat nichts damit zu tun, ob Rückmeldung oder nicht. Natürlich kann es auch in den Zündboxen vorkommen, dass die RSSI-Schwelle zu empfindlich eingestellt ist und der Empfänger deshalb durch Rauschen getriggert und vom eigentlichen Geschehen abgelenkt wird.

    Falls irgendwer schauen will, ob er damit irgendwas tunen kann, habe ich unter der Einstellmöglichkeit für die RSSI-Schwelle des Senders noch einen Button eingefügt, um die RSSI-Schwelle bei allen Zündboxen in Reichweite setzen zu können. Damit das auch funktioniert, müssen auch die Boxen mit den neuesten Firmwaredateien ausgestattet werden, die gerade frisch aus dem Compiler gepurzelt sind. Die Änderung in den Boxen ist jeweils nur bis zum nächsten Neustart gültig, danachngeht es auf den Standardwert von -103,5 dBm zurück.

    Auf dem raspEasyFire werden jetzt auch die Chains unterstützt, die man mit PyroIgnitionControl 2 anlegen kann, also die Aufsplittung einer Zündung in mehrere Zeilen. Unter raspEasyFire werden sie wieder zusammengefasst und in der Beschreibung mit " + " verknüpft. Danke an @Fibricus, mit dessen Zündplan ich das verifizieren konnte.
     
  12. Mal was zur Empfangsleistung:
    Was zeigt mir der Sender eigentlich an?
    Zeigt der die Signalstärke an, mit der der SENDER die Empfänger emfängt?
    Oder zeigt der die Signalstärke an, mit der der EMPFÄNGER den Sender emfängt und das zurückmeldet?
    Zweiteres fände ich persönlich viel interessanter. So wird das auch bei den modernen Funkfernsteuerungen im Modellbau gemacht.
    Weil eigentlich interessiert es mich ja mehr wie gut die Empfänger den Sender emfangen, da die Show ja Unidirektional gesendet wird...
     
  13. Aus Traditionsgründen (meine allerersten Zündboxen wurden damals mit dem RFM12 aufgebaut, das hatte keinen digital lesbaren RSSI-Wert) war es bisher immer so, dass der Sender auf dem Display die Leistung ausgegeben hat, mit der er die Antwort von der Box bekommt, weil noch nicht alle Boxen einen RSSI-Wert beim Empfang des Sendersignals vorweisen konnten.

    Inzwischen habe ich aber alle RFM12 schon lange in Rente geschickt und der Einwand ist völlig berechtigt. Aufgrund der typischerweise deutlich schlechteren Empfangsposition der Boxen interessiert die Leistung, die dort vom Sender kommend eintrifft, wesentlich mehr als die der Rückantwort. Wenn man die Software am Sender und den Empfängern aktualisiert, sieht man jetzt den Empfangswert der Box beim Identifizierungsaufruf durch den Sender statt den der Antwort.
     
    Fibricus und pyro-michel gefällt das.
  14. Also, Update erfolgreich eingespielt. Wird der Wert RSSI Wert dann mit der Slavesuche an die Boxen gesendet, und wenn ja bekomme Ich dann erst mit der zweiten Suche den richtigen Wert angezeigt?

    Nur von mir als kleine Anmerkung. Zur Optik würde Ich das mit dem RSSI in einen eigenen Reiter Packen, wäre ja auf dem Display noch ein Platz frei. Dann hätte man eine Art Direktzugriff.
     
  15. Und noch eine Frage, wenn nun die Warnmeldung mit dem RSSI Wert kommt, ist das dann auf den Sender Bezogen oder werden die Werte in der Auswertung zusammengelegt. Das erschließt sich mir noch nicht so ganz
     
  16. Vorheriger Zustand: Der Sender schickt eine Identifizierungsaufforderung, die Boxen empfangen sie, stellen ihre Antwort zusammen und schicken diese im für die anhand der Unique-ID festgelegten Zeitschlitz an den Sender. Der Sender nimmt diese Parameter (Unique-ID, Slave-ID, Scharfschaltungszustand, Batteriespannung, Temperatur, Kanalanzahl) und stellt sie zusammen mit derjenigen Leistung, mit der er diese Antwort empfangen hat, auf dem Display dar.

    Jetziger Ansatz: Die Boxen fügen ihrer Antwort noch die Information hinzu, mit welcher Leistung sie die Identifizierungsaufforderung des Senders empfangen haben. Der Sender bekommt diesen Wert und stellt ihn zusammen mit den anderen Informationen auf dem Display dar. Nach außen hin sieht man keinen Unterschied, der RSSI-Werts stellt jetzt aber eine andere Info dar als vorher.

    Und was soll eine zweite Slavesuche sein? Es gibt nur eine (die man beliebig wiederholen kann, wenn einem langweilig ist), aber die RSSI-Werte beziehen sich immer auf die letzte Identifizierungsanforderung vom Sender und tragen keinerlei Historie in sich.
     
  17. Ok, das würde dann soweit ja alles passen, was mir jedoch noch nicht so gut gefällt ist folgendes. Ich habe nun die Standartwerte und Ich bekomme die RSSI Warunung ( Umgebgung im Keller mit Sicherrungskasten etc. ) Er findet also keine Boxen, ich stelle nun den Wert des Empfängers auf 95,5 und er findet die Box. Im Display steht trotzdem RSSI- Warunung. Hier wäre noch gut zu wissen welcher der beiden Werte gemeint ist. Eventuell durch die zusätzliche Kennzeichnung S und E.

    Das richtig auszuloten ist echt schwer, denn es kann ja sein das der Sender in der Nähe einer Störquelle steht ,und die Empfänger stehen auf dem Platz perfekt.
     
  18. "RSSI-Warnung" bezieht sich auf das Funkmodul im Sender, das hat mit der aktuellen Änderung nichts zu tun. "RSSI-Warnung" bedeutet, dass das Modul im raspEasyFire während der Slavesuche ständig getriggert wird, ohne dass danach ein gültiges Signal empfangen wird, da muss man prinzipiell an der Empfindlichkeit des Senders drehen, nicht an der der Boxen. Es kann natürlich sein, dass auch die Boxen ständig getriggert werden, aber das erfährt man nicht unmittelbar.
     
  19. Dann mache Ich lieber für mich wieder die Vorgängerversion auf den Sender. Mir ist das mit dem RSSI Wert für die Boxen nicht schlüssig, und wenn man keine Rückmeldung bekommt ob da was Triggert, für was ist die Einstellmöglichkeit dann?
    Oder wo denke Ich falsch?

    Also die RSSI Warnung bezieht sich auf den Sender, soweit alles ok.
    Aber wo lässt sich die Änderung des RSSI Wert der Boxen ablesen? Ist das der Wert der dann am Rasp nach der Slavesuche ausgegeben wird?

    Das ist echt ein Thema das viele Fragen, und wenn auch nur von mir aufwirft ;-)
    Eventuell sollte Ich mal einen Kaffee trinken um wach zu werden.
     
  20. Du wirfst ein paar Dinge durcheinander, man muss bei den Begriffen sehr genau differenzieren.

    Was in den Einstellungen für Sender und neuerdings auch Boxen eingestellt werden kann, ist die RSSI-Schwelle. RSSI (received signal strength indicator) ist in diesem Zusammenhang vielleicht nicht der exakt passende Begriff, die Amateurfunker würden, wie mir Fibricus gesagt hat, wahrscheinlich eher von einem Squelch sprechen.

    Das ist das Leistungsniveau, bei dem ein Device (Sender oder Boxen) seine Ohren aufstellt, um eventuell Daten empfangen zu können. Liegt die Leistung bei der eingestellten Frequenz über diesem Wert, hört das Funkmodul zu und schaut, ob innerhalb einer bestimmten Zeit eine gütlige Nachricht kommt. Ob eine Nachricht gültig ist oder nicht, dafür gibt es bestimmte Datenpattern, die an vorgegebenen Stellen im Signal vorkommen müssen und am Ende den CRC-Abgleich. Wenn für eine bestimmte Zeit nach dem Überschreiten der RSSI-Schwelle keine gültige Nachricht vorliegt, dann führt das zu einem so genannten Rx-Timeout. Wenn es permanent zu Rx-Timeouts kommt, deutet es darauf hin, dass der Grundrauschpegel in der Umgebung höher ist als die RSSI-Schwelle bzw. der Squelch-Wert. Man muss diese Schwelle also erhöhen, damit der Empfänger sich auf das Wesentliche konzentriert.

    Was auf dem Startbildschirm angezeigt wird, ist der tatsächlich empfangene Leistungspegel, der logischerweise über dem Squelch-Wert liegen muss. Den Squelch-Wert der Boxen auslesen kannst du nur an den Boxen selbst, wenn du den Direktzugriff aufs Funkmodul nutzt und schaust, was in Register 0x29 als Wert steht.

    Natürlich verhält es sich mit dem Setzen des Squelch-Werts in den Boxen so wie mit der Identifizierung: Eine Box, die aufgrund eines a priori zu niedrigen Wertes die Anweisung, den Wert zu ändern, nicht mitkriegt, wird ihn natürlich nicht ändern.
     
    Fibricus und Chiricahua gefällt das.
  21. Hallo,

    ich habe eben meine kleine Silvester Show im Pyro Ignition Control geschrieben. Das Ziel war es, im SemiAutoMode zu schießen. Anbei ein Screenshot aus dem PyroIgnitionControl2.0
    Screenpyroignition.png

    Die ZPL erfolgreich auf dem PI geladen. In den SemiAutoModus gewechselt und die ZPL ausgewählt. Dann ist die Oberfläche abgestürzt zu den Punkt, wo ich zum starten des raspEasyFire den Fire Button drücken muss. Den Fire Button gedrückt und ich bin wieder zurück auf die Oberfläche gekommen. Mein Pi ist so eingestellt, dass er beim starten immer im manuellen Mode geht. Wenn ich jetzt den Modus wechsel kommt sofort der Absturz. Ein kompletter Neustart verschaffte mir auch keine Abhilfe.

    Grüße Cedrik
     
  22. Vermutlich ist da irgendwas in der ZPL enthalten, was der Parser nicht mag. Schick mir die Datei bitte mal per Mail oder als PN.
     
  23. Ich habe dir das per Mail geschickt, weil das Forum in PNs keine Dateien zulässt.
     
  24. Zum Glück hat sich das Problem schnell klären lassen. In einer älteren Version der Software kam es zum Absturz, weil bei einer fehlerhaften ZPL (im vorliegenden Fall waren alle Cues bei 0:00,000 platziert, was im Falle einer automatisch geschossenen Show nicht erlaubt ist) als Ergebnis des Imports die Rückgabevariable kein dict() ist, sondern einfach nur eine Zahl - und ich das nicht gut genug gekapselt hatte, so dass an manchen Stellen versucht wurde, auf einer Zahl dict-Operationen durchzuführen. Das Problem wurde laut Log am 25.10. behoben, tritt also mit aktuellen Softwareversionen nicht mehr auf. Jetzt sollte das Programm weiterlaufen und einfach nur durch eine Fehlermeldung auf den fehlgeschlagenen ZPL-Import hinweisen.

    Ich wünsche allen, die in der aktuellen Situation eine Silvestershow schießen dürfen und werden, viel Erfolg und viel Spaß - ansonsten allen ein gutes neues Jahr 2021 mit hoffentlich wieder besseren Aussichten!
     
  25. Super zuendler84 das du das Projekt hier supportest!
    Euch allen gut Schuss und frohes und gesundes neues. Ich hab nur paar Restbestände und mach was kleines für meine Kinder
     
    tux1975, pyro-michel und Silberschweif gefällt das.
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren, diese deiner Erfahrung anzupassen und dich nach der Registrierung angemeldet zu halten.
    Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden