FRSKY Vorsicht bei "Telemetrie verloren" mit Horus

H

helle

Erfahrener Benutzer
#41
#41
Cyclic Redundancy Check

CRC ist ein Verfahren, um aus einem beliebig langen Datenstrom eine Prüfsumme zu erzeugen. Das besondere ist, dass sich die Prüfsumme schon bei minimalen Veränderungen in den Daten stark verändert und es damit sehr unwahrscheinlich ist, dass zwei verschiedene Datenströme die gleiche Prüfsumme haben. Der häufigste Einsatzzweck von CRC ist die Überprüfung von Daten auf Unversehrtheit
bei der Datenübertragung.
Der Empfänger kann damit erkennen ob der jeweilige empfangene Datenframe fehlerfrei war.
Mit etwas aufwändigeren Verfahren kann er sogar den Datenframe bedingt wieder rekonstruieren,
je nach Verstümmelungsgrad der Daten.
Oder er wartet einfach auf den nächsten fehlerfreien Datenframe.

---
 
GerdS

GerdS

Erfahrener Benutzer
#42
#42
Normalerweise sollte man einen einzelnen CRC-Fehler gar nicht bemerken, da wird der empfangene Frame einfach verworfen, die Werte des vorherigen weiterhin ausgegeben und auf den nächsten gewartet. Je nach System dauert das maximal 20ms. Erst wenn mehrere Frames mit CRC-Fehler hintereinander folgen, sollte der Empfänger nach einer vorgegebenen Anzahl Fehler oder Zeitspanne ohne fehlerfreien Empfang auf Failsafe schalten.
Aber stimmt schon, falls FrSky da einen Softweare-Bug drin hat, würde das jede Menge bislang unerklärlicher Failsafes erklären, auch die zum Glück sehr selten auftretenden Failsafes bei meinen beiden CineWhoops mit XM+ bzw. R-XSR-Empfängern.
Das wäre natürlich eine Mega-Blamage für die Software-Qualitätssicherung bei FrSky, würde wohl also niemals eingestanden werden...

Gruß Gerd
 
Carbonator

Carbonator

Allerhopp ;)
#43
#43
Möglicherweise sind das verschiedene Routinen. Bei einem "verlorenen Frame" wird einfach auf das nächste gewartet. Kommt ein Frame durch, wird er auf Gültigkeit geprüft. Wenn diese Routine bei "bad CRC" Amok läuft, könnte das den Kanalausschlag und die Kunstpause erklären, bis irgendein Watchdog eingreift. Eventuell treten diese "bad CRC" Frames nur ganz selten auf.

Aber das ist alles reine Spekulation. Aber es passt so schön ;)
 
Carbonator

Carbonator

Allerhopp ;)
#44
#44
Wenn jemand diese Hypothese überprüfen will, dann am besten im RSSI Bereich um 45, da beginnen die ersten Frames verloren zu gehen und die Chance auf ein bad CRC ist m.E. relativ groß. Rangetestmode einen Raum weiter sollte dafür etwa passen.
R_XSR_RT.png
 
Norbert

Norbert

Erfahrener Benutzer
#45
#45
Die Theorie passt bezüglich RSSI nicht ganz, da die meisten Probleme im Nahfeld zwischen 50-200 mtr passieren.
Sonst wäre das eine Erklärung, die zu überprüfen wäre. Ich hoffe wir erhalten Antwort.
Beim Engel Forum wird gerade heftig zum Thema Hold/Ausschlag diskutiert.
 
S

strgaltdel

Erfahrener Benutzer
#46
#46
RSSi ist leider nur die halbe Wahrheit.
Wesentlich wichtiger waere der SNR Wert.
...Ich komme jetzt mal wieder mit der Fresnel Zone...
Durch die Reflektionen könnte theoretisch kurzzeitig eine Fehler in der Übertragung auftreten, obwohl der Sender "alles richtig" gemacht hat.

Was ist denn, wenn zufällig ein paar Kollegen Ihr Handy auf WLAN haben,
ein paar Piloten zufällig hin und wieder auf der gleichen Frequenz funken wollen wie dein Sender in dem Moment,
das Gras / die Umgebung feucht ist,
die G-Rx Eingänge evtl noch sensibler sind als andere Empfänger um Reichweite zu erhöhen.....

