Frage war auch, ob das mit den AFC-Fenster-Verschiebungen bei den Empfängern (da haben wir die ja festgestellt) und die dazu noch unterschiedlichster Natur sowohl in Minus- als auch in Plusrichtung für eine optimale Verbindung zum Sender technisch okay ist und damit unsere Ursachensuche damit nix zu tun hat. Ich bin kein Elektroniker und schon gar kein HF-Spezialist, um das beurteilen zu können.
FRSKY Vorsicht bei "Telemetrie verloren" mit Horus
- Themenstarter Carbonator
- Beginndatum
Habe jetzt mal bei meiner QX7 und X10S per SA die Bindefrequenz getestet.
QX7 FCC 2404 MHz
QX7 LBT 2406 MHz
X10S FCC 2404/2405 MHz
Habe keine Lust, meine X10S über FrOS zweimal hin und her zu flashen, um LBT auch zu testen. Habe leider kein LUA Script, um das einfach zu bewerkstelligen. Wenn jemand mir das LUA Script zur Verfügung stellt, dann hol ich den LBT-Test nach.
QX7 FCC 2404 MHz
QX7 LBT 2406 MHz
X10S FCC 2404/2405 MHz
Habe keine Lust, meine X10S über FrOS zweimal hin und her zu flashen, um LBT auch zu testen. Habe leider kein LUA Script, um das einfach zu bewerkstelligen. Wenn jemand mir das LUA Script zur Verfügung stellt, dann hol ich den LBT-Test nach.
Hallo Ewald,
vielen Dank für Deine aufwändingen Untersuchungen zu Frsky.
Es sind die einzigen halbwegs seriösen Ergebnisse die auf dem Tisch liegen.
Allerdings reicht das für mich nicht die Horus weiter zu betreiben. (ohgott, ohgott)
Scheinbar kommt von Frsky nichts mehr....noch nicht mal ein klitzekleines Statement.
Oder die Einsicht das grundsätzlich was falsch läuft.
Ich habe mit Frsky abgeschlossen und bin bei Flächenmodellen umgestiegen auf.....
Der Umbau aller Modelle läuft bereits.
Halt! meine Copterfarm betreibe ich noch mit einer X9d+ und dem RXSR.
Weihnachtsgrüsse an alle Suchenden. Ist ja Zeit zum Suchen an den Feiertagen.
Raimund
vielen Dank für Deine aufwändingen Untersuchungen zu Frsky.
Es sind die einzigen halbwegs seriösen Ergebnisse die auf dem Tisch liegen.
Allerdings reicht das für mich nicht die Horus weiter zu betreiben. (ohgott, ohgott)
Scheinbar kommt von Frsky nichts mehr....noch nicht mal ein klitzekleines Statement.
Oder die Einsicht das grundsätzlich was falsch läuft.
Ich habe mit Frsky abgeschlossen und bin bei Flächenmodellen umgestiegen auf.....
Der Umbau aller Modelle läuft bereits.
Halt! meine Copterfarm betreibe ich noch mit einer X9d+ und dem RXSR.
Weihnachtsgrüsse an alle Suchenden. Ist ja Zeit zum Suchen an den Feiertagen.
Raimund
Danke für den Link. Aber die X10S hat noch kein ISRM-Modul, die hat ein iXJT-HF-Modul. Habe mich da vielleicht auch vertan und es gibt dafür kein LUA Script und man muss immer noch den Umweg über FrOS machen, leider . Auch da hatte ich FrSky "gebeten", doch einen frk.file zum einfachen Flashen in den Download zu stellen. Aber nix ist es damit und wird dann ja auch nix mehr werden, da mittlerweile ja das iXJT nicht mehr verbaut wird,
. Auch da hatte ich FrSky "gebeten", doch einen frk.file zum einfachen Flashen in den Download zu stellen. Aber nix ist es damit und wird dann ja auch nix mehr werden, da mittlerweile ja das iXJT nicht mehr verbaut wird,Ja die Auflösung beträgt 1 MHz. Aber das Bindesignal ist als stehender Peak eindeutig zu identifizieren. Bei der X10S konnte ich jedenfalls erkennen, dass das Bindesignal zwischen 2404 und 2405 MHz liegt. Reicht also demnach als Genauigkeit nicht aus und ist demnach nicht verwertbar?? Wie genau müsste demnach dann diese Messung sein?
Ich denke schon, daß die Messungen oben mit dem MPM und dem RF-Explorer soweit stimmen.
Das würde bedeuten, daß man mit dem MPM ein Feintuning in 1,5kHz Schritten machen kann.
Es gilt allgemein, daß sich Empfänger- und Senderfrequenzbandbreite für eine optimale Demodulation zu mindestens 90% überlappen sollten. 10% von 232kHz Kanalbandbreite sind 23kHz, das läßt sich mit dem MPM gut abstimmen.
Man gehe einfach so vor, wie es beschrieben ist: Man ermittle die Grenzbereiche wo die Verbindung abreißt und stelle das MPM dann auf die Mitte dazwischen.
Das würde bedeuten, daß man mit dem MPM ein Feintuning in 1,5kHz Schritten machen kann.
Es gilt allgemein, daß sich Empfänger- und Senderfrequenzbandbreite für eine optimale Demodulation zu mindestens 90% überlappen sollten. 10% von 232kHz Kanalbandbreite sind 23kHz, das läßt sich mit dem MPM gut abstimmen.
Man gehe einfach so vor, wie es beschrieben ist: Man ermittle die Grenzbereiche wo die Verbindung abreißt und stelle das MPM dann auf die Mitte dazwischen.
Zuletzt bearbeitet:
Sinn und Zweck des SA des ISRM wäre zu zeigen, ob noch andere Teilnehmer auf dem Band sind oder nicht. Bei 1MHz Schritten muß dann die Empfangsbandbreite des Empfängers ebenfalls auf 1 MHz eingestellt sein. Sonst gibt es Lücken die nicht erfaßt werden. Mit einer Empfangsbandbreite von 1Mhz kann ich aber keine Messungen im 10kHz Bereich machen.
Wenn ein Bindesignal zwischen 2404 und 2405 gemessen wird, sagt mir das auch, daß die Anzeige nicht Frequenzsynchron ist, d.h. verschoben ist um etliche 100kHz.
Für einen einfache Bandscanner reicht das, aber mehr nicht.
Wenn ein Bindesignal zwischen 2404 und 2405 gemessen wird, sagt mir das auch, daß die Anzeige nicht Frequenzsynchron ist, d.h. verschoben ist um etliche 100kHz.
Für einen einfache Bandscanner reicht das, aber mehr nicht.
Ich persönlich finde die Halb-Automatische Abstimmung mit dem MPM optimal.
Im Gegensatz zu einem Vollautomatischen Abgleich während des Bindens (was vorgeschlagen wird), kriege ich hierbei mit wo ich eigentlich liege, bzw. kann ungewöhnlich große Abweichungen feststellen, welche auf einen Defekt hindeuten.
Zudem wird das durch OpenTX untertützt,, d.h. die Einstellung des MPM wird für jeden einzelnen Empfänger individuell mit der Modellnummer gespeichert.
Im Gegensatz zu einem Vollautomatischen Abgleich während des Bindens (was vorgeschlagen wird), kriege ich hierbei mit wo ich eigentlich liege, bzw. kann ungewöhnlich große Abweichungen feststellen, welche auf einen Defekt hindeuten.
Zudem wird das durch OpenTX untertützt,, d.h. die Einstellung des MPM wird für jeden einzelnen Empfänger individuell mit der Modellnummer gespeichert.
Da stellt sich mir die Frage ob die hier diskutierte Problematik jemals in Verbindung mit dem MPM beobachtet wurde? Da dessen Hardware und Firmware open source ist könnte man dem Ganzen etwas besser nachgehen und wenn man es nur zum Nachstellen des Problems an den FrSky Sendemodulen verwendet.
Fliegt jemand mit dem MPM tatsächlich auch FrSky Empfänger? Ich verwende es nur für nicht-FrSky Protokolle.
Fliegt jemand mit dem MPM tatsächlich auch FrSky Empfänger? Ich verwende es nur für nicht-FrSky Protokolle.
Norbert, fliegt mit dem MPM.
Die Problematik der CRC Fehler (Servoausschläge) ist damit nicht behoben, da das MPM die FrSky Algorithmen kopiert hat. Aber ich sag mal gelindert, da es bei optimalem Frequenzabgleich von Haus aus zu weniger FLs kommt.
Es ist einfach so, wenn auf der HF-Strecke weniger Bit-Fehler auftreten, gibt es auch weniger Fehler, welche das anschließende CRC entdecken muß und damit weniger Fehler, welche nicht entdeckt werden konnten.
Und da es bei FCC noch weniger Fehler auf der HF-Strecke gibt als mit LBT, natürlicherweise, ist dort die CRC Problematik noch geringer.
Die Problematik der CRC Fehler (Servoausschläge) ist damit nicht behoben, da das MPM die FrSky Algorithmen kopiert hat. Aber ich sag mal gelindert, da es bei optimalem Frequenzabgleich von Haus aus zu weniger FLs kommt.
Es ist einfach so, wenn auf der HF-Strecke weniger Bit-Fehler auftreten, gibt es auch weniger Fehler, welche das anschließende CRC entdecken muß und damit weniger Fehler, welche nicht entdeckt werden konnten.
Und da es bei FCC noch weniger Fehler auf der HF-Strecke gibt als mit LBT, natürlicherweise, ist dort die CRC Problematik noch geringer.
Die Implementierung der FrSky Protokolle im MPM ist eine direkte Kopie? Hat FrSky den Code mal rausgegeben? Es wird dann aber nicht die aktuellste Version sein können. Beim Überfliegen ist mir aufgefallen das LBT nicht implementiert: Note that the LBT part is not implemented, the TX transmits right away.
So wie du das sagst hab ich das auch verstanden. Ungenügende CRC Fehlererkennung lässt falsche Frames durchkommen. Ungünstige Konstellationen von Sendern/Empfängern führen dazu dass generell mehr fehlerhafte Frames auftreten, wo das CRC Problem dann wieder häufiger zuschlägt. Die ungünstigsten Konstellationen ergeben sich mit LBT und neuester Hardware. Richtig?
So wie du das sagst hab ich das auch verstanden. Ungenügende CRC Fehlererkennung lässt falsche Frames durchkommen. Ungünstige Konstellationen von Sendern/Empfängern führen dazu dass generell mehr fehlerhafte Frames auftreten, wo das CRC Problem dann wieder häufiger zuschlägt. Die ungünstigsten Konstellationen ergeben sich mit LBT und neuester Hardware. Richtig?
