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

Kurzes Update: Ich habe bis jetzt noch alles versucht um die Bootloder auf die Boxen zu bekommen. Selbst mit einem AVRLight den Ich noch hatte keine Chance. Getestet an 6 Zündkoffer, leider ohne Erfolg. Von daher null Ahnung wo der Fehler liegen kann, aber dieses Jahr werde ich leider auf diese Anlage verzichten müssen. Sehr Ärgerlich nach dem man so viel Zeit für den Zusammenbau gesteckt hat, ,,,,,, So werde nun den Rest vom Feuerwerk aufbauen zum Glück regnet es gerade nicht .......

 

Puh, da ist man einen Tag offline, kommt heim, schaut, was sich in den letzten 24 Stunden getan hat und stößt dann auf das hier.

Zunächst hat mir natürlich unser pyro-michel leid getan und ich habe mich ziemlich bescheiden gefühlt, weil mir Zweifel kamen, ob ich irgendwo etwas übersehen oder verbockt habe, was die Software unbrauchbar hätte machen und ihm den Tag versauen können.

Daher war meine Reaktion natürlich, umgehend meinen raspEasyFire zu starten. Ich habe ihn noch einmal auf das letzte Image zurückgesetzt, dann damit die Zündboxen mit der letzten Firmware versehen (funktioniert), AES-Keys synchronisiert (funktioniert), Kabelverbindung getrennt, Slave-IDs gesetzt (funktioniert) und die Testshow mit zwei Slaves durchlaufen lassen (funktioniert). Ich kann also guten Gewissens sagen, dass die von mir zur Verfügung gestellte Software das tut, wofür ich sie geschrieben habe - Erleichterung! Für die von anderen Leuten gebaute Hardware kann ich natürlich keine Garantie übernehmen, aber kann hier schon einmal diejenigen beruhigen, die vielleicht ins Zweifeln gekommen sind, ob sie der Anlage vertrauen können.

Was nun die aufgetauchten Probleme angeht: "Keine Boxen mehr zu finden" klingt zu 99,9% danach, dass der raspEasyFire auf einmal mit einem anderen AES-Key gearbeitet hat als die Boxen. Firmwareupdate gemacht und vergessen, wieder den eigenen Key einzustellen?

Was den Bootloader angeht: Wenn der einmal auf dem Controller drauf ist, dann bringt man ihn nur mittels Programmer wieder runter. Ansonsten läuft der bei jedem Neustart zuverlässig an, sofern man nicht mittels Überspannung, Hitze oder sonstige Gewalteinwirkung den Controller zerstört hat. Sicherlich müsste man ihn auch per Programmer immer wieder neu schreiben können, aber wenn das nicht funktioniert hat, gibt es vermutlich ein Hardwareproblem außerhalb meiner Reichweite (Programmer, Platine, Controller).

Zu guter Letzt wundere ich mich aber auch, warum ich Anfang der Woche sage, dass bis zum Freitag die Show schon einmal im Trockenlauf komplett getestet sein sollte, damit man auf auftretende Fehler noch reagieren kann, ich nichts höre und dann auf einmal in der Nacht vor der Show noch einmal alles auf links gedreht und hier ein großes Fass aufgemacht wird.

 

So hier mal ganz sachlich zum Sachverhalt. Die Show stand bis Freitag Abend Fix, als Plötzlich 2 Zündkoffer nicht mehr gefunden wurden. Ich habe zuerst die Funkmudule getauscht, jedoch ohne Erfolg. Also habe Ich die restlichen Koffer mittels dem Rasp umgeändert. Ich habe also zwei Platinen komplett neu bestückt und wollte über den Rasp mittels AVRMK2 den Bootloader aufspielen jedoch ohne Erfolg und ab da nahm das Schicksal seinen Lauf, auch am PC könnte der Bootloader nicht auf die Boxen gespielt werden. Auch der Tausch des ATMEGA brachte keinen Erfolg, und plötzlich ging die Zeit wie im Flug vorbei und Ich musste reagieren, also blieb mir nur das Feuerwerk per Hand zu zünden. Ich habe hier im Forum niemanden einen Vorwurf oder ähnliches gemacht. Ich habe meine Situation geschildert in der Ich war, aber wenn das nicht gewünscht ist dann sorry.

 

@zuendlER84 An dieser Stelle ein großes Danke für den anhaltenden Support und die Arbeit rund um das Projekt .

Bei mir hat sich in der letzten Stunde, nachdem ich meine dritte Zündbox fertiggestellt hatte, auch ein Problem aufgetan . Zum Testzünden hatte ich mir mal kleine 3mm LEDs mit 1k Ohm Widerstand gebastelt. Als ich die neue Box vorhin in Betrieb genommen hatte, ist mir aufgefallen, dass diese bei der sekündlichen Widerstandsmessung wesentlich heller Blinken als bei den beiden anderen Boxen. Ich gehe deshalb davon aus, das dort aus irgendeinem Grund mehr Spannung/Strom anliegt/fließt. Mit einem normalen Multimeter kann ich die kurze Spitze ja leider nicht messen, deshalb bin ich mir nicht sicher. Der Stepup ist korrekt auf 22,5 V eingestellt und ich konnte bisher weder ein falsch platziertes Bauteil, noch eine Lötbrücke o.Ä. ausmachen. Werde morgen nochmal alles durchgehen und auch mal mit einem Zünder testen, ob dieser ggf. schon bei der Messung auslöst. Hast du in der Zwischenzeit vielleicht schon eine Idee?

 

@frazzle Ich antworte mal im El-Fueradoro-Thread, weil das ja nichts mit dem raspEasyFire zu tun hat.

@pyro-michel Ich bin sehr dankbar, wenn Leute hier ihre Erfahrungen schildern, weil mir das Projekt und die Zufriedenheit der Nachbauer wirklich wichtig sind. Daher rufe ich ja auch immer wieder auf, dass getestet und berichtet werden soll, um Fehler zu finden und auszumerzen. Wenn z.B. auf einmal davon die Rede ist, dass eine Funktion bei dir "noch nie geklappt hat", dann wundert es mich, warum das jetzt zum ersten Mal zur Sprache kommt. Zudem wäre gut gewesen zu wissen: Was genau hast du getan, um die Slaves der Boxen zu ändern? An welcher Stelle lief etwas schief? Was ist genau passiert? Wie haben sich die Boxen bei einem Neustart danach verhalten? Hast du die Boxen, die nicht mehr gingen mal isoliert gesucht, um auszuschließen, dass Unique-IDs doppelt vergeben waren? Solche Infos wären hilfreicher gewesen als die Schilderung eines wilden Aktionismus ("alles versucht!"), mit dem man üblicherweise mehr kaputt macht als man retten kann.

 

@zuendlER84 ich bin sicher, pyro-michel macht dir keinen Vorwurf. Er ist der ganzen Sache und deiner Leistung doch sehr zugetan. Schief gehen kann immer Mal was.

Du musst dir auch keinen Vorwurf oder ähnliches machen, dein Support ist dermaßen gut hier im Forum, es ist aber immer noch ein Hobby Projekt. Der Gefahr eines sporadischen Fehlers sollte sich damit jeder Selbstbauer bewusst sein. Oft auch selbst verursacht.

Wenn ich in seiner Situation gewesen wäre hätte ich auch viel probiert um die Boxen ans laufen zu bekommen.

Vielleicht kommt ja auch nach dem gestrigen Stress noch eine genauere Fehler Beschreibung um dir die Evaluierung leichter zu machen.

LG und auch von mir ein Daumen hoch für euren Einsatz!!

 

Moin

@pyro-michel

Wenn Du den Bootlader nicht auf den AVR bekommst würde ich mal schauen ob der Programmer einen sauberen Reset macht bzw. mal testweise 10k nach Vcc schalten und schauen was passiert .

MFG Jens

 

