[Nils H.]

Genau. In und Thru sind durch den Opto getrennt. Im Prinzip ist das ja ein Midi-Out, der am RXD statt TXD hängt...

Eine Idee habe ich noch: Ich hab ja am Midi-Thru die Schmitt-Trigger weggelassen; kann irgendwie passieren, dass der AVR aus irgend einem Grund nach einer gewissen Laufzeit das Signal am RXD "verschmutzt"? Ein Reset hilft ja offensichtlich. Die Schmitt Trigger sollen ja wohl das Signal konditionieren und wieder steilflankig machen...

[Nils H.]

P.S.: Oh, ich sehe gerade, der Midi-Out ist doch bestückt. Ich könnte also mal einen Software-Midi-Thru implementieren und sehen, was passiert. Zumindest hängen die anderen Slaves dann nicht mehr (belastend) parallel zum Opto am RXD des AVR...

[Nils H.]

Keiner 'ne Idee, woran's liegen kann? Ich hab letzte Woche schnell den Midi-Thru-Code in die Firmware programmiert, bisher läuft damit alles einwandfrei...

[DerDomze]

Hi,

Ich an 'verschmutztes' Signal (Rauschen etc.) glaub ich weniger, eher dass die 1-Bits nicht mehr erkannt werden. Ist bei MIDI auch die +5V wie beim TTL?
Jedenfalls müsste es hier einen Schwellenwert geben bei dem die "Flanken" der Bits erkannt werden, wenn die dieser nicht erreicht wird wird auch kein Signal erkannt.

daher:
könnte sein dass hier ein Potenial 'wegdriftet'?
- Masse(Pin2) am "Through" die ja als Referenz für Rx(Pin4) und Tx(Pin5) gilt.
- bzw sind die 5V an R10 stabil oder sackt diese irgendwann mal ein?

vl kann man mit einem Singalgenerator ein passendes Rechtecksignal am MIDI-In anlegen, und dann am Midi-thru beobachten was passiert. (mit einem 2Kanal Oszi beide Signale vergleichen)

Womöglich wäre nach 4h ein mitrecorden im Normalbetrieb von Ein & Thru gang zum Vergleich  der Pegel sinnvoller.

Gruß
Dominik

Edit: hätte hier nochmal was gefunden: http://www.midi.org/techspecs/electrispec.php
hier ist wenn ich das richtig sehen nochmal ein Pegel-Verstäker vord em MidiThru, ob das solche Probleme vermeiden soll - oder für  längere Kabel am thru nötig ist.

Edit2: Midi arebeitet mit 5mA bzw. 0mA...
http://www.personal.kent.edu/~sbirch/Music_Production/MP-II/MIDI/midi_physical_layer.htm

[Nils H.]

Moin,

Ist bei MIDI auch die +5V wie beim TTL?

jepp.

könnte sein dass hier ein Potenial 'wegdriftet'?

möglich. Müsste ich über längeren Zeitraum mal messen.

- Masse(Pin2) am "Through" die ja als Referenz für Rx(Pin4) und Tx(Pin5) gilt.

Angeschlossen.

- bzw sind die 5V an R10 stabil oder sackt diese irgendwann mal ein?

Kann ich natürlich mit Sicherheit nicht sagen. Der Looper wird von einem geregelten und stabilisierten Steckernetzteil versorgt, ich glaube 12V 2A. Auf jeden Fall ist es fett genug um alle 20 Relais, das Floorboard und dessen LED zu versorgen. Und der Fall, dass alle Relais geschaltet sind ist ja eher die Ausnahme...

vl kann man mit einem Singalgenerator ein passendes Rechtecksignal am MIDI-In anlegen, und dann am Midi-thru beobachten was passiert. (mit einem 2Kanal Oszi beide Signale vergleichen)

gute Idee.

Womöglich wäre nach 4h ein mitrecorden im Normalbetrieb von Ein & Thru gang zum Vergleich  der Pegel sinnvoller.

Scheiss Fehlersucherei. Dafür muss ich halt das Rack immer auseinander reißen. Mit dem Software-Midi-Thru über den Midi Out am TXD des AVR lief der Kram jedenfalls schon 'ne ganze Weile stabil. Das muss irgendwie am "Poor Man's Design" des Midi-Thru liegen.

Danke für Deinen Input!

Gruß, Nils

[DerDomze]

Ist bei MIDI auch die +5V wie beim TTL?

jepp.

Edit2: Midi arebeitet mit 5mA bzw. 0mA...
http://www.personal.kent.edu/~sbirch/Music_Production/MP-II/MIDI/midi_physical_layer.htm

die Spannung +/- 5..15V sind RS232 bei MIDI sinds anscheinend doch Ströme 5mA sofern die Specs im obigen link stimmen...

