Hy
MU10%
Verhältnis von Sendezeit und Nichtsendezeit pro Kanalhopp
Das betrifft nur das HF-Teil mit der Firmware des Herstellers (hat nichts mit openTx zu tun)
Ein Beispiel MU 10%
einen Kanal anspringen
100us Daten senden
900us nicht senden
warten, warten, warten, ........interne Dinge bearbeiten.
nächster Kanal anspringen
100us Daten senden
900us nicht senden
warten, warten, warten, .........interne Dinge bearbeiten
usw.
Was macht das Hf-Teil beim warten in der Zwischenzeit:
Ne ganze Menge
Telemetrie empfangen
Daten für den nächsten Sendezyklus vorbereiten,
Kanaldaten, Verschlüsselung, Rahmen, Prüfzahlen, usw.
Kommunikation mit openTx für Kanaldaten und Telemetrie
Kanal Sprungtabelle verwalten
und dann:
warten, warten, warten, .........interne Dinge bearbeiten
nächster Kanal anspringen
100us Daten senden
900us nicht senden
warten, warten, warten, .........interne Dinge bearbeiten
Das DatenVolumen um 16 Kanäle zu übertragen und das ganze drumherum ist nicht groß
ca 120-150 Byte mehr läuft dan nicht hin und her.
----------------------------------
Bisherige frei laufende Systeme hatten MU von ca 20-25% (wenn man dass so vergleichen will/kann)
--------------------------------
LBT kommt (wenn er ungestört und problemlos immer senden kann ) auch wieder auf ein MU von 25%
Kanal frei, dann Kanal anspringen
100us Senden
300-400us warten
warten....interne Dinge bearbeiten
Kanal frei, dann Kanal anspringen
100us senden
300-400us warten
warten... interne Dinge bearbeiten
usw.
Die Tätigkeiten beim warten sind die gleichen
zusätzlich kurz vor dem Senden auf den nächsten Kanal reinhören ob er frei ist.
....
Falls zu viel und zu oft Kanäle belegt sind
dann vom LBT auf MU10% umschalten (macht HOTT auch so)
Das war mal stark vereinfacht dargestellt, bis auf die reallen Zeiten
Wer es ganz genau haben will muss einen Protokollanalyser in die Schnittstelle von Hauptprozessor
zu HF-Prozessor einschleusen.
Wer die HF mitlesen will braucht einen synchronisierbaren schnellen Spektrumanalyser
Profiprüfstand von R&S so ab 50000€ aufwärts.
--
MU10%
Verhältnis von Sendezeit und Nichtsendezeit pro Kanalhopp
Das betrifft nur das HF-Teil mit der Firmware des Herstellers (hat nichts mit openTx zu tun)
Ein Beispiel MU 10%
einen Kanal anspringen
100us Daten senden
900us nicht senden
warten, warten, warten, ........interne Dinge bearbeiten.
nächster Kanal anspringen
100us Daten senden
900us nicht senden
warten, warten, warten, .........interne Dinge bearbeiten
usw.
Was macht das Hf-Teil beim warten in der Zwischenzeit:
Ne ganze Menge
Telemetrie empfangen
Daten für den nächsten Sendezyklus vorbereiten,
Kanaldaten, Verschlüsselung, Rahmen, Prüfzahlen, usw.
Kommunikation mit openTx für Kanaldaten und Telemetrie
Kanal Sprungtabelle verwalten
und dann:
warten, warten, warten, .........interne Dinge bearbeiten
nächster Kanal anspringen
100us Daten senden
900us nicht senden
warten, warten, warten, .........interne Dinge bearbeiten
Das DatenVolumen um 16 Kanäle zu übertragen und das ganze drumherum ist nicht groß
ca 120-150 Byte mehr läuft dan nicht hin und her.
----------------------------------
Bisherige frei laufende Systeme hatten MU von ca 20-25% (wenn man dass so vergleichen will/kann)
--------------------------------
LBT kommt (wenn er ungestört und problemlos immer senden kann ) auch wieder auf ein MU von 25%
Kanal frei, dann Kanal anspringen
100us Senden
300-400us warten
warten....interne Dinge bearbeiten
Kanal frei, dann Kanal anspringen
100us senden
300-400us warten
warten... interne Dinge bearbeiten
usw.
Die Tätigkeiten beim warten sind die gleichen
zusätzlich kurz vor dem Senden auf den nächsten Kanal reinhören ob er frei ist.
....
Falls zu viel und zu oft Kanäle belegt sind
dann vom LBT auf MU10% umschalten (macht HOTT auch so)
Das war mal stark vereinfacht dargestellt, bis auf die reallen Zeiten
Wer es ganz genau haben will muss einen Protokollanalyser in die Schnittstelle von Hauptprozessor
zu HF-Prozessor einschleusen.
Wer die HF mitlesen will braucht einen synchronisierbaren schnellen Spektrumanalyser
Profiprüfstand von R&S so ab 50000€ aufwärts.
--
Zuletzt bearbeitet: