MIDI Übertragungsfehler [gelöst]

[Bääääär]

Hallo alle zusammen!

Ich habe folgendes Problem, bei dem ich eure Hilfe brauche:

Ein Atmega32 @ 16Mhz empfäng Daten von einem MIDI-Keyboard. Die angehängte Schaltung wandelt die Daten von einem "Strom-Signal" in ein "Spannungs-Signal" um (sodass ich sie bei 31250 Baud mit der USART empfangen kann).

Leider kommt es immer wieder zu Übertragungsfehler, was bei einem MIDI Instrument - nunja - bescheiden ist. Immer wieder bleiben Töne hängen oder gar falsche Töne erklingen.

Zwischen der Platine mit der angehängten Schaltung und dem AVR sind nochmal 15cm ungeschirmte Leitung (einfach 2 Kabel).

Was kann ich tun, um die Fehler zu minimieren?

Danke für Hilfe,
Bääääär

[PicNick]

Elektrisch kann man da nicht viel falsch machen. Ist ja eine Stromschleife, die büffelt vor sich hin.
Hangeln bleiben gibt es ja, aber "falsche" Töne sind bei MIDI seltsam.

Ist deine Empfangsroutine wasserdicht ?
running status, etc, ?

[Bääääär]

Ich hoffe doch, dass der Code in Ordnung ist. ich habe ihn mal angehangen.

Zum Phänomen: Es erklingen beim Drücken einer Taste teils falsche Töne, die dank richtig überragenem NoteOff-Event dann hängen bleiben. Das sind eigentlich fast alle möglichen Töne - rauf und runter.

Folgendes wird bem Empfangen aufgerufen:

SIGNAL (SIG_USART_RECV) {

	Keyboard_ReceiveMessage(UDR);

}

[wkrug]

Meine Vermutung ist auch, das es sich dabei um Bittfehler handelt, die sich bei der Übertragung einschleichen.
Ich würd's mal mit einem anderen Optokoppler (mit integriertem Schmitt Trigger) versuchen.
Nimm mal den PC900 von Sharp.

[Bääääär]

Ja, Bitfehler sind das sicher. Der Optokoppler könnte natürlich wirklich eine Fehlerquelle sein. Meiner wurde allerdings auch hier verwendet: http://www.mikrocontroller.net/artic...t_MMC/SD-Karte
Ok, was macht den Sharp denn besser, im Vergleich zum jetztigen? Schmitt Trigger klingt sinnvoll - aber wird das wirklich Besserung bringen?

Grüße,
Bääääär

[PicNick]

Welche Werte hast du für r5, r6 ?

Die verwende ich, geht tadellos
https://www.roboternetz.de/wissen/in...MIDI-Interface

[wkrug]

Schmitt Trigger klingt sinnvoll - aber wird das wirklich Besserung bringen?

Ich hab kürzlich mit den 6N139 ein wenig rumgepielt und hab bei einer Übertragungsrate von 38400 Bit / sek den Kollektorwiderstand auf 1k Ohm reduzieren müssen um ausreichend steile Flanken hinzukriegen. Erst bei so kleinen Kollektorwiderstand lief die Datenübertragung fehlerfrei.

Aus der Vergangenheit:
Meine Versuche mit MiDi und dem ach so beliebten CNY17 waren auch nicht von Erfolg gekrönt.

Als ich den Entwurf dann auf PC900 umgestrickt hab lief es dann plötzlich problemlos.

Der PC900 wurde, soweit ich weiß, für den Einsatz in Stromschleifen entwickelt.
Das kannst Du ja aber auch alles im Datenblatt nachlesen.
Eine Zeitlang wurde der Optokoppler als Obsolete erklärt inzwischen hat sich Sharp anscheinend eines Besseren besonnen.
Der PC900 im Ausgang nicht einfach einen Transistor, sondern einen Eingangsverstärker mit eingebautem Schmitt Trigger, was auch bei verschliffenen Eingangssignalen steile Impulsflanken generiert.
Da macht der 6N139 das genaue Gegenteil davon.
Das Teil kostet bei Conrad gerade mal 1,70€ - Einen Versuch wär mir das schon mal Wert.

[tholan]

Ich hab Deinen Code nicht durchgeackert, aber beherrscht der auch den "running status"?
Mein Masterkeyboard (M-Audio Delta V2 )produziert ebenjenen und ich hab damit schon 'ne Weile
gekämpft.

p.s.
Ich nutze seit Jahren den 6N137 mit der üblichen Eingangsbeschaltung:
Antiparallele Si-Diode, 220R.
Ausgangsseitig nutze ich nur den AVR-internen Pullup (ist der an?).
Der PC900 ist mir zu teuer und mit dem CNY17 isses 'ne Fummelei mit den Pullups.

[PicNick]

Ich hab eigentlich in dem Code nix in richtung runningstatus erkennen können.
Bei einem Controll-Byte (2^^7) setzt er den Buffer zurück.
Und er interessiert sich offenbar nur für note-on/off.
Das scheint mir für einen speziellen Zweck geschrieben zu sein.
Was soll das Zeugs denn können ?

[tholan]

Bei einem Controll-Byte (2^^7) setzt er den Buffer zurück.

Dann sollts auch mit "Running Status" funktionieren, wenn die Notennummer nicht woanders
verschluckt wird und die Velocity als solche dann interpretiert wird.
"Running Status" bedeutet, daß nicht jeden kanalabhängigen Daten ein Statusbyte vorangestellt werden
muß, solange der Status sich nicht ändert. Keyboards, die so funktionieren, wie z.B.
das Oxygen V2 von M-Audio, kennen daher auch kein echtes "Note Off" (0x8n), sondern
machen für "Note Off" nochmals ein "Note On" (Bzw. bleibt es beim Status 0x9n) mit der Velocity 0 auf die entsprechende Notennummer.
Sonst würde sich das mit dem "Runnimg Status" nicht lohnen.
Dabei geht allerdings die Loslaß-Velocity flöten.