FRSKY Vorsicht bei "Telemetrie verloren" mit Horus

Carbonator · Dez 27, 2019

Eigentlich ging es darum, ob das MPM beim Lokalisieren der Ursachen für die Lockouts helfen kann.
Die Abweichung der Empfänger kann man durch Verstimmen des MPM beurteilen (relativ). Abweichungen der Sender könnte man mit dem SA herausfinden, wenn die nötige Auflösung erreicht wird.

@arti: Du hast offenbar passende Parameter gefunden, stell sie doch hier ein, oder gleich die komplette Scanner_cc2500.ino, dann kann man für die verschiedenen MPMs je ein File fertigmachen. Durch die Möglichkeit im Sender das MPM zu flashen, ist es eine Sache von Sekunden zwischen der nomalen und der manipulierten MPM Firmware zu wechseln.

Parallel kannst du ja mal Pascal ansprechen, ob er eventuell die Konfigurationsmöglichkeit wie beim ACCESS Scanner einbauen würde. Von OpenTX Seite funktioniert es ja schon.

arti · Dez 27, 2019

C++:

static void __attribute__((unused)) Scanner_cc2500_init()
{
    /* Initialize CC2500 chip */
    CC2500_WriteReg(CC2500_08_PKTCTRL0, 0x12);   // Packet Automation Control
    CC2500_WriteReg(CC2500_0B_FSCTRL1,  0x0A);   // Frequency Synthesizer Control
    CC2500_WriteReg(CC2500_0C_FSCTRL0,  0x00);   // Frequency Synthesizer Control
    CC2500_WriteReg(CC2500_0D_FREQ2,    0x5C);   // Frequency Control Word, High Byte    // 0x5C orig
    CC2500_WriteReg(CC2500_0E_FREQ1,    0x62);   // Frequency Control Word, Middle Byte // 0x4E orig
    CC2500_WriteReg(CC2500_0F_FREQ0,    0x78);   // Frequency Control Word, Low Byte    // 0xC3 orig == 2400MHz; now 2402MHz
    CC2500_WriteReg(CC2500_10_MDMCFG4,  0xFD);   // Modem Configuration                   // 0x8D orig == ~200kHz BW; now 58kHz
    CC2500_WriteReg(CC2500_11_MDMCFG3,  0x3B);   // Modem Configuration
    CC2500_WriteReg(CC2500_12_MDMCFG2,  0x10);   // Modem Configuration
    CC2500_WriteReg(CC2500_13_MDMCFG1,  0x20);   // Modem Configuration                    // 0x23 orig = chanspc_E 3; now 0 -> orig Channelspacing 333kHz
    CC2500_WriteReg(CC2500_14_MDMCFG0,  0x00);   // Modem Configuration                    // 0xA4 orig = Chanspc_M 164; now 0 -> now Channelspacing 25kHz
    CC2500_WriteReg(CC2500_15_DEVIATN,  0x62);   // Modem Deviation Setting
    CC2500_WriteReg(CC2500_18_MCSM0,    0x08);   // Main Radio Control State Machine Configuration
    CC2500_WriteReg(CC2500_19_FOCCFG,   0x1D);   // Frequency Offset Compensation Configuration
    CC2500_WriteReg(CC2500_1A_BSCFG,    0x1C);   // Bit Synchronization Configuration
    CC2500_WriteReg(CC2500_1B_AGCCTRL2, 0xC7);   // AGC Control
    CC2500_WriteReg(CC2500_1C_AGCCTRL1, 0x00);   // AGC Control
    CC2500_WriteReg(CC2500_1D_AGCCTRL0, 0xB0);   // AGC Control
    CC2500_WriteReg(CC2500_21_FREND1,   0xB6);   // Front End RX Configuration

    CC2500_SetTxRxMode(RX_EN);  // Receive mode
    CC2500_Strobe(CC2500_SIDLE);
    CC2500_Strobe(CC2500_SRX);

    delayMicroseconds(1000);  // wait for RX to activate
}

Es werden nur ein paar Register anders gesetzt beim Initialisieren des CC2500 beim MPM SA. Die Startfrequnez, die Bandbreite und das Channelspacing. Es sind Änderungen in 5 Zeilen des Codes dafür nötig. Ich hab trotzdem die ganze Scanner_cc2500_init() reingestellt der Scanner_cc2500.ino

Carbonator hat gesagt.:

Fast, die Details der Implementierung des SA in OpenTX sind tatsächlich unterschiedlich fürs ISRM und das MPM.Es ist aber absolut kein Ding den SA vom MPM im OpenTX dahingehend zu erweitern um vom fixen Frequenzbereich abzuweichen. Selbiges gilt für das "SA Protokoll" im MPM, viele Änderungen brauchts nicht.
Ich glaube ich könnte das umsetzen aber wenn diese Änderungen langfristig in die Codebasis sollen, dann müsste ich mich auch mit Leuten von beiden Projekten kurzschließen.

arti · Dez 27, 2019

Gruni hat gesagt.:

Sorry, für den SA gibt es glaub keine Doku außer den Code selbst.

Da man mit unseren OpenTX Sendern Logs auf die SD Karte schreiben kann sollte es prinzipiell möglich sein auch die SA Scans auf die SD Karte zu kriegen. Jetzt musst du nur noch jemanden finden der gewillt ist das zu implementieren

Carbonator · Dez 27, 2019

arti hat gesagt.:

Die Frage ist wohl am Ende, wieviele Leute das tatsächlich nutzen würden, also ob es den Aufwand wert ist. Frag doch einfach mal im RCG MPM Thread, da lesen beide Devs mit

arti hat gesagt.:

Möglicherweise reicht ein Screenshot (Spezialfunktion), der funktioniert seit einiger Zeit auch mit den Farbsendern, also jetzt mit allen ....

arti · Dez 27, 2019

Carbonator hat gesagt.:

Für mich ist die Frage gerade ob ich mich auch mal mit dem OpenTX Code beschäftigen wollen würde oder nicht. Aktuell tendiere ich stark zu einem Ja. Auch wenn ich nicht weiß wo ich die Zeit dafür hernehmen soll. Eigentlich wollte ich die Urlaubszeit nutzen um meine Heliflotte zu warten und 3 noch ausstehende Helis aufzubauen. Glücklicherweise fliege ich seit meinen 2 Empfänger Lockout Crashes nicht mehr. In der Wartezeit bis FrSky das Problem endlich löst könnte ich mich ja auch Mal wieder nützlich machen und was coden.

Carbonator · Dez 27, 2019

Boah, da muss man ja bei denken

Guck mal bitte, ob ich das richtig verstanden habe:

Das sind das MPM in der T16 und meine X9E gemessen mit dem MPM in der X9D. Der tatsächliche Bereich beginnt bei 2402MHz und das Channel Spacing sind 25kHz, statt 333kHz. Ein "Klick" war also 1MHz, jetzt ist ein "Klick" 75kHz. Die angezeigten 2428 MHz sind also in Wirklichkeit 2402MHz+28*75kHz, also 2402+2,1MHz = 2404,1 MHz.
Demnach kann ich davon ausgehen, dass das MPM in der X9D um 0,1MHz danebenliegt, es ist nicht abgestimmt worden. Für meine X9E lege ich die Hand ins Feuer

Jetzt wäre natürlich eine Vergleichsmessung mit einem Sender interessant, der die Lockouts gezeigt hat.

Norbert · Dez 27, 2019

Hallo,
ihr bedenkt schon, dass der Fehler des "Mess"Senders direkt mit eingeht, es ist eine relative Messung, im Verhältnis zum SA des verwendeten Senders.
Ich kann mir nicht vorstellen, dass man so zum Ziel kommt und etwas aussagen kann, da das Messgerät immer eine 10er Potenz besser sein sollte als das Messobjekt. Wir sprechen hier von Ablagen von deutlich unter
100 Khz, also 2400 MHz zu kleiner100 KHz
Müsste noch mal messen, wann der G-RX8 aussteigt

bendh · Dez 27, 2019

ich finde zum Aufzeigen dass hier ein Problem vorliegt reicht doch eine relative Messung.

