Hi! Ich versuche, die Art/den Namen der Leitungscodierung aus einer gemessenen Datenübertragung (siehe Bild) zu bestimmen. Leider kenne ich zu wenig Leitungscodierungen und keines passt auf die Übertragung. Vielleicht weiß ja jemand von Euch, wie sie heißt, falls sie überhaupt standardisiert ist. Nachprogrammiert habe ich sie schon und funktioniert auch. Nun würde ich jedoch gern die Hintergründe bzw. den Namen dazu kennen. Zur Übertragung: Es ist eine Buskommunikation von mehreren Sensoren an ein Modul und ohne Taktleitung. High ist bei 5 V, low auf GND. Die Sensoren müssen die Ausgänge auf tri-state schalten, solange sie nichts senden. Das Busmodul hält den Bus auf High. Es gibt nur ein Startbit für den Beginn einer Transaktion von mehreren Bytes. Es gibt weder Stopbits noch Paritätsbits für jedes Byte. Lediglich am Ende einer Transaktion wird die Sendeport wieder auf tri-state geschaltet und geht somit wieder auf high. Für jedes Bit (egal ob 0 oder 1) erfolgt ein Signalwechsel (also von high auf low bzw. umgekehrt). Lediglich die Impulsdauer verdoppelt sich (von 250 µs auf 500 µs), wenn eine "1" gesendet wird. Ich hoffe, ich konnte genug Informationen liefern und jemand kennt diese Art der Leitungscodierung. -- Viele Grüße, Mathias
Angehängte Dateien:
-
comm.png
911 Bytes
Bist du dir denn in Bezug auf die Daten sicher? Es könnte auch ein UART Signal sein (Start-Bit, 9 datenbits, parity, stop). Oder es ist Manchester encoded. Dann hätte es allerdings weniger Bits. Um was für Sensoren/Modul geht es denn genau?
Interessanter Code. Die '1' vor 'Ende' unterscheidet sich auf den ersten Blick durch nichts von der vorletzten '0'. Biste sicher, dass deine Interpretation, oder deine Grafik stimmt?
Eine Code mit unterschiedlicher Bitdauer je nach Wert ist extrem ungewöhnlich.
Mathias W. schrieb: > Ich hoffe, ich konnte genug Informationen liefern und jemand kennt diese > Art der Leitungscodierung. Nein. So, wie du das bezeichnet hast, stimmt es bestimmt nicht. Die letzte 1 kann schon mal nicht stimmen. Der Rest kann Biphase-S sein, aber dann stimmt es nicht mit Anzahl der bits. Screenshot von LA ware viel besser (und genauer).
Und diese Grafik stammt nicht aus einer Hausaufgabe, Skript oder ähnlichem, sondern wurde von Dir gezeichnet?
Beitrag #4934905 wurde von einem Moderator gelöscht.
Angehängte Dateien:
-
Comm_Short_1k.jpg
150 KB -
Comm2.png
969 Bytes
Marc V. schrieb: > Mathias W. schrieb: >> Ich hoffe, ich konnte genug Informationen liefern und jemand kennt diese >> Art der Leitungscodierung. > > Nein. > So, wie du das bezeichnet hast, stimmt es bestimmt nicht. Wie meinst du das? > Die letzte 1 kann schon mal nicht stimmen. Da hast du recht. Das ist eine 0. War ein Tippfehler von mir. > Der Rest kann Biphase-S sein, aber dann stimmt es nicht mit Anzahl > der bits. Richtig. Das war das ähnlichste, welches ich gefunden hatte. Nur sind es zu viele Flanken. > Screenshot von LA ware viel besser (und genauer). Würde ich auch gern schicken. Leider friert mein neu gekauftes Owon DS7102 ein, wenn ich einen Screenshot auf USB speichern will. Dieser Bug scheint seit Jahren immer noch nicht behoben worden zu sein. Aber das ist off topic. Ich habe einfach mal ein "Smartshot" und das dazu umgesetzte Signaldiagramm angefügt. Es werden genau 6 Bytes (= 48 Bit, inkl. einer checksum) übertragen. Diese werden auch richtig vom Modul interpretiert. Ich kann auch jede beliebige andere Bytefolge senden. Das ist alles so korrekt. Gerd E. schrieb: > Und diese Grafik stammt nicht aus einer Hausaufgabe, Skript oder > ähnlichem, sondern wurde von Dir gezeichnet? Es ist definitiv keine Hausaufgabe oder der gleichen, sondern wurde von mir mit Excel gezeichnet. Es ist auch nur ein Ausschnitt des ersten Bytes. Siehe oben. Ein UART-Signal ist es definitiv nicht, da das zwingend mindestens ein Start- und Stopbit je Byte hat. -- Viele Grüße, Mathias
Was ist denn das für ein Sensor? Ist das eine IR Übertragung?
:
Bearbeitet durch User
Joe F. schrieb: > Was ist denn das für ein Sensor? > Ist das eine IR Übertragung? Ich generiere die Daten mit einem ATmega168PB und daran habe ich verschiedene Sensoren (Temperatur, Feuchte, PIR, Binäreingänge, etc.) per I²C und ADC bzw. direkt am Port hängen. Diese Sensoren gibt es auch als separate Sensoren mit direktem Bus-Anschluss. Aber daraus Rückschlüsse auf die Leitungscodierung zu ziehen funktioniert nicht, da die Kommunikationsprotokolle der einzelnen Sensoren nichts mit dem proprietären Bussystem an sich zu tun haben. Aus rein akademischen Gründen möchte ich wissen, wie die von mir gezeigte (und gemessene) Leitungscodierung heißt, da ich mehr über die Hintergründe und Zuverlässigkeit wissen möchte. Das man den Takt rekonstruieren kann, weiß ich schon. ;-)
Jetzt mache es halt nicht so anstrengend. Sag einfach was für ein Bussystem das ist bzw. was für ein Modul, und dann kann man dir auch helfen.
no return to zero, heißt das so? bei 0 ändert sich der Pegel, bei 1 nicht(Wechsel um einen Takt verzögert). vorne Synchronisation
:
Bearbeitet durch User
Lutz H. schrieb: > no return to zero > bei 0 ändert sich der Pegel, bei 1 nicht. vorne Synchronisation Nein, NRZ ist es nicht. Joe F. schrieb: > Jetzt mache es halt nicht so anstrengend. > Sag einfach was für ein Bussystem das ist bzw. was für ein Modul, und > dann kann man dir auch helfen. Ich wusste, dass diese Diskussion kommt und ich mache es auch nicht anstrengend, da es für dieses Bussystem keine öffentliche Dokumentation gibt und mir somit auch niemand durch reine Kenntnis des Namens Bussystems oder des Moduls helfen kann. Darauf wette ich einen Kasten Bier oder was gleichwertiges. Du kannst gern gegenhalten. ;-) Es ist die I-Port-Kommunikation von LCN (Local Control Network). Und, kannst du mir nun den Leitungscode sagen?
A. K. schrieb: > Eine Code mit unterschiedlicher Bitdauer je nach Wert ist extrem > ungewöhnlich. Dann schau Dir mal die DCF77 Codierung an. Logisch Low ist 100ms und logisch High ist 200ms. So viel zum Thema unterschiedliche Bitdauer je nach Wert.
Zeno schrieb: > A. K. schrieb: >> Eine Code mit unterschiedlicher Bitdauer je nach Wert >> ist extrem ungewöhnlich. > > Dann schau Dir mal die DCF77 Codierung an. Die ist ja auch extrem ungewoehnlich, denn sie wird nur bei DCF77 verwendet.
Naja, die low-level Codierung hast du ja rausgefunden. Kurz (hohe Frequenz) = 0, Lang (niedrige Frequenz) = 1. Man kann es morsen nennen, oder FSK mit halben Perioden. Du hast aber ja nach der Zuverlässigkeit gefragt, und da kann man ohne das Protokoll zu kennen wenig sagen. Die Codierung ist jedenfalls "DC-frei", und hat eine geringe Bitrate insofern gut über Übertrager/Kondensatoren oder auch Funk übertragbar. Da zum Datenformat keine Informationen existieren, und das Protokoll lt. Wikipedia u. Hersteller proprietär ist, kann man auch keine Aussagen zur Zuverlässigkeit machen. Man müsste wissen, ob Absicherungen oder Fehlerkorrekturmöglichkeiten in Form von Prüf-/Paritätsbits oder Prüfsummen vorhanden sind, und/oder ob eine Redundanz durch mehrfach wiederholte Übertragung gegeben ist.
:
Bearbeitet durch User
Mathias W. schrieb: > Aus rein akademischen Gründen möchte ich wissen, wie die > von mir gezeigte (und gemessene) Leitungscodierung heißt, Ob es einen "offiziellen" Namen gibt, weiss ich nicht, denn wie schon angemerkt sind unterschiedlich lange Bitzellen etwas ungewoehnlich. Vom Prinzip her ist es eine FM (Frequenzmodulation), nur halt mit der Besonderheit, immer genau eine Halbwelle verwendet wird, so dass die Laenge der Bitzellen schwankt. Ueblich ist dagegen, mehr Halbwellen einer hohen bzw. weniger Halbwellen einer niedrigen Frequenz zu verwenden, so dass die Laenge der Bitzellen konstant bleibt. Hach... Erinnerungen an den LC80 werden wach... :)
Possetitjel schrieb: > Vom Prinzip her ist es eine FM (Frequenzmodulation), nur > halt mit der Besonderheit, immer genau eine Halbwelle > verwendet wird, so dass die Laenge der Bitzellen schwankt. Vom Prinzip her ist es eher eine "Bitlängenmodulation" ;-) Mathias W. schrieb: > Es ist die I-Port-Kommunikation von LCN (Local Control Network). Und, > kannst du mir nun den Leitungscode sagen? Den Namen für Code (falls es überhaupt einen Namen gibt) kann ich dir nicht sagen, aber etwas ähnliches habe ich schon mehrmals eingesetzt, mit dem Unterschied, das jedes Byte auch 2 Stoppbits hatte. Der Grund war eine äußerst einfache Dekodierung zur Laufzeit - die Kommunikation lief mit 8-bit Timer und PCINT praktisch ohne den uC zu beanspruchen und war (abgesehen von ev. Störungen auf dem Bus) narrensicher. Bei 9600B brauchte es kaum mehr Code als HardwareUART mit ISR - verbrauchte aber natürlich die zehnfache uC Zeit - die lag aber selbst beim Senden bzw. Empfangen einer Null immer noch unter 3,5%. Es war ein nichtblockierendes SoftUart, sicher wie HardwareUART, aber vieeeel toleranter gegenüber Frequenzschwankungen als HW-UART.
Zeno schrieb: >> Eine Code mit unterschiedlicher Bitdauer je nach Wert ist extrem >> ungewöhnlich. > > Dann schau Dir mal die DCF77 Codierung an. Logisch Low ist 100ms und > logisch High ist 200ms. So viel zum Thema unterschiedliche Bitdauer je > nach Wert. DCF77 verwendet eine klassische PWM mit konstanter Frequenz. Die variable Pulsbreite codiert das Bit, die Periode aber ist konstant. In der hiesigen Interpretation variiert hingegen der Bitabstand, die Periode. Und das ist ungewöhnlich.
Mathias W. schrieb: > Ich wusste, dass diese Diskussion kommt und ich mache es auch nicht > anstrengend, da es für dieses Bussystem keine öffentliche Dokumentation > gibt und mir somit auch niemand durch reine Kenntnis des Namens > Bussystems oder des Moduls helfen kann. Doch. Denn wenn das System den Namen Schrullenheimer trägt, dann gibts nun eine valide Antwort, indem man das als das allgemein (noch:un)bekannte Schrullenheimer-Protokoll bezeichnet. Das hilft zwar dir nicht so direkt, aber vielleicht dem nächsten mit dieser Frage. ;-)
:
Bearbeitet durch User
A. K. schrieb: > Doch. Denn wenn das System den Namen Schrullenheimer trägt, dann gibts War das nicht der Knochenhauer ? Schrullenheimer hat das Verfahren, glaube ich zumindest, nur etwas verbessert...
Sinclair ZX-Spectrum Protokoll? Wie lang sind denn die Bit-Zeiten für Low und High?
Route 6. schrieb: > Sinclair ZX-Spectrum Protokoll? Da habe ich jetzt auf die Schnelle nix zu gefunden. > Wie lang sind denn die Bit-Zeiten für Low und High? Für "0" ungefähr 250 µs und für "1" ungefähr 500 µs. Damit funktioniert es stabil. Wenn ich jedoch die Kommunikation der anderen Sensoren messe, ist das Dauer einer "0" eher ungefähr 1/3 oder näher an 2/5 der Dauer einer "1".
A. K. schrieb: > Eine Code mit unterschiedlicher Bitdauer je nach Wert ist extrem > ungewöhnlich. Kommt drauf an, wo man sich (gedanklich) so rumtreibt. Bei Codierungen für IR-Fernbedienungen oder bei Kassetten-Aufzeichnungsformaten von Heimcomputern ist das recht verbreitet. Im Prinzip ist es ja eine simple FM. Was mich etwas verwundert ist das Fehlen von Synchronisationspunkten. Für 48 Bits mag das noch gehen. Aber für längere Telegramme würde man zwischendrin synchronisieren wollen. Das Startbit (kurze Zelle, Start mit H->L Flanke) ist klar. Aber beim Stopbit geht es schon los. Es muß länger als eine reguläre 1 sein, aber wie lang genau? Immerhin ist gesichert, daß nach einer geraden Anzahl Bits der Pegel wieder auf H ist.
Axel S. schrieb: > Im Prinzip ist es ja eine simple FM. So wie in alten Floppy-Disks? ;-)
:
Bearbeitet durch User
Axel S. schrieb: > Im Prinzip ist es ja eine simple FM. Was mich etwas verwundert ist das > Fehlen von Synchronisationspunkten. Für 48 Bits mag das noch gehen. Aber > für längere Telegramme würde man zwischendrin synchronisieren wollen. Jedes Bit synchronisiert sich selbst. Der Abstand zwischen Flankenwechseln ist beispielsweise kleiner als 1,5T oder grösser als 1,5T. Ein Startbit ist im Grunde nicht erforderlich. Kann aber sinnvoll sein, um den Receiver aus dem Schlaf zu reissen ohne Daten zu verlieren.
:
Bearbeitet durch User
A. K. schrieb: > Für 48 Bits mag das noch gehen. Beim Spectrum ging das auch für 393216 Bits (49152 Bytes)...
A. K. schrieb: > Axel S. schrieb: >> Im Prinzip ist es ja eine simple FM. Was mich etwas verwundert ist das >> Fehlen von Synchronisationspunkten. Für 48 Bits mag das noch gehen. Aber >> für längere Telegramme würde man zwischendrin synchronisieren wollen. > > Jedes Bit synchronisiert sich selbst. Der Abstand zwischen > Flankenwechseln ist beispielsweise kleiner als 1,5T oder grösser als > 1,5T. Mir ging es nicht um den Bit-Takt, sondern um die Zählung der Bits und wie man die wieder auf die Reihe bekommt, wenn mal eine Störung auf der Leitung war. > Ein Startbit ist im Grunde nicht erforderlich. Kann aber sinnvoll sein, > um den Receiver aus dem Schlaf zu reissen ohne Daten zu verlieren. Man will in der Regel schon erkennen können, daß ein Telegramm endet. Für den Beginn würde in der Tat die fallende Flanke aus dem Ruhezustand heraus reichen. Aber mit dem Stopbit kriegt man die angenehme Eigenschaft, daß die Leitung nach einer geraden Anzahl Nutzbits wieder auf H ist. Route 6. schrieb: >> Für 48 Bits mag das noch gehen. > > Beim Spectrum ging das auch für 393216 Bits (49152 Bytes)... Beim Spectrum kenne ich mich jetzt nicht aus (war damals auf der anderen Seite des eisernen Vorhangs). Aber für gewöhnlich wurden die Daten in Blöcke zerlegt, pro Block eine Prüfsumme geschrieben und zwischen den Blöcken gab es Synchronisationszeichen. Dadurch ging bei einem Lesefehler nicht gleich der ganze Rest danach verloren...
Axel S. schrieb: > Mir ging es nicht um den Bit-Takt, sondern um die Zählung der Bits und > wie man die wieder auf die Reihe bekommt, wenn mal eine Störung auf der > Leitung war. Trivial: keine Zustandsänderung über deutlich mehr als 2T.
A. K. schrieb: > Axel S. schrieb: >> Mir ging es nicht um den Bit-Takt, sondern um die Zählung der Bits und >> wie man die wieder auf die Reihe bekommt, wenn mal eine Störung auf der >> Leitung war. > > Trivial: keine Zustandsänderung über deutlich mehr als 2T. AKA "wir warten auf das nächste Stopbit". Kann man so machen. Aber unter Umständen verpaßt man so zuviel.
Axel S. schrieb: > Aber unter Umständen verpaßt man so zuviel. Der laufenden Frame, mehr nicht. Passiert nur wenn bei maximal etwas über 2T vor einem Frame einsteigt, damit die idle condition nicht erkennt und den Frame ignoriert. Kein Drama. Mehr als circa 2T an Daten verpasst man somit nicht, denn ein nur partiell empfangener Frame ist wertlos.
Axel S. schrieb: > Beim Spectrum kenne ich mich jetzt nicht aus (war damals auf der anderen > Seite des eisernen Vorhangs). Aber für gewöhnlich wurden die Daten in > Blöcke zerlegt, pro Block eine Prüfsumme geschrieben und zwischen den > Blöcken gab es Synchronisationszeichen. Dadurch ging bei einem > Lesefehler nicht gleich der ganze Rest danach verloren... Das schier Unfassbare ist aber wahr! Sir Sinclair hat volle 48 kByte Bit an Bit rausgeschoben (oder eingelesen). Die korrekte Datenübertragung zeigte dann eine ganz einfache Prüfsumme am Ende (XOR über alle Bytes). Die Bitlängen entsprachen etwa den Zeiten die der TO hier angibt: Low=244µs / High=488µs
Ich hab sowas schonmal verwendet: Beitrag "mehrere MC seriell über Datenbus verbinden (1Draht)" Der Vorteil ist, daß es sich einfach implementieren läßt, die Bandbreite optimal ausnutzt und keinen besonders stabilen CPU-Takt benötigt.
Hi A. K. schrieb: > Eine Code mit unterschiedlicher Bitdauer je nach Wert ist extrem > ungewöhnlich. Veto: 1-wire Wenn jedes Byte mit Start- und Stop-Bit gesendet wird und zwischen den Bytes mehr als die Länge eines HIGH Byte der Bus im Idle ist, läss sich spätestens beim 2.ten übertragenem Byte die Information mitlesen. Aber auch nur, wenn das 1.te Byte nicht 'von Anfang an' mitgelesen wurde. Sollte sich recht einfach implementieren lassen - wobei ich selbst weiß, daß die Fallstricke überall lauern ;) MfG
A. K. schrieb: > Eine Code mit unterschiedlicher Bitdauer je nach Wert ist extrem > ungewöhnlich. Den Code, den bspw. ein PT2262 generiert, würde ich jetzt nicht als extrem ungewöhnlich bezeichnen. Und schon Samuel Morse hat seinen Morse Code auf Bits mit ungleicher Länge aufgebaut - das hat quasi Tradition.
Patrick J. schrieb: > Veto: 1-wire Recommended (AN126): 0: 70µs = 60µs + 10µs 1: 72µs = 6µs + 64µs read: 70µs = 6µs + 9µs + 55µs Ok, du hast recht. ;-)
:
Bearbeitet durch User
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.