Mpx-Signal über IP (WLan)

Status
Für weitere Antworten geschlossen.

mmdj

Benutzer
Hallo.
Kennt jemand eine Hardwarelösung, mit der ich ein fertiges MPX-Signal codieren kann, um es durch ein normales Ethernet Netzwerk zu übertragen? Idee: WLan
Auf der anderen Seite soll das Signal natürlich wieder decodiert und dem UKW-Sender zugeführt werden.
 
AW: Mpx-Signal über IP (WLan)

Dafür gibt es MPX Link Transmitter.
Ich glaube es ist nicht einfach bzw. fast unmöglich ein komplettes MPX Signal "zu Streamen".

Hinztriller kennt sich damit aber besser aus.



gruß
 
AW: Mpx-Signal über IP (WLan)

theoretisch geht das. Man müsste das Singal mit 192kBit/s samplen, Mono langt ja, das ganze verlustfrei in PCM, kommt man auf schnuckelige 3 Megabit. Ob WLan da so optimal ist, wegen der Paketverluste und des Jitterns wage ich mal zu bezweifeln.

Geräte gibt es wohl, frag mal bei www.sumatronic.ch an, die sagten mir, sie kennen sowas.
 
AW: Mpx-Signal über IP (WLan)

Danke schon mal für die Antworten.
Es gibt sowas von "Elettronika" aus Italien (Elettronika MPX Link) allerdings als E1 Stream, dann bräuchte man wieder einen E1-IP Converter, etc... Vielleicht kennt jemand Geräte, die das direkt machen.
 
AW: Mpx-Signal über IP (WLan)

theoretisch geht das. Man müsste das Singal mit 192kBit/s samplen, Mono langt ja, das ganze verlustfrei in PCM, kommt man auf schnuckelige 3 Megabit. Ob WLan da so optimal ist, wegen der Paketverluste und des Jitterns wage ich mal zu bezweifeln.

Das MP3-Zeitalter hinterlässt auch beim verehrten Hinztriller Spuren: Er meinte eigentlich 192kHz. Mit 16 Bit in Mono und als PCM kodiert kommen wir dann aber auch auf knapp 4 MBit/s:

192000Hz * 2 Byte = 384000 Byte/s

Dann hängen wir noch jeweils ein Start/Stopp-Bit und einigen Protokoll-Overhead dran und sind damit ganz locker bei mindestens 4 MBit/s.

Eigentlich müßte eine reine Hardwarelösung nicht mit 192 kHz sampeln. Theoretisch reichen auch 114 kHz völlig aus -> max. und hochgegriffen 3 MBit/s. Ein WLAN sollte das bei guten Empfangsbedingungen schaffen. Außerdem gibt es noch QOS (Quality of Service) bzw. "DO NOT FRAGMENT".


Frage an mmdj: Wie weit soll dein WLAN für die Programmzuführung eigentlich reichen? Man kann Richtantennen kaufen (oder wie in der Zeitschrift c't mal getestet) Pringles- oder Kaffeedosen entsprechend "umbauen". Zumindest in DE müßte man dann aber die Sendeleistung verringern, um den Antennengewinn auszugleichen. Aber wer will das schon? In den Schluchten Südtirols stört das sicher niemanden. ;)

vg Zwerg#8


EDIT: Ein MPX-Signal ist doch eigentlich auch nur Ultraschall. Könnte man dieses Signal nicht vor der Übertragung über WLAN mit FLAC behandeln? Das würde zunächst die zur Übertragung notwendige Bandbreite verringern, dafür könnte man dann jede Menge Fehlerkorrektur einbauen.
 
AW: Mpx-Signal über IP (WLan)

Also die Wlan-Verbindung an und für sich wäre nicht das große Problem... Bei uns sind die Auflagen des Kommunikationsministeriums und der Landesumweltagentur sehr streng! Da wird genau nachkontrolliert.
Es wären 6Km natürlich mit Sichtverbindung. Eine 18Mbit/s Verbindung sollte man mit bem 802.11h Standard auf 5GHz hinbekommen.

Eine Alternative wäre das Signal zu demodulieren, also ganz normalen Audio-Stream zu übertragen und dann am Sender wieder einen RDS und Stereoencoder installieren... Wenns anders gar nicht geht. Dann hat man halt nicht mehr den Vorteil, dass man vom Sendestudio aus bestimmte Einstellungen verändern kann. z.B. das RDS. Auch die Demodulation und Remodulation sind nicht so toll...
 
AW: Mpx-Signal über IP (WLan)

192000Hz * 2 Byte = 384000 Byte/s => das wären nur 384 kBytes. Wir reden aber von Kilobit, also das ganze noch mal 8 dann kommen wir auf 3072 kBit/s :)
 
AW: Mpx-Signal über IP (WLan)

Ein Byte hat seit Mitte der 50er Jahre (IBM hat das wohl eingeführt) 8 Bit. Bei einer seriellen Übertragung braucht man zumindest ein Startbit. Allgemein rechnet man pro seriell übertagenen Byte also mit 10 Bits. Man kann also bei den Bytes/s stumpf eine Null hinten dranhängen.