Guten Morgen an alle, habe bis jetzt mitgelesen und wollte mich auch mal dazu äußern.
Ich habe den Raspi schon länger fertig und habe vor einigen Tagen selber versucht den bootloader auf die Empfänger zu bringen.
Das Ende vom Lied er hängt sich im Firmwaretransfer auf, der bootloader ist drauf und der Atmega ist hinüber. Am PC funktioniert es wunderbar und am Raspi leider nicht.
PS setzte jetzt alle ICS auf Sockel geht einfacher zu tauschen.
Lg aus Craalse

 

Danke für den Hinweis, da gab es wirklich noch einen Fehler!

Ich hatte die Kommandozeile vom Bootloader meines Steppers kopiert und vergessen, die LFUSE-Einstellung anzupassen, welche die Taktquelle für den Atmega einstellt. Die bisherige Einstellung stellt die Taktquelle des Atmega auf "External Clock" statt - wie es sein sollte - auf "External Full-swing Crystal". Damit läuft der Atmega auf der Platine nicht an, man spricht von "verfust".

Man kann den Chip aber wieder beleben, indem man ein Taktsignal (bieten manche Programmer, z.B. mein All-AVR an), an den Pin XTAL1 anlegt und die richtigen Fuseeinstellungen schreibt. Der LFUSE-Wert muss F7 lauten, nicht E0. Mea culpa!

 

Moin Zuendler,
ist es denn momentan notwendig auf den atmega per USB die neue Software aufzuspielen? Sonst würde ich es sogar bei der momentanen Software beibelassen und nur eine neue Img Datei auf den Rasp aufspielen. Sind diese beiden denn kompatibel miteinander?

 

Das Aufspielen per USB ist nicht betroffen, es ging alleine um das Flashen des Bootloaders via raspEasyFire, das von dem Bug betroffen war. Wenn man einmal in der Lage war, per UpdateLoader oder raspEasyFire eine Firmware über die serielle Schnittstelle aufzuspielen, dann geht das auch weiterhin.

Die letzten Versionen des raspEasyFire (seit dem 28.11.) verlangen für die Übermittlung der Widerstandsdaten bei der v3 ein neues Format, das ich gleichzeitig in die El-Fueradoro-Firmware eingefügt habe. Es dürfte aller Wahrscheinlichkeit nach kein großes Problem im Sinne von Absturz geben, wenn man eine alte El-Fueradoro-Version mit einer neuen raspEasyFire-Version am Laufen hat, allerdings wird das Widerstandsfenster keine sinnvollen Werte liefern, weil es an einer bestimmten Stelle der Nachricht entweder eine 16 oder eine 32 erwartet. Ich habe noch nicht geprüft, was passiert, wenn man am Kanal 1 genau 16 oder 32 Ohm hängen hat, aber vermutlich wird dann auch einfach Quatsch angezeigt.

 

Guten Morgen zusammen, so das Feuerwerk ist gut gelaufen und dank der vielen freiwilligen Helfer war der Abbrenner auch sehr schnell wieder sauber

Zu den letzten 2 Tage kann Ich nur sagen WOW was für ein Stress, jedoch habe Ich von gestern auf heute gerade mal 1 Stunde Augenpflege gemacht. Aber nun geht die Fehlersuche in die nächste Runde.
Fakt ist das Ich hier in keinster Art und weise die Arbeit von Zuendler in Frage stelle oder gar Kritisiere ! Er macht einen super Job hier, egal ob Software oder Hardware, denn ohne seine Hilfe hätte Ich nie eine 32Kanal Erweiterung hinbekommen.

Ich werde nun mit Zuendler versuchen nachzustellen wie und was da genau passiert ist, sobald es hier weitere Infos gibt schreibe Ich diese hier natürlich. Es ist nach wie vor ein sau starkes Projekt, und wo gehobelt wird fallen auch Späne.
Es ist jetzt so wie es ist, und nun beginnt die Fehler suche, genau wie bei einem Feuerwerk wenn der eine oder andere Effekt nicht zündet.

Es ist in den letzten Tage einfach alles zusammen gekommen, aber so langsam legt sich alles um sachlich an die Sache zu gehen und den Fehler zu finden.

Grüße und einen schönen dritten Advent
Michael

 

Schön, das es trotzdem gut gelaufen ist.
Ich kenne das Gefühl bzw. die Situation: Letztes Silvester ist mir meine selbsgebaute Anlage beim Test durch Verpolung abgeraucht und das am 30.12. Ich hab gedacht ich dreh am Rad... Naja blieb dann nichts groß übrig als kurzer Hand die Nagelbrett-Methode anzuwenden. War dann nochmal extrem stressig und ein mächtiger Kabelsalat, aber letztendlich trotzdem eins meiner besten Silvester. Davor hab ich das aber natürlich anders gesehen .

 

Servus Leute ich hab mal wieder ein anderes Problem und zwar folgendes : Habe meine fertigen Koffer mal im Garten verteilt um zu testen wie alles funktioniert.
Nachdem ich keinen einzigen per Slavesuche gefunden habe, habe ich ein Update des Raspi gemacht. Danach hat nichts mehr funktioniert Raspi ist andauernd abgestürzt.
Habe jetzt ein Image vom September drauf und damit das Problem das ich immer nur einen Empfänger finde. Starte ich die Suche neu wird ein anderer gefunden oder halt der selbe. Sind alle mit ID vergeben also 1 2 unsoweiter. Funkmodule habe ich auch proforma mal getauscht mit neuen aber selbes Problem.

 

Bist du sicher, dass überall die AES-Keys und IDs stimmen? Bei mir hingen bisher immer alle Probleme mit Empfang, Suche, etc. damit zusammen. Dass du nur eine Box findest hört sich für mich so an, als würden Unique IDs mehrfach vergeben sein.

 

Ich würde die Boxen mal nach und nach mittels USB verbinden und neu anlernen. Denke auch das da mit der Zuordnung nicht stimmt. Ich habe mir heute einen neuen AVR bestellt, ich bin leider erst einmal außer Gefecht

 

Also ich habe das Prozedere 8 mal durch. Es haben alle Slaves unterschiedliche Unique IDs und den selben AES Schlüssel. Sind alle nochmal neu programmiert worden und alles 5mal überprüft.
Ich finde jeden Slave einzeln aber wenn 2 oder mehr in Betrieb sind finde ich immer einen ab und an mal alle jeh nach Glück.

 

Die Datei RaspEasyFireRFM69.py sollte eigentlich im Ordner /home/pi/raspEasyFire3/module vorhanden sein, ist das bei dir nicht der Fall?
Außerdem bitte den richtigen Thread benutzen. Wenn es eindeutig um raspEasyFire geht, hat das nichts im El-Fueradoro-Thread verloren.


So also diese Datei gibt es bei mir nicht. Ich lade jetzt noch einmal das komplette Image runter und versuche es dann noch einmal. Über den RaspUpdater har es nicht geklappt

 

Im Image und im Repository ist die Datei zumindest vorhanden. Ich hoffe, dass das Problem durchs Neuaufspielen verschwinden wird.

 

das neue Image ist aufgespielt, aber ich kann leider trotz eines neuen AVR ISP kein Image brennen. Ich bestückt heute noch einmal eine Platine und dann ist fertig bin wohl doch zu blöd für solche Sachen

 

Hey Leute habe gerade eben mal meine Anlage mit 8 Slaves in Betrieb genommen.
Obwohl kein Slave scharf ist kann ich im Auto Modus die Show starten.
Lg
Danie

 

Steht die Option "Fehlende Slaves ignorieren" auf "Nein"? Wenn ja, hast du irgendwann in den letzten paar Tagen ein Update via Internet gemacht? Es kann sein, dass kurzzeitig im Repository ein Stand online war, bei dem dieser Fehler aufgetreten ist. Inzwischen sollte es nicht mehr so sein.

 

Hey Felix Slave ignorieren steht auf Nein.
Und Updates habe ich auch keine gemacht.

 

Das heißt du bist auf dem Stand des Images vom 16.12.?