Handhabung & Technik El Fueradoro - Funkzündanlage mit Interface

Dieses Thema im Forum "Effekte, Feuerwerkskörper, Technik, Hilfsmittel" wurde erstellt von jordanatic, 15. Januar 2015.

  1. Moin, wollte gestern ebenfalls das Update über den raspeasy vollziehen. Da ich dies zum ersten Mal machte und sonst immer über PC per USB Kabel habe ich die Box wieder per USB verbunden. Problem hierbei: Beim Updaten ist mein Raspberry gefreezed(weißes Bild). Nach etwa 5 Minuten habe ich den Raspeasy vom Strom getrennt. Daraufhin konnte ich den Empfänger per Slave Suche nicht mehr finden. Nun musste ich diesen per PC anschließen und den kompletten Bootloader neu aufspielen und wie oben schon erwähnt auhh eine neue Firmware.
    Aufgrund von Testzwecken habe ich den Empfänger und den Raspeasy erneut per USB miteinander verbunden und den Vorgang wiederholt->selbes Symptom. Also grundsätzlich bleibt bei mir zu sagen, dass das Verbinden per USB von Raspeasy zu Empfänger den ganzen Bootloader zerschiest, was zur Folgen hat, dass ich diesen neu flaschen kann.

    Das sind so die Ergebnisse von gestern.
     
  2. Moin zusammen, für mich stellen sich folgende Fragen:
    A: Warum bootet der Rasp nach dem Update welches ichbüber den Rasp ziehe nicht mehr.
    B: Beim schreiben der Firmware hängt sich der Rasp nach 10 min auf.

    Könnte es sein, das manche einen Rasp2 , Rasp3, Rasp3b oder gar Rasp3b+ haben? Gibt es hier eventuell Unterschiede?

    Das gleiche beim ISP? Den AVR ISP MK2 gibt es auch in verschiedenen Ausführungen.....

    Das sind nur gerade so meine morgendliche Gedanken dazu.....
     
  3. Wäre auf jeden Fall eine Möglichkeit, dass hier Kompatiblitatsprobleme entstehen, obwohl ja eigentlich nur die Hardware der jeweiligen Komponenten anders ist. Echt kurios. Also für mich bleibt der Entschluss, dass ich weiterhin alles über PC machen werde, sei es Firmware Update o. Ä.
     
  4. #454 zuendlER84, 17. Dezember 2019
    Zuletzt bearbeitet: 17. Dezember 2019
    Aufgrund der vielen geschilderten Probleme hier mal ein schnelles Video in einem Take mit vielen "Ähs", Wacklern und Schnauferei, wie das ganze eigentlich ablaufen sollte:


    Wenn Dinge wie Absturz, Freeze oder sonstige Unannehmlichkeiten passieren, ist das ein Problem eurer Hardware (Speicherkarte, Stromversorgung, Programmierkabel, Treiber ...).
     
    Chrigu, komp, xXBamBiXx und 3 anderen gefällt das.
  5. Danke für das Video, aber genau das meinte Ich dein ISP ist ein ganz anderer den Ich habe und das obwohl Du auch den AVRMKII auswählst. Daher die Frage ob da die Treiber oder Befehle gleich sind ?
    Denn Ich mache es genau so wie Du auch, nur bei mir klappt es nicht. Ich schaue mal das Ich auch ein Video mache.
     
  6. Der AVRISP MKII von Atmel ist einer der Urväter der Programmiergeräte für die AVR-Mikrocontroller, entsprechend teuer hat Atmel ihn sich auch bezahlen lassen, bevor er irgendwann komplett vom Markt verschwunden ist. Sein Funktionsprinzip hat eine Vielzahl von Herstellern in neue Hardware gegossen und bringt die Dinger jetzt mit dem Hinweis, dass sie kompatibel zum AVRISP MKII sind und genauso angesteuert werden können, auf den Markt. Mein ALL-AVR von Diamex (so hieß er zumindest noch, als ich ihn gekauft habe, inzwischen nennen sie ihn AVR-Prog) löst dieses Versprechen ein, ob andere das auch tun, ist aus der Ferne nicht zu beurteilen.

    Festzuhalten ist, dass der jetzt eingebaute Flash-Befehl für einen AVRISP MKII oder einen kompatiblen Nachbau die Firmware und den Standard-EEPROM korrekt überträgt, wenn alle anderen Umstände passen.
     
    pyro-michel gefällt das.
  7. Ja
     
  8. Perfekt danke, wäre vielleicht als Kaufempfehlung in der Anleitung zu erwähnen. Ich glaube derzeit steht in der Material Liste gar kein ISP Gerät drin. So dann warte Ich nun auf das Päckchen von Amazon.
     
  9. In der Materialliste stehen auch kein Lötkolben und -zinn, kein Multimeter, kein Heißluftfön, kein PC und fatalerweise auch kein Stromanschluss drin ;). Gewisse Dinge gehören einfach zur Ausstattung dazu. Andere Nachbauer haben sich den ganzen Stress mit den Programmern erspart und mir einfach einen Schwung Mikrocontroller mit der Post geschickt, damit ich ihnen den Bootloader draufbrenne. Das muss jeder selbst wissen, wie er das handhabt.
     
    komp gefällt das.
  10. Moin
    Das Video vom zuendlER84 hat mich endgültig wieder angefixt :) ich werde mir jetzt doch noch so einen schönen Koffer mit dem RaspEasyFire bauen :good:

    Zwei Fragen:
    RaspEasyFire funktioniert noch mit den uralt El Fueradoro Zündboxen aus dem Jahr 2016 ?
    Bevor ich jetzt das alte Eisen3chlorid & den Belichter wieder herauskrame ,hat jemand noch eine Platine für den Raspberry und das Funkmodul übrig / zu verkaufen ?

    MFG Jens
     
  11. Hallo @tux1975 , wenn Du Platinen brauchst oder auch den 40PIN etc einfach eine PN an mich. Natürlich habe Ich auch npch die RFM69CW sowie SMA Platinenbuchen etc.

    Grüße Michael
     
  12. @zuendlER84 Klar Lötkolben etc. sollte schon vorhanden sein. Ich dachte nur weil Du ja damit sehr gute Erfahrungen mit dem ISP gesammelt hast. Daher dachte Ich nur daran. Heute bin Ich wieder voller Tatendrang und freue mich schon auf den neuen Programmer.....
     
  13. Ja, die alten Boxen können immer noch verwendet werden, man muss ihnen nur eine aktuelle v1/v2-Software verpassen.
     
  14. Ok, ich würde mal folgendes versuchen:
    - Den IRF4905 komplett ausbauen, so dass nur die drei Lötpunkte übrig bleiben
    - Platine mit Saft versorgen
    - v3-Firmware neu aufspielen, nur um ganz sicher zu sein, dass man mit der richtigen arbeitet
    - Messen, welche Spannung am untersten der drei Lötpunkte (wenn man die großen Elkos als "oben" bezeichnet) gegen Masse (z.B. IN- oder OUT- am Step-Up-Modul) anliegt, das ist die Gate-Spannung des P-FET. Man würde hier im Nicht-Zündfall permanent irgendwas über 20 Volt erwarten, damit der P-FET sperrt. Zusätzlich auch noch die Spannung zwischen dem obersten und untersten der drei Lötpunkte (Source-Gate-Spannung) messen, die sollte nahe 0 V liegen.
    - Zusätzlich kann man auch mal die Spannung am Pin 26 des Atmega (3. Pin von oben auf der rechten Seite) gegen Masse messen. Hier sollten im Normalfall 0 V anliegen.

    Stimmt die Spannung am Gate bzw. zwischen Source und Gate nicht, dann ist irgendwo in der Treiberschaltung ein Problem. Liefert der Mikrocontroller konstant 3,3 V, muss ich noch einmal in den Code schauen. Oder laufen deine drei Boxen sicher auf der gleichen Firmware und das Problem tritt nur bei einer auf?
     
    frazzle gefällt das.
  15. Eventuell sind es auch die Bauteile D17 und D24 oder U2 nicht richtig verbaut ?
    Wäre eventuell noch ein Lösungsansatz
     
    frazzle gefällt das.
  16. Zumindest die beiden Dioden kann man ausschließen: D24 kann damit nichts zu tun haben. Selbst wenn die Diode verpolt wäre, würde der 100k-Widerstand den Strom so begrenzen, dass kein Anzünder auslöst. D17 scheidet ebenfalls aus, denn wenn die in die andere Richtung zeigt, fließt verringert das den Strom durch den Anzünder eher noch, weil dann von oben nichts mehr kommen kann.
     
    frazzle und pyro-michel gefällt das.
  17. Also ich habe mir zunächst mal eine minimale Programmierplatine wie in Post #444 beschrieben gebastelt.

    Eine zweite SD-Karte geschnappt, aktuellstes Image (laut Datumscode vom 16.12.) aufgespielt und innerhalb der RaspEasyFire Oberfläche nochmal Updates gezogen und Hexfiles aktualisiert.

    Firmware über RaspEasyFire auf den Atmega geflasht. Lief denke ich alles glatt. Alle LEDs leuchteten einmal auf nach Ende des Schreibvorgangs, Bootsequenz verlief auch normal, Grüne LED leuchtet dann dauerhaft (normal da kein RFM auf der Minimalplatine (?))

    Nebenbei ist mir hier noch aufgefallen, dass wenn ich beim AES-Key Abgleich versuche den Key auszulesen folgender Fehler kommt:
    Traceback (most recent call last):
    File "main.py", line 764, in <module>
    MainApp().run()
    File "/usr/local/lib/python3.6/site-packages/kivy/app.py", line 855, in run
    runTouchApp()
    File "/usr/local/lib/python3.6/site-packages/kivy/base.py", line 504, in runTouchApp
    EventLoop.window.mainloop()
    File "/usr/local/lib/python3.6/site-packages/kivy/core/window/window_egl_rpi.py", line 94, in mainloop
    self._mainloop()
    File "/usr/local/lib/python3.6/site-packages/kivy/core/window/window_egl_rpi.py", line 89, in _mainloop
    EventLoop.idle()
    File "/usr/local/lib/python3.6/site-packages/kivy/base.py", line 342, in idle
    self.dispatch_input()
    File "/usr/local/lib/python3.6/site-packages/kivy/base.py", line 327, in dispatch_input
    post_dispatch_input(*pop(0))
    File "/usr/local/lib/python3.6/site-packages/kivy/base.py", line 233, in post_dispatch_input
    listener.dispatch('on_motion', etype, me)
    File "kivy/_event.pyx", line 707, in kivy._event.EventDispatcher.dispatch
    File "/usr/local/lib/python3.6/site-packages/kivy/core/window/__init__.py", line 1402, in on_motion
    self.dispatch('on_touch_down', me)
    File "kivy/_event.pyx", line 707, in kivy._event.EventDispatcher.dispatch
    File "/usr/local/lib/python3.6/site-packages/kivy/core/window/__init__.py", line 1418, in on_touch_down
    if w.dispatch('on_touch_down', touch):
    File "kivy/_event.pyx", line 707, in kivy._event.EventDispatcher.dispatch
    File "/usr/local/lib/python3.6/site-packages/kivy/uix/screenmanager.py", line 1191, in on_touch_down
    return super(ScreenManager, self).on_touch_down(touch)
    File "/usr/local/lib/python3.6/site-packages/kivy/uix/widget.py", line 549, in on_touch_down
    if child.dispatch('on_touch_down', touch):
    File "kivy/_event.pyx", line 707, in kivy._event.EventDispatcher.dispatch
    File "/usr/local/lib/python3.6/site-packages/kivy/uix/relativelayout.py", line 288, in on_touch_down
    ret = super(RelativeLayout, self).on_touch_down(touch)
    File "/usr/local/lib/python3.6/site-packages/kivy/uix/widget.py", line 549, in on_touch_down
    if child.dispatch('on_touch_down', touch):
    File "kivy/_event.pyx", line 707, in kivy._event.EventDispatcher.dispatch
    File "/usr/local/lib/python3.6/site-packages/kivy/uix/widget.py", line 549, in on_touch_down
    if child.dispatch('on_touch_down', touch):
    File "kivy/_event.pyx", line 707, in kivy._event.EventDispatcher.dispatch
    File "/usr/local/lib/python3.6/site-packages/kivy/uix/widget.py", line 549, in on_touch_down
    if child.dispatch('on_touch_down', touch):
    File "kivy/_event.pyx", line 707, in kivy._event.EventDispatcher.dispatch
    File "/usr/local/lib/python3.6/site-packages/kivy/uix/widget.py", line 549, in on_touch_down
    if child.dispatch('on_touch_down', touch):
    File "kivy/_event.pyx", line 707, in kivy._event.EventDispatcher.dispatch
    File "/usr/local/lib/python3.6/site-packages/kivy/uix/behaviors/button.py", line 151, in on_touch_down
    self.dispatch('on_press')
    File "kivy/_event.pyx", line 703, in kivy._event.EventDispatcher.dispatch
    File "kivy/_event.pyx", line 1214, in kivy._event.EventObservers.dispatch
    File "kivy/_event.pyx", line 1098, in kivy._event.EventObservers._dispatch
    File "/usr/local/lib/python3.6/site-packages/kivy/lang/builder.py", line 64, in custom_callback
    exec(__kvlang__.co_value, idmap)
    File "<string>", line 49, in <module>
    File "/home/pi/raspEasyFire3/module/RaspEasyFireMatchKey.py", line 161, in get_box_key
    ausgabe=self.serialtransfer(ser, '\raeskey\r')
    File "/home/pi/raspEasyFire3/module/RaspEasyFireMatchKey.py", line 276, in serialtransfer3
    answ2.append(x.decode().replace('\r', '').replace('\n', ''))
    UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0: invalid start byte
    Was vermutlich auch auch normal ist, wenn ich so darüber nachdenke. Der Key müsste ja im RFM stehen (?), welche in diesem Szenario eben nicht vorhanden war.

    Den Atmega wieder auf die Problem-Platine gesetzt und den IRF4905 ausgelötet.

    Beim Messen erhielt ich folgende Werte:
    • Unterster Lötpunkt (A) <=> Masse: 0V
    • Unterster Lötpunkt (A) <=> oberster Lötpunkt (B): 22,6V
    • Pin 26 (C) <=> Masse: 0V
    Um sicherzugehen, dass meine MEsspunkte richtig waren, hab ich sie hier nochmal markiert:
    messpunkte.png

    Also wird wohl noch ein Problem mit der Treiberschaltung auf der Platine sein...

    Müsste eigentlich die gleiche gewesen sein. Hatte sie am 28.11 geflasht und mir da den aktuellsten Stand gezogen.
     
    zuendlER84 gefällt das.
  18. #469 zuendlER84, 18. Dezember 2019
    Zuletzt bearbeitet: 18. Dezember 2019
    Danke für den Test, damit sieht man schon klarer: C auf 0 V passt, B auf 22,6 V auch, aber dass A auf 0 V liegt, ist das Problem. Damit wird der IRF4905 komplett durchgesteuert. Und es liegt permanent die Zündspannung an den "positiven" Klemmen.

    Die naheliegendste Erklärung dafür wäre ein Kurzschluss zwischen dem linken und mittleren Bein von Q20, auch wenn du das schon überprüft hast, bzw. ein defekter Q20 oder Q18. Eine andere Variante, um hart 0 V am Gate des IRF4905 zu bekommen, sehe ich derzeit nicht.

    Der Abbruch beim Versuch des Key-Auslesens ist seltsam. Der Wert kommt aus dem EEPROM des Atmega, daher darf das fehlende Funkmodul nicht stören. Das Problem scheint im Decoding zu liegen, da kommen offenbar Zeichen über die Leitung, mit denen der Raspi nichts anfangen kann.
     
    frazzle gefällt das.
  19. Um die Sache abzurunden, kann ich noch empfehlen, einen Reset-Taster vorzusehen.

    Wenn der Bootloader alleine auf dem Controller ist oder zusammen mit einer funktionierenden Firmware, dann kann jederzeit eine neue Firmware geschrieben werden, weil die Software den Controller resetten und in den Bootloader bringen kann. Ging jedoch beim Aufspielen der Firmware etwas schief, funktioniert der Software-Reset nicht und man muss den Controller anderweitig in den Reset zwingen.

    Hierzu den unteren Anschluss des Reset-Pullup R15, der direkt mit dem linken oberen Pin des Atmega verbunden ist und GND (z.B. das Lötauge TEST2) über einen im ungedrückten Zustand offenen Taster verbinden. Damit kann man nun per Knopfdruck einen Hardware-Reset durchführen und hat danach eine Sekunde Zeit ein Firmwareupdate zu triggern. Es sollte aber auch funktionieren, zuerst das Firmwareupdate zu starten und dann den Resettaster kurz zu betätigen, denn der Updater versucht sein Glück eine längere Zeit lang.
     
    frazzle gefällt das.
  20. Guten Morgen allerseits. Die Lötarbeiten sind soweit fertig, jedoch stehe ich nun auf dem Schlauch.
    Ich habe auf dem Pi gestern das Image aufgespielt, was funktioniert. Danach mit dem USBasp den Bootloader auf die Zündbox übertragen, scheint auch normal durchgelaufen zu sein. Anschließend die Firmware übertragen, alle LEDs blinken kurz auf. Nun habe ich das Problem, dass ich den AES Key der Box nicht auslesen kann. Bei der Abfrage leuchtet die gelbe LED (Zündbox) kurz auf. Im Ruhezustand blinken an der Box einmal kurz die gelbe und danach alle vier nacheinander.
    Ich hoffe, jemand kann mit diesen Infos was anfangen und mir weiterhelfen. :wall:
     
  21. Habe den Q20 (BC 327-40) getauscht und habe nun am untersten Punkt (A) eine Spannung von 13,6V gemessen. So ganz scheint es aber immer noch nicht zu passen, da du ja geschrieben hast, dass hier ~20V zu erwarten wären... Jedenfalls scheint der alte Q20 defekt zu sein, denn dieser wird im MTester nur noch als Widerstand und nicht als PNP erkannt.

    Danke für den Tipp, werde ich sicherheitshalber mal noch so ändern.
     
  22. #473 zuendlER84, 18. Dezember 2019
    Zuletzt bearbeitet: 18. Dezember 2019
    Hast du das Verhalten deiner Box mit dem Video, das ich oben gepostet habe, verglichen? Die Startsequenz sollte so laufen:
    Kurz nacheinander gehen alle vier LEDs kurz hintereinander in der Reihenfolge gelb, grün, orange, rot an und sofort wieder aus. In den zwei Sekunden danach werden die oberen vier Bits der eingestellten Slave-ID signalisiert: Gelb = 1, Grün = 2, Orange = 4, Rot = 8; und die Summe muss man mit 16 multiplizieren. Da die Slave-ID typischerweise kleiner als 16 sein wird, leuchtet vermutlich keine LED, es ist also zwei Sekunden Ruhe, danach gehen die LEDs in der Reihenfolge rot, orange, grün, gelb an und gleich wieder aus, bevor die unteren vier Bit zwei Sekunden lang signalisiert werden. Im Urzustand ist die Slave-ID 1, d.h. es leuchtet nur die gelbe LED. Wenn die erlischt, sieht man die grüne LED aufblitzen, das signalisiert, dass die Box ihre Daten per Funk in den Äther schickt.

    Dass die gelbe LED aufleuchtet, wenn die serielle Schnittstelle Daten bekommt oder sendet, ist normal und beim Key-Abgleich auch so geplant. Welche Ausgabe siehst du anschließend auf dem Bildschirm des raspEasyFire?

    Was heißt für dich Ruhezustand? Wenn die Box hochgefahren ist wie oben beschrieben, dann sollte keine Aktivität der LEDs zu sehen sein, außer die Box ist scharf (rote LED permanent an), die Box versucht zu senden, kann aber nicht (grüne LED permanent an), es findet kabelgebundene Kommunikation statt (gelbe LED an für die Dauer der Kommunikation) oder es herrscht Funkverkehr (orange LED ist an während eines Empfangs-, grüne während eines Sendevorgangs). Wie ist die Energieversorgung sichergestellt? Wenn der Mikrocontroller nicht vernünftig versorgt wird, resettet er sich und die Startsequenz beginnt wieder, was ein permanentes Blinken erklären könnte.
     
  23. Wie du richtig sagst, das ist besser, aber "besser" ist manchmal leider schlechter als "gut".

    Ich würde im nächsten Schritt versuchen, Q18 und Q20 komplett auszulöten und die Spannung an den Lötaugen der beiden verbundenen mittleren Pins von Q18 oder Q20 (die liegen auf demselben Potential) gegen Masse messen. Hier sollten 22,5 V anliegen, sofern gerade keine Zündung ausgeführt wird. Ist das nicht der Fall, sperrt womöglich der BC337 (Q21) nicht richtig. Auch hier deswegen mal Lötverbindungen checken bzw. das Bauteil prüfen.
     
  24. Die Zündbox habe ich per USB am Pi angeschlossen, keine weitere Spannungsversorgung.
    -Beim einschalten (Schalter ein und Schlüsselschalter Scharf [falls relevant]): LEDs gehen an in der Reihenfolge gelb, grün, orange, rot.
    -2 Sek nix
    -LEDs: rot, orange, grün, gelb
    -LED gelb an
    -alle LEDs aus (egal wie die Schalter stehen)

    -Am RaspEasyFire: Menü weitere Option-> AES Key mit Box abgleichen
    - Key von Box lesen drücken, Zündbox weiterhin alles aus, im Display wird nur der Key des RaspEasyFire angezeigt, nix weiter.
    Wenn ich das selbe ohne Angeschlossene Box mache, erscheint die Meldung "Keine Box gefunden"
     
  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