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

Wenn es um die Beleuchtung des On-Off-Tasters geht: Die wird genau dann eingeschaltet, wenn ein Druck auf diesen Taster auch einen Effekt hat. Das hat mein Vorschreiber schon komp-lett richtig erkannt, um den Wortwitz zu bemühen. Während des Hochfahrens ist das nicht der Fall, dann hat man die Möglichkeit, die Kiste herunterzufahren oder zu starten, im Programm ist es dann von der Schlüsselschalterstellung abhängig, ob ein Druck auf den On-Off-Taster eine Wirkung hat oder nicht. Mit dem zweiten Taster ("Fire-Button") ist es nicht ganz so stringent, weil da die Beleuchtung eher als Signal für "bereit zum Feuern" dient. An manchen Stellen passiert also auch etwas, wenn die Beleuchtung aus ist, das ist dann aber eher informeller Natur. Wie auf meinen Bildern zu sehen, habe ich einen zusätzlichen beleuchteten Netzschalter, der permanent leuchtet, solange das Teil an ist.

Nach einigen Tests in den vergangenen Tagen habe ich ein neues Image hochgeladen. Durch eine neue Python-Version (3.6.9 statt 3.5.3), die es auch möglich gemacht hat, auf die stabile Version der Oberfläche Kivy umzusteigen, gehören die zeitweiligen spontanen "Segmentation Faults" nun hoffentlich der Vergangenheit an und nach einer Umstellung im Scheduling ist die weiter oben diskutierte mögliche Verzögerung von Cues nun deutlich geringer als vorher. Auch das Verhalten beim Scharfschalten (Deaktivierung aller Funktionen, Sprung auf den Startbildschirm) hat sich verändert und ein paar kosmetische Änderungen wie der Hinweistext "Suche läuft..." bei der Slavesuche sind dabei. Geändert hat sich auch die Adresse des Repositorys für den Python-Code, da hier ein Umstieg vom schwerfälligeren Gitlab zu Gitea vollzogen und Gitlab vom Server genommen wurde.

Ich hoffe, damit vor Silvester die letzte derart große Änderung vorgenommen zu haben, die zwingend ein Neuaufspielen des Images verlangt, weitere Fixes und Verbesserungen können dann nötigenfalls hoffentlich einfach über die Updatefunktion zur Verfügung gestellt werden.

 

Ich teste im Laufe der nächsten Woche, Feedback folgt.

 

So ich hätte eventuell noch eine Kleinigkeit die man verbessern könnte. Und zwar würde ich den Powerknopf generell zu mein und ausschalten nehmen. Und dann würde Ich im Menü noch den Punkt herunterfahren einfügen so wie einen zurück Button. Das Problem ist folgendes. Wenn man Strom auf den Raspberry gibt, dann geht er ja in eine Art Bootvorgang. Sobald man den Powerknopf drückt Bootet er ja fertig. Das Problem ist nur folgendes. Wenn ich aus dem Stand By Boote bleibt der Bildschirm "blau" leider haben das viele. Wenn ich jedoch das Raspberry ohne Herunterfahren ausschalte dann bleibt er beim erneuten einschalten hängen.....
Daher wäre eine Menügeführte Steuerung für das Runterfahren und für das zurückblättern im Menü eventuell eine gute Lösung.

 

Das Problem hatte ich auch schon öfters, außerdem fehlt mir auch ein Zurückbutton, da man beispielsweise aus dem Manuellen Zünden nicht mehr rauskommt, ohne das Gerät neu zu starten.

 

Eigentlich sollte man zurück auf den Startbildschirm kommen, wenn man den Schlüsselschalter auf entschäft stellt und den dann leuchtenden On-Off-Button betätigt. Da muss ich mir noch einmal den Code anschauen.

Nachtrag: War ein Fehler meinerseits. Ist repariert im Repository, im herunterladbaren Image noch nicht.

 

Ok, entwarnung meinerseits, dann hing das damit zusammen, dass ich damals den An/Ausschalter am falschen Kontakt angelötet hatte und ich mich dadurch irritieren lassen hab.
Vielen Dank für die Rückmeldung.

Hab jetzt nochmal dein Post gelesen und mir ist eben aufgefallen, dass der An/Ausschalter als Taster fungiert, was ja nicht die Sache des Erfinders ist, da dieser sowieso nicht richtig hält und somit auch momentan nur als Taster verwendbar ist lasse ich ihn erstmal in dieser Funktion so bestehen.

 

Was meinst du, wenn du vom "Powerbutton" sprichst? Den zweiten Taster neben dem "Fire-Button"? Da der an einem GPIO des Raspberry Pi hängt, muss der Raspi zunächst einmal mit einer Betriebsspannung verbunden sein, ansonsten kann er nicht darauf reagieren. Damit den Saft einzuschalten, wird nicht funktionieren, dafür müsste man eine neue Hardare entwickeln und auch ein Exemplar mit der entsprechenden Strombelastbarkeit (mind. 2 A, um sicher zu sein) verwenden.

Ich habe das Phänomen noch nie beobachtet, dass der Raspberry Pi nicht unmittelbar hochfährt, wenn man Strom anlegt. Ein zusätzliches Drücken des "On-Off-Buttons" ist bei mir nicht notwendig. Man kann nach dem Shutdown, wenn die Energiequelle noch verbunden ist, durch Drücken des On-Off-Buttons erneut booten, aber die Beobachtung, dass das System dann nicht wieder sauber hochkommt (Bildschirm "blau"), mache ich auf meinem System nicht. Oder verstehe ich da dein Szenario falsch?

Was verstehst du unter einer menügeführten Steuerung? Es gibt jedem Screen bis auf den Startbildschirm und die Showbildschirme (auto/manuell) eine "Zurück"- bzw. "Abbrechen"-Schaltfläche, die zurück in den übergeordneten Bildschirm führt, was hättest du gerne zusätzlich?

 

Danke für die Rückmeldung. Ich habe einem Ein/Aus Schalter - Einen Fire Button und einen Schlüsselschalter
Der Ein/Aus Schalter hängt zwischen der Powerbank und dem Raspberry. Wenn ich diesen nun einschalte Bootet er ganz normal durch. Wenn Ich auf der Aufsteckplatine an die Klemmen 9+10 On/Off Button einen Schalter anschließe dann Bootet der erst wenn ich diesen drücke. Sprich er fährt hoch und geht dann in eine Art SandBy wenn ich diesen Button nun drücke fährt er fertig hoch und dann bekomme ich nur einen blauen Bildschirm. Lasse ich den Schalter aber weg an den Klemmen 9+10 dann fährt er ganz normal hoch. Dann habe ich aber keine Möglichkeit den Raspberry sicher runter zu fahren ? Oder soll an die Klemmen 9+10 ein Taster ?
Weil zwei Powerknöpfe machen ja optisch keinen sinn....
Oder habe ich gerade einen großen Denkfehler ? Daher war die Überlegung das man im Display noch den Punkt hat, Beenden oder Rasp. runterfahren. Und wenn das System runtergefahren ist, den Powerknopf zur Stromunterbrechnung drückt.

 

Ok, da fehlt dann aber der zweite Taster, dessen LED an 9/10 der linken Klemmleiste und dessen Kontakt an 9/10 der rechten Klemmleiste, also jeweils neben die Anschlüsse des Fire-Buttons gehört. Ohne den kannst du ja die Software nicht sauber beenden und den Pi nicht herunterfahren.

Wenn du da einen Schalter anschließt und der am Ende des Bootvorgangs noch gedrückt ist, dann fährt sich der Pi herunter, weil ja der On-Off-Taster als gedrückt erkannt wird.

 

Ja das ist mir schon klar, aber wenn ich den anschließe dann Bootet der nicht durch. Sondern er fängt an zu Booten dann kommt schwarzer Bildschirm, dann drücke ich den Knop und er Bootet weiter. Aber dann habe ich nur noch einen blauen Bildschirm. Ich schließe das mal an und mache ein kurzes Video

 

@zuendlER84

So habe den Fehler bei mir gefunden ich habe statt eines Tasters einen Schalter angeschlossen ...... Wer lesen kann ist doch klar im Vorteil. Habe jedoch gerade festgestellt, das man im manuellen Modus zünden kann auch ohne vorher die Zündmodule zu suchen.
Ist das so gewollt ? War gerade etwas verdutzt, dachte das geht immer nur wenn er ein Modul gefunden hat und man auch sieht das es auch scharf geschaltet ist.

 

Ja, das ist so gewollt. Es gibt ja keinen Zündplan, anhand dessen das Programm weiß, welche Slaves vorhanden sein müssen. Daher habe ich es so eingestellt, dass man hier komplett frei ist.

 

Ok das bedeutet aber das ein anderer der im manuellen Modus unterwegs ist meine Boxen nicht ansteuern kann. Sorry für die Fragen aber Sicherheit ist ja das A und O

 

Kann er aufgrund des AES-Schlüssels ja schon nicht

 

Wer deinen AES-Schlüssel nicht kennt, kann nicht auf deine Boxen zugreifen.

Das ist unabhängig vom Modus, denn sobald die Daten am Funkmodul sind, gibt es ja keinen Unterschied mehr, welcher Modus eingestellt ist. Die Datenpakete sehen immer gleich aus.

 

OK Perfekt
Ach noch was zum neuen Images es läuft sehr stabil und auch bei einem Musikfeuerwerkt mit einer Länge von knapp 8 Minuten ohne Probleme. Finde es läuft nun doch um einiges runder. Auch wenn man zwischen den Zündboxen hin und her Switcht ......
TOP

 

