-         

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 16

Thema: MIDI Übertragungsfehler [gelöst]

  1. #1
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    13.05.2007
    Alter
    26
    Beiträge
    183

    MIDI Übertragungsfehler [gelöst]

    Anzeige

    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
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken midi.png  

  2. #2
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.836
    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, ?
    mfg robert
    Wer glaubt zu wissen, muß wissen, er glaubt.

  3. #3
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    13.05.2007
    Alter
    26
    Beiträge
    183
    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:
    Code:
    SIGNAL (SIG_USART_RECV) {
    
    	Keyboard_ReceiveMessage(UDR);
    
    }
    Angehängte Dateien Angehängte Dateien

  4. #4
    Erfahrener Benutzer Robotik Einstein Avatar von wkrug
    Registriert seit
    17.08.2006
    Ort
    Dietfurt
    Beiträge
    1.892
    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.

  5. #5
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    13.05.2007
    Alter
    26
    Beiträge
    183
    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

  6. #6
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.836
    Welche Werte hast du für r5, r6 ?

    Die verwende ich, geht tadellos
    http://www.roboternetz.de/wissen/ind...MIDI-Interface
    mfg robert
    Wer glaubt zu wissen, muß wissen, er glaubt.

  7. #7
    Erfahrener Benutzer Robotik Einstein Avatar von wkrug
    Registriert seit
    17.08.2006
    Ort
    Dietfurt
    Beiträge
    1.892
    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.

  8. #8
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    06.05.2005
    Ort
    Berlin
    Beiträge
    212
    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.

  9. #9
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.836
    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 ?
    mfg robert
    Wer glaubt zu wissen, muß wissen, er glaubt.

  10. #10
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    06.05.2005
    Ort
    Berlin
    Beiträge
    212
    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.

Seite 1 von 2 12 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •