Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Erst einmal Danke für die Infos, jetzt weiß ich immerhin die Zeiten die da so zusammen kommen.
Verstanden habe ich jetzt:
Nach der Quittung eines Telegramms muß 50 Bitzeiten gewartet werden, bevor das nächste Telegramm gesendet werden darf.
Jedes Telegrammbyte bekommt ein Paritätsbit und ist damit 9 Bit lang
Für jedes Telegrammbyte werden 13 Bitzeiten zur Übertragung benötigt
Zwischen Telegrammende und Quittungsbytestart liegen 13 Bitzeiten, im Prinzip also die Übertragungsdauer eines Bytes.
Bleiben Fragen offen:
Wenn mehr als eine Bytezeit nichts gesendet wird ist der Bus offensichtlich frei. Kennt jemand den Grund, warum 50 Bitzeiten gewartet wird (also festgelegt wurde) und nicht z.B. nur 26 (=2 Byte)?
-
9 Datenbits (8 + Parität) benötigen 13 Bitzeiten. Was enthalten die zusätzlichen 4 Bit und wie sind sie verteilt (Vor die Daten, in die Daten, nach den Daten?)
Und schließlich: Wird ein Byte beginnend mit LSB oder MSB gesendet?
Die 50 Bitzeiten gelten nur bei Wiederholungen und Alarmen. Bei anderen Nachrichten kommen 2 (IIRC) Bitzeiten dazu
Es werden übertragen:
Startbit 0 1 2 3 4 5 6 7 Parity Stop
und dann kommt eine Pause von 2 Bitzeiten.
ich weiß das zwar nicht speziell hier für'n Bus, aber generell kommt bei einer seriellen asynchronen Übertragung (seit es V24/RS232-Schnittstellen gibt, also bestimmt schon 50 Jahre oder so) vor dem Byte noch ein Startbit und danach ein bis zwei Stopbits (normal eines). Und angefangen wird mit dem LSB.
Erst einmal Danke für die Infos, jetzt weiß ich immerhin die Zeiten die da so zusammen kommen.
Verstanden habe ich jetzt:
Nach der Quittung eines Telegramms muß 50 Bitzeiten gewartet werden, bevor das nächste Telegramm gesendet werden darf.
Jedes Telegrammbyte bekommt ein Paritätsbit und ist damit 9 Bit lang
Für jedes Telegrammbyte werden 13 Bitzeiten zur Übertragung benötigt
Zwischen Telegrammende und Quittungsbytestart liegen 13 Bitzeiten, im Prinzip also die Übertragungsdauer eines Bytes.
Bleiben Fragen offen:
Wenn mehr als eine Bytezeit nichts gesendet wird ist der Bus offensichtlich frei. Kennt jemand den Grund, warum 50 Bitzeiten gewartet wird (also festgelegt wurde) und nicht z.B. nur 26 (=2 Byte)?
-
9 Datenbits (8 + Parität) benötigen 13 Bitzeiten. Was enthalten die zusätzlichen 4 Bit und wie sind sie verteilt (Vor die Daten, in die Daten, nach den Daten?)
-
Und schließlich: Wird ein Byte beginnend mit LSB oder MSB gesendet?
Ja es gibt zwei Pausen. Einmal muss vor dem senden des Telegrammms gewartet werden, das sind die 5.2ms (50 Bitzeiten). Bei niedrigeren Prioritäten kommen dann noch 2 Bitzeiten dazu.
Die andere Pause kommt nach dem Paket (1.35ms), erst dann darf das ACK gesendet werden.
* Kennst du die Autoren (Zechel, Nowakowski) des PDFs?
Wg. Frage ob wir evtl. ein paar der Graphiken ins Lexikon übernehmen bzw. das ganze doc verlinken können/dürfen.
Nein, kenne ich nicht. Habe ich auch per Suchmaschine gefunden.
PS: Deine Frage zum Lexikonartikel, du darfst das Quittungsbyte nicht zur Gesamtlänge zählen.
kannst du bitte die Achtung-Box in dem ersten verlinkten Artikel (Paketaufbau) auflösen? Das konnte ich beim Eintragen dieses Lexikon-Artikels irgendwie nicht klären. Danke!
Hallo Markus,
23 ist richtig, wenn man das Quittungsbyte nicht mit mitzählt, 24 ist dann inkl. Quittungsbyte.
Ist aber auch nur die halbe Wahrheit: inzwischen gibt es sog. extended Frames, die bis zu 254 Byte (wenn ich mich richtig erinnere) Nutzdaten tragen können.
* Ist die pause nicht 5,2ms + 1,35ms?
* Kennst du die Autoren (Zechel, Nowakowski) des PDFs?
Wg. Frage ob wir evtl. ein paar der Graphiken ins Lexikon übernehmen bzw. das ganze doc verlinken können/dürfen.
kannst du bitte die Achtung-Box in dem ersten verlinkten Artikel (Paketaufbau) auflösen? Das konnte ich beim Eintragen dieses Lexikon-Artikels irgendwie nicht klären. Danke!
Nebenbei: Hat jemand mal einen Link auf eine ganz genaue Beschreibung was da physikalisch tatsächlich auf die Leitung moduliert wird? Anscheinend finde ich immer nur Beschreibungen, die von Pausen und zusätzlichen Bits nichts wissen...
Hm, ich bin davon ausgegangen, das für ein Byte tatsächlich 8 Bit gesendet werden...
Und das ACK ist meines Wissens nach ein Bit am Ende des Telegramms das die Empfänger zeitlich exakt (und synchron) treffen müssen, das Zeitfenster entspricht da wohl einer Bitlänge, also rund 104 us. Das macht den Kohl nicht fett.
Wiederholungstelegramme würde ich jeweils mitzählen, sie treten auf meinem Bus aber fast nie auf. OK, wenn ich über eine Schnittstelle hinweg arbeite, die beim Senden selbständig Telegramme wiederholt, dann sieht das sendende Gerät dahinter das wohl nicht. Ich meine hier aber die Telegrammzahl, die ein hörendes Gerät direkt am Bus sieht.
Aber selbst wenn durch zusätzliche Bits und Pausen ein Telegramm zeitlich doppelt so lang wird, als von mir angenommen, sind 7-12 Telegramme/s einfach zu wenig.
Und wenn man tatsächlich praktisch 49 Telegramme/s über den Bus bekommt, warum gibt es dann so viele Geräte, die zwar zertifiziert sind, aber garantiert keine 49 Telegramme/s schaffen? Nicht einmal lesend und erst recht nicht schreibend? Gut, nicht jedes Gerät hat einen solchen Informationsbedarf, aber Schnittstellen und Koppler/Router müssten auf jeden Fall mehr Bandbreite besitzen als der Bus selbst - was anscheinend nicht bei allen der Fall ist - trotz Konnex-Segen...
Nebenbei: Hat jemand mal einen Link auf eine ganz genaue Beschreibung was da physikalisch tatsächlich auf die Leitung moduliert wird? Anscheinend finde ich immer nur Beschreibungen, die von Pausen und zusätzlichen Bits nichts wissen...
Selbst mit kleinen Pausen müßte der Bus also mindestens 40 Telegramme/s schaffen, bei im Mittel 10 Byte langen Telegrammen müßten rund 100 Telegramme/s über den Bus gehen können. Dauerhaft!
Nach jeder Nachricht am Bus kommt ein ACK (ich glaube innerhalb 12ms) vom Empfänger. Ganz ohne Sicherungsschicht läuft das also nicht ab. Das drückt Rate wohl auf 50/s, theoretisch.
Sollte das Telegramm nicht ankommen wird wiederholt (3xmal [meistens]).
Irgendwie verstehe ich das nicht ganz:
KNX-TP läuft mit 9600 Bit/s entspricht 1200 Byte/s.
Die längsten Telegramme haben 24 Bytes, die kürzesten 9 Byte.
Die meisten dürften zwischen 9 und 12 Byte liegen.
Selbst mit kleinen Pausen müßte der Bus also mindestens 40 Telegramme/s schaffen, bei im Mittel 10 Byte langen Telegrammen müßten rund 100 Telegramme/s über den Bus gehen können. Dauerhaft!
Welcher Designfehler führt den dazu, das man in der Realität gerade mal 10% davon schafft? Und das noch nicht einmal sicher?
Mal rechnen: 7 * 9 Byte pro Sekunde sind 36 Byte/s. Ziemlich wenig, wenn das Transportmedium eigentlich 1200 Byte/s schaffen sollte, oder?
Selbst wenn ich nur Strings sende sind 7 * 24 Byte = 168 Byte immer noch sehr mager.
Ich kenne kein anderes System, das derart ineffizient ist. Und ich rede hier nicht von Netto-Nutzdaten (9 Byte Telegramme für 1 Bit Nutzdaten - nun ja) sondern vom Brutto-Telegramm - da ist der gesammte Protokolloverheat schon enthalten.
Also was macht KNX eigentlich so entsetzlich langsam?
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
]).
Einen Kommentar schreiben: