Hallo zusammen, wir haben neulich innerhalb des Studiums einen Laboversuch zum Thema synchrone Datenübertragung durchgeführt und nun habe ich dazu eine Frage. Und zwar gab es einen Sender, der den Buchstabe "A" zu einem entsprechenden Empfänger übertragen hat. Getestet wurde dies mit zwei unterschiedlichen Synchronisationswörtern: Syncwort 1: 00011010 = 26 = Substitutionszeichen. Syncwort 2: 01010101 = 85 = U. Mit Syncwort 1 klappte das ganze und der Empfänger erkannte das Zeichen. Allerdings wechselte sich das "A" ständig mit dem "a (mit einem o oben drüber)" ab. Dies sollte jedoch laut Versuchsunterlagen kein Fehler sein. Kann mir jemand sagen, wie das flackern zwischen beiden Zeichen zustande kommt und warum es sich hier NICHT um einen Fehler handelt? Jetzt zu Syncwort 2. Damit war das gesendete "A" vom Empfänger nun nicht mehr lesbar. Ich könnte mir vorstellen, dass es damit zusammenhängt, dass das Syncwort 2 nun ein Zeichen ist, welches im normalen Zeichensatz des ASCII-Codes enthalten ist und somit die Probleme beim Empfänger zustande kommen. Liege ich mit meiner Vermutung richtig? Würde mich über eine Aufklärung zum Thema freuen. Beste Grüße und allen ein schönes Osterfest. Daniel
> Allerdings wechselte sich das "A" ständig mit dem "a (mit einem o oben > drüber)" ab. Dies sollte jedoch laut Versuchsunterlagen kein Fehler > sein. ASCII oder ÅSCÏÏ?
Daniel L. schrieb: > Und zwar gab es einen Sender, der den Buchstabe "A" zu einem > entsprechenden Empfänger übertragen hat. ... Tja, der Sender wird nicht nur den Buchstaben "A" übertragen haben, sondern ihn irgendwie verpackt haben. Und der Empfänger wird darauf einrasten und das dann dekodiert haben. Das kann so oder so organisiert sein. Offensichtlich was das nicht eindeutig, so dass es zu Synchronisationsfehlern gekommen ist bzw. gar nicht funktioniert hat.
Hallo, was ist das für eine Datenübertragung? RS232, I2C ... ? Gruß Manfred
Hallo und Danke erst einmal für die bisherigen Antworten. @Manfred Koch: Das weiß ich eben nicht genau. Es handelte sich bei dem Versuchsaufbau um das "Student's Workbook 53-002s". Habe dazu auch schon im Internet nachgesucht, jedoch wenig gefunden. Man hat eine Benutzeroberfläche auf dem PC vor sich und sieht ein dort eingebettetes virtuelles Oszilloskop. Es ist jedoch hardwaremäßig eine Schaltung an den PC angeschlossen, mit der auch Einstellungen abgeändert werden können. Wirklich genaue Datenblätter habe ich zu diesem "Student's workbook" nicht gefunden. Es ist eben so, dass im Anschluss eine Frage folgt, die besagt, dass dieses flackern zwischen den zwei Zeichen "A" und "å" weder ein Fehler an der Hardware, noch ein Fehler an der Software ist.
> Es ist eben so, dass im Anschluss eine Frage folgt, die besagt, dass > dieses flackern zwischen den zwei Zeichen "A" und "å" weder ein Fehler > an der Hardware, noch ein Fehler an der Software ist. Dann kann es ja nur ein Fehler im Konzept sein.
Daniel L. schrieb: > Es handelte sich bei dem Versuchsaufbau > um das "Student's Workbook 53-002s". Das hat 295 Seiten! Und ihr werdet die wohl kaum alle in EINEM Versuchsaufbau behandeln. Es geht wohl eher um den Abschnitt 4.4. ab Seite 292(4-41)(Fast am Ende!) Und eigendlich ist da viel erklärt. Und wenn du die vorrangegangenen Kapitel gewissenhaft durchgearbeitet hast solltest du damit klar kommen.
Das Buch habe ich auch schon im Internet gesehen. Wir haben nur Auszüge davon bekommen und einzelne Themengebiete daraus abgehandelt (gut 50 Seiten). Die Fragen sind jedoch vom Dozent teilweise abgeändert worden und somit habe ich im Moment noch keinen Ansatz, wenn es sich um das besagte "flackern" NICHT um einen Hardware- oder Softwarefehler handeln soll.
Kann es evtl. etwas damit zu tun haben, dass das "å" nicht mehr im normalen ASCII-Zeichensatz enthalten ist, sondern dem Extended ASCII-Code entstammt?
Daniel L. schrieb: > einen Laboversuch zum Thema > synchrone Datenübertragung durchgeführt Ich kaufe ein "a" und möchte lösen... Du hast mit Sicherheit ein Laborversuch zu *a*synchroner Datenübertragung gemacht. So steht es jedenfalls auf den Seiten 293+294: "The recovered bit clock [...]" / "Bit Clock Recovery". Wenn es eine synchrone Datenübertragung wäre, würde die Clock übertragen und nicht auf Empfängerseite erst wieder recovered. > Syncwort 1: 00011010 = 26 = Substitutionszeichen. > Mit Syncwort 1 klappte das ganze und der Empfänger erkannte das Zeichen. > Allerdings wechselte sich das "A" ständig mit dem "a (mit einem o oben > drüber)" ab. Soll kein Fehler sein. [...] > Kann es evtl. etwas damit zu tun haben, dass das "å" nicht mehr im > normalen ASCII-Zeichensatz enthalten ist, sondern dem Extended > ASCII-Code entstammt? Laut dem Versuchsaufbau auf Seite 294 empfängst du immer 8bit. Aber ASCII ist nur 7bit. "A" entspricht 0x41, also binär 1000001. Man beachte nur 7bit, nicht 8bit. Dein Empfänger empfängt aber immer 8bit. Vermutlich wahlweise in den Geschmacksrichtungen mit 8tem bit als 0 oder 1 (vermutlich vorne) dran. A = 0x41 = 65 = 1000001 0 davor -> 01000001 = 0x41 = 65 = "A" in ASCII 1 davor -> 11000001 = 0xC1 = 193 = "┴" GND symbol in codepage 850 / extended ASCII In welcher Codepage dein Simulator jetzt arbeitet um "å" zu interpretieren spekuliere ich jetzt mal nicht. > Syncwort 2: 01010101 = 85 = U. > Jetzt zu Syncwort 2. Damit war das gesendete "A" vom Empfänger nun nicht > mehr lesbar. Ich könnte mir vorstellen, dass es damit zusammenhängt, > dass das Syncwort 2 nun ein Zeichen ist, welches im normalen Zeichensatz > des ASCII-Codes enthalten ist und somit die Probleme beim Empfänger > zustande kommen. Liege ich mit meiner Vermutung richtig? Na dann denke doch bitte einmal nach, wie die Erkennung des Syncwortes implementiert ist. Genau eine Zustandsautomat welcher die bitfolge 01010101 ("U") erkennt. Gut, dann überlegst du dir jetzt mal was passiert wenn wir diesen Zustandsautomaten mit der Zeichenfolge "..UAUA.." gefüttert wird. ..UAUA.. -> 01010101 01000001 01010101 01000001 -------^ bing Sync erkannt ######## datadata -------^ bing 2ter Sync erkannt ######## datadata Empfange Daten: 2x 01000001 -> 2x 65 -> 2x "A" Und jetzt mal mit der Zeichenfolge "..AUAUA.." gefüttert wird. ..AUAUA.. -> 01000001 01010101 01000001 01010101 01000001 ---* sync, ne doch nich --------^ bing Sync erkannt ## ###### da tadata --------^ bing 2ter Sync erkannt ## ###### da tadata Empfange Daten: 2x 01 010000 -> 2x 80 -> 2x "P" Und jetzt solltest du dir die Fragen aus Kapitel "4.4.5.2 Question" mal selber beantworten. P.S.: Das genannte Workbook liegt hier: http://80.251.40.59/eng.ankara.edu.tr/kalaycio/aykut/elm460/53-002_STUDENT.pdf
Angehängte Dateien:
-
DSCN6459_2.gif
280 KB
Danke erstmal @void, das bringt mich ein ganzes Stück weiter!!! Hier mal ein Screenshot vom "å", welches während des "flackerns" angezeigt wird. Die Anzeige suggeriert eine ständige Übertragung von 8bit. Ob es wirklich so ist, weiß ich natürlich nicht. Was jedoch auch auffällig ist (kann natürlich Zufall sein): Der Binärcode des "å" ist zum Syncwort genau invertiert, d.h.: Syncwort: 00011010. "å": 11100101. @void: Deine Ausführungen zum Thema 7Bit und 8Bit klingen plausibel. Was mich jedoch noch interessiert: Es wird auf dem angefügten Screenshot folgendes Bitschema für das "å" angezeigt: 11100101. Deine Ausführung zeigt ein Bitschema von 11000001. Ist es möglich, dass hier noch ein anderer Effekt auftritt?
Eine UART synchronisiert auf die fallende Flanke des Startbits. Daher sind zur Synchronisation nur die Codes geeignet, die keine weitere fallende Flanke beinhalten. Also: 0x00, 0x80, 0xC0, ..., 0xFE, 0xFF Daniel L. schrieb: > Syncwort 1: 00011010 = 26 = Substitutionszeichen. > Syncwort 2: 01010101 = 85 = U. Sind also beide völliger Mumpitz.
@Peter: Es geht hier um einen Laborversuch zur Veranschaulichung, aber ich habe nichts gegen eine gute und detaillierte Aufklärung. Interessiert mich ja auch.
Daniel L. schrieb: > Es ist eben so, dass im Anschluss eine Frage folgt, die besagt, dass > dieses flackern zwischen den zwei Zeichen "A" und "å" weder ein Fehler > an der Hardware, noch ein Fehler an der Software ist. Es ist eindeutig ein Fehler in der Software, nämlich das ein ungeeignetes Syncwort programmiert wurde.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.