MB hat ja das Wort Verschlüsselung auch deutlich in Anführungszeichen gesetzt ! Für mich - der ich einen offenbar betroffenen Sender habe - bedeutet das erst mal noch abwarten. Die Geschichte ist noch am gären und da ich - trotz hohen Frameverlusten - im Betrieb mit meinen (Flächen)Modellen nie Probleme im Flug hatte ist die Version 2.0.? (noch) keine sicher(ere) Option.
FRSKY Vorsicht bei "Telemetrie verloren" mit Horus
- Themenstarter Carbonator
- Beginndatum
Wenn V2 final ist, macht es schon Sinn für dich upzudaten. Es ist nur halt nur schade, dass du dir die Sicherheit vor Lockouts und USM mit einer geschönten Lost Frame Anzeige erkaufst. Aber FrSky wird davon vermutlich nicht wieder abgehen, weil man sonst relativ leicht zeigen kann, dass die hohen Frameverluste bei bestimmten Kombinationen nach wie vor bestehen. Und vermutlich auch die R-XSR Copter mit betaflight mit diesen Kombis nach wie vor vom Himmel fallen würden.
Gerade gesehen, auch Ewald ist jetzt für eine ehrliche LQ Anzeige. 
Ich glaube nicht, dass die FL-Bitmanipulation Bestand haben wird. Man muss aber immer wieder auf RCG und jetzt vor allem auch auf github dran bleiben und nicht aufgeben.
Genauso mit dem geforderten LQ Sensor. Natürlich gibt es "verständnisvolle" Poster auf RCG, die bereit sind bei ACCST auf einen solchen Sensor zu verzichten, weil FrSky sich ja um ACCESS und andere neue Produkte kümmern muss. Nur vergessen diese Poster, dass alle Empfänger ja schon einen LQ Wert vom HF-Chipsatz bekommen und diesen auch zusammen mit dem Signalstärkewert dann in einer uns allen unbekannten Mischkalkulation zum RSSI-Wert vermatschen. Mir kann jetzt keiner erzählen, dass es ein Riesenaufwand bedeutet, wenn man ganz einfach diesen schon verfügbaren LQ-Wert einfach als Sensorwert in den Telemetrie-Datenstrom an den Sender mit einspeist.
Genauso mit dem geforderten LQ Sensor. Natürlich gibt es "verständnisvolle" Poster auf RCG, die bereit sind bei ACCST auf einen solchen Sensor zu verzichten, weil FrSky sich ja um ACCESS und andere neue Produkte kümmern muss. Nur vergessen diese Poster, dass alle Empfänger ja schon einen LQ Wert vom HF-Chipsatz bekommen und diesen auch zusammen mit dem Signalstärkewert dann in einer uns allen unbekannten Mischkalkulation zum RSSI-Wert vermatschen. Mir kann jetzt keiner erzählen, dass es ein Riesenaufwand bedeutet, wenn man ganz einfach diesen schon verfügbaren LQ-Wert einfach als Sensorwert in den Telemetrie-Datenstrom an den Sender mit einspeist.
Mir würde es vollkommen reichen, wenn das LF Bit wieder technisch sauber gesetzt wird. 95% der User können mit dem Wert eh nichts anfangen. Das gibt nur Stress, wenn die schlechtgelaunten Ogottogotts anfangen, die verlorenen Frames zu suchen
Aber prinzipiell wäre dein Vorschlag natürlich eine feine Sache. Der Aufwand ist minimal, ich hatte das MB beim D8 vorgeschlagen und es war ruckzuck realisiert. Mal sehen, wie sie das bei ACCESS hinbekommen. Ich hab ja jetzt Zeit, das ISRM in die T16 einzubauen. Mich nervt nur, dass ich die externe Antenne nicht exclusiv einschalten kann - auch wieder so ein Quatsch
Aber prinzipiell wäre dein Vorschlag natürlich eine feine Sache. Der Aufwand ist minimal, ich hatte das MB beim D8 vorgeschlagen und es war ruckzuck realisiert. Mal sehen, wie sie das bei ACCESS hinbekommen. Ich hab ja jetzt Zeit, das ISRM in die T16 einzubauen. Mich nervt nur, dass ich die externe Antenne nicht exclusiv einschalten kann - auch wieder so ein Quatsch
Na klar, dir und allen mit nem selbstgebauten LQ Sensor reicht schon das nicht-manipulierte LF-Bit, alle anderen aber schauen in die Röhre. Und bzgl der Beurteilung eines dann für alle neuen LQ-Sensorwertes, da denke ich wird es sehr schnell Richtwerte geben, auch von Usern in den Foren.
Ein solcher LQ-Wert hat aber voraussichtlich auch seine Tücken ...... und zwar für FrSky selber. Er könnte durchaus, so vermute ich, Unterschiede bzw Schwächen in den LQs bei bestimmten Empfängern und Sender/Empfänger-Kombis offenbaren, deren Ursache nach wie vor in der Frequenzshift zwischen Sender und Empfänger liegt. Einzige umgesetzte Massnahme => Vergrösserung des AFC-Fensters. NIcht gemacht => auto-Frequenztuning beim Binden. Kann mir vorstellen, dass genau das auch FrSky bewusst ist und auch darum bei ACCST keinen LQ-Sensor haben will. Sie könnten als Folge damit auch irgendwann gezwungen sein, das auto-Frequenztuning bei der ACCST Firmware noch nachzuschieben.
Auch sollte FrSky dann gleichzeitig die bisher angewandte Mischkalkulation für den RSSI drangeben, also den LQ da ganz raus lassen. Evtl nur skalieren oder sogar das unterlassen. Dann könnte man damit endlich mathematisch relativ sauber vom RSSI-Wert auf die Reichweite schliessen. Damit hätte FrSky auch eine Lösung für das RSSI-Dilemma bei ACCESS, wo sie ja trotz aller Versuche bislang keine vergleichbare Skalierung des RSSI (so wie bei ACCST) hinkriegen und darum zu niedrigeren Alarmwerten raten.
Ein solcher LQ-Wert hat aber voraussichtlich auch seine Tücken ...... und zwar für FrSky selber. Er könnte durchaus, so vermute ich, Unterschiede bzw Schwächen in den LQs bei bestimmten Empfängern und Sender/Empfänger-Kombis offenbaren, deren Ursache nach wie vor in der Frequenzshift zwischen Sender und Empfänger liegt. Einzige umgesetzte Massnahme => Vergrösserung des AFC-Fensters. NIcht gemacht => auto-Frequenztuning beim Binden. Kann mir vorstellen, dass genau das auch FrSky bewusst ist und auch darum bei ACCST keinen LQ-Sensor haben will. Sie könnten als Folge damit auch irgendwann gezwungen sein, das auto-Frequenztuning bei der ACCST Firmware noch nachzuschieben.
Auch sollte FrSky dann gleichzeitig die bisher angewandte Mischkalkulation für den RSSI drangeben, also den LQ da ganz raus lassen. Evtl nur skalieren oder sogar das unterlassen. Dann könnte man damit endlich mathematisch relativ sauber vom RSSI-Wert auf die Reichweite schliessen. Damit hätte FrSky auch eine Lösung für das RSSI-Dilemma bei ACCESS, wo sie ja trotz aller Versuche bislang keine vergleichbare Skalierung des RSSI (so wie bei ACCST) hinkriegen und darum zu niedrigeren Alarmwerten raten.
Zuletzt bearbeitet:
@FJH deinen Post kann ich komplett so unterschreiben. Aber realistisch gesehen, muss FrSky wirtschaftliche Ziele verfolgen. Ich glaube nicht, dass sie einen langfristigen Imagegewinn dem kurzfristigen finanziellen Gewinn vorziehen. Dazu gehört letztlich auch eine Kundschaft, die das versteht und honoriert. Gibt es die?
Schaun wir mal .....
Schaun wir mal .....
Hi,
gemeint ist wahrscheinlich Verwürfelung (Scrambling).
Das kann mehreren Zwecken dienen.
Das Signal wird spektral besser verteilt.
- Das macht weniger Störstrahlung
- Man kann bei serieller Übertragung den Takt häufiger regenerieren.
- Wenn das Signal als Basisband einer Hochfrequenz aufmoduliert wird, ist das Produkt ebenfalls besser spektral verteilt. (Spread Spektrum)
Gruß
Dieter
gemeint ist wahrscheinlich Verwürfelung (Scrambling).
Das kann mehreren Zwecken dienen.
Das Signal wird spektral besser verteilt.
- Das macht weniger Störstrahlung
- Man kann bei serieller Übertragung den Takt häufiger regenerieren.
- Wenn das Signal als Basisband einer Hochfrequenz aufmoduliert wird, ist das Produkt ebenfalls besser spektral verteilt. (Spread Spektrum)
Gruß
Dieter
Leider bekommen oder wollen sie es nicht hinbekommen auch bei ACCST die Skalierung auf einen Einheitlichen Nenner mit dem man auch was anfangen könnte. (vielleicht denken sie das der User einen vorteil sieht bei den hohen RSSI werten
Habe gestern Spaßeshalber einen G-RX8 mit der V2.10 geflasht, der RSSI geht im Nahbereich bis 118db und Failsafe fängt schon bei etwas unter 40db an, bei der V1 war nach oben bei ca 90 bis max 100 Schluss und der Failsafe kam weit unter 30db.
Leider auch wieder Telemetrie Ausreiser von jenseits gut und Böse.
Aber sie haben auch den etwas fast gutes gemacht.... sie haben es tatsächlich hinbekommen den Alt Wert zu nullen und stabil zu halten ohne das er ewig weit weg driftet, kleiner nachteil bei der Geschichte das nullen klappt nicht immer zumindest wenn weitere Sensoren am S-Port hängen klappt es entweder gar nicht oder dauert bis gut drei Minuten, aber immerhin kein driften.
Wenn es interessiert und das verhalten des nullen sehen möchte auf Git habe ich einen LOg eingestellt der das verhalten zeigt.
G-RX8 LBT 2.10 · Issue #9 · FrSkyRC/Firmware-Test
Habe gestern Spaßeshalber einen G-RX8 mit der V2.10 geflasht, der RSSI geht im Nahbereich bis 118db und Failsafe fängt schon bei etwas unter 40db an, bei der V1 war nach oben bei ca 90 bis max 100 Schluss und der Failsafe kam weit unter 30db.
Leider auch wieder Telemetrie Ausreiser von jenseits gut und Böse.
Aber sie haben auch den etwas fast gutes gemacht....
sie haben es tatsächlich hinbekommen den Alt Wert zu nullen und stabil zu halten ohne das er ewig weit weg driftet, kleiner nachteil bei der Geschichte das nullen klappt nicht immer zumindest wenn weitere Sensoren am S-Port hängen klappt es entweder gar nicht oder dauert bis gut drei Minuten, aber immerhin kein driften.Wenn es interessiert und das verhalten des nullen sehen möchte auf Git habe ich einen LOg eingestellt der das verhalten zeigt.
G-RX8 LBT 2.10 · Issue #9 · FrSkyRC/Firmware-Test
Du meinst bestimmt diese hier +- 20m/s ?
Das ist der neue Abgleich beim einschalten vom RX, zumindest sieht es wie ein null Abgleich aus.
So wie es hier in diesem LOg aussieht geht es schnell und schein so gewollt zu sein, anschließend geht VSPD und Alt auf 0 und bleibt sogar da stabil ohne zu driften... ich war erstaunt.
und so sieht es aus wenn ein weiterer Sensor am S-Port hängt.... und dauert dann rund 3-4 Minuten.
Das ist der neue Abgleich beim einschalten vom RX, zumindest sieht es wie ein null Abgleich aus.
So wie es hier in diesem LOg aussieht geht es schnell und schein so gewollt zu sein, anschließend geht VSPD und Alt auf 0 und bleibt sogar da stabil ohne zu driften... ich war erstaunt.
und so sieht es aus wenn ein weiterer Sensor am S-Port hängt....
und dauert dann rund 3-4 Minuten.
Ja die +/-20m/s meinte ich. Die Höhe kann man ja einfach auf Null klemmen, wenn eingeschaltet wird und so lange der VSpd zeigt, dass noch nicht gestartet wurde. Macht die Konkurrenz ja auch so.
Für mich sieht das eher danach aus, wie wenn die Firmware ein Eigenleben entwickelt. Immer ml wieder was Neues
Für mich sieht das eher danach aus, wie wenn die Firmware ein Eigenleben entwickelt. Immer ml wieder was Neues
Hallo RayX,
Ich hab deine Logs auf github gesehen.
Bei dem letzten Bild ist mir aufgefallen, dass du auf 5104 keine Dreieckfunktion hast, sondern einen Sägezahn.
Falls du das LQBB4 Programm nicht geändert hast, solltest du auf Kanal8 ein Dreieck ausgeben, so wie im Kommentar beschrieben.
Die Werte 5101 und 5102 sind nicht so interessant. Die Link Qualität wird durch 5101 (SBus FL-Bit) und 5103 (Auswertung der Dreiecksfunktionvon Kanal 8) beschrieben.
Ich hab deine Logs auf github gesehen.
Bei dem letzten Bild ist mir aufgefallen, dass du auf 5104 keine Dreieckfunktion hast, sondern einen Sägezahn.
Falls du das LQBB4 Programm nicht geändert hast, solltest du auf Kanal8 ein Dreieck ausgeben, so wie im Kommentar beschrieben.
Die Werte 5101 und 5102 sind nicht so interessant. Die Link Qualität wird durch 5101 (SBus FL-Bit) und 5103 (Auswertung der Dreiecksfunktionvon Kanal 8) beschrieben.
Die frage bei allen Messungen wie kann mann unterschieden das zb Empfäger Sender ein probelm haben oder es sich um äussere einflüse Handelt. Zb Funksstörugen Welan Kranstuerugen Völig überlasseter Ätter in der Region usw. Das kanman doch nich mer ales messen mit unsern Steuerugen da würde ja ganez Mess Funkwagen benötigt!!!
Hallo Reinhard,
Sorry, ich hatte nur den Text hier gelesen und im Sketch selbst nicht mal reingeschaut.
Danke für die Info, habe es jetzt geändert, müsste jetzt passen.
Die Skalierung des RSSI vom G-RX8 ist auf jeden fall total daneben und nicht vergleichbar mit den allen anderen Empfängern zumindest in der V1, die V2.10 habe ich bis jetzt nur auf einem RX alles weitere lohnt sich auch noch nicht, einfach zu viele Bugs.
Vorsicht! der Failsafe kommt schon bei recht genau RSSI 35, da ist bei der V1 und anderen Empfängern noch lange nicht Schluss.
Also nicht freuen das der Wert jetzt deutlich über dem Alten liegt und die (Reichweite ja VIELLL besser ist),
er ist einfach nur verschoben / falsch Skaliert.
Sorry, ich hatte nur den Text hier gelesen und im Sketch selbst nicht mal reingeschaut.
Danke für die Info, habe es jetzt geändert, müsste jetzt passen.
Die Skalierung des RSSI vom G-RX8 ist auf jeden fall total daneben und nicht vergleichbar mit den allen anderen Empfängern zumindest in der V1, die V2.10 habe ich bis jetzt nur auf einem RX alles weitere lohnt sich auch noch nicht, einfach zu viele Bugs.
Vorsicht! der Failsafe kommt schon bei recht genau RSSI 35, da ist bei der V1 und anderen Empfängern noch lange nicht Schluss.
Also nicht freuen das der Wert jetzt deutlich über dem Alten liegt und die (Reichweite ja VIELLL besser ist),
er ist einfach nur verschoben / falsch Skaliert.
Das ist ein Haustest gewesen im Range Mod, den ich immer exakt so wiederhole schon seit Jahren und dadurch kann ich ganz gut abschätzen ob sich was geändert hat.
Größer ist die Entfernung auf keinen Fall geworden, der RSSI ist vermutlich Falsch Skaliert, siehe LOg oben.
Mit Voller Leistung im Nahbereich RSSI 118db dann gehe ich im Haus an die Stelle wo ich immer den Sender abstelle RRSI bei 70-80, dann schalte ich um in den Range Mod RSSI 40-45 jetzt schirme ich die Antenne langsam so weit ab bis der RSSI langsam abfällt bis zum Failsafe RSSI 35-36 ab hier sind keine Steuerfunktionen mehr vorhanden, Also Failsafe nicht nur Telemetrie Lost.
Kannst du das Verhalten des Vario was ich weiter oben gezeigt habe auch bestätigen ?
Oder die andauernd Sensor Lost Meldungen wenn ein zusätzlicher Sensor am S-Port steckt ?
Größer ist die Entfernung auf keinen Fall geworden, der RSSI ist vermutlich Falsch Skaliert, siehe LOg oben.
Mit Voller Leistung im Nahbereich RSSI 118db dann gehe ich im Haus an die Stelle wo ich immer den Sender abstelle RRSI bei 70-80, dann schalte ich um in den Range Mod RSSI 40-45 jetzt schirme ich die Antenne langsam so weit ab bis der RSSI langsam abfällt bis zum Failsafe RSSI 35-36 ab hier sind keine Steuerfunktionen mehr vorhanden, Also Failsafe nicht nur Telemetrie Lost.
Kannst du das Verhalten des Vario was ich weiter oben gezeigt habe auch bestätigen ?
Oder die andauernd Sensor Lost Meldungen wenn ein zusätzlicher Sensor am S-Port steckt ?
