FRSKY Vorsicht bei "Telemetrie verloren" mit Horus
- Themenstarter Carbonator
- Beginndatum
Es ist richtig, daß man sich bei einer 16bit CRC kaum die gegebene Fehlerhäufigkeit vorstellen kann.
Aber an Pascals Code ist zu erkennen, daß bei der CRC16-Berechnung eine "Look-Up-Table" mit "nur" 16 aus den möglichen 65536 Werten angewandt wird. Das spart Rechenleistung.
Pascal hat das auch nur von FrSky übernommen, vielleicht ohne weiter darüber nachzudenken.
const uint16_t PROGMEM FrSkyX_CRC_Short[]={ 0x0000, 0x1189, 0x2312, 0x329B, 0x4624, 0x57AD, 0x6536, 0x74BF, 0x8C48, 0x9DC1, 0xAF5A, 0xBED3, 0xCA6C, 0xDBE5, 0xE97E, 0xF8F7 };
Damit wird die Fehlererkennungsrate eingeschränkt.
Vielleicht kann sich einer der Spezialisten hier aufraffen, auch mal einen konstruktiven Beitrag zu präsentieren und die Wahrscheinlichkeiten der Fehlererkennung für 16-Werte- und 256-Werte-Tabelle rechnerisch gegenüberstellen (65536-Werte Tabelle macht SW-mäßig keine Sinn).
Aber an Pascals Code ist zu erkennen, daß bei der CRC16-Berechnung eine "Look-Up-Table" mit "nur" 16 aus den möglichen 65536 Werten angewandt wird. Das spart Rechenleistung.
Pascal hat das auch nur von FrSky übernommen, vielleicht ohne weiter darüber nachzudenken.
const uint16_t PROGMEM FrSkyX_CRC_Short[]={ 0x0000, 0x1189, 0x2312, 0x329B, 0x4624, 0x57AD, 0x6536, 0x74BF, 0x8C48, 0x9DC1, 0xAF5A, 0xBED3, 0xCA6C, 0xDBE5, 0xE97E, 0xF8F7 };
Damit wird die Fehlererkennungsrate eingeschränkt.
Vielleicht kann sich einer der Spezialisten hier aufraffen, auch mal einen konstruktiven Beitrag zu präsentieren und die Wahrscheinlichkeiten der Fehlererkennung für 16-Werte- und 256-Werte-Tabelle rechnerisch gegenüberstellen (65536-Werte Tabelle macht SW-mäßig keine Sinn).
Zuletzt bearbeitet:
Hunderte Flüge im Grenzbereich der Reichweite ohne einen Furz reichen wohl nicht. Was erwartest du von Leuten, die schon jahrelang auf ACCST schwören. Nicht vom Hörensagen, sondern aus eigener Erfahrung.
Die CRC Sache ist kein real existierendes Problem, wie auch Pascal schreibt.
Die CRC Sache ist kein real existierendes Problem, wie auch Pascal schreibt.
Zuletzt bearbeitet:
Lach dann werden die marken herseller für Opentx unter vertrag genommen udndei ganze model Szene hat ein einheitlich programmierbares system. so schönnnnnnnn oooooo sssssooooooo schönn aufwachen der Wecker hat geklingelt.
Uiiiiiiiii was jetzt sind das alles nur eingebildete Fehler oder nur zur Foren Belebung ersstellten Themen
Uiiiiiiiii was jetzt sind das alles nur eingebildete Fehler oder nur zur Foren Belebung ersstellten Themen
Gleich der nächste Beitrag von Kilrah stellt es doch klar:
Andererseits wird niemand ohne Einblick in den aktuellen und einen geänderten Code genaueres sagen können. Also heißt es nur abwarten und gucken, was die Updates am Problem ändern oder ggfs. neue Probleme schaffen.
Du kannst ja zwischenzeitlich schon mal die Spezifikation von "openRF" ausarbeiten ...
Andererseits wird niemand ohne Einblick in den aktuellen und einen geänderten Code genaueres sagen können. Also heißt es nur abwarten und gucken, was die Updates am Problem ändern oder ggfs. neue Probleme schaffen.
Du kannst ja zwischenzeitlich schon mal die Spezifikation von "openRF" ausarbeiten ...
Carbo,
hast du denn jeden deiner Flüge geloggt und kannst du ausschließen daß nicht ein "unbenutzter Servoausgang" betroffen war oder zB nur der Gaskanal? Bei ungenutzten Ausgängen "friert" das System ja nur für ca 0,9 Sekunden ein und ist somit oftmals garnicht sichtbar!
Erkannt wird der Fehler ja nur wenn ein Servoauschlag sichtbar wird, Höhe-Tiefe, bei nur einem Querruder oder zB vollem Wölbklappenausschlag.
Bei dem besagten Fehler ist die Wahrscheinlichkeit ja sehr viel höher das er garnicht bemerkt wird obwohl er real existiert! Mich würde die Dunkelziffer Mal interessieren.
Gruß Michael
hast du denn jeden deiner Flüge geloggt und kannst du ausschließen daß nicht ein "unbenutzter Servoausgang" betroffen war oder zB nur der Gaskanal? Bei ungenutzten Ausgängen "friert" das System ja nur für ca 0,9 Sekunden ein und ist somit oftmals garnicht sichtbar!
Erkannt wird der Fehler ja nur wenn ein Servoauschlag sichtbar wird, Höhe-Tiefe, bei nur einem Querruder oder zB vollem Wölbklappenausschlag.
Bei dem besagten Fehler ist die Wahrscheinlichkeit ja sehr viel höher das er garnicht bemerkt wird obwohl er real existiert! Mich würde die Dunkelziffer Mal interessieren.
Gruß Michael
Deswegen macht es auch keinen Sinn, wie von Ewald gefordert, falsche CRC Wahrscheinlichkeiten zu berechnen. Das Problem liegt nicht dort.
Nee, es haben tatsächlich einige Horus Nutzer Probleme mit Lockouts und unbeabsichtigten Servoausschlägen. Aber doch nicht alle FrSky Nutzer, bitte nicht alles über einen Kamm scheren.
Wieviele Störungen hattest du denn? Ich meine mit CRC?
Nee, es haben tatsächlich einige Horus Nutzer Probleme mit Lockouts und unbeabsichtigten Servoausschlägen. Aber doch nicht alle FrSky Nutzer, bitte nicht alles über einen Kamm scheren.
"Allerhopp" kann den Mike ja mal überzeugen ... . Der wiederum hat übersehen oder weiß nicht, dass die Probleme auch in nicht "very noisy RF environments" auftreten.
. Der wiederum hat übersehen oder weiß nicht, dass die Probleme auch in nicht "very noisy RF environments" auftreten.
"Allerhopp" kann den Mike ja mal überzeugen ... . Der wiederum hat übersehen oder weiß nicht, dass die Probleme auch in nicht "very noisy RF environments" auftreten. Dort halt viel seltener.
. Der wiederum hat übersehen oder weiß nicht, dass die Probleme auch in nicht "very noisy RF environments" auftreten. Dort halt viel seltener.
Und wie der sich erst wundern wird, wenn er hört, dass es auch mit FCC auftritt ....
Zuletzt bearbeitet:
Im Log wird nur ein "Einfrieren" der Werte sichtbar. Bei 0,2s sollte man das am RSSI sehen können, dort sind aufeinanderfolgende identische Werte sehr selten. Sollte man mit einem Script finden können.
Hier ein sehr deutliches Beispiel aus einem Flug von Norbert mit dem problematischen iXJT. Höhe wird im Sender gelogt und ist natürlich nicht betroffen.
Hier ein sehr deutliches Beispiel aus einem Flug von Norbert mit dem problematischen iXJT. Höhe wird im Sender gelogt und ist natürlich nicht betroffen.
Meine Logs laufen sogar mit 0,1s aber auf den ersten Blick fällt sowas nicht auf, erst recht wenn der Log etwas länger ist wie ein paar Minuten z.b beim Segler da kann schon mal 1-2 Stunden zusammen kommen.
Oben im Log von Carbonator ganz schön zu sehen, man muss den Log schon Stark auseinander ziehen und vergrößern.... Wer macht das von euch? die nur fliegen wollen und im schlimmsten FAll den Log überhaupt aktiveren bestimmt nicht
Was ich damit sagen möchte, man Muss schon wissen nach was man gezielt danach suchen.
Oben im Log von Carbonator ganz schön zu sehen, man muss den Log schon Stark auseinander ziehen und vergrößern.... Wer macht das von euch? die nur fliegen wollen und im schlimmsten FAll den Log überhaupt aktiveren
bestimmt nichtWas ich damit sagen möchte, man Muss schon wissen nach was man gezielt danach suchen.
Könnte funktionieren, auf gehts...
Warum ich das sage ist einfach weil vermutet wurde das man es in den Log sieht (oder besser, einfach sehen kann), wie gesagt man sieht es wenn der Log läuft und man sich die Zeit nimmt nach dem Flug danach zu suchen.
Noch mal die Frage wer macht das, geschweige denn wer sucht nach etwas von dem man gar nicht weis das es Existiert
Warum ich das sage ist einfach weil vermutet wurde das man es in den Log sieht (oder besser, einfach sehen kann), wie gesagt man sieht es wenn der Log läuft und man sich die Zeit nimmt nach dem Flug danach zu suchen.
Noch mal die Frage wer macht das, geschweige denn wer sucht nach etwas von dem man gar nicht weis das es Existiert
