Ich habe vor 6 Datenströme je ~12Mbps(=74,328) über ein LAN-Kabel zu Übertragen und hinterher wieder zu trennen. Dabei ist mir der Datendurchsatz und die stätige Zuverlässigkeit dieser Verbindung sehr wichtig. Ich will auf den MAC Controller und TCP/IP-Stack verzichten und Steuere den PHY direkt an (Ich Glaub das ist besser für einen konstanten Datenstrom). Nur mir fällt jetzt kein praktikabler Weg für die Datenübertragung zwischen Datenstrom und PHY ein. Ein µC währe mir am liebsten(Daten müssen noch "zusammen geschnitten" werden) bloß habe ich bisher nur Erfahrung bei der PIC16F Serie Gesammelt. Wie würden eure Lösungsansätze aussehen? gibt es vielleicht schon fertige IC die das schaffen? Danke.
Ich habe mir das so vorgestellt das ich erstmal 64bit Daten Aufnehme und sie dann Sende. Da die Daten isochron ankommen müssen diese hinterher(beim decodieren) auch wieder so rauskommen. Dazwischen will ich erstmal den Datendurchsatz schaffen.
Die Idee mit dem Phy finde ich gut. So setzt Du auf bewährte Technologie auf. Diese Dinger anzusteuern kann nicht allzu schwer sein. Soweit ich weiß braucht man dazu ein SPI oder I²C Interface zur Konfiguration, sowie Rx und Tx Leitungen für die Daten. Ich würde mich allerdings über die zu erwartende Fehlerrate informieren.
Als PHY verwende ich momentan den DP83848CVV der kommt auch ohne SPI oder I2C aus. Nur hat der 4 TX Pins an denen ich 6 Datenströme seriell anbinden muss. Zu dem muss auch die Taktrate kompatibel gehalten werden. Ankommen tuen die Daten mit 6x12.288Mbps die müssen dann auf 4x25Mbps sinnvoll aufgeteilt werden. Zudem muss der PHY regelmäßig Disabled werden damit der Empfänger sich wieder neu synchronisieren kann. Meineserachtens währe für diese Aufgabe ein µC am besten geeignet. Bloß habe ich bisher keinen finden können der die Daten so schnell verarbeiten kann. Der müsste dann so ungefähr 200MHz CPU tackt haben um den PHY schell genug seine Daten zu liefern Während er Weiterhin welche aufnimmt. Wichtig ist auch wie ich den µC mit dem PHY synchronisiere da er mir ja ein tackt vorgibt.
Hi, wäre es nicht sinnvoller die 6x12.288Mbps auf 3 * 24.576Mbps aufzuteilen? Das lässt sich sicher einfacher realisiseren. Gruß Jonas
Sind die 12Mb Datenströme zueinander taktsynchron? Bestehen die Datenströme aus Rohdaten, d.h. ein reiner Bitmultiplex ist ausreichend, weil ein irgendwie darin enthaltenes Framing im Multiplex mit übertragen wird?
@ Martin Elend (iiimaddiniii) >Ich habe vor 6 Datenströme je ~12Mbps(=74,328) über ein LAN-Kabel zu >Übertragen und hinterher wieder zu trennen. Klingt nach 100 Mbit Ethernet. >Ich will auf den MAC Controller und TCP/IP-Stack verzichten und Steuere >den PHY direkt an (Ich Glaub das ist besser für einen konstanten >Datenstrom). Glauben heißt nicht wissen. Als unterste Schicht solltest du direktes Ethernet mit seinen Frames nutzen, dafür ist es gebaut und milliardenfach bewährt. Was man darüber für eine Protokoll setzt, ist diskussionsfähig. Dr einfachste Ansatz ist die Daten direkt in die Ethernetfragmes zu packen und gut. Etwas aufwändiger, wenn gleich schon deutlich leistungsfähiger ist es, UDP zu nutzen, dann kommt man sogar durch die unendlichen Weiten des Internet, wenn das nötig ist. > Nur mir fällt jetzt kein praktikabler Weg für die >Datenübertragung zwischen Datenstrom und PHY ein. Erfinde das Rad nicht neu und informiere dich erstmal über bestehende Verfahren, bevor du, gerade mit deinem Kenntnisstand, was selbstgestricktes machen wilst. Derartige Datentunnel gint es schon lange in allen möglichen Konstellationenen. > Ein µC währe mir am >liebsten(Daten müssen noch "zusammen geschnitten" werden) Na dann mal viel Spass bei 80 Mbit/s. Da sind selbst größere 32 Bit CPUs gut beschäftigt. > bloß habe ich >bisher nur Erfahrung bei der PIC16F Serie Gesammelt. Von Dreirad gleich in die Formel 1? Ob das sinnvoll ist? > Wie würden eure >Lösungsansätze aussehen? gibt es vielleicht schon fertige IC die das >schaffen? Was sind denn das für Datenströme? I2S?
@Jonas Biensack Das wäre zwar einfacher aber der PHY gibt mir fest vor das es 4x25Mbps(TXD0..3) sein müssen. Ich fände es auch besser eigene Datenraten festlegen zu können. Ich kenne leider auch keine andere Schnittstelle die 80Mbps FullDuplex auf 50m länge unterstützt. Also wenn keiner einen kompatiblen PHY kennt und auch keine andere Schnittstelle die den Datendurchsatz auf der länge schafft muss ich die Daten konvertieren. Die frage ist nur wie. @A. K. Die 12Mbps Datenströme sind tacktsyncron. Ja ein Bitmultiplex würde gut laufen, aber leider nur auf kurzer Distanz ohne speziellen Treiber. Als Datenleitung steht auf jeden Fall ein 50m cat5 LAN Kabel Fest das ich doppelt nutze. @Falk Brunner Ja Ich muss zugeben ist schon ein "kleiner" Sprung den ich da mache. Das die meisten CPUs zu langsam sind habe ich auch schon festgestellt. Kennst du denn alternativen zu µC. Die Daten kommen von Optischen Toslink Empfänger die ein ADAT Signal führen. Jetzt zum Ethernet: Ich benötige ein sehr konstanten Datenstrom da ich keine großen Latenzen haben will. Mein Gedanke war, dass wenn ein CRC im Ethernet Frame auftaucht Wird das Paket nochmal gesendet und der Datenstrom ist Futsch. Außerdem werden viele nicht benötigte Daten wie MAC Adresse mitgesendet, ist eine Direkte Verbindung Zwischen sender und Empfänger.
@ Martin Elend (iiimaddiniii) >Ja Ich muss zugeben ist schon ein "kleiner" Sprung den ich da mache. Das One smal setp for man, one giant leap for mankind . . . ;-) >die meisten CPUs zu langsam sind habe ich auch schon festgestellt. >Kennst du denn alternativen zu µC. Die Daten kommen von Optischen >Toslink Empfänger die ein ADAT Signal führen. Aha. Hmmm. Es muss auf jeden Fall einer sein, der das ADAT Signal mit einem dafür speziallisierten Interface einlesen kann. Dann die Daten fix in einen Ethernet-Frame packen und fertig. Das Ganze mit einem kleinen FIFO entkoppelt. Da es ja ein sychroner Datenstrom mit eigener Taktquelle ist, darf man sich hier mit dem Thema Taktrückgewinnung, PLL und plesiochrone System beschäftigen. D.h., in deinem Ethernet, das nicht synchron zu deinen Daten ist, musst du Lücken in den Daten vorsehen, die je nach Frequnzabweichung mal größer oder kleiner werden (Stopfbits, bzw. Stopfbytes). Aus diesen Informationen musst du am Empfänger dann wieder mittels (digitaler) PLL den ADAT Takt gewinnen. Alles in allem nix für Anfänger, das ist schon was für die hohen Semester. >Ich benötige ein sehr konstanten Datenstrom da ich keine großen Latenzen >haben will. Naja, dann könnte man es anders machen, wenn gleich das auch viel Aufwand bedeutet. Man baut einen klassischen Multiplexer auf Bitebene. Dessen Takt wird mittels PLL fest an den Eingangstakt angebunden, z.B. x5. Dann muss der Datenstrom noch brauchbar kodiert werden, z.B. 8B10B und los gehts. Auch nix, was man mal nebenbei macht. Hmm, da fällt mir was ein. Man könnte einen CameraLink Tranceiver misbrauchen, die multiplexen 28 Bit auf 3 Doppeladern, Plug & Play. Aber dann sind 24 Bit ungenutzt. Auch nicht so schön. Oder man baut sowas im Kleinformat nach, nur 1 Datenleitung und 1 Taktleitung. Das vereinfacht den Empfänger. Hmm, sowas hab ich mal vor langer Zeit gebaut, einen High Speed UART. Könnte man hier auch machen. Je 4 Bit + Start + Stop in Datenwort packen und mit x6 Takt versenden. Für den Takt könnte man auf DDR Übertragung zurückgreifen, um die Taktfrequenz zu halbieren. Der Empfänger ist sehr einfach aufgebaut. Hmmm, das könnte man relativ leicht in einen etwas größeren CPLD packen. Aber auch das ist Arbeit und deutlich über PIC16 Niveau ;-) > Mein Gedanke war, dass wenn ein CRC im Ethernet Frame >auftaucht Wird das Paket nochmal gesendet und der Datenstrom ist Futsch. Daran musst du dich gewöhnen, wenn du es schnell und einfach haben willst. Wenn Übertragungsfehler nicht nur erkannt, sondern auch KORRIGIERT werden sollen, brauchst du FEC (forward error correction). >Außerdem werden viele nicht benötigte Daten wie MAC Adresse mitgesendet, >ist eine Direkte Verbindung Zwischen sender und Empfänger. Ethernet ist ja auch ein Netzwerkstandard un keine ultrasimple Punkt zu Punkt Verbindung.
Falk Brunner schrieb: > @ Martin Elend (iiimaddiniii) > >>Ich habe vor 6 Datenströme je ~12Mbps(=74,328) über ein LAN-Kabel zu >>Übertragen und hinterher wieder zu trennen. > > Klingt nach 100 Mbit Ethernet. > Klingt eher nach zwei 100 Mbit Leitungen oder einer Gbit-Leitung. Wenn die Rohdaten schon 80 Mbit betragen und dazu noch Ethernetframes und Leerräume zwischen den Paketen kommen... Wenn man plant etwas zu übertragen, sollte man min. 1/3 "Luft" lassen, vorallem wenn es darauf ankommt, alles zuverlässig zu übertragen.
Irgendwie hört sich das ganze noch einem "Hobbyprojekt" an. Beschreibe doch mal bitte was das ganze denn werden soll wenn es fertig ist. Evt. können wir dann auch noch bessere Tipps geben, als nur 80MB/s zu übertragen.
@ Phantomix Ximotnahp (phantomix) >Klingt eher nach zwei 100 Mbit Leitungen oder einer Gbit-Leitung. Nö. >Wenn die Rohdaten schon 80 Mbit betragen und dazu noch Ethernetframes >und Leerräume zwischen den Paketen kommen... Schon mal geschaut, wie groß die sind? http://de.wikipedia.org/wiki/Ethernet#IEEE_802.3_Tagged_MAC_Frame Ethernet header sind 26 Byte + 4 Byte CRC, Inter-Frame-Spacing sind minimal 12 Byte http://de.wikipedia.org/wiki/Inter_Frame_Spacing Macht in Summe 42 Byte. Wenn man 1000 Bytes/ Frame überträgt, sind das gerade mal 4% Overhead. >Wenn man plant etwas zu übertragen, sollte man min. 1/3 "Luft" lassen, >vorallem wenn es darauf ankommt, alles zuverlässig zu übertragen. Nicht, wenn man eine Punkt zu Punkt Verbindung hat, dier braucht man nahezu 0 Reserve, weil niemand anderes dazwischenfunken kann.
Martin Elend schrieb: > Die 12Mbps Datenströme sind tacktsyncron. Ja ein Bitmultiplex würde gut > laufen, aber leider nur auf kurzer Distanz ohne speziellen Treiber. Als > Datenleitung steht auf jeden Fall ein 50m cat5 LAN Kabel Fest das ich > doppelt nutze. Das eigentliche Problem ist also die Reichweite der physikalischen Signale und jedwedes durch Ethernet-PHY erzwungene Framing verkompliziert die Sache erheblich, weil erst dadurch überhaupt eine Taktratenanpassung und Pufferung erforderlich wird. Eigentlich benötigst du also eine Bit-Modulation mit Taktrückgewinnung und passende Transceiver. Zu den Transceivern fallen mir dazu als Roh-Idee die SFPs aus dem Netzwerkbereich ein, die zwar meist für Fiber bekannt sind, aber auch für Kupfer/RJ45 exitieren. Deren elektrisches Interface ist ein reiner serieller Bitstream: http://en.wikipedia.org/wiki/Small_form-factor_pluggable_transceiver
Falk Brunner schrieb: > @ Phantomix Ximotnahp (phantomix) > >>Klingt eher nach zwei 100 Mbit Leitungen oder einer Gbit-Leitung. > > Nö. Doch. >>Wenn die Rohdaten schon 80 Mbit betragen und dazu noch Ethernetframes >>und Leerräume zwischen den Paketen kommen... > > Schon mal geschaut, wie groß die sind? ... > Macht in Summe 42 Byte. Wenn man 1000 Bytes/ Frame überträgt, sind das > gerade mal 4% Overhead. Er redet von 64 Bytes sammeln und dann übertragen. Damit wären das 64 + 42 = 106 Bytes gesamt oder eine Bruttodatenrate von 132 MBit/s. Vielleicht kann er gar nicht warten bis 1000 Bytes voll sind weil dann die Latenz zu groß ist o.ä.
Falk Brunner schrieb: > @ Phantomix Ximotnahp (phantomix) >>Wenn man plant etwas zu übertragen, sollte man min. 1/3 "Luft" lassen, >>vorallem wenn es darauf ankommt, alles zuverlässig zu übertragen. > > Nicht, wenn man eine Punkt zu Punkt Verbindung hat, dier braucht man > nahezu 0 Reserve, weil niemand anderes dazwischenfunken kann. Vielleicht dazu noch: Ich sage nicht, dass es nicht geht, nur dass es kein schöner Ansatz ist, von vorn herein seinen Übertragungskanal aufs letzte Bit auszureizen. Wenn man also die Chance hat sowas richtig zu planen, lässt man da genügend Luft nach oben. Auch wenn das ein Gigabitkabel statt 100 MBit bedeutet.
Martin Elend schrieb: > Mein Gedanke war, dass wenn ein CRC im Ethernet Frame > auftaucht Wird das Paket nochmal gesendet und der Datenstrom ist Futsch. > Außerdem werden viele nicht benötigte Daten wie MAC Adresse mitgesendet, > ist eine Direkte Verbindung Zwischen sender und Empfänger. Ethernet zwingt niemanden, irgendwelche Pakete zu wiederholen. Das muß die höhere Schicht schon selber machen, wenn sie das will (TCP nimmt man dafür gerne). Ethernet selbst wiederholt Pakete nur bei Kollisionen, also auf einem halbduplex-Medium. Man kann einem Ethernet-Chip einreden, ein CAT5-Kabel sei halbduplex, aber man kann das auch bleibenlassen. Normalerweise hängt der Ethernet-Sender eine 32-bit-CRC an, aber das kann man abschalten. Normalerweise prüft der Ethernet-Empfänger die CRC und ignoriert das Paket, wenn sie nicht stimmt, aber dieses Verhalten kann man abschalten. Üblicherweise schreibt man vorne im Ethernet-Paket die Empfänger- und Absenderadresse rein; moderne Ethernet-Chips können das automatisch. Aber das kann man abschalten bzw. bleibenlassen. Normalerweise prüft der Ethernet-Empfänger anhand der Adresse vorne, ob das Paket für ihn ist, und ignoriert es andernfalls. Aber auch dieses Verhalten läßt sich abschalten ("promiscuous mode"). Wenn sich also beide Enden das Kabels einig sind, kann das Ethernetpaket recht effizient aufgebaut sein: Präambel + SFD + Nutzdaten + interframe gap, macht also 20 Byte "Verpackung", d.h. ab 80 Byte Nutzdaten pro Paket geht die Rechnung auf. Etwas längere Pakete sind natürlich ratsam, wegen Toleranzen bei den Taktfrequenzen, aber wegen der Latenz will man die natürlich so klein wie möglich haben; da kann schon 80 Byte zu viel sein, zumal die Ethernet Pakete ja sowohl beim Sender als auch beim Empfänger je einmal komplett im RAM liegen müssen.
Wie immer, die Loesung kommt vor der Aufgabe... Lass uns mal wissen, was das Ganze soll. Allenfalls kann man auch einen SERDES nehmen, der kann zB 64bit auf's mal serialisieren, und deserialisieren. Sonst kann man sich selbst einen SERDES mit je einem FPGA basteln,
Ich wuerd auch SERDES verwenden. Ein CAT6 Kabel hat 4 Aderpaare. Eins davon fuer den Clock. Dann 3 fuer synchrone Daten mit 30MBit oder so. Das kleinste FPGA sollte das koennen.
Falk Brunner schrieb: > Ethernet ist ja auch ein Netzwerkstandard un keine ultrasimple Punkt zu > Punkt Verbindung. Deshalb will ich auch kein Ethernet verwenden sondern nur die Hardware um die Daten über ein Cat5 Kabel zu senden. Dann brauch ich mir auch keine sorgen um die Hardware-Übertragung machen. @Phantomix Ximotnahp Ich verwende kein Ethernet da es in diesem Fall kein nutzen hat: Falk Brunner schrieb: > Ethernet ist ja auch ein Netzwerkstandard und keine ultrasimple Punkt zu > Punkt Verbindung. Ich will nur die Hardware verwenden da diese über lange Distanzen immer noch gut lauft. Dann habe ich nur noch 2Byte Overhead vom Frame start und Frame End(macht der PHY schon intern). Zur not könnte ich von der einen LAN Leitung auch alle 4 Aderpaare nutzen und zwei Verbindungen aufbauen(obwohl ich mir die für eventuelle Erweiterungen vorbehalten wollte. @Markus Müller+Martin schrieb: > Di willst das hier haben: > > http://appsys.ch/products/34-digitalaudio/55-adx32badx64b Es Geht darum ein "Digitales Audio Multicore" zu erstellen welches ich zum Abmischen benutzen will. Das alles möglichst mit kleiner Latenz(max 100µs). Ja im Prinzip will ich eine ähnliche Funktion erzielen, nur ist mir das keine 558 Euro wert und ich kann noch einiges im Bezug auf Datenübertragung lernen. @Dumpfer Nilp (Gast) Deine Idee ist ähnlich der von Falk Brunner: > Naja, dann könnte man es anders machen, wenn gleich das auch viel > Aufwand bedeutet. Man baut einen klassischen Multiplexer auf Bitebene. > Dessen Takt wird mittels PLL fest an den Eingangstakt angebunden, z.B. > x5. Dann muss der Datenstrom noch brauchbar kodiert werden, z.B. 8B10B > und los gehts. > Auch nix, was man mal nebenbei macht. Nur muss ich mich dann auch noch um die zuverlässige Hardware Übertragung kümmern. Ich klaube ich werde mir wohl mittels FPGA einen FIFO bauen der auch für den richtigen Datenfluss sorgt. Muss mich in das Thema jetzt erstmal richtig einlesen.
Am einfachsten dürfte es sein einen optischen Transceiver zu benutzen. Die findet man auf BASE-FX-karten und sind standadisiert. Arbeiten mit ECL und können je nach Fabrikat mit bis zu 250 MHz Bittakt arbeiten. Wenn die Ferrulen i.O. sind, gibt es praktisch keine Bitfehler. Also könnte ein CPLD oder FPGA deine ADAT-Ströme zu einem einkanal-Bitstrom muxen. Dafür musst du aller Wahrscheinlichkeit nach trotzdem puffern.
Mit Lichtleiter-Kabel möchte ich nicht so gerne arbeiten da die ziemlich empfindlich sind und schnell kaputt gehen wenn ein par Leute drauf treten. Zu dem Finde ich ist das schon ein bisschen überdimensioniert. Dass ich puffern muss ist mir schon klar nur will ich den Puffer so klein wie möglich halten.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.