Wir könnten adhoc dutzende, erst einmal plausible Erklärungen liefern, die nach und nach "abgehakt" / widerlegt werden müssten.

Ich glaube ohne reproduzierbaren Fehler kommen wir nicht weiter,
und dann stellt sich nach der Analyse ggf. noch die Frage, ob man dann wieder eine Woche bis zum nächsten Fehler im Versuchsaufbau warten muss, um eine Theorie zu bestätigen....


Aber aus der Erfahrung heraus ist nur ein Problem mit dem Byte stuffing :wow:
 
Carbonator

Carbonator

Allerhopp ;)
#47
#47
Als "Nichtbetroffener" kann ich wenig dazu sagen. Ich finde aber die "bad CRC" Hypothese ist bis jetzt der beste Ansatz. Nur wie kann man "bad CRC" provozieren? Entweder an der Reichweitengrenze, das war mein Vorschlag mit RSSI ~45, oder im Nahbereich mit Störquellen, die sozusagen in valide Frames "hineinbrezeln".

Das könnte man nachstellen, indem man den Sender im Rangetest laufen lässt und einen, zwei, drei andere NonLBT Sender parallel laufen lässt, in der Hoffnung, dass relativ oft Frames mutieren. Oder jemand, der die Technik dazu hat, zerschießt die Frames aus dem CC2500 und schaut, ob dann der Prozessor ins Stolpern kommt.

Byte stuffing wäre auch mein Favorit gewesen :D
 
M

masterblaster

Active member
#48
#48
"bad CRC" wäre aber ein Empfänger-Problem und kein Problem am Sender. Der Empfänger muss das Frame dann ja einfach verwerfen.
Wenn das das Problem ist, dann sollte es potentiell doch mit allen Sendern auftreten. Ich habe das hier aber so verstanden, dass es nur mit bestimmten Sendern auftritt.

Man könnte theoretisch die pascallanger/DIY-Multiprotocol-TX-Module Firmware so modifizieren, dass alle paar Frames eine falsche Prüfsumme geschickt wird und dann schauen wie der Empfänger reagiert.
 
Erhaltene "Gefällt mir": Norbert
Norbert

Norbert

Erfahrener Benutzer
#49
#49
Würde da auch helfen die Mittenfrequenz des Multiprotokol Moduls zu verdrehen? Dann fängt die grüne LED auch an zu flackern und irgendwann bricht die Verbindung ab - das ist dann aber wahrscheinlich kein bad CRC
 
Carbonator

Carbonator

Allerhopp ;)
#50
#50
@masterblaster Mein Eindruck war, dass das Problem stärker mit den neuen Sendern und LBT auftritt. Als Vielflieger mit alten Sendern und FCC hätte es mich ja auch mal treffen müssen. Aber man weiß es halt nicht genau.

Die Idee mit dem MM finde ich sehr gut. Willst du den Pascal mal ansprechen, ob das überhaupt möglich ist?
@Norbert: eher nicht, aber der Pascal Langer kann da sicher etwas zu sagen.
 
M

masterblaster

Active member
#51
#51
Willst du den Pascal mal ansprechen, ob das überhaupt möglich ist?
Zum Vergrößern anklicken....
Solange die Prüfsumme von der Software berechnet wird sollte das auch möglich sein. Wie aufwändig das ist steht auf einem anderen Blatt.
Ich will mich da aber ungern reinhängen da wenig Zeit und auch selbst nicht betroffen. Habe hier nur mitgelesen und wollte das mal als Idee loswerden.
 
Carbonator

Carbonator

Allerhopp ;)
#52
#52
Die Routine war relativ leicht zu finden. Jetzt muss nur noch jemand hinkriegen, dass jedes 1000. Frame mit einem falschen Prüfwert gesendet wird. Traut sich das jemand zu? Wenn nicht, könnte ich mal Midelic fragen, der hat es geschrieben .....

Code: 
//**CRC**
const uint16_t PROGMEM frskyX_CRC_Short[]={
    0x0000, 0x1189, 0x2312, 0x329B, 0x4624, 0x57AD, 0x6536, 0x74BF,
    0x8C48, 0x9DC1, 0xAF5A, 0xBED3, 0xCA6C, 0xDBE5, 0xE97E, 0xF8F7 };
