Hallo, ich würde gerne mit 100Mbps übertragene Ethernet-Frames direkt an der Twisted-Pair-Leitung abtasten und auf einem 500MHz-Oszi darstellen. Die erste Idee wäre gewesen, das Patch-Kabel aufzutrennen, Tx und Rx "anzuzapfen" und zwei RJ45 zu BNC - Baluns zu verwenden, um das Oszi direkt mit Koax-Kabeln anzuschließen. Ich habe allerdings kein Gerät gefunden, dass diese Datenrate unterstützt. Gibt es Alternativen bzw. wäre es überhaupt möglich mit einem Aufbau dieser Art auf der Leitung mitzuhören? MfG
Ohne die Signale zu beeinflussen, wäre es vermutlich am einfachsten, einen Hub (keinen Switch) in die Leitung einzufügen und einfach an einem freien Port den Oszi anzuschalten. Galvanisch getrennt ist dann alles, weil die Impulsübertrager da schon drin sind. Vermutlich müsstest du dir um symmetrisch/unsymetrisch dann nicht mal Gedanken machen. Da es nicht so einfach ist, einen Hub für 100 MBit zu bekommen, könntest du dir aus 2 Impulsübertragern ein T-Stück bauen, parallel zu den vorhandenen TX/RX Pärchen. Allerdings müssen dann die Netzwerkkarten die doppelte Last treiben, was sie erfahrungsgemäss aber hinbekommen.
Du musst das Kabel auftrennen und das Signal differenziell messen. Wenn Du RX+TX gleichzeitig messen willst, brauchst Du natürlich einen 4-Kanal Oszi RXn -> K1 RXp -> K2 TXn -> K3 TXp -> K4 => RX = K1-K2 => TX = K3-K4 - Abschirmung auf Masse - Kurze bzw. keine Stichleitung - Ader-Paare möglichst lange verdrillt lassen - Oszi-Eingänge hochohmig, e.v. auf AC
Hallo Matthias, es geht darum das Delay zu messen von der Flanke eines anderen Signals bis zu dem Beginn des jeweiligen Ethernet-Frames, also beide Signale am Oszi darzustellen. Wenn ich einen Hub verwende, habe ich das Delay vom Hub in der Messung, das zwar durch den Speed Grade als Maximum angegeben ist, aber doch variieren kann. Deshalb würde ich gerne "direkt" an der Leitung abtsten. MfG
Robert schrieb: > es geht darum das Delay zu messen Ahh, o.k., davon war vorher nicht die Rede. Dann mach es doch so wie Peter vorschlägt, oder mit den von mir erwähnten Impulsübertragern (wie sie auf Netzwerkkarten zu finden sind). Wenn die Oszi Eingänge hochohmig genug sind, musst du vermutlich sogar nur TX+ bzw. RX+ messen und kannst auf TX- bzw. RX- verzichten, ohne die Symmetrie all zu sehr zu stören. Dann fehlt dir allerdings der Bezugspunkt, da die Netzwerkkabel ja immer galvanisch getrennt sind.
Robert schrieb: > Deshalb würde ich gerne "direkt" an der Leitung abtasten. Und warum geht das nicht? Man kann doch einfach die Leitung abisolieren und das Oszi mit geeigneten Tastköpfen (wenn verfügbar Differenztastköpfe) dann drauf klemmen? > das Patch-Kabel aufzutrennen "Auftrennen" bedeutet i.A. "Abschneiden" Du meinst vermutlich nur "Abisolieren"...
Angehängte Dateien:
-
HP_54500.png
3,5 KB
Du kannst doch direkt am Ausgang des Ethernetcontrollers messen bevor das Signal durch die Uebertrager auf die Leitung geht. Mach dir allerdings nicht viel Hoffnung dort was erkennen zu koennen. Im Anhang ein Messung an einem 100MBit Netzwerkcontroller.
Helmut Lenzen schrieb: > Mach dir > allerdings nicht viel Hoffnung dort was erkennen zu koennen. So wie ich das verstanden habe, will der TE praktisch nur eine Latenzzeit messen, zwischen einem externen Signal und dem Beginn des Ethernetframes auf der Leitung. Dazu würde ja die Signaltreue nicht so wichtig sein. Tja, 100 MBit sind eben nur noch 10ns pro bit... Ach, wo wie gerade dabei sind: Bei GBit Netzwerken werden ja alle 4 Kabelpärchen benutzt. Muss ich mir das als interleaved vorstellen? Also abwechselnd bitweise auf der einen und auf der anderen TX Leitung, oder ist das paketweise gelöst?
>Mach dir allerdings nicht viel Hoffnung dort was erkennen zu koennen
Das ist tatsächlich so, mit 100BaseTx hast Du ein stetiges Idle-Signal
(Dauer-1, 4B5B-Codiert und dann noch MLT-3 (Differenziell 3-Level)) auf
der Leitung, da ist es aufwändig einen Frame-Start zu erkennen, bzw. der
Oszi müsste fast das Ethernet-Signal dekodieren können. (z.B. per
SW-Modul auf einem modernen Digital-Oszi)
Hallo, danke für die Antworten. Ja Lothar, ich meine natürlich abisolieren. Also die Isolierung auftrennen ;) Ich hatte die Messung schon mal wie von Peter beschrieben durchgeführt, aber die Qualität war miserabel - bin jetzt im Nachhinein draufgekommen, dass es an den zu langen Stichleitungen lag. Habe die Messung jetzt in ähnlicher Qualität wie Helmut Lenzen hinbekommen, den Beginn des jeweiligen Frames in dem MLT-3 Signal zu suchen wird aber noch spassig werden....
>Ach, wo wie gerade dabei sind: Bei GBit Netzwerken werden ja alle 4 >Kabelpärchen benutzt. Muss ich mir das als interleaved vorstellen? Also >abwechselnd bitweise auf der einen und auf der anderen TX Leitung, oder >ist das paketweise gelöst? Da wird gleichzeitig über alle 4 Paare in beide Richtungen übertragen, der Sender kompensiert dann das eigene TX-Sigal, so dass er nur das Signal der gegenseite sieht 4 x 125 MBaud x 2 Bit = 1 GBit
Peter schrieb: >>Mach dir allerdings nicht viel Hoffnung dort was erkennen zu koennen > Das ist tatsächlich so, mit 100BaseTx hast Du ein stetiges Idle-Signal > (Dauer-1, 4B5B-Codiert und dann noch MLT-3 (Differenziell 3-Level)) auf > der Leitung, da ist es aufwändig einen Frame-Start zu erkennen, bzw. der > Oszi müsste fast das Ethernet-Signal dekodieren können. (z.B. per > SW-Modul auf einem modernen Digital-Oszi) Sowas würde mir in der Tat eine riesige Einsparung an Zeitaufwand bringen - hab aber leider nichts für Yokogawa DSOs gefunden, Tektronix steht mir leider nicht zur Verfügung....
Kennt jemand ein LabView VI das ich für diese Anwendung benutzen könnte? (100Mbit/s Ethernet Frames dekodieren) Habe bis jetzt leider nichts entsprechendes finden können.... mit einem LabView-Treiber für das Oszilloskop und dem entsprechenden VI könnte es klappen.
Womöglich ist auch die Freeware-SW Wireshark ( http://www.wireshark.org/ ) nützlich, der captured Ethernet-pakete quasi in Realtime und liefert eine zeitliche Auflösung im us Bereich
Hallo Peter, ich kenne Wireshark bereits, aber die Auflösung ist zu grob für die Messung des Delays das ich oben angesprochen habe. Ausserdem wird das Delay immer von der Flanke eines digitalen Signals (nennen wir es V_trig) bis zum Beginn eines bestimmten Frames gemessen, und das Signal V_trig habe ich im Wireshark nicht zur Verfügung. Lg
Da die Frage sich nun eher in die Richtung LabView-Programmierung entwickelt hat, habe ich einen weiteren Thread im Unterforum "PC-Programmierung" angelegt: Beitrag "LabView VI zur Dekodierung von Ethernet Frames"
Robert schrieb: > es geht darum das Delay zu messen von der Flanke eines anderen Signals > bis zu dem Beginn des jeweiligen Ethernet-Frames, also beide Signale am > Oszi darzustellen. Hi, Verstehe ich das richtig: Du hast ein Gerät, dass - einen Impuls (oder so) über einen Ausgang ausgibt und - zum selben Zeitpunkt wird ein Ethernet-Paket versendet aber das nichts mit verteilten Uhren über Netzwerk (vgl. IEEE 1588) zu tun? Wenn das so ist, ist es gegeben, dass das Gerät beides zum selben Zeitpunkt macht (vorallem das Ethernet-Paket ausgibt)?
Ich weiß, dass es das nicht gleichzeitig macht, sondern ein Delay dazwischen ist. Und genau dieses Delay soll mit dieser Messung herausgefunden werden.
Wenn über den Netzwerkanschluss "nur" die gewünschten Pakte drüber gehen, dann kannst Du die LED vom Netzwerkanschluss benützen. Informier dich mal über "Wireshark Timestamp Precision". Wenn Du keine besondere Hardware benützt, dann wird dir wohl diese Genauigkeit ausreichen. Allerdings wüsste ich jetzt nicht, wie man das andere Signal ins Spiel bringt, ausser die Nachrichten/Signale werden mit einer festen Wiederholrate gesendet.
Wenn es um Datentransfer geht, würde ich dir einen HUB (nicht Router) empfehlen und Wireshark. Wenn es um die Signalqualität geht, musst du natürlich mit dem Oszi ran, da reicht es aber single-ended zu messen.
♪Geist schrieb: > @ mar IO: du glaubst wohl nicht, dass die LED bitsynchron flackert oder? Die NIC weiß ja wohl am besten wann was gesendet wird. Darum gehe ich stark davon aus... Hubs wurden hier schon erwähnt, aber braucht man nicht. Es genügt ein Ehternet Tab: http://www.enigmacurry.com/category/diy/ Man greift nur mit RX auf die Leitung zu. Ein Nachteil ist, dass man nur von einem Partner den Netzwerkverkehr bekommt.
mar IO schrieb: > ♪Geist schrieb: >> @ mar IO: du glaubst wohl nicht, dass die LED bitsynchron flackert oder? > > Die NIC weiß ja wohl am besten wann was gesendet wird. Darum gehe ich > stark davon aus... > Ich kann von dieser LED nicht auf dem Signal auf der Leitung rückschließen, weil das Signal auf der Leitung bei 100Mbit/s wie in den vorigen Beiträgen bereits erwähnt MLT-3 kodiert ist. Die bis jetzt vielversprechendste Methode wäre wie schon erwähnt die Signale aufzunehmen und in LabView weiter zu verarbeiten sprich zu dekodieren, siehe: Beitrag "LabView VI zur Dekodierung von Ethernet Frames"
Robert schrieb: > Ich kann von dieser LED nicht auf dem Signal auf der Leitung > rückschließen, weil das Signal auf der Leitung bei 100Mbit/s wie in den > vorigen Beiträgen bereits erwähnt MLT-3 kodiert ist. das ist doch wohl der LED egal, sie leuchet ja nur wenn daten übertragen werden also erkennt sie es grundsätzlich. Das Problem dabei ist das Blinken, ich weiss nicht ob sie immer bei einem Datenpacket mit "hell" anfängt zu leuchten oder ob das signal mit einem Blink-Takt verunden wird. Aber ein Versuch ist es zumindest wert, man muss nur dafür sorgen das wirklich nichts anderes im Netzt übertragen wird.
Robert schrieb: > Ich kann von dieser LED nicht auf dem Signal auf der Leitung > rückschließen, Wenn, dann musst Du sicherstellen, dass nur das eine Paket gesendet wird. Robert schrieb: > Ich weiß, dass es das nicht gleichzeitig macht, sondern ein Delay > dazwischen ist. Es ist kein festes Delay, sondern es hängt ab von ein paar Faktoren... (ausser Du hast special HW). Ehrlich gesagt, verstehe ich den Sinn dahinter noch nicht. Eigentlich lässt man der Gegenstelle auch ein Signal ausgeben und misst den Versatz beider Signale zueinander.
Wenn Du sicherstellst, dass nur das eine Paket gesendet wird, dann musst Du auch nix "entschlüsseln", sondern nur erkennen was idle ist und was nicht.
Hallo Robert, wir messen das Timing zwischen Prozesssignalen und Netzwerk Frames mit einem Netanalyzer der Firma Hilscher. Dieses Gerät verfügt neben den Ethernet Ports über 4 binäre Eingänge deren Zustandswechsel als 'Pseudoframes' in das Wireshark Capture eingefügt werden. (Haken: > 1000€) Gruß Ulrich
Hallo Ulrich, danke für den Tipp! Würde eine Alternative sein wenn es mit den "günstigeren" Methoden nicht klappt. Lg
Hallo, Trigger doch einfach mit einem Digitaloszi auf die flanke des Externen Signals. Zeichne parallel den Ethernet Datenstrom auf. (2 10:1 oder 100:1 Tastköpfe). Wenn der Zeitliche Verzug konstant ist stehen beide Kurven. Denke man kann den Start des Ethernet Frames optisch erkennen. MfG Michael
Michael schrieb: > > Denke man kann den Start des Ethernet Frames optisch erkennen. > Hallo Michael! Kann man wegen der Leitungskodierung bei 100Mbit/s nicht, das wurde in diesem Thread schon ein paar mal besprochen ;)
Wenn es nur um die Zeit zwischen externen Signal bis Begin Netzwerkframe geht ist die Geschwindigkeit des Netzes doch egal. Warum dann nicht einfach das Gerät an einen alten 10 Mbit Hub anschliessen. Am besten einen der auch noch zusätzlich eine Koax Anschluß hat. Dort ist die Übertragung einfach Manchaster Codiert und ich glaube bei Idle ist da auch Ruhe auf dem Bus.
Hallo Jürgen, es handelt sich dabei um einen Powerlink Slave als FPGA Implementierung, der nur eine Übertragung mit 100 Mbit/s implementiert hat. Lg
Messe doch an dem MII des Phy und addiere dessen Latenz anhand der Datenblattagaben. Oder ist das zu ungenau?
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.