search

jp112sdl / AskSinAnalyzer

Analyzer for radio telegrams in a HomeMatic environment
Other
73 stars 12 forks source link

WebUI: Anzeige des DutyCycle (einzelner Geräte, Zentrale, etc.) #46

Open jp112sdl opened 4 years ago

jp112sdl commented 4 years ago

@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.

jp112sdl commented 4 years ago

Nach meinen Recherchen dauert 1 Byte 0,81 Sekunden.

Bildschirmfoto 2019-10-25 um 18 18 11

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ß:

stan23 commented 4 years ago

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?

jp112sdl commented 4 years ago

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.

jens-maus commented 4 years ago

Geschlossen? Warum?

jp112sdl commented 4 years ago

Geschlossen? Warum?

Zu schnell/viel aufgeräumt 😎 Ich denke aber auch nicht, dass hier noch viel bzw. überhaupt was passieren wird.

jens-maus commented 4 years ago

Wieso? Technisch sollte es doch machtbar sein den DutyCycle je Gerät zu berechnen und mit darzustellen, oder?!?

psi-4ward commented 4 years ago

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.

TomMajor commented 4 years ago

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.

HMSteve commented 4 years ago

@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.

psi-4ward commented 4 years ago

Im Analyzer XS habe ich nun mal etwas eingebaut:

Screenshot-2020-03-18_14-37

stan23 commented 4 years ago

Die bereits im Web angezeigte Länge Len ist 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.

stan23 commented 4 years ago

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;
jp112sdl commented 4 years ago

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

stan23 commented 4 years ago

grafik 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 ;) grafik

stan23 commented 4 years ago

Die Frage ist halt, was man als Telegramm definiert. Zur Berechnung des Duty Cycle müssen aber alle gesendeten Bytes mit einbezogen werden.

jp112sdl commented 4 years ago

Ahhh! Jetzt hab ich die Diskrepanz verstanden 👍

stan23 commented 4 years ago

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 :-)

HMSteve commented 4 years ago

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 ;-)

1101

jp112sdl commented 4 years ago

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.)

HMSteve commented 4 years ago

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.