AskSinAnalyzer
AskSinAnalyzer copied to clipboard
jp112sdl
WebUI: Anzeige des DutyCycle (einzelner Geräte, Zentrale, etc.)
@jens-maus kam die Idee, den DutyCycle im Web mit anzeigen zu lassen.
Folgende Überlegungen dazu: Die Telegrammlänge (in Bytes) ist bekannt.
Es gilt noch zu ermitteln, wie lange die Übertragung eines einzelnen Bytes dauert.
Es müssten dann - je Gerät - die Sendezeiten in einem Zeitfenster der letzten 60 Minuten addiert werden.
Anschließend wird der prozentuale Anteil der errechneten Sendezeit von den max. 36 erlaubten Sekunden in 60 Minuten (1% je Stunde) angezeigt.
Vorschlag: Das Tortendiagramm könnte dahingehend angepasst werden, dass nicht die Anzahl an Nachrichten dargestellt wird, sondern die Summe der Telegramm-Bytes.
Nach meinen Recherchen dauert 1 Byte 0,81 Sekunden.
Quelle: eQ3
Die bereits im Web angezeigte Länge Len ist die Länge ohne das Byte für die Länge selbst.
(siehe Attacking Homematic ab ca. 06:15).
Demzufolge müsste zu Len noch 1 addiert und die Summe mit 0,81 multipliziert werden, um die Übertragungsdauer des Telegramms zu berechnen.
Was ich jedoch nicht weiß:
- Es muss eine Sendervorlaufzeit geben. Wird die (bei eQ3) mit in die DC-Berechnung einbezogen? Wenn ja, wie lang ist die? Das könnte evtl. @stan23 mit einem Logikanalyzer herausbekommen? Es geht um die kurze Zeit zwischen "Sender TX ein" bis "Nutzdaten werden gesendet".
Nach meinen Recherchen dauert 1 Byte 0,81 Sekunden.
Millisekunden ;)
Es muss eine Sendervorlaufzeit geben. Wird die (bei eQ3) mit in die DC-Berechnung einbezogen? Wenn ja, wie lang ist die?
Das könnte man ja überprüfen wenn man die interne Berechnung der CCU damit vergleicht.
Das könnte evtl. @stan23 mit einem Logikanalyzer herausbekommen? Es geht um die kurze Zeit zwischen "Sender TX ein" bis "Nutzdaten werden gesendet".
Hmm, die SPI-Telegramme zu sampeln ist kein Problem. Aber wie erkenne ich dass jetzt gesendet wird?
Aber wie erkenne ich dass jetzt gesendet wird?
Hmm, gute Frage.
In der AskSin++ gibt es das STX-Command, das den CC1101 auf TX schaltet, gefolgt von einem 100µS Delay: https://github.com/pa-pa/AskSinPP/blob/8acfa125eeb8654a2dc762aa08e20f445a8a61b5/Radio.h#L561
In der CC1101 Doku S. 54, 19.6 Timing liegen die Zeiten (je nachdem aus welchem Modus man kommt), die das Modul zum Einschwingen braucht, bei max. 800µS.
Wir können diese geringe Latenz aber meiner Meinung nach auch vernachlässigen.
Geschlossen? Warum?
Zu schnell/viel aufgeräumt 😎 Ich denke aber auch nicht, dass hier noch viel bzw. überhaupt was passieren wird.
Wieso? Technisch sollte es doch machtbar sein den DutyCycle je Gerät zu berechnen und mit darzustellen, oder?!?
Ich könnte mir schon vorstellen, dass ich doch noch mal muse finde. Für die Daten "ab jetzt" ist die Berechnung auch nicht schwer aber einen hübschen Algorithmus für ein Sliding-Window hatte ich damals nicht auf die Schnelle gefunden.
Nach meinen Recherchen dauert 1 Byte 0,81 Millisekunden.
Habe mal den Gegencheck gemacht:
CC1101_MDMCFG4, 0xC8, // 0x8C channel bandwidth
CC1101_MDMCFG3, 0x93, // 0x22 symbol data rate
Das ergibt nach meinen Berechnungen (zu später Stunde) nach Abschnitt 12 Data Rate Programming ca. 10 kBaud Datenrate und ein Byte wäre damit ca. 0,8ms lang, passt also ganz gut.
@jens-maus kam die Idee, den DutyCycle im Web mit anzeigen zu lassen. ... Das Tortendiagramm könnte dahingehend angepasst werden, dass nicht die Anzahl an Nachrichten dargestellt wird, sondern die Summe der Telegramm-Bytes.
Finde die Idee gut und so ein Feature nett, jedoch wuerde ich das unbedingt konfigurierbar oder als 2. Kuchen (der ist sowieso immer gut😀) vorschlagen. Die Torte mit den Telegrammanzahlen ist m.E. ein sehr hilfreiches Tool, die Aktivitaet der Geraete schnell zu ueberblicken. Das sollten wir uns nicht nehmen.
Im Analyzer XS habe ich nun mal etwas eingebaut:
- Der DC von jedem Device wird zum Zeitpunkt eines empfangenen Telegrams berechnet
Dieser ist erst plausibel wenn die Aufzeichnung mind. eine Stunde läuft - In der Tabelle wird der DC für jedes Telegram mit ausgegeben
- Bei einem Klick auf den Wert wird der DC nach Device für diesen Zeitpunkt visualisiert.
Die bereits im Web angezeigte Länge
Lenist die Länge ohne das Byte für die Länge selbst.
Das passt nicht wirklich.
Wenn die Nutzdaten (hellgrün) laut Folie 1 bis 17 Byte sein dürfen, dann kommen nach dem Längenbyte noch 11 bis 27 Byte.
Mein Analyzer zeigt mir aber Len Werte von 10 bis 26.
Und alle Byte zusammengezählt sind es 21 bis 37, jeweils ohne Burst.
Ausgehend von diesen Byte-Zählungen muss die Formel hier eher so lauten:
// len + 11 * 0.81 => transmission time in ms
// 1% airtime allowed => 36sec * 1000ms/sec is 100% DC
const duration = (telegram.len + 11) * 0.81;
if (telegram.flags.burst) {
// 360 ms burst instead of 4 bytes preamble
duration = duration + 360 - 4 * 0.81;
}
const dc = (telegram.len + 11) * 0.81 / 360;
Laut ccc "attacking homematic" enthält das Längen-Byte die gesamte Telegrammlänge ohne das Byte für die Länge selbst.
https://media.ccc.de/v/30C3_-5444-en-saal_g-201312301600-attacking_homematic-sathya-_malli
Ab ca. 6:20 min
Hier ist es doch offensichtlich dass packet length nur die 11 Bytes von message counter bis payload zählt.
Es fehlen im Gegensatz zu Frank Graß' Vortrag die 4 Byte Präambel, 4 Byte Syncword und 2 Byte CRC. Zusammen mit dem Längenbyte sind das 11 ;)
Die Frage ist halt, was man als Telegramm definiert. Zur Berechnung des Duty Cycle müssen aber alle gesendeten Bytes mit einbezogen werden.
Laut Kapitel 15 im CC1101 Datenblatt wird Preamble, Syncword und CRC tatsächlich auch vom CC1101 hinzugefügt.
Hat eQ-3 nicht mal vor ein paar Jahren die DC-Berechnung gefixt, und danach viel höhere Werte bekommen? Vielleicht war das ein ähnlicher Fehler. Gerade bei kurzen Telegrammen hat man etwa 50% Abweichung. Wenn man die Bursts unter den Tisch fallen lässt noch viel mehr :-)
Habe mal versucht, das indirekt an Hand der Stromaufnahme des CC1101 zu verifizieren. Die Stroeme gem. Kap. 8 im Datenblatt findet man recht exakt so vor. Deduziert man daraus die Dauer des Tx-Modus und setzt das gleich mit der Dauer, in der der Traeger gesendet wird, ist der a.G. obiger Ueberlegungen ermittelte DC eigentlich noch zu klein: Mit der Modemconfig der AskSin (DRATE_M=0x93, DRATE_E=0x08) ergibt sich gem. Kap. 12 eine Datenrate von 9.992 kBaud bzw. bei 2-FSK 1249 Bytes/s. bzw. 0.80ms/Byte, wie Jerome ja auch schrieb. Mit einem Telegramm der Laenge 23 im Beispiel unten, also insg. gesendeten 34 Bytes, muesste sich somit eine Sendezeit von ca. 27ms ergeben. Die Dauer der Stromausnahme von ca. 34mA = Tx Modus deutet jedoch auf ca 35ms Sendezeit hin. Hoffe, ich liege falsch und das wird nicht der naechste Fix bei eQ-3 ;-)
Die Dauer der Stromausnahme von ca. 34mA = Tx Modus deutet jedoch auf ca 35ms Sendezeit hin.
Werden während der gesamten Zeit auch Nutzdaten gesendet? Oder könnte es sich nur um Sendervor- und -nachlaufzeit handeln? (Dann wäre die Frage, in wie weit diese Zeiten bei der DC Berechnung eine Rolle spielen. Streng gesetzlich genommen müsste man sie berücksichtigen.)
Dachte auch zwischendurch, dass evtl die Praeambel oefter wiederholt wird, habe jedoch eben einen Test mit brutto 53 uebertragenen Bytes gemacht, die fuehrten zu 50ms entsprechend hoher Stromaufnahme. Das passt irgendwie nicht zur Bytedauer von 0.80ms.