MIDI-Übertragung Drahtlos...Lösungen?

[Bernd Gumler]

Hallo

Ein Thema, zu dem ich im Internet bisher ausser einigen vagen Andeutungen
nix gefunden hab. Angeblich gibts da schon fertig käufliche Lösungen (u.a.
auf Bluetooth Basis), aber auf allen Links die ich bisher verfolgt hatte:
Fehlanzeige, darum mal hier mal meine neugierige Frage, was den Bastlern
hier so dazu einfällt.

Problem: MIDI-Daten (seriell, nicht ganz 32 kbps) sollen drahtlos und
möglichst preisgünstig übertragen werden. Der Sender muß mobil sein (sprich:
Batteriebetrieb), erhält Daten z.B. von so einem 80er
Jahre-Modern-Talking-Showkeyboard.

Eine erste Idee kam mir, als ich ne Compact-Flash-Bluetooth-Karte gesehen
hab (obwohl ich ich immer noch nicht weiß, wie die beiden Begriffe richtig
zusammenpassen sollen): CF ist ja nicht sooo kompliziert zum ansteuern, mit
etwas Internethilfe ein machbares PIC-Projekt...nur irgendwie hab ich noch
Probleme, CF mit Bluetooth zu verbinden. CF ist ja ein Datenträger,
Bluetooth speichert aber doch nix...
Außerdem frag ich mich, wie es mit der Reichweite, Signalqualität von
Bluetooth auf der mit Metallen und Signalen vollgestopften Bühne (div.
Ständer, Cases, Gehäuse, Kabel, andere Funkmikros,
Wireless-In-Ear-Systeme)...

Gibts andere Ideen, Vorschläge...

Auf Ihr Bastler... ;-)

Vielen Dank
Bernd Gumler

 

[Sebastian Voitzsch]

Bernd Gumler wrote:

Eine erste Idee kam mir, als ich ne Compact-Flash-Bluetooth-Karte gesehen
hab (obwohl ich ich immer noch nicht weiß, wie die beiden Begriffe richtig
zusammenpassen sollen): CF ist ja nicht sooo kompliziert zum ansteuern,
mit etwas Internethilfe ein machbares PIC-Projekt...nur irgendwie hab ich
noch Probleme, CF mit Bluetooth zu verbinden. CF ist ja ein Datenträger,
Bluetooth speichert aber doch nix...

Dabei geht's IMHO eher um den Sockel und die Bauform von CF-Karten. PCMCIA
ist ja ursprünglich auch mal ein Format für Speicherkarten gewesen - heute
gibt's da alles für.

BlueTooth dürfte hier Kanonen auf Spatzen sein. Denn es reicht nicht, eine
Funkverbindung aufzubauen; vielmehr müßte das ganze Protokoll unterstützt
werden. Einfacher dürfte es sein, Funkmodems zu verwenden. Diamond z.B. hat
dergleichen in seinen HomeFree-Funknetzwerkkarten gemacht: einen IRDA-Chip
mit einem Funkmodem gekoppelt. Das Modem kümmert sich um den Funkkram,
alles andere ist normaler serieller Datenverkehr, der sich per ľC in alle
möglichen Datenraten, Formate etc. bringen läßt. Diese Karten gibt's noch
gebraucht (eBay...); die PCI-Variante enthielt das Funkmodul in steckbarer
Form. Funkt im 2,4GHz-Band. Evtl. ist auch die restliche Ansteuerung
interessant: der verwendete Chip ist der TIR2000, der ist recht gut
dokumentiert (http://focus.ti.com/lit/ds/symlink/tir2000.pdf). Mit ein
bißchen AVR, PIC o.Ä. sollte man den angesteuert bekommen.

Sebastian

 

[Andreas Lobinger]

Aloha,

Bernd Gumler schrieb:

Ein Thema, zu dem ich im Internet bisher ausser einigen vagen Andeutungen
nix gefunden hab. Angeblich gibts da schon fertig käufliche Lösungen (u.a.
auf Bluetooth Basis), aber auf allen Links die ich bisher verfolgt hatte:
Fehlanzeige, darum mal hier mal meine neugierige Frage, was den Bastlern
hier so dazu einfällt.

Problem: MIDI-Daten (seriell, nicht ganz 32 kbps) sollen drahtlos und
möglichst preisgünstig übertragen werden. Der Sender muß mobil sein.

Du solltest noch zwei Punkte in das Pflichtenheft aufnehmen:
1) Latenzzeit so kurz wie möglich. (bei Musik < 5ms (da kann man jetzt
streiten))
2) Rahmen- (das wäre Note-On/Off Paare), Symbol- (das wären Kommandos)
und Bitfehler in schwindelerregenden Tiefen (<1 pro Auftritt).

1 ist selbsterklärend. Für 2 sollte man mal ein bischen die MIDI-Spec
lesen, der ganze Spaß wird uncodiert übertragen und es gibt auch kein
Protokol (mit ARQ oder so). Jedes empfangene Byte wird interpretiert.
Und da liegt man mit einem Einzelbitfehler schnell mal eine kleine Terz
daneben...

Einen fröhlichen Tag wünschend
LOBI

 

[Peter Heitzer]

Andreas Lobinger <andreas.lobinger@netsurf.de> wrote:
: Aloha,

: Bernd Gumler schrieb:
: 1 ist selbsterklärend. Für 2 sollte man mal ein bischen die MIDI-Spec
: lesen, der ganze Spaß wird uncodiert übertragen und es gibt auch kein
: Protokol (mit ARQ oder so). Jedes empfangene Byte wird interpretiert.
: Und da liegt man mit einem Einzelbitfehler schnell mal eine kleine Terz
: daneben...
Das kommt ganz auf die Art der Musik an, die man spielt. Bei modernen
Kompositionen fällt das u.U. gar nicht auf. Ärgerlicher kann ein
Bitfehler bei einem Programchange-Befehl sein, z.B. Tuba statt
E-Gitarre und das bei Vollplayback.

 

[Bernd Gumler]

"Andreas Lobinger" <andreas.lobinger@netsurf.de> schrieb im Newsbeitrag
news:3F795887.2BDF2AEA@netsurf.de...

Aloha,

Bernd Gumler schrieb:
Ein Thema, zu dem ich im Internet bisher ausser einigen vagen
Andeutungen
nix gefunden hab. Angeblich gibts da schon fertig käufliche Lösungen
(u.a.
auf Bluetooth Basis), aber auf allen Links die ich bisher verfolgt
hatte:
Fehlanzeige, darum mal hier mal meine neugierige Frage, was den Bastlern
hier so dazu einfällt.

Problem: MIDI-Daten (seriell, nicht ganz 32 kbps) sollen drahtlos und
möglichst preisgünstig übertragen werden. Der Sender muß mobil sein.

Du solltest noch zwei Punkte in das Pflichtenheft aufnehmen:
1) Latenzzeit so kurz wie möglich. (bei Musik < 5ms (da kann man jetzt
streiten))
2) Rahmen- (das wäre Note-On/Off Paare), Symbol- (das wären Kommandos)
und Bitfehler in schwindelerregenden Tiefen (<1 pro Auftritt).

1 ist selbsterklärend. Für 2 sollte man mal ein bischen die MIDI-Spec
lesen, der ganze Spaß wird uncodiert übertragen und es gibt auch kein
Protokol (mit ARQ oder so). Jedes empfangene Byte wird interpretiert.
Und da liegt man mit einem Einzelbitfehler schnell mal eine kleine Terz
daneben...

1) sollte nicht so das Problem sein: Ein Note-On-Befehl "dauert" rund 0,07
ms, dann ist er sagen wir im PIC, der das Senden steuert. In 0,1 ms kann ein
20 MHz PIC einige tausend Instruktionen ausführen, sollte reichen um
Fehlerkorrektur aussenrum zu basteln. Die Funkübertragung schaffen die oben
erwähnten HomeFree-Funkmodems mit bis zu 1 Mbps, also eine Zeit deutlich
hinter dem Komma. Dann wieder etwas Zeit im Empfänger zum Auspacken und 0,07
ms zum Senden über UART ins MIDI-Netz. Nach meinen Abschätzungen klar unter
1 ms...Oder hab ich mich da wo gewaltig verrechnet?

2) würde in eine Menge Software-Arbeit ausarten. Was mir das grad so
einfällt: Bi-Direktional ist bei den meisten Fehlerkorrekturen, Prüfsummen
usw. ja unbedingt nötig? Bin in dem Gebiet halt (noch nicht) so gar nicht
fit...Wer liefert mir denn mal ein paar Begriffe mit denen ich da am
geschicktesten einsteige?

Vielen Dank
Bernd Gumler

P.S. Ja so sind se halt die Physiker: Spieltrieb und Neugierde...

 

[Andreas Lobinger]

Aloha,

Peter Heitzer schrieb:

Andreas Lobinger <andreas.lobinger@netsurf.de> wrote:
: Und da liegt man mit einem Einzelbitfehler schnell mal eine kleine Terz
: daneben...
Das kommt ganz auf die Art der Musik an, die man spielt. Bei modernen
Kompositionen fällt das u.U. gar nicht auf.

Du solltest mal deine Kenntnisse über moderne Kompositionen auf den
aktuellen Stand bringen...

Ärgerlicher kann ein
Bitfehler bei einem Programchange-Befehl sein, z.B. Tuba statt
E-Gitarre und das bei Vollplayback.

Ärgerlich ist's immer, gerade das wollte ich zum Ausdruck bringen.

Einen fröhlichen Tag wünschend
LOBI

 

[Jan-Hinnerk Reichert]

Bernd Gumler wrote:

"Andreas Lobinger" <andreas.lobinger@netsurf.de> schrieb im
Newsbeitrag news:3F795887.2BDF2AEA@netsurf.de...

Du solltest noch zwei Punkte in das Pflichtenheft aufnehmen:
1) Latenzzeit so kurz wie möglich. (bei Musik < 5ms (da kann man
jetzt
streiten))
2) Rahmen- (das wäre Note-On/Off Paare), Symbol- (das wären
Kommandos)
und Bitfehler in schwindelerregenden Tiefen (<1 pro Auftritt).

1 ist selbsterklärend. Für 2 sollte man mal ein bischen die
MIDI-Spec lesen, der ganze Spaß wird uncodiert übertragen und es
gibt auch kein Protokol (mit ARQ oder so). Jedes empfangene Byte
wird interpretiert. Und da liegt man mit einem Einzelbitfehler
schnell mal eine kleine Terz daneben...

1) sollte nicht so das Problem sein: Ein Note-On-Befehl "dauert"
rund 0,07 ms, dann ist er sagen wir im PIC, der das Senden steuert.
In 0,1 ms kann ein 20 MHz PIC einige tausend Instruktionen
ausführen, sollte reichen um Fehlerkorrektur aussenrum zu basteln.
Die Funkübertragung schaffen die oben erwähnten HomeFree-Funkmodems
mit bis zu 1 Mbps, also eine Zeit deutlich hinter dem Komma. Dann
wieder etwas Zeit im Empfänger zum Auspacken und 0,07 ms zum Senden
über UART ins MIDI-Netz. Nach meinen Abschätzungen klar unter 1
ms...Oder hab ich mich da wo gewaltig verrechnet?

Verrechnet nicht. Du unterschätzt bloß das, was in einem Funkmodem
geschehen kann.

Ein Funkmodem ist für einen anderen Anwendungsbereich konzipiert. Gute
Funkmodems sorgen für Datenintegrität und hohen Durchsatz.

So kann es sein, daß das Modem die Daten in Packeten transportiert.
Die sind dann auch mit Checksumme gesichert und alles. Das Problem
ist, daß dann bei einer fehlerhaften Übertragung, das Packet erneut
angefordert wird und so weiter bis zur Kapitulation. Da kommen
schnell mal ein paar Sekunden zusammen, wenn man ein Funkloch
erwischt. Also Vorsicht bei bewegtem Sender/Empfänger.

Das nächste Problem entsteht dann durch die Forderung nach hohem
Durchsatz. Das Modem weigert sich gegebenenfalls einen einzelnen
MIDI-Befehl direkt zu senden (da das Packet noch lange nicht voll
ist) und wartet lieber erstmal ein paar ms, ob noch was kommt.

Solche Wartezeiten sind ggf. konfigurierbar.

2) würde in eine Menge Software-Arbeit ausarten. Was mir das grad so
einfällt: Bi-Direktional ist bei den meisten Fehlerkorrekturen,
Prüfsummen usw. ja unbedingt nötig? Bin in dem Gebiet halt (noch
nicht) so gar nicht fit...Wer liefert mir denn mal ein paar Begriffe
mit denen ich da am geschicktesten einsteige?

Wie schon gesagt eine Fehlererkennung (Checksumme) bringt Dir nicht
viel, da für eine Wiederholung nicht genug Zeit ist. Natürlich ist
ein verspätetes Note-Off besser als gar keins.

Es gilt also Fehler zu vermeiden. Stichwort: ECC (error correcting
code). Einfaches Beispiel: sende ein Bit dreimal, nimm am Empfänger,
das was häufiger auftritt. In echt gibt es da viel tollere Dinge ;-)
Es gilt aber immer, daß man Sicherheit gegen Durchsatz eintauscht.

ECC läßt sich m.E. aber nur *im* Funkmodem selbst sinnvoll benutzen.

Jan-Hinnerk

 

[Andreas Lobinger]

Aloha,

Bernd Gumler schrieb:

"Andreas Lobinger" <andreas.lobinger@netsurf.de> schrieb im Newsbeitrag
Bernd Gumler schrieb:
Ein Thema, zu dem ich im Internet bisher ausser einigen vagen
Andeutungen nix gefunden hab. Angeblich gibts da schon fertig
käufliche Lösungen (u.a. auf Bluetooth Basis), aber auf allen Links
die ich bisher verfolgt hatte:
Fehlanzeige, darum mal hier mal meine neugierige Frage, was den Bastlern
hier so dazu einfällt.

Problem: MIDI-Daten (seriell, nicht ganz 32 kbps) sollen drahtlos und
möglichst preisgünstig übertragen werden. Der Sender muß mobil sein.

Du solltest noch zwei Punkte in das Pflichtenheft aufnehmen:
1) Latenzzeit so kurz wie möglich. (bei Musik < 5ms (da kann man jetzt
streiten))
2) Rahmen- (das wäre Note-On/Off Paare), Symbol- (das wären Kommandos)
und Bitfehler in schwindelerregenden Tiefen (<1 pro Auftritt).

1 ist selbsterklärend. Für 2 sollte man mal ein bischen die MIDI-Spec
lesen, der ganze Spaß wird uncodiert übertragen und es gibt auch kein
Protokol (mit ARQ oder so). Jedes empfangene Byte wird interpretiert.
Und da liegt man mit einem Einzelbitfehler schnell mal eine kleine Terz
daneben...

1) sollte nicht so das Problem sein: Ein Note-On-Befehl "dauert" rund 0,07
ms, dann ist er sagen wir im PIC, der das Senden steuert. In 0,1 ms kann ein
20 MHz PIC einige tausend Instruktionen ausführen, sollte reichen um
Fehlerkorrektur aussenrum zu basteln. Die Funkübertragung schaffen die oben
erwähnten HomeFree-Funkmodems mit bis zu 1 Mbps, also eine Zeit deutlich
hinter dem Komma. Dann wieder etwas Zeit im Empfänger zum Auspacken und 0,07
ms zum Senden über UART ins MIDI-Netz. Nach meinen Abschätzungen klar unter
1 ms...Oder hab ich mich da wo gewaltig verrechnet?

Ja, zunächst komme ich auf 2worte * 10bit/wort * 1s/31250bit -> 0.64ms.
Dann hast du unter anderem das Problem mit der Fehlerkorrektur.
Ohne jetzt in Details gehen zu wollen, was du an der Stelle brauchst
ist ein Blockcode. Die sind i.d.R konstruierbar, d.h. du kannst aus
den Vorgaben Blocklänge und korrigierbare/erkennbare Bitfehler
einen Code konstruieren. Einer der Eigenschaften des Codes ist
der sog. Codegewinn; das ist eine Vehältnisangabe um wieviel
weniger an Sendeleistung pro bit/Symbol du brauchst, um die gleiche
Fehlerrate wie uncodierte Übertragung zu erzielen. Leider leider
sind für so kurze Blöcke (8bit) keine guten Codes bekannt.

Zu den 1Mbit/s. Never underestimate the bandwidth of a station wagon
full of tapes. Die Bandbreite der Verbindung sagt leider leider noch
garnichts über die Latenzzeit (die wir hier mal als Durchlaufzeit
für 1 komplettes Byte annehmen wollen) aus.
Afaik kann man bei BT nicht sofort senden, sondern der MAC entscheidet,
wann die Verbindung gut genug ist und bläst dann gleich mehrere
Packete hinüber.

Wenn die Funkverbindung in einem freibenutzbaren Band stattfindet,
dann liegt das heutzutage > 300MHz. Das ist die Gegend, in der
die Wellenlänge anfängt mit der Raumgeometrie zu korrelieren. Du bekommst
dann schnell so Dinge wie Mehrwegeausbreitung und damit über kurz
oder lang fastfading. Der einzig mir bekannte gangbare Ausweg dafür
ist die übertragene Information über die Zeit zu verteilen, so das
selbst wenn grad mal Funkloch ist, ein Teil der Bits im nächsten
guten Bereich zu übertragen werden. Das kostet dich Zeit.