Also ergeben 384000 Bytes/s etwa 3,8 MBit/s netto. Und wie geschrieben, kommt auch noch (TCP)Protokoll-Overhead hinzu.

Nix für ungut.
Grüßle Zwerg#8
 
AW: Mpx-Signal über IP (WLan)

Ich dachte immer die Bitrate sei Samplingrate [Hz] * Abstasttiefe * Anzahl der Kanäle
Wenn ich 192000 Hz Samplingrate habe und das ganze in Mono (1 Kanal) mit 16 Bit Signaltiefe abtaste komme ich auf eine Datenrate von 3072000 Bit/s dividiert duch 1024 => 3000 kBit/s
 
AW: Mpx-Signal über IP (WLan)

Ich dachte immer die Bitrate sei Samplingrate [Hz] * Abstasttiefe * Anzahl der Kanäle

Das ist richtig. Wie gesagt, zunächst gilt:

192kHz * 2 Bytes = 384.000 Bytes/s oder

192kHz * 16 Bit = 3072000 Bits/s

Wenn man diese Zahl in Megabit/s umrechen will, kommt man logischerweise auf 3,072 Megabit/s. Und bekanntlich rechnen gerade Leute aus dem "Informatikbereich" aber mit 2 hoch 10 = 1024 Bytes. Ein "Mega"Byte entspricht nach dieser "Weltanschauung" also 1024 hoch 2 = 1073741824 Bytes, nicht 1000 hoch 2 = 1 Mio.

Wenn ich 192000 Hz Samplingrate habe und das ganze in Mono (1 Kanal) mit 16 Bit Signaltiefe abtaste komme ich auf eine Datenrate von 3072000 Bit/s dividiert duch 1024 => 3000 kBit/s

Ja, aber nur Netto und mit der Weltanschauung eines Informatikers. Real (und rein physikalisch) müssen trotzdem

3072000 Bit/s + Overhead übertragen werden!


Wie "groß" du nun den "Overhead" definierst kann ich (im Moment) nicht einschätzen. Wie gesagt: Üblicherweise rechnet man mit 10 Bit pro Byte + Overhead.


EDIT: Potenzprobleme. ;) "hoch 3" in "hoch 2" geändert....
 
AW: Mpx-Signal über IP (WLan)

@@mmdj
Kannst Du die ganze Struktur incl. aller Standorte und verfügbarer Signale mal beschreiben? Vielleicht ergeben sich daraus ja ganz andere Ansätze auch hier über 1000 bzw. 1024 Bytes pro kByte zu diskutieren...
markus
 
AW: Mpx-Signal über IP (WLan)

Hallo Markus!
Punkt A: Ballempfang möglich, freie Sicht zu einem bestehnden Sender.
Punkt B: Neuer Senderstandort, nur Sichtkontakt zu Punkt A.
Geplante Verbindung: Zwischen Punkt A und B.
Mehr steht momentan (noch) nicht zur Verfügung.
 
AW: Mpx-Signal über IP (WLan)

Welche Steuerinformationen werden denn benötigt? RDS-Daten nehme ich an? Also der Text auf dem Radiodisplay und evtl. noch TP. Wie werden die RDS-Daten denn bisher generiert? Ich nehme an, dass die RDS-Daten ferner per RS232 / RS485 in einen entsprechenden Encoder eingespeist werden. Vermutlich kommt hierbei UECP zum Einsatz. Da RDS-Daten (zumindest der Theorie folgend) verlustfrei übertragen werden sollten, bietet sich hierbei evtl. TCP (!) und das Konvertieren bzw. Weiterreichen der seriellen Daten an. Also UECP-Daten -> Schnittstelle -> IP -> Schnittstelle -> zweiter RDS-Encoder -> Sender. Für das reine Audiosignal würde ich per sé (um die Puffergrößen zu minimieren) bei einer solchen Konstellation lieber UDP einsetzen wollen. Dieses Protokoll gibt zwar keine Garantie, dass die Daten tatsächlich und in der richtigen Reihenfolge beim Empfänger eintreffen. Bei Paketverlust oder Jitter leidet zwar die Übertragungsqualität, der Dienst wird jedoch nicht vollständig gestört oder "hängt" (vgl. VoIP).

Ein anderes Problem stellt sich bei der Laufzeitverzögerung. Da IP-Pakete in ihrer Laufzeit zwischen 2 Punkten (zumindest in der Theorie) nur schwer einzuschätzen sind, müsste man entsprechende Messungen anstellen. Stichwort: Synchronisationspunkt der Ausstrahlung. Man stelle sich folgendes Szenario vor: Das Autoradio eines Hörers wechselt per RDS auf eine alternative Frequenz des gleichen Programms (AF). Der Hörer bekommt einen Sprachfetzen im Überlappungsgebiet zweiter Funktürme doppelt vorgespielt, weil einer konventionell und einer per IP bespielt wird. Da muss man entsprechend Abhilfe schaffen, um das Erreichen der Wellen im Überlappungsgebiet möglichst zu synchronisieren.