(Schon zu 35 MHz Zeiten hatten diejenigen einen deutlichen Reichweitenvorteil die einen Abgleich im Eingangskreis des Empfängers vorgenommen hatten.)

Norbert · Dez 27, 2019

Jaja - das ist schon richtig - es genügt, wenn Empfänger und Sender relativ zueinander abgestimmt sind. Da ist es egal, ob sie 20 khZ unter oder 50 Khz oberhalb der Sollfrequenz sind. Das kann man wunderbar mit dem MPM machen, indem man alle Empfänger ausmisst und im OTx die Mittenfrequenz speichert.

Was man hier versucht ist - wenn ich das richtig verstehe, mit einem Sender einen anderen Sender auszumessen, obwohl man die Abweichung des "messs"Senders nicht kennt, der ja selbst schon (wahrscheinlich) daneben liegt. Ausserdem reicht meiner Ansicht die Auflösung nicht.

Ich würde ein SpektrumAnalyser ( eigentlich Vektroanalyser) Modul von Banggood empfehlen, das erstaunlich gut ist - mit dem man auch Antennen ausmessen kann.

Geekcreit® Spectrum Analyzer USB LTDZ_35-4400M_Spectrum Signal Source with Tracking Source Module RF Frequency Domain Analysis Tool Module Board from Electronics on banggood.com

Norbert

Carbonator · Dez 27, 2019

Das ist sicher ein guter Tip, aber es wäre natürlich schöner, wenn man mit "Bordmitteln" arbeiten könnte. Bei den Empfängern klappt das ja schon und wenn ich 5 Empfänger mit dem MPM abgestimmt habe, dann weiß ich auch ungefähr, wo mein MPM frequenzmäßig liegt. Mein internes T16 MPM ist recht genau, hier zeigt es die Bindefrequenz meiner X9D (internes XJT). Es kann gut sein, dass die Auflösung wirklich zu niedrig ist, das wird man dann sehen, wenn jemand einen problematischen Sender mit einem unproblematischen vergleicht.

Wir wissen auf jeden Fall schon mal, dass die neuen Empfänger und die alten Empfänger oft (immer?) unterschiedlich liegen. Und worst case, wie Ewald schon schrieb, kann es mit dem falschen Sender dann zu viel werden. Dazu könnten wir noch ein paar Daten sammeln, oder still rumsitzen, wie das Kaninchen vor der Schlange. Lernen tut man bei solchen Aktionen immer etwas

Ich hänge mal die bin-Dateien für das AVR-MPM und das interne T16MPM an, falls mal jemand Sender messen will. Bei beiden ist #define CHECK_FOR_BOOTLOADER aktiv.

arti · Dez 27, 2019

Carbonator hat gesagt.:

Im Grunde stimmt dein Vorgehen. Wo ich mir aktuell nicht ganz sicher bin bei dem Tracker step von 1MHz weil der Code dahinter etwas umfangreicher ist.
Eine Möglichkeit es zu testen wäre das ursprünglich gesetzte Channelspacing von 333kHz und die 249 Kanäle. Abhängig vom verwendeten Display ändert sich die Pixelzuweisung der Kanäle. Bei der X9E sollte ein Pixel einem Kanal entsprechen (max 212 Kanäle sichtbar), also ändert sich der Tracker um exakt 3 Pixel mit jedem Knopfdruck. Auf der Xlite ist es natürlich extra schlimm weil 2 Kanäle auf einen Pixel landen, also muss ich das große MPM an der Horus nutzen um bessere Sicht zu haben.
Übrigens, 0,1 MHz vom MPM würde ich glauben. Genau dafür ist die Frequenzabstimmung ja da, sagt ja schon die Doku vom diesem Feature. Die FrSky Module wurden im Werk abgestimmt, die MPM Frequenz darfst du dagegen selbst finden.

Norbert hat gesagt.:

