Vorsicht bei "Telemetrie verloren" mit Horus

Hier braucht's Leute, die mitdenken. Und du bist einer von denen, also streng dich an. Ich bin nicht Baby Schimmerlos ;)
 
Ich finde, solche 'Hetze' hat in einem Forum nichts zu suchen. Jeder kann doch seine eigene Meinung haben und diese frei äußern. Das sollte man akzeptieren, auch wenn man anderer Meinung ist.
 
Also wenn du meinen Kommentar zu @ralfwo meinst, @ralfwo weiß genau wie das gemeint ist und grinst sich einen. Wir lieben uns hier alle und was sich liebt, das neckt sich :)

In meinem Post ist sogar ein Lob versteckt, man muss es nur finden ....
 
Ich meine deine Jagd nach RCJohn. Einen Preis auszusetzen (Lost Frame Sensor) finde ich nicht mehr lustig. Lass uns doch bei der technischen Diskussion bleiben.
 
Einverstanden, aber auch eine technische Diskussion darf Spaß machen.

Ich mag halt offenes Visier lieber. Wenn sich jemand neu anmeldet, um in so eine Diskussion einzusteigen, ist das erstmal seltsam. Aber ich habe den Grund jetzt vermutlich kapiert und rückblickend war das tatsächlich doof von mir. War aber als Spaß gemeint, wie soll man denn die wahre Identität eines "RCJohn" herausfinden? Der kann sich nur selbst outen.
 
Ja, Spaß darf die Diskussion machen, nur nicht auf Kosten anderer. Das muss man halt akzeptieren, wenn jemand sich in verschiedenen Foren mit unterschiedlichen Namen anmeldet.
OK, ich musste das mal loswerden. Ist für mich jetzt erledigt.
 
Ist ja auch OK, man soll aus seiner Mördergrube keine Herzen machen.
Carbo war mein erster Username bei openrc, der war überall sonst belegt, also habe ich hier Carbonator draus gemacht, was ziemlich uncool klingt und woanders heiße ich Allerhopp - ich finde das ist überschaubar ;)
 
Moin, ich mach mal einen Bericht zur Lage ;)

So wie es aussieht, sind die Jungs mit Ahnung jetzt aktiv. Ich muss nicht mehr so tun, als ob ich Ahnung hätte :D
Wirkliche Fakten sind aber noch nicht auf dem Tisch. Die CRC-Sache wird von den meisten angenommen, nur Midelic bezweifelt immer noch, dass bei alter Hard- und Firmware, X9D,-E,X8R,X4R überhaupt ein falsches Bit durchkommen kann. Ist mir sympathisch, denn das ist auch mein Eindruck aus der Praxis. Muss aber rnicht stimmen.

Es gibt eine Stimme mit Ahnung, die sagt, dass eine Frequenzabweichung im Sender und Störungen von außen das Problem verursachen können.

Es wird noch gestritten, ob von FrSky das Update auch für eine Verschlüsselung genutzt wurde, die Konkurrenz ausschließen soll. Der, der versucht sie zu knacken, sagt ja, die Anderen nein. :rolleyes:

Meine dramatische Enthüllung der SBus Fälschung interessiert keine S.u :D

Hier ein Schicksal, das zeigt, wie sch..ßegal FrSky die eigenen, guten Kunden sind.
  • Original ACCST X10 Horus (running OTX 2.3.5 and iXJT 2.0.1
  • 2x RSXR receivers (running 2.0.1)
  • RB-20 redundancy box with 2x 2S LiPos supplying power
  • S-Port connected from the RB-20 to both receivers
  • Various sensors, but primarily the RDT turbine s-port telemetry interface.
Er muss zurück auf die Vorgängerfirmware, weil die Telemetrie keinen sicheren Betrieb zulässt. Er stellt aber fest, dass es die Vorgängerfirmware bei FrSky gar nicht gibt. Er müsste über FrOs gehen. Die Verursacher der Chose haben sich nach Veröffentlichung des Updates in die Ferien verdrückt.

Zum Glück hat die Community die HF-Firmware aus FrOS extrahiert und verlinkt.

Ich wundere mich nach wie vor, wie geduldig die Schafe dem Hirten immer noch hinterherlaufen. Es werden ja nicht nur die Kunden, sondern auch die Händler nicht ernst genommen. Ein Händler, der sich um seine Kunden sorgt, ist aktuell vermutlich am Schlimmsten dran.

Der US Händler verweist nicht auf FrSky in seinem Erklärungen, sondern auf Dritte bei RCG. Wie arm ist das denn, FrSky? Man muss aber auch sagen zum Ver@rschen braucht es immer zwei.
 
Zuletzt bearbeitet:

arti

Well-known member
Fleißig am zusammenfassen wie die Lage sich entwickelt. Alleine alle laufenden Diskussionen in den verschiedenen Communities zu verfolgen braucht ein wenig Zeit.
Merci für die Kurzvariante :)
 
Die "Germany's next topmodell" Redaktion hat einen Scripted Reality Autor abgestellt, der nichts anderes macht, als dieses Drama zu beobachten. Vermutlich werden wir es in ähnlicher Form noch mal erleben, wenn Cindy Nadine anzickt ;)
 
Mike Blandford, der "einsame Wolf" mit interessanten Informationen (übersetzt von mir):

Neben der Hardware-CRC hat /hatte FrSky meines Erachtens ein weiteres Problem. Jedes Paket enthält Daten darüber, wie man in der Sprungsequenz zum nächsten Kanal gelangt. Dies sollte in jedem Paket gleich sein. Ich vermute, dass FrSky den Wert aus dem Paket jedes Mal verwendet, wenn ein Paket empfangen wird. Wenn ein Paket mit Fehlern akzeptiert wird, könnte dieser Wert falsch sein, und das Ergebnis wäre die 0,9-Sekunden-Sperre, da sie im Empfänger falsch hoppen würden.

Mein Verständnis eines Ereignisses, das vor einiger Zeit stattgefunden hat, ist, dass jemand, der an openTx arbeitet, Informationen von FrSky (unter NDA) hatte, diese aber veröffentlichte. Dies ärgerte FrSky, der nun viel vorsichtiger damit umgeht, Informationen an Entwickler weiterzugeben.
Wir sind jetzt auf der Faktenebene angelangt, was oft nur durch grobe Provokation gelingt, sonst wird nämlich nur rumgesülzt. Ab hier bitte sachlich bleiben, das gilt speziell für mich ;)
 
Hmm. Das ist die Antwort auf die angebliche NDA Verletzung durch OpenTX Dev's. Es scheint sich um die Geschichte zu handeln, als FrSky die Zusatzhardware zur Abschaltung von Fremdmodulen eingebaut hat. Kilrah schreibt, dass sie das mit Hilfe der User selbst herausgefunden haben und überhaupt keine Info von FrSky dazu vorlag.
 

FJH

Erfahrener Benutzer
Verwendung des ISRM-Nachrüstmoduls in der Horus verursachte (dessen Firmware) durch die Sender-interne Verifizierung (ob FrSky oder Fremdsender) gefährliche Übertragungs-/Steuerfehler, da FrSky das ohne Abstimmung mit den OTx Devs reingepackt hatte.
 
Mike Blandford, der "einsame Wolf" mit interessanten Informationen (übersetzt von mir):



Wir sind jetzt auf der Faktenebene angelangt, was oft nur durch grobe Provokation gelingt, sonst wird nämlich nur rumgesülzt. Ab hier bitte sachlich bleiben, das gilt speziell für mich ;)
Das steht seit Wochen in der Erklärung des FrSky Forums, daß neben Nutzdaten auch Kontrolldaten fehlerhaft sein können und daß es in dem Fall zum Verlust der Synchronisation kommen kann, d.h. 0,9s hold.

Mike: ".........da sie im Empfänger falsch hoppen würden........"

Allerdings kann ich mir nicht vorstellen, daß der RX diese Daten dazu verwendet um sich nach jedem Frame in der Spruntabelle neu auszurichten. Das wäre viel zu instabil bei lost Frames (LBT als auch FCC).
Die Sprungtabelle ist fest, das kann man messen, unabhängig davon wie viele Frames verloren gehen.
Vielmehr ist diese Maßnahme ein zusätzlicher Sicherheitsabgleich, daß die Synchronisation noch intakt ist und daß keine Verwechslung mit Nachbarkanälen anliegt. Das könnte sonst besonders im Nahbereich beim Einschalten passieren (Kanal-Übersprechen bei hoher Feldstärke).
Wenn dieser Wert nicht paßt, dann geht der RX in den Synch-Modus, aber keine Änderung der Sprungtabelle.
 
RCLogger

FPV1

Banggood

Banggood

Oben