Handhabung & Technik Besteht Interesse an einer DIY Zündanlage?

Dieses Thema im Forum "Effekte, Feuerwerkskörper, Technik, Hilfsmittel" wurde erstellt von TelosNox, 4. Januar 2017.

  1. Youtube ist mir ein wenig zu öffenlich. Normalerweise pack ich sowas einfach ins google drive und gebe dann den Link weiter.
     
  2. Man kann auf YT videos auch auf nicht gelistet stellen
     
  3. Ok das wäre ne Option.
    Ich hab bisher noch nie was auf Youtube hochgeladen, daher hab ich 0 Erfahrung damit. Aber irgendwann muss man damit ja mal anfangen.

    Kurzer Zwischenstand:
    Wie geplant läuft die Konfiguration jetzt direkt über die gefundenen AdHoc Module. Die kann man per Context Menü in ein Konfiguriertes Modul umwandeln. Umgekehrt kann man Konfigurierte Module mittels Kontext Menü auch wieder löschen.
    Screenshot ist angehängt.

    Dämlicherweise erscheint das Context Menü beim obersten Eintrag irgendwo ganz unten (weil es sonst außerhalb der View wäre). Lässt sich lösen, wenn ich die Buttons nach oben verlege. Sieht aber dann irgendwie doof aus...
    /edit: Das falsch platzierte Context Menü scheint Android 7 spezifisch zu sein. Zumindest lese ich das so im Netz. Ist also aktuell weniger tragisch.

    Module_Overview.jpg
     
  4. Neue Baustelle:
    Ich hab die ganze direkte Kommunikation mit den Modulen über AsyncTask gelöst. Dumm, dass die Dinger in einer Queue laufen und sich gegenseitig blockieren.

    Aufgefallen ist mir das irgendwie schon vorher. Das eine Modul hatte einen guten Ping und beim anderen Modul war der Wert fast doppelt so hoch.
    Jetzt als ich mal das erste Modul ausgeschalten hab, ist der Ping vom 2. Modul massiv in die Höhe gegangen.
    Ist auch logisch. Die erste Anfrage wartet 300ms auf Antwort und bricht dann ab (Timeout, das Modul ist offline). Erst danach kommt das zweite Modul überhaupt zum Zug.

    Das ist *******e! So darf das nicht sein, denn im Zweifel hat man 5 bekannte Module, die 4 ersten gehen offline und Modul 5 braucht jetzt gute 2 Sekunden, um Befehle abzusetzen.

    Ich muss den ganzen Mist jetzt also nochmal umbauen. Back to the basics.... wird erstmal wieder nix mit neuen Features :(
     
  5. Umbau ist erfolgt und man kann jetzt schon grundsätzlich ein Feuerwerk planen:
    Man kann Name, Modul, Kanal und Delay angeben.
    Allerdings wird das bisher weder abgespeichert, noch kann man es irgendwie abspielen (das kommt natürlich noch).
    Auch umsortieren der Reihenfolge ist noch nicht möglich, das muss noch rein.

    Als nächstes muss das dann irgendwie gespeichert werden können (idealerweise unter einem Namen) und dann muss man es auch noch "abspielen".

    Dann wäre schonmal ein großer Teil geschafft. Das ist jetzt alles noch ohne virtuelle Kanäle. Man kann Kanäle nicht umbennen. Aber die Zündaktionen im geplanten Feuerwerk kann man bennenen.
    Ich kann mir vorstellen, dass das bereits reichen könnte.

    Ich hab wieder nen Screenshot angehängt, wie das aktuell aussieht, wenn man so ein Feuerwerk zusammengeklickert hat.
    Die Zeiten sind aktuell als Delta angegeben (also Abstand zum vorherigen Zündzeitpunkt).

    Das ist vielleicht nicht ganz so intelligent. Vielleicht macht es mehr Sinn, wenn man der jeweiligen Zündaktion ihre Laufzeit mitgibt. Dann würden die Zeitpunkte immer noch stimmen, wenn man umsortiert.
    Allerdings trifft das nur zu, wenn man nach Ende eines Effekts das nächste zünden will. Wenn man etwas verzögert zünden will, so dass beide Effekte Zeitgleich enden, bringt es wieder nix mehr mit der Laufzeit.

    FeuerwerkPlan.jpg
     
  6. Ich hab mal die Kamera draufgehalten. Dummerweise ist die Aufnahme LED an, die spiegelt im Handy. Sollte aber nicht so tragisch sein.

    Die Texte im UI sind stellenweise noch Schrott. Einfach ignorieren, ich lasse mir da noch was gescheites einfallen.

    Wohl bekomms...
    https://youtu.be/FziFb449aEc
     
    tommihommi1 gefällt das.
  7. Langsam wirds interessant.
    Ich hab mal den ersten Entwurf am laufen, wie so ein geplantes Feuerwerk dann in der App automatisiert abläuft.

    Aktuell kann die App ein geplantes Feuerwerk abspielen. Die Delays sind immer relativ zur vorherigen Zündung (also Verzögerungen). Auch der Start kann verzögert werden (wenn die erste Zündaktion ein Delay hat).

    Screenshot ist angehängt. Oben rot sieht man die letzte Zündung (das läuft also gerade). Darunter mit einem ProgressBar die nächste anstehende Zündung. Wenn der Balken durch ist, wird gezündet. Darunter dann die Liste mit den übrigen Zündaktionen (die ist scrollbar, man kann sich also nen Überblick verschaffen).

    Noch werden keine Zündungen ausgelöst, das ist aber nachher eine Kleinigkeit. Es gibt aktuell auch eine feste Taktung von 200ms (alle 200ms wird geprüft, wie weit der Fortschritt ist). Man könnte hier auch beliebige Verzögerungen realisieren, allerdings wirds dann mit dem ProgressBar kompliziert. Das stelle ich erstmal hintenan, zumal ich Verzögerungen eh im Sekundenbereich geplant habe (alleine die Kommunikation braucht schon ca. 30ms, da macht es nicht viel Sinn im Millisekunden Bereich zünden zu wollen). Auch eine Verzögerung von 0 ist aktuell immer mindestens 200ms lang (******* Konzept...). Da werd ich mir noch was einfallen lassen, denn das ist nachher die Brückenlösung, um mehrere Kanäle gleichzeitig zu zünden.

    Geplant ist jetzt erstmal, dass die gleichzeitige Zündung geht und dass auch tatsächlich Module angesteuert werden.
    Wenn ich das soweit habe, dann will ich die Semiautomatik machen.
    Wenn das durch ist, will ich eine Übersicht des geplanten Feuerwerks realisieren. So dass man jeweils das vollständige Modul mit allen Kanälen sieht und dann aber am jeweiligen Kanal angezeigt wird, welcher Zündaktion er zugeordnet ist und wann sein absoluter Zündzeitpunkt wäre (relativ wäre an der Stelle unnütz).
    Damit kann man dann bequem kontrollieren, ob man korrekt verkabelt hat (wenn man die Module aufbaut, so wie ich :D - dann entspricht die Anzeige in der App nämlich den Terminals am Modul).

    Irgendwann zwischenrein muss ich mir dann mal noch überlegen, wie man so ein geplantes Feuerwerk speichert. Schwierigkeit dabei ist, dass es sich ja auf konkrete Module bezieht, die nicht (mehr) zwingend in der Konfiguration vorhanden sein müssen. Außerdem will man vielleicht parallel unterschiedliche Feuerwerke planen. Also will man das benennen und die gespeicherten Planungen auswählen können. Alles leider nicht trivial, vor allem, wenn man mit so wenig Berechtigungen wie möglich auskommen will.

    GeplantesFeuerwerkSchiessen.jpg
     
  8. Mann mann mann...

    wenn man mal vorher schaut, wie man so einen Countdown Progress machen kann, ohne das alles zu Fuß zu implementieren, dann geht es einfacher.
    0 Delay funktioniert jetzt korrekt und das Delay kann jetzt theoretisch im Millisekunden Bereich liegen (ich erlaube es aktuell aber nicht).

    Als nächstes mache ich definitiv die Speicherei fürs Planen. Es nervt nämlich, wenn man für jedes mal ausprobieren wieder alles neu eingeben muss.
     
  9. Hier gibt's wieder was zu sehen:
    https://youtu.be/u8LUBe3yIUU

    Das automatische Abspielen eines geplanten Feuerwerks ist jetzt als Prototyp implementiert.

    Ansonsten hab ich jetzt auch schon das Speichern der geplanten Feuerwerke drin, allerdings ergibt sich aktuell die Reihenfolge aus der alphabetischen Order der Namen. Ich muss hier noch den Index mitspeichern und nach dem dann sortieren.

    Die Automatische Ausführung sendet aktuell auch nur blind die Befehle und interessiert sich weder für Rückantworten, noch für den aktuellen Status. Auch Scharfschalten geht hier noch nicht, das muss man im manuellen Modus machen.

    Frage die hier aufkommt: Was mache ich beim Automatischen Abspielen, wenn eine Zündung nicht erfolgt ist (also das Modul nicht Erfolg zurückmeldet). Ich würde es jetzt einfach mal ignorieren und nach Plan weitermachen. Alles Andere nützt dem User ja nix, er kann ja eh nix an der Situation ändern.

    Was definitiv noch rein muss ist vor dem Start eine Prüfung, ob alle benötigten Module online sind und ob alle nötigen Kanäle belegt sind. Und ein Scharfschalten aller nötigen Module natürlich auch (samt Prüfung, ob sie alle scharf sind).
     
  10. wie sieht es eigentlich mit dem Code für die boards aus, darf man sich das mal anschauen? :)
     
  11. Natürlich.
    Ich hänge heut abend mal das aktuelle Sketch an.
     
    tommihommi1 gefällt das.
  12. https://github.com/TelosNox/noxnition
    Hier der komplette Code und auch das KiCad.

    Ich bin was Git angeht ein absoluter Noob. Ich hoffe mal, dass ich alles korrekt mache und das Zeug auch gepublished ist.

    Schlagt mich nicht für den teils arg unaufgeräumten Code, das Ganze wächst halt, wie es wächst und Android ist für mich relativ neu. Da, wo es mich stört, da räume ich zwischendurch mal auf.
     
    tommihommi1 gefällt das.
  13. Hab mir bisher nur den Arduino-Code angeschaut, der ist doch recht übersichtlich und kürzer als erwartet, dank tollen libraries
     
  14. Jo aber alles prozedural wird halt schnell voll. Allerdings da jetzt noch eigene Libs schneidern wäre zu viel des Guten, es lohnt nicht =)

    Übrigens, falls sich jemand mal selbst die App anschauen will: Die kompilierte Apk liegt im bin Ordner mit drin.
     
  15. Mir fällt grad auf, dass man mit der App nicht wirklich rumspielen kann, wenn man kein Modul hat. Man kann ja kein Modul konfigurieren, wenn sich keines meldet.

    Jetzt müsste man noch irgendwie irgend einen Fake bereitstellen, der auf den Broadcast reagiert und sich meldet. Allerdings hab ich aktuell wenig Lust dazu, das umzusetzen :rolleyes:
     
  16. Nachdem sich jetzt länger nix getan hat, wollte ich mal kurz Rückmeldung geben.
    Der Stand ist unverändert, ich hab nichts weiter gemacht. Aktuell bin ich einfach nicht so motiviert (bzw. hab einfach andere Dinge, auf die ich Bock habe).
    Außerdem bin ich unentschlossen, wie ich den Modulstatus aggregieren will (wird ja beim automatischen Zünden mit mehreren Modulen benötigt).
    Ich tendiere aber dazu, das so zu machen, dass man ein Programm scharf schaltet und der Schritt dann prüft, ob die Module online sind und ob alle notwendigen Kanäle Durchgang haben. Außerdem werden abschließend alle Module scharf geschalten und nur wenn der Status dann passend zurückkommt, dann kann auch das Programm abgespielt werden.
    Auf Zustandsänderungen zwischendrin reagiere ich dann nicht mehr, da gibt es nur noch Fire&Forget (man kann als Nutzer dann eh nichts mehr ändern).

    Wie schon gesagt, im Moment ist bei mir Pause. Wenn es mich wieder packt, dann gehts weiter.
     
  17. Hi, ich hole mal den alten Beitrag hoch. Gibt es was neues zum Projekt oder weiterhin Stillstand?
     
  18. Also ich bin noch da, hab aber weiter nix mehr gemacht.
    Der Code der App ist ziemlich durcheinander (weil er ja prototypisch ist und ich vieles erstmal lernen musste). Ich müsste da mal Refaktorieren und mir ein allgemeines Konzept ausdenken. So wie es aktuell ist, machen weitere Funktionen alles nur noch unübersichtlicher.
    Dem kommt hinzu, dass mir die App so wie sie aktuell ist erstmal auch reichen würde. Der Benefit ist relativ gering, um da jetzt den Aufwand zu investieren.
     
  19. Heute hat sich nochmal was getan.
    Mir hat der vollautomatische Modus nicht gefallen. Ich halte das für nicht sinnvoll mit Silvesterfeuerwerk. Daher wurde die vollautomatik durch einen Halbautomatik ersetzt.
    Man plant genau so wie bei Vollautomatik ein Feuerwerk. Man sieht den Timer ablaufen und wird beim geplanten Zündzeitpunkt informiert (visuell und vibration). Gezündet wird aber erst, wenn man entweder einen entsprechenden Touchbutton drückt oder "Lautstärke runter" (ich wollte eine physikalische Taste haben).

    So kann ich die Zeitpunkte on the fly anpassen und bei Bedarf früher oder etwas später zünden.
     
  20. Der Praxistest ist erfolgt:

    1. Geplantes Feuerwerk semiautomatisch schießen ging voll in die Hose. Ich hatte noch keine gescheite Sortierung eingebaut (war einfach Alphabetisch). Ist mir nie aufgefallen, weil ich die Zündschritte nie umbenannt hatte. Hab ich zu Silvester aber gemacht (nach Batterien benannt) und beim wieder aufrufen zum schießen war dann alles durcheinander. Ich hab dann manuell geschossen.

    2. Die WLAN Verbindung ist ein wenig instabil. Mit kam es 1x vor, dass der Befehl nicht ankam. Da ich sowieso manuell gezündet hab, war das nicht schlimm, ich konnte einfach nochmal draufdrücken. In der Semiautomatik wäre das aber komplett fail gewesen, weil das bisher noch Fire&Forget ist.


    Jetzt wird entsprechend angepasst.
    Ich muss sicherstellen, dass bei Semiautomatik nur weitergesprungen wird, wenn der Kanal auch gezündet wurde. Das lässt sich für Einzelzündungen recht einfach bewerkstelligen. Wenn aber mehrere Kanäle zugleich gezündet werden sollen, dann funktioniert das mit der aktuellen Variante nicht mehr.
    In der aktuellen Version wird ja der nächste Befehl sofort geschickt, wenn als Delay 0 eingetragen ist. Das funktioniert mit Fire&Forget. Aber nicht mehr, wenn der nächste Befehl erst dran kommt, wenn die Rückmeldung da ist. Das würde zu langen Zeitversatz verursachen.
    Also kommt jetzt DOCH die Möglichkeit virtuelle Kanäle anzulegen. Man gibt dem Ding einen Namen und weist dann beliebig viele Module und Kanäle zu. Im Zündplan wird dann nur noch dieser Stellvertreter hinzugefügt und mit dem Delay versehen.
    Die App kann dann alle nötigen Befehle zugleich senden und warten, bis alle bestätigt wurden. Fehlt für irgend einen die Bestätigung, so schaltet die App nicht weiter und zeigt den Fehler an. Durch nochmaliges Drücken wird nochmal gezündet (mal schauen ob ich hier dann einfach alles nochmal schicke oder ob ich nur fehlerhafte nochmal schicke).
     
    St0neC0ld gefällt das.
  21. Hmmm... ohne jetzt allzu viel hier gelesen zu haben:
    Für mich hört sich das arg nach "gebastel" an... ich schick mal einen Zündbefehl... wenn der nicht ankommt mach ich es halt nochmal.... das kann es doch nicht sein, oder?
    Wäre es nicht viel sinnvoller eine funktionierende Funktechnik einzusetzen? WLAN (inkl. IP) hat da meiner Meinung nach nichts zu suchen. Wenn ich das machen will kann ich per WLAN oder auch BT eine App an einen Funksender koppeln... der dann sicher und autark mit den Zündmodulen "spricht"...

    Gruß, Thomas
     
  22. WLAN+IP ist ziemlich zuverlässig, man sollte halt kein UDP verwenden, sondern TCP.

    Mit anderen Funklösungen ist es ja genauso, man sendet ein Signal, wartet auf ne Antwort, wenn nichts kommt, sendet man nochmal. Anders gehrs nicht
     
  23. Es ist http und somit tcp. Wenn das WLAN kurzzeitig aussetzt, dann geht nix raus. Dann kann man nicht anders, als wiederholen.
    Wir standen halt parallel zu einem Haus und die Module vor einem anderen Haus. Da sind auch viele Störungen durch andere WLAN.
    Zudem arbeitet alles mit System on Chip, damit es einfach umzusetzen ist. Da sind die Signale schwach wegen kleiner Antennen. Das kann man später immer noch ergänzen.
     
  24. So jetzt bin ich zu Hause und kann da mehr zu sagen.

    Die Kommunikation ist bisher Javaseitig ganz billig mit HttpURLConnection gelöst. Da gibts kein Autoretry oder ähnliches. Wenn die Gegenstelle nicht erreichbar ist, weil das Netz kurzfristig gestört wird, dann haut das Ding ne Exception raus und das wars.
    Ich werde das vermutlich noch durch den ApacheHttpClient ersetzen, der kann auch automatischen Retry.

    Mit Funkstörungen muss man immer rechnen und diese behandeln. Das passiert bei professionellen Funkmodulen ebenso. Ich bin noch mitten drin in der Erprobung der Features und da ist die technische Umsetzung stellenweise halt noch ganz billig gemacht. Durch den Praxistest finde ich dann die Stellen, die problematisch sind und kann sie verbessern.

    Wenn man vor Funkstörungen komplett sicher sein will, dann muss man das so machen, dass die Zündmodule das fertige Programm abspulen und von der App nur noch zyklisch Info bekommen, dass das Programm noch weiter laufen soll (damit ein Abbruch möglich wäre). Genau das will ich aber gar nicht. Ich will nicht, dass ein Modul autonom arbeiten kann. Das bringt nämlich die nächsten Sicherheitsprobleme mit sich und das will ich nicht haben. Das Modul ist nur ein dummer Empfänger, der Zündbefehle umsetzen kann und den Status liefert. Zudem die elektronische Scharfschaltung und die Zünderprüfung (die ist im Modul gesichert, die Scharfschaltung wird erst deaktiviert, dann wird die Spannung gemessen und nur wenn die im erwarteten Bereich liegt, wird geprüft).

    Und ja: es ist im Endeffekt "Gebastel". Jedes DIY, das auf der grünen Wiese startet, ist erstmal Bastelei. Meine Motivation für das Projekt ist 1. dass ich Spaß dran habe, sowas mal selbst umzusetzen und 2. dass ich evaluieren will mit wie wenig Aufwand sich sowas nachher nachbauen lässt.

    Man bedenke: Ein 8 Kanal Zündmodul benötigt lediglich einen NodeMCU, ein Schieberegister, 9 N-Mosfet, 1 P-Mosfet, 1 Lastwiderstand, paar kleine Widerstände und den Anschlusskram + Schalter und Dioden (wenn man die will). Will man mehr Kanäle: Einfach weitere Schieberegister und passend N-Mosfet dazu + Widerständchen.. fertig.
    Man braucht sich nicht um Spannungswandler, Funkmodule oder sonst was zu kümmern.
    Die Basiskomponenten incl. Akku kosten ca. 20-25€. 8 Kanäle kosten jeweils ca. 10€ und können beliebig in 8er Schritten erweitert werden (wenn man genug Platz hat, könnte man ca. 32000 Kanäle realisieren - dann läuft irgendwann der Integer über).

    Und die Fernsteuerung? Ein beliebiges Android Gerät, das Tethering kann (also quasi jedes).
    Und wenn jemand mit einem anderen Gerät fernsteuern will? Die Module sind über http ansprechbar, also kann sich jeder selbst was dafür basteln. Man kann sogar im Modul einen Webserver realisieren und dann drückt man in einer Webseite Knöpfe.

    Es soll keine Profianlage sein. Das steht auch direkt auf Seite 1. Man hat sowieso je nach Verbindungsqualität Latenzen zwischen 20ms und 400ms. Wer hier ganz exakte Timings braucht, muss sich was anderes suchen. Zielgruppe sind diejenigen, die sich günstig und mit möglichst wenig Löterei (wobei die leider auch nicht ganz wenig ist) eine Funkzündanlage mit einigen Kanälen für Silvester hinstellen wollen und denen es egal ist, ob es im Zweifel halt mal 1sec später zündet. Das ist auch der Grund, warum ich z.B. beim geplanten Feuerwerk das Delay in Sekunden mache und hier keine Millisekunden zulasse (das macht gar keinen Sinn).
     
    St0neC0ld und tommihommi1 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