Entwicklung eines Midi-Switching-Systems auf Arduino-Basis

Technik > Tech-Talk Design & Konzepte

<< < (27/30) > >>

torus:
gelöscht (wurde auf vorherigen Seiten schon besprochen)

Nils H.:

--- Zitat von: Nils H. am 17.08.2014 12:26 ---Eine Sache macht mir allerdings etwas Kopfschmerzen, die ist mir in den acht Monaten jetzt zweimal passiert: Der Controller hat anscheinend irgendwelchen Quatsch rausgesendet, und plötzlich kam nur noch Gequietsche und Gerausche ausm Amp ;D . Ein Tritt auf ein Preset hat's wieder erledigt, da es beide Male tierisch laut war, konnte ich nicht genau nachvollziehen, was passiert war. Ärgerlich, und schwer zu finden, weil nicht reproduzierbar - passierte beide Male im Preset Mode ohne aktives Zutun meinerseits.

--- Ende Zitat ---

Okay, gestern bei der Probe ist das wieder passiert. Wieder komplett ohne eigenes Zutun, ich war im Proberaum gerade am Lüften und die Anlage lief, ich hab aber nicht gespielt oder so. Da ich aber mit dem Volumenpedal in der Loop die Lautstärke runtergedreht hatte, war diesmal der Schock nicht so groß 8) und ich konnte mal nachverfolgen, was los war.

Scheint ein Problem mit dem Looper u sein, der hat selbsttätig ALLE Loops aktiviert und alle Schaltausgänge geschaltet - ausnahmslos ALLE, sogar die, für die im FLoorboard kein CC eingerichtet war - spricht also dagegen, dass der Controller irgendwelchen Müll sendet, den der Looper dann falsch interpretiert, zumal die anderen MIDI-Geräte unbeeindruckt bleiben.

Spricht alles dafür, dass der I²C-Bus "abgestürzt" ist und die Port Expander zurück gesetzt wurden. Dann tritt genau das Problem ein, weswegen ich eine Einschaltverzögerung der Relaisspannung eingebaut habe: Die PCF sind nach dem Einschalten alle HIGH, der ULN invertiert das, und die Relais werden aktiviert. Ich tippe auf einen Wackler in der SPannungsversorgung im Platinensteckverbinder zwischen µC- und PCF/ULN Board. Werde also in den kommenden Tagen das Teil mal ausm Rack ausbauen und überprüfen.

Hardwareseitig könnte ich natürlich die inverse Logik durch Inverter umpolen, aber das Problem bleibt: Wenn ein Bus-Reset auftritt, ist dann alles aus statt an, das ist ja auch nicht so toll - nur nicht so laut.

Bleibt also trotzdem die Frage, wie ich das ganze Softwareseitig am besten absichere. Meine Idee: Wenn der Bus n/die PCF nicht reagieren, Relaisspannung kappen, ansonsten die PCF zyklisch immer wieder statt nur einmal setzen. Gibt's noch elegantere Methoden? Jemand Vorschläge?

Gruß, Nils

Nils H.:
Moin Leute,

ich brauch mal Eure Hilfe. Ich hab ein Problem, das ich nicht verstehe.

Die Anlage lief im Prinzip (bis auf das letzte Problem mit dem Wackelkontakt im I2C-Bus) seit ewig problemlos; seit ein paar Wochen habe ich aber das Problem, dass der Midi-Thru-Ausgang am Looper "abstürzt".

Das Setup ist wie folgt: Der Midicontroller hängt am Pedal-In (Midi mit Phantom) an der Frontplatte, hinten sitzt der Midi-Thru und leitet alles an ein G-Major 2 weiter.

Problem: Irgendwann (nicht reproduzierbar) kommen am GM2 keine Midisignale mehr an. Ich war mir erst wicher, es sei das GM2-das abstürzt, jetzt stellte sich mit einem Leihgerät aber raus: Is nich, mit dem Leihgerät passiert das genauso. Gestern nach einer Laufzeit von ca. 4 Stunden.

Ich doktore schon recht lange an der Analyse des Problems rum; Neustart des Midicontrollers brachte nichts, Neustart des GM2 auch nicht. Was manchmal zu helfen schien war, das Preset am GM2 manuell zu wechseln. Das scheint aber doch eher zufall zu sein, gestern brachte das nichts.

Was half: Das Rack aus- und wieder einschalten - Effektiv also, den Looper neu zu starten. Es sieht also so aus, als würde der Looper irgendwann die eingehenden Mididaten nicht mehr an den Thru weiterleiten.

Weiteres Problem: Ich verstehe nicht, was passiert. Der Midi-Thru-Port kann nicht "abstürzen", weil er nix mit Software zu tun hat... es ist ein "poor man's"-Hardware-Midi-Thru, der schlicht parallel zum Opto am RXD des AVR hängt (siehe dazu angehängter Stromlaufplan). Der Midi-Out ist nicht bestückt.

Es ist definitiv nicht der Midicontroller, der sich aufhängt, da der Looper immer noch weiter auf Befehle korrekt reagiert. Der Controller sendet also definitiv Mididaten raus.

Jetzt kann's natürlich sein, dass ein Bug in der Software dafür sorgt, dass nur noch auf Midikanal 1 Daten raus gehen. Ich weiß nicht genau, wie ich das analysieren kann. Ich kann leider die Midikanäle von Looper und GM2 nicht tauschen, weil der Midikanal im Looper hardcoded ist... (jaja, ich weiß. Faulheit rächt sich immer irgendwann). Ich könnte, wenn der Fehler das nächste mal auftritt, das GM2 auf Omni stellen und schauen, ob was ankommt.

Mehr Ideen habe ich nicht. Wie gesagt, mit der Loopersoftware KANN das nichts zu tun haben, weil der Thru Hardware ist. Am Opto kann's auch nicht liegen, denn der AVR im Looper bekommt immer noch seine Befehle.

WTF? Ich bin ratlos...
Nils

Athlord:
Hi Nils,
wenn ich das richtig sehe, dann sind die Eingänge am Looper nicht galvanisch getrennt oder?
Gruss
Jürgen

Tante Edit: Blödsinn geschrieben, der 6N139 macht´s...

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete

Zur normalen Ansicht wechseln