So nach einigen Tests heute habe Ich doch festgestellt das meine Powerbak trotz 2A Ausgang den Raspberry nicht zu 100% mit Strom versorgen kann. Es kommt immer zum Start der Show zu einer kurzen Verzögerrung. Mache Ich jedoch einen Akku mit 12 Volt und 3,5 aH mit einem Step Down dran, dann läuft es ohne Probleme,
Was für Powerbanks habe ihr denn so verbaut ?

 

Bei mir ist eine Anker Powercore irgendwas mit 20000 mAh und 2,4 A pro Ausgang dran. Läuft relativ stabil bislang.

 

Ich hab die Anker PowerCore II 6700mAh verbaut. Muss aber erst mal noch richtig testen, um mehr dazu sagen zu können.

 

Die habe ich in meiner kompakten Version, die ich fürs Zünden verwende, auch. In der offenen Kiste, die ich für die Entwicklung nehme, habe ich etwas Größeres, eine Goobay 63533.

Nadelöhr ist tatsächlich oft das Micro-USB-Kabel, weil die Hersteller da gar nicht genug Kupfer sparen können, außerdem sind wohl auch die Platinen des Raspberry Pi nicht allzu gut optimiert hinsichtlich der Leitungswiderstände zu den USB-Anschlüssen. Für die USB-Zuleitung des Displays auf meiner Entwicklungskiste habe ich daher das Kabel vom Pi zum Display abisoliert, das rote Kabel (+5 V) gekappt und beim schwarzen GND-Kabel Kupfer freigelegt. Von einem der USB-Anschlüsse der Powerbank habe ich dann die 5V mit dem "Displayende" verbunden und GND mit der freigelegten Stelle, so dass das Display zwar weiterhin die Daten vom Pi bekommt, aber den Saft direkt aus der Powerbank, also so:


Damit läuft das Display meines Erachtens deutlich stabiler und ich messe auch auf der Aufsteckplatine konstant über 4,75 V (minimal zulässige USB-Spannung laut Definition).

Um Verwirrung zu vermeiden: Die Versorgung des RasPi über einen weiteren Anschluss der Powerbank ist hier nicht eingezeichnet, die gibt es natürlich auch noch.

 

Hallo Zusammen, ich habe heute bei Reichelt eine Aufsteckplatine für den Raspberry entdeckt und stelle mir nun die Frage ob diese eventuell Sinn machen würde ? Hier mal der Link

RASP STROM PI 2 - Raspberry Pi - Der StromPi 2

 

Ich habe gerade auf das neue Image geupdated und dann gleich mal meinen Zündplan ausprobiert. Als ich den Plan ausgewählt habe, kam folgende Ausgabe. Scheint ein Fehler mit dem Plan zu geben, sagt "Grund 4" etwas aus?



Den Zündplan habe ich mit Pyroignitio Control V1.4.4 erstellt.

 

Exception-Grund 4 ist eine Verletzung des 100-ms-Zündabstand-Kriteriums. Im Zusammenspiel mit einem neuen Codeteil führt das zu einem Absturz, habe ich gerade nachvollzogen. Sollte so natürlich nicht passieren und wird gefixt, wenn in deiner ZPL aber die Zündabstände stimmen, dürfte auch alles geladen werden.

Nachtrag: Bugfix ist ins Repository hochgeladen. Grund ist bei Zeile 601 in der main.py:

usedSlavesOriginal = list(self.arrUsedSlaves)

muss zu

if(isinstance(self.arrUsedSlaves, list)):
usedSlavesOriginal = list(self.arrUsedSlaves)
else:
usedSlavesOriginal = []

werden - am Beginn der ersten und dritten Zeile müssen acht Leerzeichen stehen, vor used in Zeile 2 und 4 zwölf.

 

Danke für die schnelle Antwort. Ich war parallel schon auf die selbe Idee gekommen und hatte den Zündplan mit dem schemecheck überprüft. Waren tatsächlich noch zwei 100ms Verletzungen drin. Das passte ja zu den zwei Grund 4 Zeilen.
Ausgebaut und... wieder abgestürzt. Diesmal nur noch eine Zeile mit Grund 4, schemecheck sagt alles ok. Auch manuell habe ich keine Verletzung mehr gefunden.

Hane jetzt einfach mal alle 100ms Timings auf 102ms gesetzt, allerdings will jetzt gerade das Flashen des Images (um auf Default zurück zu kommen) nicht mehr.

 

Kannst du mir deine Showfiles mal gezippt per PN zukommen lassen? Dann gehe ich der Sache auf den Grund.

Spontan würde ich noch schauen, ob es womöglich an den ersten beiden Cues liegt. Beim Import wird bei jedem Cue 70 ms Delay abgezogen, d.h. er rutscht auf der Timeline nach vorne. Wenn aber Cue 1 weniger als 70 ms vom Nullpunkt entfernt liegt, rutscht er nur auf 0 und Cue 2 könnte dann nach Subtraktion des Offsets auf einmal zu nahe an Cue 1 liegen. Das ist im Schemecheck nicht berücksichtigt.