Na das trifft sich ja gut. Ich hab einen problematischen Sender zur Hand. An einen richtigen Spectrumanalyzer könnte ich unter Umständen sogar auch rankommen. Vielleicht wäre das den Aufwand sogar wert. Die Mittenfrequenz (beim Binden) über der Zeit wäre die Wunschgröße? Dann das Ganze noch bei einer X9D, einer X12S und der Xlite Pro.
FRSKY Vorsicht bei "Telemetrie verloren" mit Horus
- Themenstarter Carbonator
- Beginndatum
Das wäre super, wenn du einen Vergleich mit verschiedenen Sendern machen könntest.
Meines Wissens wird beim Binden in EU modus 2405 MHZ, in int. Modus 2404 MHz genutzt.
Kann man auch in D8 Modus machen.
Meine Sender liegen alle sehr nahe beieinander, aber alle verschoben, aber warten wir dei Ergebnis ab.
Meines Wissens wird beim Binden in EU modus 2405 MHZ, in int. Modus 2404 MHz genutzt.
Kann man auch in D8 Modus machen.
Meine Sender liegen alle sehr nahe beieinander, aber alle verschoben, aber warten wir dei Ergebnis ab.
@nihonski
Da drängt sich mir die Frage auf, warum liegen die neuen RX darüber, wenn die älteren darunter liegen ?
Anstatt den Fang bereich zu Vergrößerern wäre es in meinen Augen sinnvoller beide auf die gleiche Frequenz zu bringen, ein vergrößern des Fangbereichs hat ja auch wieder Nachteile.
Können die neuen RX Chips das nicht oder hat Frsky da einfach mal einen Frequenz aus der Luft gegriffen?
Bevor mich jemand steinigt, mit HF habe ich nichts zu tun und keinen schimmer, das sind nur meine laienhaften Gedanken!
Da drängt sich mir die Frage auf, warum liegen die neuen RX darüber, wenn die älteren darunter liegen ?
Anstatt den Fang bereich zu Vergrößerern wäre es in meinen Augen sinnvoller beide auf die gleiche Frequenz zu bringen, ein vergrößern des Fangbereichs hat ja auch wieder Nachteile.
Können die neuen RX Chips das nicht oder hat Frsky da einfach mal einen Frequenz aus der Luft gegriffen?
Bevor mich jemand steinigt, mit HF habe ich nichts zu tun und keinen schimmer, das sind nur meine laienhaften Gedanken!
Aber ist der Abstand der Bindefrequenz zu den Hoppingkanälen fix?
Die Idee von einem driftenden Frequenznormal würde sich sehr leicht mit der Bindefrequenz überprüfen lassen weil sich diese zeitlich ja eben nicht ändern soll. Die Hoppingkanäle direkt zu prüfen ist dagegen nicht so einfach.
Selbst der Spectrum Analyzer mit den ISRM Modulen könnte das. Oder der SA im Multiprotokollmodul. Soweit die Idee. An meiner Xlite Pro tut der SA wunderbar mit 2.3.1, mit 2.3.4 sieht das noch nicht so überzeugend aus. Dafür tut der SA vom MPM mit 2.3.4 aber ohne jegliche Einstellmöglichkeiten des angezeigten/abgetasteten Frequenzbereichs. Auf ein MHz genau wird man das ablesen können, aber auf keinen Fall besser.
Übrigens, 2404Mhz hat meine Taranis geliefert beim Binden (LBT-EU)
Die Idee von einem driftenden Frequenznormal würde sich sehr leicht mit der Bindefrequenz überprüfen lassen weil sich diese zeitlich ja eben nicht ändern soll. Die Hoppingkanäle direkt zu prüfen ist dagegen nicht so einfach.
Selbst der Spectrum Analyzer mit den ISRM Modulen könnte das. Oder der SA im Multiprotokollmodul. Soweit die Idee. An meiner Xlite Pro tut der SA wunderbar mit 2.3.1, mit 2.3.4 sieht das noch nicht so überzeugend aus. Dafür tut der SA vom MPM mit 2.3.4 aber ohne jegliche Einstellmöglichkeiten des angezeigten/abgetasteten Frequenzbereichs. Auf ein MHz genau wird man das ablesen können, aber auf keinen Fall besser.
Übrigens, 2404Mhz hat meine Taranis geliefert beim Binden (LBT-EU)
ich habe mich mit dem Auffinden der Lockouts per Skript beschäftigt und zwei Varianten gebastelt.
Bei der ersten wird eine neue Log-Datei mit verdächtigen Stellen (mit 5s Vor-/Nachlauf) erstellt.
Bei der zweiten wird ein zusätzlicher Wert (LockTrigger) erstellt, der von Null auf Eins (bei den verdächtigen Stellen) wechselt.
Der Companion Log Viewer wechselt leider bei beim Zuschalten von weiteren Werten vom gezoomten Bereich auf den Gesamtzeitraum. DataExplorer ist da besser. Dort kann man auch direkt in bestimmte Zeiträume zoomen.
Bei der ersten wird eine neue Log-Datei mit verdächtigen Stellen (mit 5s Vor-/Nachlauf) erstellt.
Bei der zweiten wird ein zusätzlicher Wert (LockTrigger) erstellt, der von Null auf Eins (bei den verdächtigen Stellen) wechselt.
Der Companion Log Viewer wechselt leider bei beim Zuschalten von weiteren Werten vom gezoomten Bereich auf den Gesamtzeitraum. DataExplorer ist da besser. Dort kann man auch direkt in bestimmte Zeiträume zoomen.
Ich frage mich, warum der Fangbereich bei fast jedem Empfängertyp Frequenz-mässig anders liegt, warum also die Mitte nicht dicht bei der Hoppingfrequenz laut vereinbarter Tabelle liegt. Design-Schlamperei beim HF-Empfangstuning vom Empfänger oder technisch zu aufwendig, da dann zu teuer? Wenn der Referenzquarz des Empfängers doch präzise arbeitet, dann müsste doch auch das jeweilige Tuning auf die vereinbarte nächste Hoppingfrequenz mit ausreichender Präzision machbar sein, oder sehe ich das falsch? Wenn der Referenzquarz aber nicht präzise arbeitet, dann kann eben auch die Hoppingfrequenz nicht präzise getroffen werden und als Resultat sehen wir dann den verschobenen Frequenzbereich des Empfängers, oder etwa nicht?
In Stichpunkten:
Aus 26Mhz werden 2.4GHz erzeugt, das ist Faktor 92.
Bei 2,4GHz entsprechen 24kHz Abweichung = 10ppm.
Wie genau werden Quartze hergestellt und welchen Einflüssen ist die Genauigkeit unterworfen?
Quartze sind für bestimmte Lastkapazitäten spezifiziert und hergestellt, bei X-Empfängern ca. 15pF, die Streukapazität des PCB mitgerechnet, welches ebenfalls einer Herstellungstoleranz unterliegt.
Ohne AFC geht das nicht mit einfachen Quartzen.
Und TCXOs sind jenseits FrSky's Preisklasse.
Aus 26Mhz werden 2.4GHz erzeugt, das ist Faktor 92.
Bei 2,4GHz entsprechen 24kHz Abweichung = 10ppm.
Wie genau werden Quartze hergestellt und welchen Einflüssen ist die Genauigkeit unterworfen?
Quartze sind für bestimmte Lastkapazitäten spezifiziert und hergestellt, bei X-Empfängern ca. 15pF, die Streukapazität des PCB mitgerechnet, welches ebenfalls einer Herstellungstoleranz unterliegt.
Ohne AFC geht das nicht mit einfachen Quartzen.
Und TCXOs sind jenseits FrSky's Preisklasse.
Mit einer intelligenten Firmware kann man Toleranzen wunderbar wegrechnen. Die Technik hat sich in den letzten hundert Jahren weiterentwickelt. Und das Preisklassenargument bei Elektronik funktioniert nur noch am Modellfliegerstammtisch, dort aber leider immer noch sehr gut. Das sind Nebelkerzen, sorry.
Ich hoffe, dass wir mal konkrete Zahlen von einem problematischen Sender bekommen. Und ein Gegencheck mit einem MPM wäre gut, um zu sehen, ab welcher Frequenzverschiebung Lost Frames auftreten. FrSky hat verschiedene Möglichkeiten gegenzusteuern. Mit einer offenen Kommunikation der Maßnahmen könnten sie verlorenes Vertrauen bei ihren Usern wieder herstellen. Heute kommt schließlich der Weihnachtsmann
Ich hoffe, dass wir mal konkrete Zahlen von einem problematischen Sender bekommen. Und ein Gegencheck mit einem MPM wäre gut, um zu sehen, ab welcher Frequenzverschiebung Lost Frames auftreten. FrSky hat verschiedene Möglichkeiten gegenzusteuern. Mit einer offenen Kommunikation der Maßnahmen könnten sie verlorenes Vertrauen bei ihren Usern wieder herstellen. Heute kommt schließlich der Weihnachtsmann
Und genau so sehe ich das auch. Es ist überhaupt kein Problem mit etwas Hirnschmalz Protokolle zu entwickeln die einfach nur funktionieren. Fehlerfreie Datenübertragung über verrauschte Kanäle ist eine Aufgabe die technisch bereits gelöst wurde und das nicht nur ein Mal. Das Ganze auf einem spezifischen Satz Hardware zu implementieren ist dann nur noch eine Fleißaufgabe für den Hersteller. Genau diese Fleißarbeit wird auch bezahlt, deswegen ist es nicht zuviel verlangt dass die Implementierung zuverlässig funktioniert und keine Modelle deswegen abstürzen.
Neben dem SA der Xlite Pro habe ich gleich 2 MPMs zur Hand, für eine Xlite und eine Taranis. Über die Feiertage sollte ich dazu kommen damit etwas rumzuspielen
Neben dem SA der Xlite Pro habe ich gleich 2 MPMs zur Hand, für eine Xlite und eine Taranis. Über die Feiertage sollte ich dazu kommen damit etwas rumzuspielen
