Das Problem mit FrSky ist halt, dass sie mal mit V1 einen Maßstab für das SBus FL Bit gesetzt haben und diesen nun verlassen haben. Andere Marken wie Jeti, Futaba mögen auch das FL Bit filtern, aber das haben sie dann schon immer getan. Ich denke, bei FrSky ist der Nerd Anteil (ich schließe mich da ein) auch höher als bei den anderen Marken, deshalb wird jede Änderung kritischer durchleuchtet.
Link Quality Sensor von Tadango
- Themenstarter Carbonator
- Beginndatum
- Status
Wenn ich bei Jeti richtig lese, wird hier noch völlig anders verfahren.
Man nimmt bei Jeti den Empfangenen Frame und sendet ihn per Rückkanal an den Sender zurück.
Der Sender prüft die Übereinstimmung und setzt hier das Lost im Sender. Es wird also immer die Hin und Rückstrecke gleichzeitig bewertet. Eine Unterscheidung ob der Fehler auf der Hin oder Rückstrecke lag, wird nicht gemacht. Obwohl vielfach von den Fliegern gefordert.
Unser vielseitig, mit mehreren Systemen erfahrene Wolfgang wird es erkennen, wenn ich falsch gelesen habe.
Sigi
Man nimmt bei Jeti den Empfangenen Frame und sendet ihn per Rückkanal an den Sender zurück.
Der Sender prüft die Übereinstimmung und setzt hier das Lost im Sender. Es wird also immer die Hin und Rückstrecke gleichzeitig bewertet. Eine Unterscheidung ob der Fehler auf der Hin oder Rückstrecke lag, wird nicht gemacht. Obwohl vielfach von den Fliegern gefordert.
Unser vielseitig, mit mehreren Systemen erfahrene Wolfgang wird es erkennen, wenn ich falsch gelesen habe.
Sigi
Hi,
muss jetzt hier auch mal ahnungslos fragen.
Habe ja die T16 mit dem ACCESS Modul (der ein oder andere hats vlt. mitbekommen)
Bin gestern damit fliegen gewesen. Einmal Goblin570 mit R-XSR Empfänger mit ACCESSund einmal Goblin380 mit XSR und logischerweise normal D16.
Der 570er flog einwandfrei mit dem ACCESS system. Beim 380er mit dem XSR im D16 hatte ich 2 mal das der Motor im Flug abstellte. Beim 2. mal flog ich leider grade auf dem Rücken, wodurch die Auro nicht ganz einfach war, aber den Schaden gering gehalten hat. Im LOG des FBL sieht man das er in 2 mal in Failsafe ging.
Am Sender wurde jedoch nichts gemeldet von wegen Telemetrie verloren. Leider ist das ISRM upgrade Modul ja noch nicht updatebar auf V2. Ist irgendwas bekannt ob es bei ACCESS auch zu aussetztern gekommen ist. Der XSR im Goblin 380 machte mit dem alten Sendemodul aus der X10 übrigens nie Probleme.Also wird es an der Kombi liegen.
muss jetzt hier auch mal ahnungslos fragen.
Habe ja die T16 mit dem ACCESS Modul (der ein oder andere hats vlt. mitbekommen)
Bin gestern damit fliegen gewesen. Einmal Goblin570 mit R-XSR Empfänger mit ACCESSund einmal Goblin380 mit XSR und logischerweise normal D16.
Der 570er flog einwandfrei mit dem ACCESS system. Beim 380er mit dem XSR im D16 hatte ich 2 mal das der Motor im Flug abstellte. Beim 2. mal flog ich leider grade auf dem Rücken, wodurch die Auro nicht ganz einfach war, aber den Schaden gering gehalten hat. Im LOG des FBL sieht man das er in 2 mal in Failsafe ging.
Am Sender wurde jedoch nichts gemeldet von wegen Telemetrie verloren. Leider ist das ISRM upgrade Modul ja noch nicht updatebar auf V2. Ist irgendwas bekannt ob es bei ACCESS auch zu aussetztern gekommen ist. Der XSR im Goblin 380 machte mit dem alten Sendemodul aus der X10 übrigens nie Probleme.Also wird es an der Kombi liegen.
Man muss mit dem Sensor ein bisschen Erfahrung sammeln, sonst ist es wie immer beim Messen 
Hier ein paar Logs aus einem Gespräch mit einem Kollegen, der seine Kombinationen mit dem Sensor prüfen wollte. Das erste Ergebnis im Haus:
Ganz übel. Aber es hat sich dann herausgestellt, dass das Haus "HF-verseucht" ist und sogar eine Fahrstuhlfahrt enthalten war. Das ist schlicht nicht verwertbar für eine Aussage über die verwendete Hardware.
Dann wurden Tests mit diesem und einem zweiten Sender im Freien durchgeführt:
Die 100% Phasen links und rechts zeigen ganz eindeutig, dass die Kombinationen kein grundsätzliches Problem haben. Aber ist die erste Kombi schlechter? Nach meiner Erfahrung besteht keine Lockout/USM Gefahr, aber die zweite Kombi zeigt solidere 100% bei hohem RSSI und weniger Verluste bei fallendem RSSI. Der erste Sender hat interne Antennen, der zweite eine externe Antenne. Um 45dB RSSI beginnen standardmäßig die feldstärkebedingten Frameverluste und die 2-3dB Vorteil der externen Antenne machen hier den Hauptunterschied zwischen den beiden Sendern. Möglicherweise hat der erste Sender auch noch eine leichte Frequenzabweichung, aber das ist leider nicht einfach nachzumessen und deswegen Spekulation.
Fazit: Um einen Überblick über die Frameverluste der verwendeten Hardware zu bekommen, muss man zuallererst in einem störungsfreien Gebiet unterwegs sein.
Hier ein paar Logs aus einem Gespräch mit einem Kollegen, der seine Kombinationen mit dem Sensor prüfen wollte. Das erste Ergebnis im Haus:
Ganz übel. Aber es hat sich dann herausgestellt, dass das Haus "HF-verseucht" ist und sogar eine Fahrstuhlfahrt enthalten war. Das ist schlicht nicht verwertbar für eine Aussage über die verwendete Hardware.
Dann wurden Tests mit diesem und einem zweiten Sender im Freien durchgeführt:
Die 100% Phasen links und rechts zeigen ganz eindeutig, dass die Kombinationen kein grundsätzliches Problem haben. Aber ist die erste Kombi schlechter? Nach meiner Erfahrung besteht keine Lockout/USM Gefahr, aber die zweite Kombi zeigt solidere 100% bei hohem RSSI und weniger Verluste bei fallendem RSSI. Der erste Sender hat interne Antennen, der zweite eine externe Antenne. Um 45dB RSSI beginnen standardmäßig die feldstärkebedingten Frameverluste und die 2-3dB Vorteil der externen Antenne machen hier den Hauptunterschied zwischen den beiden Sendern. Möglicherweise hat der erste Sender auch noch eine leichte Frequenzabweichung, aber das ist leider nicht einfach nachzumessen und deswegen Spekulation.
Fazit: Um einen Überblick über die Frameverluste der verwendeten Hardware zu bekommen, muss man zuallererst in einem störungsfreien Gebiet unterwegs sein.
Ich habe die aktuelle Software für den LQ-Sensor nach @Bionicbone Methode auf RCG veröffentlicht.
Ich habe die aktuelle Software für den LQ-Sensor mit dem Link in #287 geladen. Funktioniert auch mit 2.1-Update gut. Allerdings nur im D16 K1-8 Mode.
Wenn man mehr als 8 Kanäle nutzen möchte klappt es bei 2.1 nicht (5103 immer auf 100, 5104 keine Bewegung).
Im Original der Bionicbone-Mehode ist es aber beschrieben, dass es auch mit D16 K1-16 funktioniert ( Waveform z.B auf K8 und K16).
Es wåre schön, wenn das auch mit der aktuellen Software für den LQ-Sensor funktionieren würde.
Die Tadango- Methode funktioniert natürlich immer, aber bei 2.1 nicht korrekt.
Gruß BL
Wenn man mehr als 8 Kanäle nutzen möchte klappt es bei 2.1 nicht (5103 immer auf 100, 5104 keine Bewegung).
Im Original der Bionicbone-Mehode ist es aber beschrieben, dass es auch mit D16 K1-16 funktioniert ( Waveform z.B auf K8 und K16).
Es wåre schön, wenn das auch mit der aktuellen Software für den LQ-Sensor funktionieren würde.
Die Tadango- Methode funktioniert natürlich immer, aber bei 2.1 nicht korrekt.
Gruß BL
Im 16 Kanal Modus werden die Kanäle nur bei jedem zweiten SBus frame aktualisiert. Die Differenzen zwischen den Kanal Samples sind dann etwa doppelt so groß, wie im 8 Kanal Modus. Die Sensor SW muss dann die Triggerschwellen umschalten, was nicht weiter schwierig ist, aber der Vergleich des 5103 Signals mit dem 5100 Signal im 16 Kanal modus (mit V1 SW), war bisher nicht zufriedenstellend. Da muss noch mehr gemacht werden, als nur die Triggerschwellen umzuschalten. Ich schau's mir bei Gelegenheit nochmal an.
Moin,
von einem Kollegen habe ich einen Rangetest mit dem RX8Rpro und D16 V2.1.0 bekommen, der ganz interessant ist. Deswegen antworte ich einfach hier:
Der RX8Rpro sendet dann wie der RX8R tatsächlich die echten Los Frames, ein "Pro" halt :
Link Quality Sensor von Tadango
Zum RSSI nochmal: Der RX8Rpro steigt wie die anderen RX bei rund 35dB RSSI aus -> Failsafe. Die übertragenen RSSI Werte berücksichtigen zusätzlich die Linkqualität. Wir wissen, dass sich für 6dB RSSI Abfall die Entfernung verdoppeln muss (wenn sich sonst nichts ändert) . Wenn der RSSI schlagartig un 10dB oder mehr fällt, dann hat das andere Gründe, nämlich die Einrechnung des LQ, die FrSky in der Firmware vornimmt. Das machen sie übrigens nicht bei allen RX, das macht die Sache noch etwas komplizierter 😉 Ich hab mal versucht, in den Log den „wahren“ RSSI (blau) einzuzeichnen.
Deswegen würde ich bei diesem RX die Warnungen unbedingt auf dem Standard lassen und wenn öfter Warnungen kommen, die Antennenposition verbessern. Man sollte wissen, was man tut, wenn man an den RSSI Warnstufen dreht. Dazu verzapfen nämlich ziemlich viele Leute ziemlich viel Bullshit in den Foren.
Zum Vergleich habe ich noch einen geflogenen Rangetest mit dem RX4R (V1) angehängt, der den echten RSSI überträgt. Ich nehme an, dass es bei der V2 Firmware des RX4R auch noch so ist.
von einem Kollegen habe ich einen Rangetest mit dem RX8Rpro und D16 V2.1.0 bekommen, der ganz interessant ist. Deswegen antworte ich einfach hier:
Der RX8Rpro sendet dann wie der RX8R tatsächlich die echten Los Frames, ein "Pro" halt
:Link Quality Sensor von Tadango
Zum RSSI nochmal: Der RX8Rpro steigt wie die anderen RX bei rund 35dB RSSI aus -> Failsafe. Die übertragenen RSSI Werte berücksichtigen zusätzlich die Linkqualität. Wir wissen, dass sich für 6dB RSSI Abfall die Entfernung verdoppeln muss (wenn sich sonst nichts ändert) . Wenn der RSSI schlagartig un 10dB oder mehr fällt, dann hat das andere Gründe, nämlich die Einrechnung des LQ, die FrSky in der Firmware vornimmt. Das machen sie übrigens nicht bei allen RX, das macht die Sache noch etwas komplizierter 😉 Ich hab mal versucht, in den Log den „wahren“ RSSI (blau) einzuzeichnen.
Deswegen würde ich bei diesem RX die Warnungen unbedingt auf dem Standard lassen und wenn öfter Warnungen kommen, die Antennenposition verbessern. Man sollte wissen, was man tut, wenn man an den RSSI Warnstufen dreht. Dazu verzapfen nämlich ziemlich viele Leute ziemlich viel Bullshit in den Foren.
Zum Vergleich habe ich noch einen geflogenen Rangetest mit dem RX4R (V1) angehängt, der den echten RSSI überträgt. Ich nehme an, dass es bei der V2 Firmware des RX4R auch noch so ist.
Anhänge
Moin,
von einem Kollegen habe ich einen Rangetest mit dem RX8Rpro und D16 V2.1.0 bekommen, der ganz interessant ist. Deswegen antworte ich einfach hier:
Der RX8Rpro sendet dann wie der RX8R tatsächlich die echten Los Frames, ein "Pro" halt :
Link Quality Sensor von Tadango
Zum RSSI nochmal: Der RX8Rpro steigt wie die anderen RX bei rund 35dB RSSI aus -> Failsafe. Die übertragenen RSSI Werte berücksichtigen zusätzlich die Linkqualität. Wir wissen, dass sich für 6dB RSSI Abfall die Entfernung verdoppeln muss (wenn sich sonst nichts ändert) . Wenn der RSSI schlagartig un 10dB oder mehr fällt, dann hat das andere Gründe, nämlich die Einrechnung des LQ, die FrSky in der Firmware vornimmt. Das machen sie übrigens nicht bei allen RX, das macht die Sache noch etwas komplizierter 😉 Ich hab mal versucht, in den Log den „wahren“ RSSI (blau) einzuzeichnen.
Anhang anzeigen 181248
Deswegen würde ich bei diesem RX die Warnungen unbedingt auf dem Standard lassen und wenn öfter Warnungen kommen, die Antennenposition verbessern. Man sollte wissen, was man tut, wenn man an den RSSI Warnstufen dreht. Dazu verzapfen nämlich ziemlich viele Leute ziemlich viel Bullshit in den Foren.
Zum Vergleich habe ich noch einen geflogenen Rangetest mit dem RX4R (V1) angehängt, der den echten RSSI überträgt. Ich nehme an, dass es bei der V2 Firmware des RX4R auch noch so ist.
von einem Kollegen habe ich einen Rangetest mit dem RX8Rpro und D16 V2.1.0 bekommen, der ganz interessant ist. Deswegen antworte ich einfach hier:
Der RX8Rpro sendet dann wie der RX8R tatsächlich die echten Los Frames, ein "Pro" halt
:Link Quality Sensor von Tadango
Zum RSSI nochmal: Der RX8Rpro steigt wie die anderen RX bei rund 35dB RSSI aus -> Failsafe. Die übertragenen RSSI Werte berücksichtigen zusätzlich die Linkqualität. Wir wissen, dass sich für 6dB RSSI Abfall die Entfernung verdoppeln muss (wenn sich sonst nichts ändert) . Wenn der RSSI schlagartig un 10dB oder mehr fällt, dann hat das andere Gründe, nämlich die Einrechnung des LQ, die FrSky in der Firmware vornimmt. Das machen sie übrigens nicht bei allen RX, das macht die Sache noch etwas komplizierter 😉 Ich hab mal versucht, in den Log den „wahren“ RSSI (blau) einzuzeichnen.
Anhang anzeigen 181248
Deswegen würde ich bei diesem RX die Warnungen unbedingt auf dem Standard lassen und wenn öfter Warnungen kommen, die Antennenposition verbessern. Man sollte wissen, was man tut, wenn man an den RSSI Warnstufen dreht. Dazu verzapfen nämlich ziemlich viele Leute ziemlich viel Bullshit in den Foren.
Zum Vergleich habe ich noch einen geflogenen Rangetest mit dem RX4R (V1) angehängt, der den echten RSSI überträgt. Ich nehme an, dass es bei der V2 Firmware des RX4R auch noch so ist.
Den nächsten Log werde ich dann auch im Flug machen.
Gruß Michael
Es gibt aktuell auf RCG den Testbericht eines Kollegen (mpjf01), der nach wiederholten Bindevorgängen unterschiedliche Testergebnisse bekommt. Mal treten mehrere FS auf, mal kein einziger. Derselbe Sender, derselbe Empfänger, dieselbe Firmware ACCST v2.1.0 FCC, dieselbe Location.
Mir war es nicht bewusst (hab's vielleicht auch verpennt), dass es sowas auch hier schon gegeben und in Beiträgen von @Stoschek beschrieben wurden (Beiträge #187, #195, #199, #206, #208). Eine Erklärung dazu habe ich aber nicht gefunden. Gibt es denn inzwischen neue Erkenntnisse dazu, vielleicht sogar gesicherte?
Mir war es nicht bewusst (hab's vielleicht auch verpennt), dass es sowas auch hier schon gegeben und in Beiträgen von @Stoschek beschrieben wurden (Beiträge #187, #195, #199, #206, #208). Eine Erklärung dazu habe ich aber nicht gefunden. Gibt es denn inzwischen neue Erkenntnisse dazu, vielleicht sogar gesicherte?
Die Frage ist erst mal, ob das etwas mit dem Binden zu tun hat.
Man nehme eine Anlage 1, messe die FLs, und schalte eine zweite Anlage 2 als Störer dazu.
Mit jedem neuen Aus-und Einschalten der Anlage 2 ändern sich die FLs der Anlage 1, weil
a) FrSky mit jedem neunen Einschalten das Hoppingmuster ändert,
b) die Anlagen asynchron zueinander laufen. Wenn zufällig Anlage 2 dann sendet (3,5ms) wenn Anlage 1 den LBT check macht (ca. 0,2ms) dann treten vermehrt FLs auf.
Also was passiert genau bei jenen Messungen, wir wissen es nicht und es muß nicht etwas mit FrSky zu tun haben.
Man nehme eine Anlage 1, messe die FLs, und schalte eine zweite Anlage 2 als Störer dazu.
Mit jedem neuen Aus-und Einschalten der Anlage 2 ändern sich die FLs der Anlage 1, weil
a) FrSky mit jedem neunen Einschalten das Hoppingmuster ändert,
b) die Anlagen asynchron zueinander laufen. Wenn zufällig Anlage 2 dann sendet (3,5ms) wenn Anlage 1 den LBT check macht (ca. 0,2ms) dann treten vermehrt FLs auf.
Also was passiert genau bei jenen Messungen, wir wissen es nicht und es muß nicht etwas mit FrSky zu tun haben.
Mein Kollege hatte gestern ein paar klassische FrSky Zucker. = 5 mal Tief rein gelaufen mit Abzucker von ca. 2 - 3 m. In einem Flug.
Leider kein Log aufgezeichnet. (er weis auch nicht das es das gibt)
Da will ich mal mit dem FL-Zähler ran.
Ich in gerade dabei einen Tadango Zähler zu bauen, Nano hab ich noch.
Ich gehe nach dem Bauschema aus Post Nr 40. Hier wird ein Mini verwendet.
Frage: Der Nano hat einen 5V Eingang und einen VIN.
Kann man dem 5 V noch 5,5 V zumuten oder geht da bereits der VIN.
Sigi
Leider kein Log aufgezeichnet. (er weis auch nicht das es das gibt)
Da will ich mal mit dem FL-Zähler ran.
Ich in gerade dabei einen Tadango Zähler zu bauen, Nano hab ich noch.
Ich gehe nach dem Bauschema aus Post Nr 40. Hier wird ein Mini verwendet.
Frage: Der Nano hat einen 5V Eingang und einen VIN.
Kann man dem 5 V noch 5,5 V zumuten oder geht da bereits der VIN.
Sigi
Zuletzt bearbeitet:
- Status
