Handhabung & Technik El Fueradoro - Funkzündanlage mit Interface

Mit Parallel-Zündungen meinst du auf mehreren Slaves gleichzeitig zu zünden, richtig?

Mit der aktuellen SW ist es sehr einfach, du musst im Zündplan Einträge für die verschiedenen Slaves mit identischen Zündzeitpunkten anlegen. Diese werden dann gleichzeitig ausgeführt.

 

Mal interessehalber, was für eine Zündzeit brauchst du denn?

 

Die G-Flames von Galaxis zünden genau so lange, wie Spannung am Trigger-Eingang anliegt. Bei 350ms gäbe es schöne Kugeln und hätte den netten Nebeneffekt, dass man wahrscheinlich auf dem Kanal "nachzünden" könnte um die Flammdauer zu verlängern.
Den Ausgang als Stepper angesprochen lässt sich ja beliebig oft "nachzünden".

Dein Mini-Modul wäre natürlich dafür natürlich PERFEKT geeignet!
Ich muss nur mal testen ob die Ausgangspannung von dem Step-Up in deinem Modul reicht. Galaxis scheibt 12-24V vor.

 

Die Option, die Öffnungszeit auf 350 ms einzustellen, habe ich gerade eingebaut. Solange es sich um einen festen Wert handelt, ist das in der Software kein allzu großer Aufwand.

Man muss sich nach einem Firmwareupdate mit der entsprechenden Zündbox per Terminal verbinden (serielle Verbindung bei 9600 Baud) und dann über "igniter" das Auswahlmenü aufrufen und anschließend dort "f" für Flamer wählen, dann wird die Auslösedauer auf 350 ms gesetzt und bleibt auch nach einem Neustart und Firmwareupdate erhalten.

 

Sensationell!!!
Werde das am Sonntag (schlechtes Wetter)mal testen.

Gruß und Dank!

 

G-Flames an der RaspEasyFire!

Hier eine kurze Rückmeldung von der Flamer-Front: Es tut!
Dank Felix' schneller Intervention, eine 3 Zünddauer einzupflegen, ist das Ansteuern von Flamern jetzt einfach möglich.
Ich habe es mit den G-Flames von Galaxis probiert.
Jetzt lassen sich auch unterschiedlich lange Flamendauern realisieren:
- fest: 350ms
- variabel: 450ms - unendlich
Hier ein kurzes Video vom ersten Test mit gasförmigem Gas vier Zündungen: 350ms, 500ms, 350ms 1000ms.

Eingebetteter Inhalt von YouTube

Diesen Inhalt anzeigen

Inhalte von YouTube immer anzeigenInhalte von YouTube immer ausblendenImmer alle eingebetteten Inhalte anzeigenImmer alle eingebetteten Inhalte ausblenden

Vielen Dank mal wieder an Felix!

Gruß

Tobias

 

Verstehe nur gerade nicht wie man das machen kann ..... Ich gehe mit dem Kanalausgang in den Flamer so weit ist mir das klar, aber wie kann Ich dann sagen 350ms oder 500ms das leuchtet mir nicht ganz ein ?

 

Es hindert dich ja niemand daran, den Kanal nach 150 ms erneut zu zünden, dann läuft er für 150 ms + 350 ms.

 

Genau aus dem Grunde gibt es auch zwei mögliche Flammendauern:
- 350ms (1x getriggert)
- 450ms (1x nach 100ms nachgetriggert) oder beliebig länger (x-mal nachtriggern)

Wegen der Zündimpulslänge 350ms (im Flamer-Modus) sind Flammendauern von weniger als 350ms nicht möglich.
UND
Wegen der 100ms-Minimal-Zündabstandszeit sind Flammendauern zwischen 350ms und 450ms nicht möglich.
Alles andere geht!

Ganz einfach!

 

Und hier noch ein Test mit zwei G-Flames (mehr Gasflaschen hatte ich gerade nicht zur Hand...)
Je zweimal zeitgleich und dann im Wechsel mit erst 350ms und dann 700ms Brenndauer.
...und zu viel Wind...