static uint16_t __attribute__((unused)) frskyX_CRCTable(uint8_t val)
{
    uint16_t word ;
    word = pgm_read_word(&frskyX_CRC_Short[val&0x0F]) ;
    val /= 16 ;
    return word ^ (0x1081 * val) ;
}
static uint16_t __attribute__((unused)) frskyX_crc_x(uint8_t *data, uint8_t len)
{
    uint16_t crc = 0;
    for(uint8_t i=0; i < len; i++)
        crc = (crc<<8) ^ frskyX_CRCTable((uint8_t)(crc>>8) ^ *data++);
    return crc;
}
 
GerdS

GerdS

Erfahrener Benutzer
#53
#53
Das ist zwar der Code zur CRC-Berechnung, nicht aber der Code, welcher den Frame zusammensetzt und genau dort müsste man ansetzen, also an der oder den Stellen wo der obige Code aufgerufen wird...

Gruß Gerd
 
Carbonator

Carbonator

Allerhopp ;)
#54
#54
OK, in meinem jugendlichen Leichtsinn hätte ich hier einen Zähler eingebaut und beim 1000. Mal die Prüfsumme einfach um X erhöht. Aber ich bin eher der Hardwareguy.
 
Carbonator

Carbonator

Allerhopp ;)
#55
#55
Mike Blandford hat gerade geantwortet. Er hält es für möglich, dass aus irgendeinem Grund die Synchronisation verloren geht, wenn viele Frames verloren gehen. An die CRC-Geschichte glaubt er eher nicht. Aber er ist bereit zu helfen, was schon mal eine Riesensache ist. Er schlägt einen RCG Thread vor.

Ich verstehe zwar alles, aber meine englischen Formulierungen sind eher suboptimal.
@strgaltdel Kannst du bei RCG einen Thread mit aussagefähigem Titel aufmachen, damit sich dort weitere Betroffene melden können? Du hast auch wahrscheinlich den besten Überblick. Vielleicht klar formulieren, dass das kein häufiger Fehler ist und die meisten völlig problemlos unterwegs sind. Aber es besteht halt eine geringe Chance, dass ein Hard- oder Firmwareproblem existiert. Möglichst so, dass die Hater nicht aufwachen ;)

Dieser Thread enthält sehr gute Daten, den kann man auch verlinken.
 
S

strgaltdel

Erfahrener Benutzer
#56
#56
Hi,
ich kann alles aktuell bekannte mal zusammenfuegen und einen thread aufmachen.
Komme aus Zeitgruenden allerdings erst morgen Abend oder Montag dazu.

Wenn es schneller gehen soll kann jemand vorab den thread mit Grobbeschreibungen starten, ich poste dann weitere Infos.

Denke vendors/Frsky sollte der richtige Platz sein
 
Carbonator

Carbonator

Allerhopp ;)
#58
#58
mstrens war so nett und hat den Code so geändert, dass jedes 1000ste Frame eine falsche Prüfsumme hat. Ich muss den ganzen Kram erst noch suchen, flashen u.s.w., wenn ich Zeit habe, vielleicht ist ja jemand schneller.

Code: 
//**CRC**

const uint16_t PROGMEM frskyX_CRC_Short[]={

0x0000, 0x1189, 0x2312, 0x329B, 0x4624, 0x57AD, 0x6536, 0x74BF,

0x8C48, 0x9DC1, 0xAF5A, 0xBED3, 0xCA6C, 0xDBE5, 0xE97E, 0xF8F7 };

static uint16_t __attribute__((unused)) frskyX_CRCTable(uint8_t val)

{

uint16_t word ;

word = pgm_read_word(&frskyX_CRC_Short[val&0x0F]) ;

val /= 16 ;

return word ^ (0x1081 * val) ;

}

int16_t counter_wrong_crc = 1000; // added

static uint16_t __attribute__((unused)) frskyX_crc_x(uint8_t *data, uint8_t len)

{

uint16_t crc = 0;

for(uint8_t i=0; i < len; i++)

crc = (crc<<8) ^ frskyX_CRCTable((uint8_t)(crc>>8) ^ *data++);



counter_wrong_crc--; // modified if( counter_wrong_crc == 0 ) { // added

counter_wrong_crc = 1000; // added

crc++; // added

} // added



return crc;

}
 
Zuletzt bearbeitet:
Um antworten zu können musst du eingeloggt sein.
FPV1

Banggood

Oben Unten