Der SPort wird nicht gestresst, der sendet immer alle 12ms seine Daten, egal ob ein Sensor angeschlossen ist oder nicht. Nur die Update Rate für die Sensor Info kann runtergehen, wenn mehrere Sensoren angeschlossen sind (z.B. eine zusätzliche Flight Control mit Telemetrieausgabe oder ein zusätzlicher OpenX-Sensor).
Wenn ein Sensor auf dem SPort liegt, läuft das SPort Timing folgendermaßen:
ms
0 ------ 'bekannter Sensor A' sendet einen 32Bit Wert, z.B. ID
5100
12 ---- Empfänger fragt 'unbekannten Sensor' #1 an (keine Antwort, wenn nicht angeschlossen)
24 ---- 'bekannter Sensor A' sendet einen 32Bit Wert, z.B. ID 5101
36 ---- Empfänger fragt 'unbekannten Sensor' #2 an (keine Antwort, wenn nicht angeschlossen)
48 ---- 'bekannter Sensor A' sendet einen 32Bit Wert, z.B. ID 5102
60 ---- Empfänger fragt 'unbekannten Sensor' #3 an (keine Antwort, wenn nicht angeschlossen)
72 ---- 'bekannter Sensor A' sendet einen 32Bit Wert, z.B. ID 5103
84 ---- Empfänger fragt 'unbekannten Sensor' #4 an (keine Antwort, wenn nicht angeschlossen)
96 ---- 'bekannter Sensor A' sendet einen 32Bit Wert, z.B. ID 5104
108 --- Empfänger fragt 'unbekannten Sensor' #5 an (keine Antwort, wenn nicht angeschlossen)
120 -- 'bekannter SensorA' sendet einen 32Bit Wert, z.B. ID
5100
132 --- Empfänger fragt 'unbekannten Sensor' #6 an (keine Antwort, wenn nicht angeschlossen)
usw.
Der Sensorwert 5100 wird hier also bei jeder 5. Abfrage aktualisiert. Bei der Original Tadango SW wird der 5100 Wert auch nur bei jeder 5. Abfrage des Tadango-Sensors aktualisiert (k.A. warum, vielleicht hatte Tadango in seiner 1. SW Version Probleme alle 24ms einen aktuellen Wert zur Verfügung zu stellen. Seine Pufferspeicher waren mit long Variablen indiziert, jetzt sind sie aber auf 100 Werte reduziert, was die Prozentberechnung sehr einfach macht), dazwischen wird der Wert auf 'nicht verfügbar' gesetzt.
Ich bin auch mal gespannt, ob FrSky bei dem FL-Bit in der V2.x einen Rückzieher macht.