[Nils H.]

Recht hast Du natürlich... MIDI arbeitet mit einer Stromschleife. Hab ich gestern auch nicht richtig nachgedacht.

Theorie: Vielleicht stellt sich irgendwann ein Zustand ein, wo der µC des Floorboards (da ist auch ein AVR drin) durch die Doppelbelastung (Midi-In am Looper und davon parallel abgegriffener Thru) nicht mehr genug Strom liefert, so dass der den Opto im Receiver des GM2 den entsprechenden Spannungspegel für den RXD des Prozessors erzeugen kann.

Mal schauen, ob ich irgendwas über das HW-Design des GM2 finde. Der Opto in meinem Looper (6N139) scheint jedenfalls weiterhin den Strom in einen ausreichenden Spannungshub umzusetzen, dass der AVR das als high erkennt...

[hofnar]

Hi,

wie genau hast du das MIDI In Signal zum Thru gemacht? Wenn du die Schmittrigger weggelassen hast, muss das Midisignal ja wie du sagst den Opto vom Looper und den vom GM2 bedienen. Die Schmittrigger nehmen das Signal hochohmig ab. Ich denke auch das da das Problem liegt.

Gruß
Chris

[Nils H.]

Hi,

wie genau hast du das MIDI In Signal zum Thru gemacht? Wenn du die Schmittrigger weggelassen hast, muss das Midisignal ja wie du sagst den Opto vom Looper und den vom GM2 bedienen. Die Schmittrigger nehmen das Signal hochohmig ab. Ich denke auch das da das Problem liegt.

Gruß
Chris

Jepp, volle Zustimmung. Wie oben gesagt: Poor Man's Design  . Rächt sich immer... es wäre so geil, wenn man davon Ahnung hätte und vorher nachdenkt  . Insofern erstaunlich, dass es überhaupt über Stunden funktioniert... ca. ein halbes Jahr lang hab ich gar nix gemerkt und hatte keine Probleme...

[DerDomze]

... es wäre so geil, wenn man davon Ahnung hätte und vorher nachdenkt 

ach dann wärs doch langweilig 

[Nils H.]

Moin

da ich gerade Urlaub habe, habe ich an dieser Baustelle mal wieder rumgeschraubt. Anlass war, dass mir in den letzten Wochen der Controller mehrfach ausgestiegen ist - spontaner Reset. Gefunden habe ich, dass der Spannungsregler sich losgerappelt hatte und ein Bein angebrochen war - ich hoffe, das war's.

Jedenfalls, ich habe dann noch ein paar Bugs gefixt und eine gaaaanz wichtige Sache nachgerüstet: Sysex-Dump und Reload!

Hier hatte/habe ich aber ein paar Probleme. Ich konnte relativ leicht mit MIDI-OX das komplette 64k-EEPROM auslesen. Das zurück schreiben bereitet mir aber etwas Probleme.

Erst dachte ich, mein Algorithmus wäre Schrott, weil nicht das im Controller ankam, was MIDI-OX rausschickte. Ich hab dann aber mal mit der Sendepuffergröße rumgespielt, jetzt geht's - dauert aber ewig  .

Das zurück schreiben läuft nur dann zuverlässig, wenn ich den Sendepuffer auf 1 Byte Größe (!) stelle. Bei der Pause zwischen den Puffern kann ich auf 15 ms runtergehen, trotzdem dauert das zurück schreiben der Daten ewig.

Okay, das I2C-EEPROM ist nicht das schnellste, und es kostet etwas Zeit, dass ich noch ein paar Debug-Ausgaben auf dem LCD habe. Die Schreibgeschwindigkeit liegt aber nur bei ca. 80 Byte/s - klar, dass da massig Daten verloren gehen, wenn MIDI-OX die zu schnell rausschickt. Daran ändert sich auch nix, wenn ich die LCD-Ausgaben abklemme.

Meine Frage: Jemand 'ne Idee, ob ich irgendwas radikal falsch machen könnte, oder ist das halt so, dass das I2C-EEPROM vom AVR nur relativ langsam beschrieben werden kann? der I2C läuft mit 100 kHz (mehr machen die Expander nicht), ich nutze die UART-Lib von Peter Fleury mit einem Ringpuffer von 512 byte - trotzdem gehen mir massig Daten verloren, sobald ich nur etwas schneller werde  .

Am Ende egal, weil's ja funktioniert - ich habe mein EEPROM jetzt schon zweimal erfolgreich kopiert, Konfiguration und Presets sichern ist also endlich kein Problem mehr. Trotzdem doof...

Wenn ich mit dieser Runde fertig bin, stelle ich - wie versprochen - endlich mal meinen Quelltext ein.
Gruß, Nils