FRSKY Vorsicht bei "Telemetrie verloren" mit Horus
- Themenstarter Carbonator
- Beginndatum
Das ist ja interessant. Das scheint die Synchronisation für den Rückkanal verloren zu gehen. An einen Defekt glaube ich eher nicht. Ich nehme an, es ist derselbe Sender, also immer dieselbe UID. Kannst du mal die nichtfunktionierende Kombination auf die Empfängernummer der funktionierenden Kombination umstellen? Dann sind auch die Hoppingtabellen identisch, vielleicht ist bei der Berechnung etwas faul. Beim Binden wird diese neu berechnet und gespeichert.
"Neu binden" mache ich nach jedem umflashen, bzw ändern der Leistung, aber bisher nicht gleich nachdem die Telemetrie weg war.
RSSI und Spannung (beides vom RX) wird tatsächlich noch angezeigt, alles andere kommt via f.port von der fc (matek 405 / iNav 2.1) und wird nicht empfangen (auch diese HW/SW, ist beim problemlosen quad identisch).
Ich hatte fc/f.port in Verdacht, aber wie kann das gefixed werden, wenn der Sender kurz ausgeschaltet wird.
RSSI und Spannung (beides vom RX) wird tatsächlich noch angezeigt, alles andere kommt via f.port von der fc (matek 405 / iNav 2.1) und wird nicht empfangen (auch diese HW/SW, ist beim problemlosen quad identisch).
Ich hatte fc/f.port in Verdacht, aber wie kann das gefixed werden, wenn der Sender kurz ausgeschaltet wird.
Wenn die Medung "Telemetry lost" kam, wird nichts mehr übertragen, auch kein RSSI und RxBt, diese Werte sind dann eingefroren.
Wenn RSSI und RxBt noch leben, und "nur" die FC-Daten fehlen, kam die Meldung "Sensor lost", das ist dann tatsächlich ein iNav/FC Problem und kann eher nicht durch Sender ausschalten neu synchronisiert werden (will ich aber nicht ausschließen).
Wenn es "Telemetrie lost" war, dann versuch es doch mal mit der Empfängernummer der funktionierenden Kombination.
Wenn RSSI und RxBt noch leben, und "nur" die FC-Daten fehlen, kam die Meldung "Sensor lost", das ist dann tatsächlich ein iNav/FC Problem und kann eher nicht durch Sender ausschalten neu synchronisiert werden (will ich aber nicht ausschließen).
Wenn es "Telemetrie lost" war, dann versuch es doch mal mit der Empfängernummer der funktionierenden Kombination.
Ja, das hat sich überschnitten. Meine Antwort bezog sich auf @markus1234 und das R9 System. Da sind wir ein bißchen vom Thema abgeschweift.
Diese "Failsaves" bis hin zum unklaren Modellverlust sind ansich ja deswegen schon bemerkenswert, weil das Übertragungsprotokoll recht sicher ist ( im Vergleich zu dem 35 MHz Zeiten ) .
Ich selbst erlitt 2x einen na sagen wir "eingefrorenen" Empfänger bei Futaba ( je ein 617er ) --warum, weswegen , unklar , da die beiden Spezialisten seit langem problemlos laufen ( von Segler bis Multicopter... ) also seit langem nach diesem "Ausfall" meine ich jetzt konkret, um Mißverständnissen vorzubeugen
Weswegen ich schreibe ist folgendes : Es gab mal einen interessanten wissenschaftlichen Artikel ob der Rückkanaltechnik- also Telemetrie heutiger Form. Dort wurde festgestellt ,dass die Ausfallstatistik um den Faktor 8 höher ist ggüb normalen, also telemetrielosen 2,4 GHz RC-systemen.
Dann dies. Ein bekannter verlor sein teures Flugzeug im LehrerSchülerbetrieb.... Grund. das Smartphone empfing eine Nachricht mit Bilddatei .... Dies konnte mit einem
"Opfermodell" reproduziert werden ...( MPX Anlage btw ) ein Fehler wurde zwar gefunden --wurde aber nicht in die Logdatei aufgezeichnet.....
wg Hitze.... jau ein ganz spezielles Thema ,denn 50° sind im Modell schnell erreicht. Deswegen fliege ich ab so 33° höchstens Billigflieger ,also keine Copter etc
Ich selbst erlitt 2x einen na sagen wir "eingefrorenen" Empfänger bei Futaba ( je ein 617er ) --warum, weswegen , unklar , da die beiden Spezialisten seit langem problemlos laufen ( von Segler bis Multicopter... ) also seit langem nach diesem "Ausfall" meine ich jetzt konkret, um Mißverständnissen vorzubeugen
Weswegen ich schreibe ist folgendes : Es gab mal einen interessanten wissenschaftlichen Artikel ob der Rückkanaltechnik- also Telemetrie heutiger Form. Dort wurde festgestellt ,dass die Ausfallstatistik um den Faktor 8 höher ist ggüb normalen, also telemetrielosen 2,4 GHz RC-systemen.
Dann dies. Ein bekannter verlor sein teures Flugzeug im LehrerSchülerbetrieb.... Grund. das Smartphone empfing eine Nachricht mit Bilddatei .... Dies konnte mit einem
"Opfermodell" reproduziert werden ...( MPX Anlage btw ) ein Fehler wurde zwar gefunden --wurde aber nicht in die Logdatei aufgezeichnet.....
wg Hitze.... jau ein ganz spezielles Thema ,denn 50° sind im Modell schnell erreicht. Deswegen fliege ich ab so 33° höchstens Billigflieger ,also keine Copter etc
Nach etlichen Messflügen mit dem openXsensor, sicher deutlich mehr als 100, kann ich sagen, dass der FrSky 2.4GHz Telemetrie Link extrem robust ist. Ich hatte nicht einen einzigen "Sensor Lost" oder "Telemetry Lost" Alarm. Seitdem bin ich von FrSky überzeugt.
R9 ist eine andere Baustelle, da gab es etliche Probleme mit "Sensor Lost", vielleicht auch "Telemetry Lost", da bin ich grad nicht sicher.
Beim iXJT gibt es die kurzen 1,2s Link-Verluste mit ganz kurzem Failsafe, bei denen noch nicht ganz klar ist, was sie genau verursacht. Der einzige Hinweis bei Flächenmodellen oft nur die "Telemetry Lost" Warnung.
Man sollte diese Effekte und auch die Meldungen klar unterscheiden.
Am WE werden 2 Longrange-Copter fertig, die beide mit R9 fliegen. Ich bin mal gespannt, wie robust die Telemetrie mit der aktuellen Firmware sein wird.
R9 ist eine andere Baustelle, da gab es etliche Probleme mit "Sensor Lost", vielleicht auch "Telemetry Lost", da bin ich grad nicht sicher.
Beim iXJT gibt es die kurzen 1,2s Link-Verluste mit ganz kurzem Failsafe, bei denen noch nicht ganz klar ist, was sie genau verursacht. Der einzige Hinweis bei Flächenmodellen oft nur die "Telemetry Lost" Warnung.
Man sollte diese Effekte und auch die Meldungen klar unterscheiden.
Am WE werden 2 Longrange-Copter fertig, die beide mit R9 fliegen. Ich bin mal gespannt, wie robust die Telemetrie mit der aktuellen Firmware sein wird.
Gerade habe ich beim fliegen wieder die "Telemetrie verloren" Meldung gehört, leider von dem "guten" meiner R9 Systeme 
. Allerdings ist es auch sehr heiß draussen. Ein "recover" der Telemetrie gabs erst nach einem Power cycle des Senders.
. Allerdings ist es auch sehr heiß draussen. Ein "recover" der Telemetrie gabs erst nach einem Power cycle des Senders.
Mit 2.4GHz hatte ich nie Probleme, dieser Problemfall ist bei 868MHz. Und selbst dabei hatte ich immer die volle Kontrolle - nur die Telemetrie ist ausgefallen.
Interessant. So einen Fall habe ich mit R9 noch nicht erlebt. Die komplette Telemetrie ist weg, der Sender logt nur noch seine eigenen Daten. Ich bin nicht sicher, was das sein könnte. Empfänger ausschalten hat ja auch mal geholfen. Wenn die sich neu suchen müssen, geht es wieder .....
Hast du mal die Empfängernummer gewechselt, um eine andere Hopping-Tabelle zu erzeugen?
Hast du mal die Empfängernummer gewechselt, um eine andere Hopping-Tabelle zu erzeugen?
Anhänge
"Yes, exactly that. I've just fixed a problem where if the Rx received a data packet, with a bad CRC, it lost sync. for half a second or so. I've just range checked this (Tx in range check mode), on my drive. I had full control when over 30 paces away (I'd be crossing the road to get any further!). I was sing a X9D+ with LBT firmware."
Dieser Beitrag hat mich gerade alarmiert. Mike Blandford arbeitet zwar an einer eigenen Firmware für die D8 Empfänger, da bin ich schon Standby zum Testen. Beim Lesen fiel mir aber sofort diese Sache hier ein. Wäre zu schön um wahr zu sein, wenn FrSky dasselbe "bad CRC" Problem hätte
Ich hab Mike mal angeschrieben, er hat einen guten Draht zu FrSky, vielleicht kommt ja etwas heraus.
Dieser Beitrag hat mich gerade alarmiert. Mike Blandford arbeitet zwar an einer eigenen Firmware für die D8 Empfänger, da bin ich schon Standby zum Testen. Beim Lesen fiel mir aber sofort diese Sache hier ein. Wäre zu schön um wahr zu sein, wenn FrSky dasselbe "bad CRC" Problem hätte
Ich hab Mike mal angeschrieben, er hat einen guten Draht zu FrSky, vielleicht kommt ja etwas heraus.
Danke!
Moin, FrSky scheint mit jedem Datenpaket, das über die Luft geht, einen Prüfwert mitzuschicken, um das Paket auf Gültigkeit überprüfen zu können. Wenn dieser Prüfwert ein nicht gültiges Paket ergab, hat sich die Firmware eine Auszeit genommen.
Aber das war bei Mike B.s D8 Firmware, es wäre ein großer Zufall, wenn FrSky denselben Fehler eingebaut hätte. Aber es ist auch nicht ausgeschlossen. Und vor allem könnte so ein Effekt alle bisherigen Beobachtungen zu dem Thema erklären.
Aber das war bei Mike B.s D8 Firmware, es wäre ein großer Zufall, wenn FrSky denselben Fehler eingebaut hätte. Aber es ist auch nicht ausgeschlossen. Und vor allem könnte so ein Effekt alle bisherigen Beobachtungen zu dem Thema erklären.