Na bei 50€ braucht man ja nicht Mal überlegen. Unter der Annahme dass es Software dazu gibt werd ich das mal bestellen. Merci für die Info. Das MPM als SA mit feinerer Auflösung als 25kHz zu benutzen wäre auch kein Problem, der CC2500 kann das (bis auf die minimale Bandbreite von 58kHz), nur wenn es schon fast umsonst einen fertiges Gerät aus dem Chinashop gibt, warum nicht?

Gruni · Dez 27, 2019

Na wenn schon, denn schon...
Geekcreit® Spectrum Analyzer USB LTDZ 35-4400M Signal Source with Tracking Source Module RF Frequency Domain Analysis Tool With Aluminum Shell Module Board from Electronics on banggood.com

Grüsse Gruni

quax2011 · Dez 28, 2019

Moin Leute, ich muss gestehen dass ich - je mehr ich hier lese ohne eine Ahnung von HF - Technik zu haben - immer verunsicherter werde. Für mich stellen sich mehrere Fragen : 1 Hab ich (X9D+ und HorusX12S) einen nicht betroffenen Sender oder einen betroffenen (und hab's nur noch nicht bemerkt). 2 Wie kann ich das ohne großen Aufwand - wenn überhaupt - feststellen (Lost frame zähler ??? Die Brocken dazu hab ich mal bestellt). 3 Ist nun eigentlich sicher geklärt ob es am Sender(Typ) am Empfänger oder an einer Kombi aus beiden liegt? Und 4 Was kann ich tun???? Wenn einer der Spezialisten mal eine Zusammenstellung der - unstrittigen, gesicherten - Erkenntnisse hier posten könnte wäre das sicher für viele hilfreich. Ich hoffe dieser Wunsch ist jetzt nicht unverschämt.

Gruß Jürgen
P.S. Meine Empfänger: X6R und X8R sowie zwei R-X6R und ein paar alte D8.

arti · Dez 28, 2019

quax2011 hat gesagt.:

Genau so geht es mir auch. Aber exakt gleich.

Bis zum Herbst bin ich mit einer X9D+ und einer X12S geflogen. verwendete Empfänger:
auf Helis X8R, RX8R, X4R, XSR und R-XSR, immer ohne Redudancy Funktion, also ein Empfänger pro Modell. Auf Coptern hatte ich ausschließlich den XM+
In der Kombination hatte ich auf einem einzigen Heli etwa alle 50 Flüge eine Auffälligkeit bemerkt, dieser ist mit R-XSR und danach mit RX8R unterwegs gewesen, mit X9D+ und danach mit X12S als Sender. Im Herbst bin ich auf eine Xlite Pro umgestiegen. Bei in Summe etwa 50 Flügen über verschiedenen Helis mit der Xlite Pro habe ich innerhalb 2 Wochen 2 Empfänger Lockouts gehabt die beide Male in einem Crash endeten. Einmal ein RX8R und einmal ein XSR als Empfänger.
Seitdem war ich nicht mehr in der Luft weil ich nichts weiter riskieren will.

Soweit ich das überblicke sind es zwei Dinge die mit reinspielen.
Die erste Hypothese (aber ohne einen Nachweis dafür) geht davon aus, dass bei neuerer Hardware der Frequenzüberlapp zwischen Empfänger und Sender nicht ausreichend gut ist. Dabei ist es zunächst irrelevant ob ein kleinerer Fangbereich oder eine Frequenzdrift der Hardware daran Schuld ist. In Folge dessen bekommt man öfters ungültige Frames über den HF Link wo einzelne Bits der Datenpakete geflippt sind.
Hier kommt jetzt die zweite wichtige Hypothese (gibt es dafür schon einen Nachweis?). Der CRC Check,der die Gültigkeit eines Frames überprüft, ist nicht ausreichend gut implementiert. In der aktuellen Form schaffen es auch ungültige Frames durch den CRC Check. Diese ungültigen Frames werden nicht als lost Frames vom Empfänger verworfen sondern werden weiter verarbeitet. So bekommt man je nachdem wo das falsche Bit sitzt falsche Informationen auf den einzelnen SBUS Kanälen oder gleich einen Empfänger Neustart.

Der erste Teil des Problems häuft sich erst bei neuerer Hardware. Der zweite Teil, der CRC Check, ist dagegen schon immer ein Problem gewesen. Es war nur seltener sichtbar bei der bisherigen Hardware. Zusätzlich sind die Konsequenzen bei FCC geringer als bei LBT. Dort kann es sogar zu einem Empfänger Lockout führen und nicht nur zu falschen Servo Ausschlägen.

Mein jetztiger Plan ist es auf eine Lösung von FrSky zu warten, ich habe ja sowieso keinen Zugang zum Code von deren Firmware. Bis eine Lösung gefunden wird werde ich versuchen mich mit deiner Fragestellung beschäftigen, wie kann ich das Problem selber sichtbar machen und wieder Vertrauen in die FrSky Hardware gewinnen?

Carbonator · Dez 28, 2019

Man sollte noch erwähnen, dass die weit überwiegende Zahl der FrSky Nutzer noch nie ein Problem hatten und haben und der Rest der Welt noch problemlos mit FrSky fliegt. Als ich das Thema eröffnet habe, waren es vielleicht eine Handvoll konkrete Auffälligkeiten, jetzt sind wir wo? Zwanzig Betroffene? Davon mit "alten" Sendern und Empfängern? Einer, Zwei oder doch gar keiner?

Wenn die Empfängerprüfung mit dem MPM keine auffällige Abweichung zeigt und die grüne Empfänger LED nicht flackert, kann man relativ sorglos fliegen. Wenn man dann noch die Möglichkeit hat, die Senderfrequenz auf Abweichung zu prüfen, sind alle Spatzen gefangen. Ach ja, wichtig: keine WLAN-Router, die Spielfilme übertragen und keine Störsender ins Modell packen

arti · Dez 28, 2019

Carbonator hat gesagt.:

So genau hab ich darüber noch gar nicht nachgedacht, das ist ein sinnvoller Vorschlag die Mittenfrequenz eines Empfängers zu prüfen. Über das Frequenztuning des MPM kann man die nötige Verstimmung des MPMs bestimmen um minimalen Frameloss zu sehen. Das so ermittelte Frequenztuning sollte für alle "guten" Empfänger quasi gleich und vor allem gleich breit sein.

Eine äquivalent einfache Messung für die Senderfrequenz steht noch aus.

Ich bin übrigens immer noch der Meinung dass der HF Link auch bei starker Verwendung des 2.4GHz Bandes immer noch zuverlässig sein sollte. Genau dafür treibt man ja diese FHSS und LBT Spielchen.

Carbonator · Dez 28, 2019

arti hat gesagt.:

Ich auch, aber man muss darauf achten, dass bei Tests realistische Bedingungen herrschen. Und es ist nicht realistisch, dass die Störquellen im Flugmodell mitfliegen. Dann macht der Modellbauer nämlich etwas falsch. Die üblichen Störer, also andere Sender, Telemetrieempfänger, Bluetooth, WLAN dürfen natürlich nicht zu Beeinträchtigungen führen.

FJH · Dez 28, 2019

arti hat gesagt.:

Da liegst du bezüglich LBT völlig falsch, das genaue Gegenteil ist der Fall. LBT erhöht in kritischen Empfangslagen das Risiko in den FS zu laufen.

Carbonator · Dez 28, 2019

FJH hat gesagt.:

Von der Theorie her sollte LBT, wenn es gut gemacht ist, die Situation für alle verbessern. Gibt es konkrete Untersuchungen zu dem Thema?

Elyot · Dez 28, 2019

LBT funktioniert dann gut, wenn es ALLE benutzen. Da es aber noch mehr als genug "Altgeräte" ohne LBT und auch viele HF-Schleudern gibt, ...

FRSKY Vorsicht bei "Telemetrie verloren" mit Horus

Allerhopp ;)

Well-known member

Well-known member

Allerhopp ;)

Well-known member

Allerhopp ;)

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Allerhopp ;)

Anhänge

Well-known member

Erfahrener Benutzer

Erfahrener Benutzer

Well-known member

Allerhopp ;)

Well-known member

Allerhopp ;)

Erfahrener Benutzer

Allerhopp ;)

Erfahrener Benutzer