Eingebetteter Inhalt von YouTube

Diesen Inhalt anzeigen

Inhalte von YouTube immer anzeigenInhalte von YouTube immer ausblendenImmer alle eingebetteten Inhalte anzeigenImmer alle eingebetteten Inhalte ausblenden

 

Nochmal ne Frage zu den Zeitgleichen Zündungen:

Was wird genau von der Anlage zu zeitgleichen Zündungen herangezogen. Nur die, die auf die Milisekunde gleich sind oder alles bis 99ms?
Ich frage mich nämich, wie ich jetzt noch die Show bezüglich der 100ms kontrollieren kann.

Gruß und Dank!

Tobias

 

Ja, es muss auf die ms gleich sein, nur dann wird es als gleichzeitige Zündung gewertet.
Bei unterschiedlichen Zeiten unter 100ms wären es dann unterschiedliche Zündungen mit zu kleinem Abstand.

Ich habe noch nicht überprüft, ob der Checker mit gleichzeitigen Zeiten noch funktioniert.

 

Meine Prämisse ist: Der User wird sich bei der Erstellung seines Plans schon etwas gedacht haben und soll nach Möglichkeit seinen Willen bekommen.

Daher wird der Zündplan nicht verändert, sondern jede Zündzeit so übernommen wie vorgegeben. Gleichzeitige Zündung von bis zu sieben verschiedenen Cues (gleiche Slave-Kanal-Kombinationen gelten als ein Cue) mit auf die Millisekunde gleicher Zündzeit ist möglich, davor und danach muss 100 ms Pause sein.

 

OK, verstehe.
Gibt es nun eine Möglichkeit die Show zu checken, also Cue-Abstände zwischen 1 und 99 ms zu finden? Im PyroEgnitionControl wird ja immer nur das kürzeste Intervall angezeigt, also dann die gewollten Parallelzündungen mit 0ms...
Vielleicht hat ja jemand ne Idee.

Gruß Tobias

 

Servus, ich hab aktuell ein Problem mit einer meiner Zündboxen, es geht um die 16 Channel V3-Version mit einem HCW-Modul.
Die Tage habe ich dann das neueste Image und die Firmware(26.04.2021) aufgespielt mittels PC.
Bei einer Box gab es Verbindungsprobleme beim Neuaufspielen mittels Winloader32, woraufhin ich dann den Bootloader neu geflasht habe. Im Anschluss konnte ich dann den Updateprozess mittels Winloader32 normal durchlaufen. Im Anschluss habe ich dann die Box mittels USB und dem Raspeasyfire verbunden und wollte dann den AES-Key ablesen, was grundsätzlich schonmal nicht ging.
Beim Drücken der Touchfläche geschah nichts. Im Anschluss nochmal an den PC angeschlossen und das ganze per Putty versucht. Hier konnte auch keine Verbindung hergestellt werden, die Konsole blieb schwarz. Nochmal versucht die Firmware neu aufzuspielen, was wieder in Verbindung fehlgeschlagen resultierte. Erneut Bootloader neu aufgespielt-> per Winloader Firmware aufgespielt.
Es kam wieder die Rückmeldung Firmware Update Erfolgreich beendet. Nun versucht direkt per Puttytel zu verbinden, erneut nur die Schwarze Putty Konsole.
Den ganzen Prozess habe ich mehrmals wiederholt, leider ohne Erfolg.
Die Firmware konnte ich hierbei ohne Probleme bei den anderen Boxen aufspielen, egal ob V3 16/32CH CW oder HCW Version.
Das benannte Problem konnte ich nur bei der einen besagten Box reproduzieren.
Hier nochmal die CMD-Ausgabe beim flashen des Bootloaders:



Using Port : usb
Using Programmer : avrispmkII
Setting bit clk period : 50.0
avrdude.exe: usbdev_open(): Found AVRISP mkII, serno: 008F5B78163A
AVR Part : ATmega328P
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :

Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff
flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00

Programmer Type : STK500V2
Description : Atmel AVR ISP mkII
Programmer Model: AVRISP mkII
Hardware Version: 1
Firmware Version Master : 1.24
Vtarget : 3.2 V
SCK period : 51.62 us

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude.exe: Device signature = 0x1e950f (probably m328p)
avrdude.exe: safemode: hfuse reads as D6
avrdude.exe: safemode: efuse reads as FD
avrdude.exe: NOTE: "flash" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: reading input file "bootload_m328p_9830400.hex"
avrdude.exe: input file bootload_m328p_9830400.hex auto detected as Intel Hex
avrdude.exe: writing flash (32768 bytes):

Writing | ################################################## | 100% 0.01s

avrdude.exe: 32768 bytes of flash written
avrdude.exe: verifying flash memory against bootload_m328p_9830400.hex:
avrdude.exe: load data flash data from input file bootload_m328p_9830400.hex:
avrdude.exe: input file bootload_m328p_9830400.hex auto detected as Intel Hex
avrdude.exe: input file bootload_m328p_9830400.hex contains 32768 bytes
avrdude.exe: reading on-chip flash data:

Reading | ################################################## | 100% 0.01s

avrdude.exe: verifying ...
avrdude.exe: 32768 bytes of flash verified
avrdude.exe: reading input file "std_eep.eep"
avrdude.exe: input file std_eep.eep auto detected as Intel Hex
avrdude.exe: writing eeprom (128 bytes):

Writing | ################################################## | 100% 0.50s

avrdude.exe: 128 bytes of eeprom written
avrdude.exe: verifying eeprom memory against std_eep.eep:
avrdude.exe: load data eeprom data from input file std_eep.eep:
avrdude.exe: input file std_eep.eep auto detected as Intel Hex
avrdude.exe: input file std_eep.eep contains 128 bytes
avrdude.exe: reading on-chip eeprom data:

Reading | ################################################## | 100% 0.37s

avrdude.exe: verifying ...
avrdude.exe: 128 bytes of eeprom verified
avrdude.exe: reading input file "0xf7"
avrdude.exe: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.02s

avrdude.exe: 1 bytes of lfuse written
avrdude.exe: verifying lfuse memory against 0xf7:
avrdude.exe: load data lfuse data from input file 0xf7:
avrdude.exe: input file 0xf7 contains 1 bytes
avrdude.exe: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.01s

avrdude.exe: verifying ...
avrdude.exe: 1 bytes of lfuse verified
avrdude.exe: reading input file "0xd6"
avrdude.exe: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.02s

avrdude.exe: 1 bytes of hfuse written
avrdude.exe: verifying hfuse memory against 0xd6:
avrdude.exe: load data hfuse data from input file 0xd6:
avrdude.exe: input file 0xd6 contains 1 bytes
avrdude.exe: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.01s

avrdude.exe: verifying ...
avrdude.exe: 1 bytes of hfuse verified
avrdude.exe: reading input file "0xfd"
avrdude.exe: writing efuse (1 bytes):

Writing | ################################################## | 100% 0.02s

avrdude.exe: 1 bytes of efuse written
avrdude.exe: verifying efuse memory against 0xfd:
avrdude.exe: load data efuse data from input file 0xfd:
avrdude.exe: input file 0xfd contains 1 bytes
avrdude.exe: reading on-chip efuse data:

Reading | ################################################## | 100% 0.00s

avrdude.exe: verifying ...
avrdude.exe: 1 bytes of efuse verified

avrdude.exe: safemode: hfuse reads as D6
avrdude.exe: safemode: efuse reads as FD
avrdude.exe: safemode: Fuses OK (E:FD, H6, L:F7)

avrdude.exe done. Thank you.

Grüße Emil.

 

Der Bootloader wird erfolgreich geschrieben, aber wie verhält sich die Firmware denn? Siehst du beim Start die "Lichtorgel", reagiert die Box auf Drehen des Schlüsselschalters?

Wenn die Neuprogrammierung nicht klappt, liegt es meist daran, dass die Software nicht per "kill" zum Neustart gezwungen werden kann und somit nicht in den Bootloader kommt, um das Update durchzuführen. Das kann dann ein Problem beim USB-UART-Signalweg (Lötstellen, Kabel, Bauteile) sein.

 

Das hatte ich ganz am Anfang auch schon einmal bei mir war es damals der MCP2221 von Reichelt

 

So, Raspeasyfire funktioniert, die Zündbox v3_32 ist auch fertig. Der Bootloader und die Firmware wurden erfolgreich mittels Raspeasyfire aufgespielt. Den AES Key habe ich auch schon verglichen, ist der selbe. Danach habe ich auf Slave suchen gedrückt und da hat sich nichts getan, sprich es wurde keine Box gefunden. Könnte das Funkmodul defekt sein, oder ist es ein anderer Fehler?

Danke!

 

Um sagen zu können, was es ist, musst du ein bisschen mehr ins Detail gehen. Bauteildefekte sind üblicherweise die Ausnahme, meistens ist es irgendein profaneres Problem.

Die Box startet wie erwartet, zeigt ihre Slave-ID an und man sieht ganz am Ende des Startvorgangs auch den kurzen grünen LED-Blitz, dass sie ihre Daten verschickt?

Wenn du auf "Slaves suchen" gehst, siehst du die Sende-LED am raspEasyFire zweimal im Abstand von einer Sekunde kurz aufleuchten und leuchtet quasi synchron dazu auch die orange LED an der Zündbox auf (raspEasyFire sendet, Zündbox empfängt)? Wenn ja, leuchtet am Ende nach der orangen LED auch die grüne LED an der Zündbox und dazu die orange am raspEasyFire (Zündbox sendet ihre Daten, raspEasyFire empfängt sie)?

Steht nach der Slavesuche beim raspEasyFire "SQUELCH-Warnung" im Display?

Dass beide Funkmodule fest mit einer Antenne verbunden sein müssen, brauche ich hoffentlich nicht mehr erwähnen. Manchmal hilft es auch, die beiden Geräte zumindest ein oder zwei Meter auseinander zu stellen, damit die Übersteuerungen am Funkmoduleingang nicht ganz so groß sind.

 

Wenn ich die Zündbox aufdrehe, leuchten die Kanal LEDS, die Led beim Schlüsselschalter leuchtet zweimal auf, ebenso leuchten die RX und die UART LED auf, danach leuchtet bei der Zündbox nichts mehr. Bei der Slave Suche leuchtet nur die grüne LED zweimal auf, bei der Zündbox Keine. Beim Hochfahren vom Raspeasyfire habe ich eine Fehlermeldung für das Funkmodul entdeckt (siehe Bild).

 

Richtige Firmwareeinstellung beim raspEasyFire bzgl. CW oder HCW? Schau dir mal das Video zum Firmwareupdate an, da ist die LED-Sequenz genau gezeigt.

 

Beim flashen des Bootloaders blinken RX und TX vom Raspeasyfire abwechselnd und schnell. Dieser Vorgang wird mir mit Erfolgreich bestätigt. Bei der Box hat nichts geleuchtet. Nach dem ziehen des USB Kabels leuchten auch keine LEDs. Beim Firmware schreiben blinken wieder RX und TX abwechselnd. Danach verhalten sich die LEDs wie im Video, zusätzlich gehen noch alle Channel-LEDs an.
In den Einstellungen ist das RFM69HCW (20 dBm) ausgewählt, welches auch verbaut ist.
Dann habe ich wieder auf Slaves suchen gedrückt und es ist wieder nichts passiert.

 

Hast du mal geschaut ob das Funkmodul auch richtig auf dem Sockel sitzt ? Zum anderen könntest du zum testen einfach ein anderes Funkmodul nehmen, somit kannst Du den Fehler schon etwas eingrenzen. Wenn das Funkmodul nicht richtig sitzt dann macht es auch den Selbsttest nicht.

 

Was ich vergessen habe, die orange LED der Box blitzt ganz zum Schluss auch nochmal kurz auf.