An einem Feldversuch bin ich in der Tat schon sehr interessiert und wäre auch bereit (gern unter Einbeziehung weiterer Personen und Messtechnik) an der Realisation mitzuhelfen. PN genügt.
 
AW: Mpx-Signal über IP (WLan)

Im Prinzip werden keine weiteren Informationen ausser das Audio Signal gebraucht. Natürlich wäre es fein, wenn RDS auch dabei wäre. Muss aber nicht sein.
Momentan läuft das Signal im Studio durch den Soundprozessor, RDS kommt dazu und über Richtfunkstrecken 2,4GHz geht's dann zu jedem Sender.

Es wird also für diese eine Strecke wohl sowas werden:
Audio Over IP
 
AW: Mpx-Signal über IP (WLan)

Warum soll den der RDS Coder im Studio bleiben ?
Es wird wahrscheinlich billiger sein, diesen beim Sender zu plazieren.
Dann einfach durch einen Stereo Coder beim Sender und fertig.

Über Wlan (erst recht 2.4ghz) würde ich niemals eine Zuführung in Betracht ziehen.
Dafür gibt es ja MPX Link Transmitter, die erstens sehr zuverlässig, zweitens eine recht hohe reichweite je nach bandlage haben und drittens auf einschlägig Bekannten Internetseiten gebraucht sehr günstig im Set zu erwerben sind.

Neu erhälst du ein Set für 2000€ denke ich mal.




gruß
 
AW: Mpx-Signal über IP (WLan)

Ich stimme bennylein voll zu.

Wenn du einmal Audio über IP über WLAN gemacht hast (mit Latenz kleiner 2 Sekunden), dann willst Du das nicht mehr wirklich haben.

Markus
 
AW: Mpx-Signal über IP (WLan)

Der Preis ist hier nicht das große Problem. Vielmehr geht's darum, dass WLan im 5GHz Bereich bis zum 1W EIRP frei sein sollte, also keine Genehmigungen gebraucht werden...
Hier bei uns machen es alle Sender so, dass Stereo Coder und RDS im Studio bleiben, das fertige MPX Signal kommt dann per Richtfunk zu den einzelnen Sendern.
Somit lassen sich RDS-Daten im Studio einstellen.


Ich stimme bennylein voll zu.

Wenn du einmal Audio über IP über WLAN gemacht hast (mit Latenz kleiner 2 Sekunden), dann willst Du das nicht mehr wirklich haben.

Markus

Warum?
 
AW: Mpx-Signal über IP (WLan)

ich glaub markus meinte ned wlan sondern link transmitter.
Ist dann noch kleiner als 2s. viel viel kleiner. Im ms sekunden bereich.



gruß
 
AW: Mpx-Signal über IP (WLan)

@mmdj und bennylein
Ich meinte schon WLAN. Wenn man Audio über IP überträgt bekommt man das mit 15 Sekunden Latenz (wie z.B. mit Icecast und Streaming) gut hin. Auch bei WLAN sollte das noch ohne Probleme gut gehen. Aber wenn die Latenz kürzer wird, werden auch die Möglichkeiten zur Fehlerkorrektur, um z.B. fehlerhafte oder fehlende IP Pakete zu berichtigen, immer geringer. Bei 2 Sekunden Latenz sollten schon alle Pakete richtig ankommen, um ein gutes Signal zu erhalten. Bei weniger als 2 Sekunden Latenz wird das ganze noch schwieriger, insbesondere bei WLAN, was ja deutlich anfälliger ist für Störungen wie LAN.

Ein richtiger Link Transmitter überträgt alles ohne IP deutlich besser, einfacher und mit weniger Latenz, weil die Fehlerkorrektur nicht paketorientiert arbeitet.

>> dass WLan im 5GHz Bereich bis zum 1W EIRP frei sein sollte
Warum muß denn immer alles ohne Frequenzzuteilung möglich sein? Laßt Euch eine Frequenzzuteilung bei möglichst kleiner Frequenz (desdo kleiner die Frequenz, desdo weniger Beeinflussung durch Hindernisse) für eine Richtfunkstrecke ohne IP zuteilen. Das kostet vergleichsweise wenig und macht anschließend noch weniger Ärger. Aber Ihr habt dann eine Frequenz auf der nur Ihr funkt und sonst keiner.

Grüße, Markus
 
AW: Mpx-Signal über IP (WLan)

Hallo Markus75.
Das mit den Frequenzen ist bei uns in Italien nicht so einfach. Überhaupt in Südtirol...

Ok, Icecast, Shoutcast usw. haben gleich einmal 10sek und mehr Verzögerung. Mit spezieller Hardware (z.B. Barix-Geräte), siehe oben verlinkten Thread, sollte eine weitaus verzögerungsarmere Übertragung möglich sein. Außerdem hat man das Problem nicht, dass ein PC abstürzen kann usw...
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben