SONSTIGE Wird das Crossfire-Protokoll der neue Standard?

[Carbonator]

So langsam habe ich den Eindruck, dass das Ende von SBus naht. Das Protokoll benötigt einen Inverter und ist auch vom Speed her nicht mehr wirklich zeitgemäß.
Crossfire mit 420.000 Baud kann vier mal so schnell und auch die Telemetrie, die nach jedem zweiten Steuerframe an der Reihe ist, ist theoretisch doppelt so schnell (vereinfacht).
Matek liefert die passende Hardware, um Crossfire aufzudröseln, auch ein GPS kann schon angeschlossen werden. Es fehlt leider noch die Vario-Funktionalität. Das Protokoll kennt VSpeed, aber nur die GPS-Höhe und keine barometrische Höhe. Das könnte man aber umgehen, in der Regel reicht ja eine Höhe. Wenn ein Baro vorhanden ist, überträgt man natürlich die barometrische Höhe. Die offenen Systeme sind flexibel genug, um die Telemetrie umzubenennen.
Crossfire würde sich wirklich gut als neuer Standard für die RX-Schnittstelle eignen. ELRS ist der nächste "big player", der die Schnittstelle nutzt. Was meint ihr?
Das passende Präfix für diesen Thread wäre Crossfire, aber das gibt es nicht Und es würde wohl auch zu Verwechslungen führen.

 

[markus1234]

Ich bin deiner Meinung. Ich setze schon lange auf Crossfire und im 2G4 Bereich bin ich jetzt auf ELRS umgestiegen.
S.Bus hat keine Telemetrie, da braucht man noch zusätzlich S.PORT, belegt also 2 Uarts. F.PORT wollte das beheben, hat sich aber nie so richtig durchgesetzt.

 

[Stefan_73]

SBUS ist seit Jahren ein totes Pferd. Da naht nix
Im FPV Bereich hat es sich m.E. nur aufgrund der zeitweisen Dominanz von FrSky gehalten. Es ist langsam, beschränkt und auch eine invertierte Serielle ist eine blöde Idee. Dies Invertierung stammt irgendwo aus den 90igern, um so eine Art proprietäres Protokoll zu haben. Und selbst FrSky hat SBUS längst hinter sich gelassen.

Es gibt eine Menge andere Protokoll, die den Quark mit der Invertierung lassen wie IBUS oder Ghost und viele andere mehr. Ich sehe auch nicht, dass CRSF irgendeine technische Superqualität hätte. ELRS hat es halt genommen, weil es in unserem Bereich weit verfügbar ist und als Protokoll schon OpenSource. Das ist pragmatisch. Insofern ist glaube ich die Möglichkeit der Firmen vorbei, Ecosysteme durch eigene serielle Protokolle zu erzeugen. Alle diese Protokolle basieren auf einer standardkonformen seriellen Verbindung und Flight Controller sind klein und billig. Damit kann man letztlich alles adaptieren und das serielle Protokoll am Empfänger wird ein eher nebensächliches Problem. Damit wird nicht alles Crossfire werden.

 

[Hazzahfpv]

... Es fehlt leider noch die Vario-Funktionalität. Das Protokoll kennt VSpeed, aber nur die GPS-Höhe und keine barometrische Höhe...

Baro Support wurde mit der Firmware 6.13 eingeführt. Ich nehme an, dass die Baro-Höhe damit auch in VSpd einfließt, aber getestet habe ich es noch nicht.

 

[Carbonator]

Baro Support wurde mit der Firmware 6.13 eingeführt. Ich nehme an, dass die Baro-Höhe damit auch in VSpd einfließt, aber getestet habe ich es noch nicht.

Da hoffe ich auch noch auf mehr Klarheit, denn das VSpd-Feld gibt es schon länger im Crossfire-Protokoll. Was ist genau mit Baro Support gemeint? Bezieht sich das eventuell nur auf einen bestimmten TBS-Sender, der jetzt die Vario-Funktion unterstützt? Oder kann man ein i2c Barometer direkt an den RX anschließen?

 

[djblue]

SBUS würde ich nicht als totes Pferd sehen. In vielen anderen Modellbaubereichen ist das momentan immer noch die gängingste Übertragung, z.B. im Grossseglerbereich werden viel Sbus-adressierte Servos verwendet, ebenso im Heli-Bereich zwischen Flybarless und RX. Nur in der "Flightcontroller-Ecke" hat sich CRSF deutlich hervorgehoben. Wahrscheinlich weil es eh schon sehr Technisch und weniger Physikalisch ist... nur meine Vermutung.
CRSF darf gerne der nächste "Standard" werden, finds gut.

 

[markus1234]

Da MSP in CRSF eingebettet ist kann von der FC eigentlich alles was da ist an den Sender übermittelt werden. Ich habe da bisher nichts vermisst, oder was übersehe ich? Evtl sollte man hier das CRSF Protokol von Crossfire unterscheiden.

 

[Carbonator]

Da MSP in CRSF eingebettet ist kann von der FC eigentlich alles was da ist an den Sender übermittelt werden. Ich habe da bisher nichts vermisst, oder was übersehe ich?

Nicht jeder hat einen FC an Bord. Diesen Thread habe ich auch ein bisschen für die LOS Flieger gemacht, die auf ELRS und das CRSF-Protokoll, als Alternative zu herstellergebundenen Lösungen, hoffen. Tracer ist ja auch nicht uninteressant für diese Leute.

GPS geht schon ohne FC, wenn jetzt noch das Vario ginge, wäre das ein großer Schritt. Einen FC nur als PWM-Konverter und Sensor Interface zu nutzen, schreckt mich noch ein bisschen ab. Aber dieser FC könnte immerhin auch noch das SBus Signal für eventuelle SBus Servos liefern. Man baut sich damit aber einen weiteren "single point of failure" in sein Modell ein

 

[markus1234]

Auch mit FC kann ich LOS und Manual fliegen. Features nutzen ist kein muss.
Jetzt noch irgendein Zusatz-Board installieren damit ich PWM für Servos und ESC habe und noch eines für Telemetrie mit verschiedenen Sensoren? Ohne Prozessor wird das nix, im Prinzip bist du dann bei einer FC - auch wenn du dem Kind einen anderen Namen gibst....
Die alten F3 FC's funktionieren bei mir super dafür.

 

[QuadCrash]

Einen FC nur als PWM-Konverter und Sensor Interface zu nutzen, schreckt mich noch ein bisschen ab.

Wird Zeit das Du mal etwas neues lernst ... . Außerdem ist so ein "Super-Sensor" doch 'ne gute Sache und weit leistungsfähiger als alte Arduino-Projekte.

Was Crossfire und CRSF angeht, wäre es schon schön, wenn man bei Crossfire als Marke/Produkt bleibt und wenn es ums Protokoll geht, es dann auch direkt als CRSF benennen würde. Auch hier im Thread-Titel ...

 

[Carbonator]

Ohne Prozessor wird das nix, im Prinzip bist du dann bei einer FC - auch wenn du dem Kind einen anderen Namen gibst....

Klar, im Prinzip hast du Recht. Aber die Komplexität eines FC ist höher als die eines reinen PWM-Konverters und damit auch die Ausfallwahrscheinlichkeit auf Hard- und Softwareseite. Und wenn nur das Sensor-Interface ausfällt - who cares.
Wenn sich so ein 5 kg Brocken davonmacht, ist das eine andere Nummer, als wenn ein Schaumwing oder ein Racecopter abgeht. Da muss ich erst Vertrauen aufbauen ....

.... und weit leistungsfähiger als alte Arduino-Projekte.

Das lassen wir mal so im Raum stehen Mehr als perfekt zufrieden geht kaum
Ich habe auch keinen Leidensdruck, ich will nur die Optionen verstehen.

 

[markus1234]

Ich möchte niemanden was verkaufen..
Die FCs mit den üblichen SW Kandidaten werden sehr häufig eingesetzt und sind schon gut erprobt - außerdem reden wir ja nur über die Grundfunktionen.
Vertrauen zu komplexen Systemen gewinnen ist tatsächlich so eine Sache... Fährst du ein modernes Auto?

 

[Carbonator]

Fährst du ein modernes Auto?

Auf dieser Ebene wollte ich eigentlich nicht diskutieren. Ich war 20 Jahre im KFZ-Technik-Bereich unterwegs. Ich glaube, dass es bei der Qualitätskontrolle und bei den systematischen Tests vor Markteinführung doch dezente Unterschiede zu unserem Hobby gibt. Aber lassen wir das, du weißt es vermutlich besser

 

[QuadCrash]

Wenn sich so ein 5 kg Brocken davonmacht, ist das eine andere Nummer, als wenn ein Schaumwing oder ein Racecopter abgeht. Da muss ich erst Vertrauen aufbauen ....

Der Witz ist der, dass sich so ein "5 kg Brocken" ohne FC öfter mal davon macht, als mit ...

Vertrauen aufbauen ist aber sicherlich wichtig, ebenso die Optionen zu überblicken. Und da muss ich selbst sagen, dass es extrem viele Optionen gibt. Insgesamt 'ne spannende Sache.

 

[jasc]

Auch mit FC kann ich LOS und Manual fliegen. Features nutzen ist kein muss.
Jetzt noch irgendein Zusatz-Board installieren damit ich PWM für Servos und ESC habe und noch eines für Telemetrie mit verschiedenen Sensoren? Ohne Prozessor wird das nix, im Prinzip bist du dann bei einer FC - auch wenn du dem Kind einen anderen Namen gibst....
Die alten F3 FC's funktionieren bei mir super dafür.

Versuch mal einen FC in einen F5K zu kriegen....
Aber ja, bei grösseren Sachen geht es grundsätzlich. Aber dann macht ja eher so ein Projket wie OpenXsensor Sinn. Mehr Funktionen, bedeutet mehr FEhlerquellen und einige wollen halt lieber bauen und fliegen als flashen und löten
Leider scheint das ja tot zu sein.

@Carbonator
Ich hoffe auch schon länger auf Vario Unterstützung und war erst sehr erfreut über das Matek Teil, aber musste dann auch leider feststellen, dass Vario fehlt und nicht hinzugefügt werden kann.
Bei den "normalen" Modellbauern ist das ganze FPV Zeug nun mal nicht wirklich bekannt. Da weiß keiner was ELRS oder CSRF ist und was die alles können....
Grundsätzlich denke ich, es gibt sehr fähige Angebote im klassischen Umfeld (diese ganze Jeti, Unisense whatever) aber CRSF ist OpenSource und eröffnet damit ein Feld für ein ganzes Öko System in Verbindung mit günstigen Sensoren. OpenXSensor wäre ja eine Möglichkeit. Ich hatte da mal ein Issue aufgemacht, aber keine Antwort erhalten

 

[Carbonator]

Grundsätzlich denke ich, es gibt sehr fähige Angebote im klassischen Umfeld (diese ganze Jeti, Unisense whatever) aber CRSF ist OpenSource und eröffnet damit ein Feld für ein ganzes Öko System in Verbindung mit günstigen Sensoren. OpenXSensor wäre ja eine Möglichkeit. Ich hatte da mal ein Issue aufgemacht, aber keine Antwort erhalten

Ich sehe da auch eine große Chance für einen neuen Standard, aber wir sind noch in einem frühen Stadium, denke ich. Ich hoffe, wir können hier ein paar Infos zusammentragen.

Mit Michel vom oXs stehe ich in Kontakt, er hat etwas Sorgen, dass die 400000 Baud bei längerer Leitungsführung störungsanfälliger sind, deswegen zieht er u.a. 100000 Baud vor. Sein letzter Satz bezieht sich u.a. auf einige seglerspezifischen oXs Features (Varioumschaltung, Leistungsmessung etc.). Dafür wird man bei ACCST bleiben müssen.

I am trying to make a ELRS version of openXsensor.
Still I have some comments:
- ELRS telemetry does not transmit many data (less than Frsky). There are only 4 types of telemetry frames supported I think: GPS, Vario (Vspeed only), attitude (roll, pitch, yaw), battery (volt, current, capacity, %). I hope that OpenTx allows to reuse some of the fields (otherwise, it make not a lot of sense). Perhaps you can test it.
- ELRS communicates with flight controller at high speed (400000 bauds). I expect it can be reduced to 100000 baud when ELRS would generates SBUS for the servos. Arduino pro mini (or equivalent) it is not able to support such a high baudrate. So I imagine to use another type of micro controller: a RP2040-Zero. I just got one from aliexpress and I discover it.

I do not plan to migrate all functions available on oXs sensor on this new MCU but I hope to support at least 1 vario, 1 voltage and GPS for the ELRS (=crossfile) telemetry protocol.

 

[jasc]

@Carbonator
Aus meiner Sicht wird da etwas ausser Acht gelassen: Für Servo gesteuerte Flieger machen diese hohen Baud Raten / Geschwindigkeiten nur bei wenigen Anwendungen Sinn (3D Heli) aber sonst sind Servos im Verhältnis eh so lahm, dass das nichts ausmacht.
Weiterhin hat ELRS verschiedene Betriebsmodi was die Telemetrie angeht und man hat die Wahl zwischen mehr Speed und besserer Telemetrie aber die Telemetrie ist glaube ich immer beschnitten. Crossfire überträgt Telemetrie vollständig und umfangreicher als ELRS. ELRS wurde auf Speed gezüchtet aber nicht auf Daten. Da hat Crossfire definitiv die Nase vorn.
Für "normale" Anwendungen bräuchte ELRS einen Modus mit weniger Speed aber mehr Telemetrie.

 

[Carbonator]

@jasc Da bin ich komplett bei dir. Es gibt ja auch dieses lustige Bardwell Video, wo er versucht, "blind" den Unterschied zwischen 500 und 50 Hz Frame-Rate zu erfliegen und das mit dem schnell reagierenden Copter

Ideal wäre es, wenn man sich alle Parameter im Konfigurator individuell zusammenstellen könnte. Von ultra-sicher bis ultra-schnell und von 0% bis 100% Telemetrie-Bandbreite. Teilweise geht das ja schon. Hier kommt jetzt noch TBS ins Spiel, von denen so ungefähr die Aussage kommt, dass LoRa bei großem Payload kaum noch Sinn macht. Es bleibt also spannend

 

[jasc]

Ich denke TBS hat da sicher absolut recht, sind ja auch keine Nasenbohrer. Aber ELRS hat wohl auch diese andere Modulation in der Mache, also die die TBS nutzt :-D :-D WEiterhin ists ja wohl auch so, dass in den neueren CRSF Modi beide Geräte eine Baudrate aushandeln (weshalb auch immer RX/TX angeschlossen werden muss) Trappy erwähnte das in der letzten Lounge.

Aber alles in allem könnte man es sich ja so vorstellen:
SensorModul+TBS -> funzt einfach so
SensorModul+ELRS->man muss einen speziellen Modus setzen