Alternative sind, wenn die Mehrwegeausbreitung ausgeprägt ist,
Diversity Verfahren, typisch RX-Div. Du brauchst dann auf der
Empfangsseite unabhängige Empfangspfade (Mehrere Antennen die
räumlich getrennt sind d.h. > 4*Wellenlänge).

2) würde in eine Menge Software-Arbeit ausarten. Was mir das grad so
einfällt: Bi-Direktional ist bei den meisten Fehlerkorrekturen, Prüfsummen
usw. ja unbedingt nötig? Bin in dem Gebiet halt (noch nicht) so gar nicht
fit...Wer liefert mir denn mal ein paar Begriffe mit denen ich da am
geschicktesten einsteige?

Nein. Ich würde kein Protokoll/Handshake aufsetzen, sondern tatsächlich
eine besonders sichere streaming Verbindung bauen mit mäßiger
Fehlerkorrektur und nachfolgender MIDI-Protokollanalyse (MIDI-MAP).

- FEC (Forward Error Correction), dort (klassisch) Reed-Solomon Codes
- Interleaving
- Maximum a posteriori (MAP) Decoder
- (gerne) Soft-
- Mobilfunkkanäle
u.s.w.

Einen fröhlichen Tag wünschend
LOBI

 

[Bernd Gumler]

"Andreas Lobinger" <andreas.lobinger@netsurf.de> schrieb im Newsbeitrag
news:3F797FA4.7F1FC34B@netsurf.de...

Aloha,
1 ms...Oder hab ich mich da wo gewaltig verrechnet?

Ja, zunächst komme ich auf 2worte * 10bit/wort * 1s/31250bit -> 0.64ms.

Und zwar wie gewaltig...naja, wie war der Spruch meines alten Mathelehrers
nochmal: Mathematik fängt da an, wo das Rechnen aufhört ;-)

Alternative sind, wenn die Mehrwegeausbreitung ausgeprägt ist,
Diversity Verfahren, typisch RX-Div. Du brauchst dann auf der
Empfangsseite unabhängige Empfangspfade (Mehrere Antennen die
räumlich getrennt sind d.h. > 4*Wellenlänge).

Bei dem Begriff fallen mir unsere normalen Drahtlosanlagen für Mikros auf
der Bühne ein.
Wäre es nicht ne Möglichkeit einen solchen Taschensender (UHF 710 bis 865
Mhz) über ein "Modem" (naja, eher nur dem "Mo"-Teil) mit meinem MIDI-Signal
zu speisen. Was über ne Telefonleitung mit deren doch bescheidener
Sprachqualität klappt sollte doch über die auf Sprachqualität getrimmten
Drahtlosanlagen auch funktionieren, auch in Bezug auf Bandbreite...

Vielen Dank auf alle Fälle schon mal für alle Beiträge, mich treibt halt vor
allem die Neugierde zu solchen Ideen.
Von fertigen MIDI-Funk-Anlagen hat auch noch niemand was gehört?

Bernd Gumler

 

[Carsten Kurz]

Bernd Gumler schrieb:

Problem: MIDI-Daten (seriell, nicht ganz 32 kbps) sollen drahtlos und
möglichst preisgünstig übertragen werden. Der Sender muß mobil sein (sprich:
Batteriebetrieb), erhält Daten z.B. von so einem 80er
Jahre-Modern-Talking-Showkeyboard.

Halbwegs zuverlässig dürfte das momentan wohl schon mit BT gehen. Die
meisten anderen bezahlbaren Funkmodule sind von der Bandbreite her zu
eng, allemal, wenn man Fehlerkorrektur einbauen will. Da müsste man
jedenfalls selbst einiges an KnowHow reinstecken. Allerdings muss der
Funkkanal nicht unbedingt 31250 machen, lediglich die UARTs müssen das
können, intern kann man auch mit weniger arbeiten, fürs Spielen reicht
das allemal.

Am simpelsten dürften diese transparenten SPP BT Module sein, die gibts
mit unterschiedlichen Reichweiten/Classes.
man muss halt zur Zeit für so ein Modul inkl. Antenne zwischen 60 und
100 Euro rechnen.

Keine Ahnung, wie groß die Latenz bei solchen Modulen ist, muss man wohl
austesten. Es dürfte nicht mehr lange dauern, und solche Module sind
billger als die einfachen ISM/433 MHZ Teile.

- Carsten




--
Audio Visual Systems fon: +49 (0)2238 967926
Carsten Kurz fax: +49 (0)2238 967925
Fasanenweg 38a email: audiovisual@t-online.de
50259 Pulheim / Germany WGS84:N50°58'44.7" E06°47'03.5"