FRSKY Vorsicht bei "Telemetrie verloren" mit Horus
- Themenstarter Carbonator
- Beginndatum
. Ich glaub einfacher wäre es, wenn die Betroffenen Sender (OS und HF-Firmware) und RX auf den aktuellen Stand bringen würden, Log einschalten und dann dann weiter testen. So wie es sich aktuell darstellt, sind einfach zu viele unterschiedliche Konfigurationen in Benutzung.
Wie bereits mehrfach geschrieben, treten die Probleme mehr im Nahfeld auf. Zum Teil unter 50 mtr Abstand und 5 mtr Höhe. Mein letzter Ausfall " Doppelausfall" war in 10 oder 20 mtr Luftlinie. Davor 2 Tage ohne Probleme, danach wieder 2 Tage ohne Probleme am Moosberg mit ungefähr 10 anderen in der Luft???
Das einzig vielleicht interessant war, dass ich zuvor und danach mit externer Antenne geflogen bin. Hatte die externe Antenne abgebaut, weil ich den Sender dieses mal im Rucksack hochtrug, um sie nicht zu beschädigen. Keine Reichweitenprobleme, nur "Landeprobleme". Die externe Antenne war vorher natürlich abgeschaltet. Nach dem Vorfall sicherheitshalber wieder montiert.
UND DOCH: Kontollverlust von 1 sec kann tötlich sein: Da es 17:00 war ( Kaffeezeit bei uns ) wollte ich meinen XPlorer landen. Da ich 50 mtr hoch war habe ich ihn im 50° Winkel angestochen um 1 Looping und eine Rolle zu machen und dann zu landen. Bei 20 mtr wollte ich ziehen - nada. Gottseidank kurz vor dem Boden konnte ich wieder ziehen - voll. Da er für den Windenstart gebaut ist, hielt er es klaglos aus.
Da ich immer mitlogge sind jede Menge Daten da - aber man sieht bei den ungesteuerten Ausschlägen nichts - nur die Korrekturreaktion und bei den Aussetzern gerade Striche im Log.
Muss den Log von gestern Abend noch kontrollieren, da stotterte der Varioton und die Höheansage beim Steigen hing 2x für ~3 - 4 Sekunden beim gleichen Wert um dann auf den korrekten Wert zu springen.
Ich merke Aussetzer sofort, da ich ständig die relative Höhe, Abstand, Richtung und Vario mitlaufen habe. Beim Kreisen korrigiere ich laufend die Schräglage mit Quer und Längsachse mit Höhe, sodaß ich Kontrollverlust < 1 sec bemerke. Nur beim stationären Geradeausflug würde ich nur das hängen der Telemtriewerte bemerken.
"Elektrostatische Entladungen wie von Tadango vermutet kann ich ausschliessen, " sehe ich nicht so, da es schon genügt über den Teppichboden zu laufen und die Antennenspitze zu berühren. Glaube aber nicht, dass das unser Fehler ist, da dann eher der Empfänger "taub" wird und nicht für kurze Augenblicke "spinnt".
Der ratlose Norbert
Das einzig vielleicht interessant war, dass ich zuvor und danach mit externer Antenne geflogen bin. Hatte die externe Antenne abgebaut, weil ich den Sender dieses mal im Rucksack hochtrug, um sie nicht zu beschädigen. Keine Reichweitenprobleme, nur "Landeprobleme". Die externe Antenne war vorher natürlich abgeschaltet. Nach dem Vorfall sicherheitshalber wieder montiert.
UND DOCH: Kontollverlust von 1 sec kann tötlich sein: Da es 17:00 war ( Kaffeezeit bei uns ) wollte ich meinen XPlorer landen. Da ich 50 mtr hoch war habe ich ihn im 50° Winkel angestochen um 1 Looping und eine Rolle zu machen und dann zu landen. Bei 20 mtr wollte ich ziehen - nada. Gottseidank kurz vor dem Boden konnte ich wieder ziehen - voll. Da er für den Windenstart gebaut ist, hielt er es klaglos aus.
Da ich immer mitlogge sind jede Menge Daten da - aber man sieht bei den ungesteuerten Ausschlägen nichts - nur die Korrekturreaktion und bei den Aussetzern gerade Striche im Log.
Muss den Log von gestern Abend noch kontrollieren, da stotterte der Varioton und die Höheansage beim Steigen hing 2x für ~3 - 4 Sekunden beim gleichen Wert um dann auf den korrekten Wert zu springen.
Ich merke Aussetzer sofort, da ich ständig die relative Höhe, Abstand, Richtung und Vario mitlaufen habe. Beim Kreisen korrigiere ich laufend die Schräglage mit Quer und Längsachse mit Höhe, sodaß ich Kontrollverlust < 1 sec bemerke. Nur beim stationären Geradeausflug würde ich nur das hängen der Telemtriewerte bemerken.
"Elektrostatische Entladungen wie von Tadango vermutet kann ich ausschliessen, " sehe ich nicht so, da es schon genügt über den Teppichboden zu laufen und die Antennenspitze zu berühren. Glaube aber nicht, dass das unser Fehler ist, da dann eher der Empfänger "taub" wird und nicht für kurze Augenblicke "spinnt".
Der ratlose Norbert
Wer Lust hat, kann mal in Mike Blandfords Thread zur Entwicklung einer D16 Firmware für D8 Empfänger schauen. Besonders der Teil mit den verlorenen 100 Frames und dem Resync ist interessant. ich hoffe ja immer noch, auf diesem Umweg weiter zu kommen, mal schaun .....
Da ich leider nicht über die Zeit und Kompetenzen verfüge etwas zu bauen:
Im frsky-forum und auch hier kommt ja immerwieder die Theorie, dass der Sender die falschen Signale im Modulschacht ausgibt und auch an den Empfänger so übermittelt (kein Falesafe). Um den Fehler eindeutig nachzuweisen müssten wir doch einfach mit einem passenden Arduino + SD Karte im Modulschacht und im Modell die Servobewegungen (z.b. über SBUS) mitloggen?
Wäre so ein Logger schwierig umzusetzen? Ich habe die Hardware schon liegen, welche ich auch weitergeben würde, aber zu wenig Know-How.
Im frsky-forum und auch hier kommt ja immerwieder die Theorie, dass der Sender die falschen Signale im Modulschacht ausgibt und auch an den Empfänger so übermittelt (kein Falesafe). Um den Fehler eindeutig nachzuweisen müssten wir doch einfach mit einem passenden Arduino + SD Karte im Modulschacht und im Modell die Servobewegungen (z.b. über SBUS) mitloggen?
Wäre so ein Logger schwierig umzusetzen? Ich habe die Hardware schon liegen, welche ich auch weitergeben würde, aber zu wenig Know-How.
Zuletzt bearbeitet:
Die Theorie wurde aber deutlich abgeschwächt.
Der Betroffene mit dem externen Modul, weswegen der aktuelle thread geöffnet wurde, schrieb ein paar Tage später;
"Hallo und guten Morgen,
seit Gestern stellt sich mein Problem anders dar und die Horus scheint nicht für alles verantwortlich zu sein.
Gestern wieder eingefrorene Ruder in der Kombination Graupner MX-22 mit Jeti Modul. "
Der Betroffene mit dem externen Modul, weswegen der aktuelle thread geöffnet wurde, schrieb ein paar Tage später;
"Hallo und guten Morgen,
seit Gestern stellt sich mein Problem anders dar und die Horus scheint nicht für alles verantwortlich zu sein.
Gestern wieder eingefrorene Ruder in der Kombination Graupner MX-22 mit Jeti Modul. "
Der Fehler riecht so streng nach HF-Modul/-Firmware, dass ich da keine Zeit ivestieren würde. Klar kann man PXX oder PPM capturen und analysieren, aber da wird nix bei rauskommen, da bin ich sehr sicher.
Meine aktuelle Hypothese ist, dass irgendetwas im Empfangsbereich passiert, was die Firmware nicht abfängt. Entweder falsche Prüfsumme oder ein Fehler in der Hopping-Tabelle oder ähnliches. Es scheint dann den Kanal 1 kurz zu verändern, dann hängt sich der Empfänger für 1 Sekunde weg. Danach wird neu synchronisiert und es läuft, bis zum nächsten Ereignis. Riecht vielleicht ein bisschen nach einem overflow.
Meine aktuelle Hypothese ist, dass irgendetwas im Empfangsbereich passiert, was die Firmware nicht abfängt. Entweder falsche Prüfsumme oder ein Fehler in der Hopping-Tabelle oder ähnliches. Es scheint dann den Kanal 1 kurz zu verändern, dann hängt sich der Empfänger für 1 Sekunde weg. Danach wird neu synchronisiert und es läuft, bis zum nächsten Ereignis. Riecht vielleicht ein bisschen nach einem overflow.
Gestern nach längerer Zeit auch mal wieder bei mir: Meldung RXLOSS mit Failsafe auf meinem CineBee 75 HD Whoop mit R-XSR-Empfänger und Sender X-Lite (LBT) in ca. 15m Entfernung.
Zum Glück hielten ihn meine aktuellen Failsafe-Einstellungen stabil in der Luft bis meine Steuerbefehle wieder durch kamen...
Gruß Gerd
Zum Glück hielten ihn meine aktuellen Failsafe-Einstellungen stabil in der Luft bis meine Steuerbefehle wieder durch kamen...
Gruß Gerd
Ganz vergessen, hier gab es noch einen Kollegen, der exakt diesen Fehler beschreibt. Der V8R7-II ist ein D8 Empfänger. Demnach wäre der Fehler wieder sehr stark auf das HF-Modul selbst einzugrenzen.. Andererseits wirft es die Frage auf, warum so wenig FCC Piloten von dem Fehler berichten.
Hi,
falls jemand Zeit hat und Lust verspuert einen SBUS Monitor auf seinem Rechner ans Laufen zu bringen,
ich habe am Wochenende leider zu viele Baustellen, werde mich erst im Laufe der naechsten Woche drum kuemmern:
notwendig sind meinem Verstaendnis nach
- Java
- eine "Processing" Umgebung / workframe
- das script
- ein FTDI Adapter
- ein Inverter um SBUS am FTDI ans Laufen zu bekommen
(je nach FTDI Adapter kann wohl per tool auch via SW invertiert werden)
Damit wuerden sich schnell Zucker und Failsaves darstellen lassen.
Wenn es ans Laufen zu bringen ist wuerde ich versuchen "Schleppzeiger" fuer die Servoausschlaege zu integrieren und eine Frameloss Zaehlung unterzubringen.
das script und seine Beschreibung:
Real-Time Graphical Representation | S.BUS Protocol - ROBOTmaker
die Processing Umgebung
Download \ Processing.org
... funktioniert wohl ein wenig wie Arduino IDE, nur eben am Rechner und auf Basis Java
Ich hab's kurz versucht, ohne Erfolg
evtl liegt es daran, dass die aktuelle Processing Version nicht mehr kompatibel ist
im Moment muss ich mich leider anderweitig beschaeftigen
Revidiere:
kaum nimmt man einen anderen Rechner, schon funktionierts scheinbar
zumindestens erhalte ich den Eroeffnungsscreen mit der Meldung no data,
nun mal schauen ob ich noch genug Teile fuer den Inverter hierhabe
falls jemand Zeit hat und Lust verspuert einen SBUS Monitor auf seinem Rechner ans Laufen zu bringen,
ich habe am Wochenende leider zu viele Baustellen, werde mich erst im Laufe der naechsten Woche drum kuemmern:
notwendig sind meinem Verstaendnis nach
- Java
- eine "Processing" Umgebung / workframe
- das script
- ein FTDI Adapter
- ein Inverter um SBUS am FTDI ans Laufen zu bekommen
(je nach FTDI Adapter kann wohl per tool auch via SW invertiert werden)
Damit wuerden sich schnell Zucker und Failsaves darstellen lassen.
Wenn es ans Laufen zu bringen ist wuerde ich versuchen "Schleppzeiger" fuer die Servoausschlaege zu integrieren und eine Frameloss Zaehlung unterzubringen.
das script und seine Beschreibung:
Real-Time Graphical Representation | S.BUS Protocol - ROBOTmaker
die Processing Umgebung
Download \ Processing.org
... funktioniert wohl ein wenig wie Arduino IDE, nur eben am Rechner und auf Basis Java
Ich hab's kurz versucht, ohne Erfolg
evtl liegt es daran, dass die aktuelle Processing Version nicht mehr kompatibel ist
im Moment muss ich mich leider anderweitig beschaeftigen
Revidiere:
kaum nimmt man einen anderen Rechner, schon funktionierts scheinbar
zumindestens erhalte ich den Eroeffnungsscreen mit der Meldung no data,
nun mal schauen ob ich noch genug Teile fuer den Inverter hierhabe
Zuletzt bearbeitet:
Aktuell berichtet einer auf RCG über kurze Verbindungsabbrüche mit kurzzeitigem Failsafe sowohl im Flug wie auch am Boden. Betrifft diesmal nicht FrSky sondern anderes 2,4 GHz System (Assan). Nach seinen Ermittlungen zur Ursache, wurden die Störungen durch aktives WiFi seines Smartphones verursacht. Nach Abschalten des WiFi gab es keine Empfangsstörungen mehr. Also entweder WiFi beim Smartphone ausschalten oder gleich das Smartphone wärend des Fliegens nicht am Mann tragen, sondern beiseite legen. Die in der Nähe stehenden Kollegen sollten dabei tunlichst das gleiche tun.
Im deutschen Frsky-Forum hat Fa. Engel von Frsky bestätigt bekommen, dass es unter bestimmten Umständen durch ein kombiniertes Hardware/Softwareproblem zu diesen Kanalzuckern und Failsafe kommen kann, häufiger bei den LBT- und selten bei FCC-Verisonen. Es wird an einem Fix gearbeitet.
Hier könnt Ihr mal den Fall live mit anschauen. Mein CineWhoop kippt unvermittelt nach rechts ab, gleichzeitig erscheint die RXLOSS-Meldung und Betaflight fängt ihn dank angepasstem Failsafe-Handling wieder ab. Gesteuert mit X-Lite, Empfänger ist ein R-XSR.
Gruß Gerd
Dropbox - RXLOSS.mp4 - Simplify your life
Hier könnt Ihr mal den Fall live mit anschauen. Mein CineWhoop kippt unvermittelt nach rechts ab, gleichzeitig erscheint die RXLOSS-Meldung und Betaflight fängt ihn dank angepasstem Failsafe-Handling wieder ab. Gesteuert mit X-Lite, Empfänger ist ein R-XSR.
Gruß Gerd
Dropbox - RXLOSS.mp4 - Simplify your life
Im Engel Forum wurden Details genannt. Es sollen sich trotz Fehlerkorrektur falsche Kanalwerte im SBus Signal bzw. am PWM Ausgang einstellen können. Sehr selten, aber bei allen D16 Anlagen und zwar von Anfang an.
Das mag der Fall sein. Aber ich habe es nie bemerkt oder gemessen. Und ich habe wirklich viel Zeit damit verbracht, das FrSky Protokoll und die Geräte zu verstehen. Zumindest den Teil, der für die Praxis wichtig ist.
Ich bin sehr sicher, dass der Fehler, um den es hier geht, ein völlig anderer ist:
- eine falsche Kanalinformation für 1/111s bekommt man überhaupt nicht mit
- der beschriebene Fehler führt nicht zu einer "telemetry lost" Meldung
- auch nicht zu einer "RX loss" Meldung
- und auch nicht zu einem 1 Sekunden Lockout
- viele Fehler traten im Nahbereich bei Null Frameloss auf
Schließlich waren auch nur wenige Kombinationen betroffen. Und da vor allem iXJT. Dieser letzte Punkt wird überhaupt nicht beachtet. Es sollen alle ACCST Sender betroffen sein.
Da waren die Kollegen leider auf der falschen Spur unterwegs. Ich hoffe, dass bei einer eventuellen Korrektur dieses "Fehlers" keine neuen Fehler in das D16 Protokoll eingebaut werden.
Das mag der Fall sein. Aber ich habe es nie bemerkt oder gemessen. Und ich habe wirklich viel Zeit damit verbracht, das FrSky Protokoll und die Geräte zu verstehen. Zumindest den Teil, der für die Praxis wichtig ist.
Ich bin sehr sicher, dass der Fehler, um den es hier geht, ein völlig anderer ist:
- eine falsche Kanalinformation für 1/111s bekommt man überhaupt nicht mit
- der beschriebene Fehler führt nicht zu einer "telemetry lost" Meldung
- auch nicht zu einer "RX loss" Meldung
- und auch nicht zu einem 1 Sekunden Lockout
- viele Fehler traten im Nahbereich bei Null Frameloss auf
Schließlich waren auch nur wenige Kombinationen betroffen. Und da vor allem iXJT. Dieser letzte Punkt wird überhaupt nicht beachtet. Es sollen alle ACCST Sender betroffen sein.
Da waren die Kollegen leider auf der falschen Spur unterwegs. Ich hoffe, dass bei einer eventuellen Korrektur dieses "Fehlers" keine neuen Fehler in das D16 Protokoll eingebaut werden.
Zuletzt bearbeitet:
