VLink S.BUS Telemetrie-Empfänger für Micro-Helis Telemetrie Verlust?

Liebes Forum-Team,

aktuell fliege ich den neuen VLink S.BUS Telemetrie-Empfänger für Micro-Helis in meinem OMPHobby M2V3 Sport. Nach einem erfolgreichen Update des OFS3 konnte ich die Telemetrie für VBar in der App aktivieren.

Leider habe ich nun folgendes Problem: Während des Flugs verliert der Empfänger 2–3 Mal die Telemetrie des Akkus. Dadurch muss der Flugakku jedes Mal erneut bestätigt werden.

Hat jemand eine Idee zur Lösung?

Beste Grüße aus Innsbruck

Thomas

Okay - da kämpfen vermutlich auf der OMP Seite 2 Sachen miteinander.

Wir können uns schon vorstellen was Das sein wird, denn beide Signale laufen in deren FBL über denselben I/O am Prozessor des OFS und werden im Wechsel per Multiplexer im OFS auf diesen aufgeschaltet. Dadurch ergeben sich hier ggf. "Fehlzeiten" im TELE bei uns - weil eben wenn der Prozessor dort gerade in S.Bus reinhört - nix bei uns auf TELE ankommt. Vielleicht kann man das kaschieren:

Welche Updaterate ist denn in Makrozellen => Ein/Ausgangskonfiguration eingestellt? - Ich vermute 14ms. Teste bitte mal 10ms aus. Nach dem Umstellen bitte einmal Neustarten des Helis.

regards (EN) / Gruss (DE)

Rainer Vetter

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Posting and answering - please use a PC and a standard keyboard. Answer all questions fully, take the needed time, don't forget probably requested attachments.

Für Posts und Antworten bitte einen PC und eine richtige Taststaur benutzen sowie alle Fragen vollständig abarbeiten. Nehmt Euch Zeit, beantwortet Rückfragen in Ruhe und vollständig.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Für Einzelkommunikation bitte ausschließlich Email verwenden! - PN, Messenger, Chat usw. werden nicht bearbeitet.
For single user communication please send a email only! PM, Messenger, Chat etc. won't be read.

Guten morgen Lieber Rainer,

vielen Lieben Dank für die rasche Rückmeldung! Die Updaterate habe ich wie in der OMP- Beschreibung auf 7ms eingestellt. Ich werde heute mal die von dir empfohlenen 10ms einstellen und berichten .

Liebe Grüße
Thomas

Lieber Rainer,

die Umstellung auf 10 ms hat den gewünschten Effekt gebracht. Ich bin heute 10 Akkus geflogen und hatte keinen einzigen Telemetrie-Verlust des Akkus.

Allerdings habe ich nach dem Flug diese Meldung im Log erhalten (siehe Foto), als die VBar Evo+ nach dem Flug ziemlich nahe am Heli auf dem Flugtisch lag. Ich vermute, dass das daran lag, dass VBar und Empfänger zu nahe beieinander waren – was meinst du dazu?

Zur Sicherheit habe ich alle Kabel kontrolliert, konnte aber keine Unregelmäßigkeiten feststellen.

Beste Grüße
Thomas

Und da müssen wir differenzieren:

Das Signal geht zwar von uns zum OFS - aber der Regler bekommts von diesem auch dann aufbereitet weitergegeben.

insofern - ist hier die Verbindung des OFS zum Regler vorrangig zu untersuchen. Wir bekommen die Botschaft nur über die Reglertelemetrie eingespielt und zeigen sie an.

Das kann natürlich letztlich mit dem o.g. Dilemma das man nur einen UART für beides (TELE und S.BUS) mit einem Multiplexer zum Umschalten verwendet. Wenn dieser was anders im Takt umschaltet als der Prozessor dann mit den entsprechenden Signalketten versorgt wird (ist ja dann zufällig obs grad "Voll" passt) - könnte das OFS durchaus hier auch mal eine Ausgabe "auslassen" - und der Regler meckerts an.

Insofern - da es vermutlich Hardware oder die Auswertezyklen des S.Bus und TELE Ausgabe an uns betrifft - bitte OMP kontaktieren, wir sind hier sauber da wir getrennte Schnittstellen für TELE und S.Bus haben.

regards (EN) / Gruss (DE)

Rainer Vetter

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Posting and answering - please use a PC and a standard keyboard. Answer all questions fully, take the needed time, don't forget probably requested attachments.

Für Posts und Antworten bitte einen PC und eine richtige Taststaur benutzen sowie alle Fragen vollständig abarbeiten. Nehmt Euch Zeit, beantwortet Rückfragen in Ruhe und vollständig.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Für Einzelkommunikation bitte ausschließlich Email verwenden! - PN, Messenger, Chat usw. werden nicht bearbeitet.
For single user communication please send a email only! PM, Messenger, Chat etc. won't be read.



1 mal bearbeitet. Zuletzt am 09.05.2026 15:32 von RV.

Lieber Rainer,

vielen lieben Dank für die Infos! Ich halte Dich am laufenden .

Beste Grüße
Thomas

Selbiges Problem bei mir. OEM stehen die OMPHOBBY Makrozellen Presets auf 7ms. Hab eben M1 und M2 mit den neuen Empfängern getestet und bei beiden das von Thomas geschilderte "Problem" festgestellt, nach Umstellung auf 10ms war Ruhe und keine Probleme mehr

Vielleicht sollte OMPHOBBY das auch direkt mal umsetzen...aber da ist wer anders für verantwortlich

Na - wir sind dabei ein aktuelles OMP Preset zu integrieren, da sind wir in Kontakt. Aaron und ich sind da in den letzten Zügen ;-)

regards (EN) / Gruss (DE)

Rainer Vetter

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Posting and answering - please use a PC and a standard keyboard. Answer all questions fully, take the needed time, don't forget probably requested attachments.

Für Posts und Antworten bitte einen PC und eine richtige Taststaur benutzen sowie alle Fragen vollständig abarbeiten. Nehmt Euch Zeit, beantwortet Rückfragen in Ruhe und vollständig.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Für Einzelkommunikation bitte ausschließlich Email verwenden! - PN, Messenger, Chat usw. werden nicht bearbeitet.
For single user communication please send a email only! PM, Messenger, Chat etc. won't be read.

Sehr nice!
Das wird ja immer besser

Ich habe natürlich bei meinen M1 und M2 mit OFS3 und dem neuen Micro RX Heli Only Empfänger die selben Probleme mit der Telemetrie.
Habe auch die 144Hz/7ms eingestellt gehabt und werde nun auch auf die 10ms umschalten.

Aber jetzt mal meine Frage, hätte es für den neuen Empfänger keine andere, bessere, Lösung als einen mittlerweile verhaltenen S-Bus gegeben und dann noch zusammen mit der Telemetrie auf einen UART / Port ????????????????

Und warum tritt dieses Signal Problem nicht bei den Vorgängern den RX6 Only Empfängern auf, von denen habe ich 4 Stück in Verwendung, die funktionieren problemlos mit 144Hz/7ms ?



1 mal bearbeitet. Zuletzt am 10.05.2026 12:22 von Orpheus.

RV schrieb:
-------------------------------------------------------
> Na - wir sind dabei ein aktuelles OMP Preset zu
> integrieren, da sind wir in Kontakt. Aaron und ich
> sind da in den letzten Zügen ;-)

Das klingt super - da freu ich mich schon drauf

Mein M1 & M2 fliegt aktuell mit dem OMP Makrozellen Presets auf 7ms einwandfrei - und auf 10ms ebenfalls keine Probleme...

Aber "das Bessere ist des Guten Feind" - bin schon gespannt was euer neues Preset hergibt - da ist bestimmt noch Luft nach oben

Das "Problem" ist ja ein wenig, dass das OFS keine Bänke kennt - und man daher sowohl bei den Makrozellen, als auch im OFS gewisse Parameter (Wendigkeit, Drehzahl) anpassen muss, um gewünschte "unterschiedliche Flugerlebnisse" auf den Bänken zu realisieren..

LG,
Thomas

Quote:

Aber jetzt mal meine Frage, hätte es für den neuen Empfänger keine andere, bessere, Lösung als einen mittlerweile verhaltenen S-Bus gegeben und dann noch zusammen mit der Telemetrie auf einen UART / Port ????????????????

Die Doppelbelegung der UART ist auf OMP/OFS Seite - NICHT bei uns. Die Kollegen da haben dies halt aus Mangel an I/O Hardware (I/O am Prozessor) so implementiert.

S.Bus ist nunmal unsere Schnittstelle dafür - da haben wir die original Futaba Spec und halten uns daran. Insofern ist das alles gut.

Quote:

Und warum tritt dieses Signal Problem nicht bei den Vorgängern den RX6 Only Empfängern auf, von denen habe ich 4 Stück in Verwendung, die funktionieren problemlos mit 144Hz/7ms ?

Hast Du da die Telemetrie des OFS mit dran? - vermutlich nicht.

regards (EN) / Gruss (DE)

Rainer Vetter

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Posting and answering - please use a PC and a standard keyboard. Answer all questions fully, take the needed time, don't forget probably requested attachments.

Für Posts und Antworten bitte einen PC und eine richtige Taststaur benutzen sowie alle Fragen vollständig abarbeiten. Nehmt Euch Zeit, beantwortet Rückfragen in Ruhe und vollständig.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Für Einzelkommunikation bitte ausschließlich Email verwenden! - PN, Messenger, Chat usw. werden nicht bearbeitet.
For single user communication please send a email only! PM, Messenger, Chat etc. won't be read.



2 mal bearbeitet. Zuletzt am 10.05.2026 19:14 von RV.

Wo muss ich die updaterate genau umstellen. Welcher Menüpunkt ist das?? Kenn mich mit der vbar Control noch nicht so gut aus. Lg Stefan

RV schrieb:
-------------------------------------------------------

> Hast Du da die Telemetrie des OFS mit dran? -
> vermutlich nicht.


Hallo Rainer!
Doch, ich habe bei allen vier NEO micro 6Kanal RX Only ganz normal die SBus Verbindung und die Telemetrie vom Tele1 (korrekter) Pin eine Verbindung zum CRFS TX Pin des OFS3
So wie in der OMP Anleitung Revision 5 beschrieben.
Sowie auf 144Hz/7ms eingestellt.
Hier funktioniert die komplette Telemetrie und Akkumanager problemlos und keiner der elektronischen Komponenten meckert rum.

Einziger Unterschied zum neuen Micro Heli RX Only ist das hier nur eine 1 polige Verbindung zu TX besteht
Beim Neuen habt ihr alle 4 Adern zum CRFS ausgeführt, was aber nicht bedeuten muss das ihr alle Pins in Verwendung habt.

Lg Dietmar



1 mal bearbeitet. Zuletzt am 10.05.2026 21:52 von Orpheus.

Moin,

wir haben nur ein Kabel am CRFS in Verwendung (TX), die anderen stabilisieren den Stecker und das (sonst) arme einzelne Käbelchen, was man sonst ggfs. leicht abreißen könnte.

Was ich auch noch nicht ganz verstanden habe, OMPHOBBY unterscheidet ja auch zwischen S.BUS und S.BUS wide (?), vermutlich andere Paket'beschaffenheit', was proprietäres), und für Telemetrie am integrierten Empfänger gibt es sogar scheinbar noch einstellbare Verhältnisse zwischen Steuerung:Telemetriedaten (bei VLink stets 1:1), was bedeuten könnte, dass sie immer wieder Slots frei halten (müssen), um in denen dann (dann aber kaum in Echtzeit?) Telemetriedaten zurück zu schicken. KP ob und wie das auch ext. Empfänger betrifft.

S.BUS hat aber in der Implementation, so wie ich es verstehe, da keinen Einfluss: der S.BUS-Datenstrom kommt alle 7, 10, 14, ... ms, Paket-Paket-Paket-Paket, und die Telemetrie wird über den anderen Anschluss entgegengenommen, da beeinflusst sich bei uns nix gegenseitig.
Der VLink-Empfänger behandelt das auf der Funkstrecke zum Sender wie jede andere VStabi auch, 5 ms senden, 5 ms empfangen, repeat.
Dem aufmerksamen Leser wird auffallen, dass nur 5 und 10 eine Gemeinsamkeit haben, das kann synchron laufen, bei anderen Pärchen wird es immer eine Wartezeit geben (müssen), bis der andere wieder Aufnahmefähig ist bzw. wieder was ausgibt (asynchron).
Wenn aber vom Fremdsystem eben für eine gewisse Zeit (Verhältnis Steuerung zu Telemetrie? Wenn das hier überhaupt einen Einfluss hat, den es nicht haben müsste, dürfte, _oder_ Verhältnis am I/O, Multiplexer, wie viele Zyklen auf was entfallen) keine Daten kommen, hat der Empfänger nix weiterzugegeben, und der Sender 'denkt sich', alle babbela, kommt nix mehr. Dann doch wieder, bups, Akku-Auswahl, oder schlimmer, wenn das zeitlich blöd zusammenfällt, gepaart mit asynchronem Timing, hakelige Steuerung.

Wenn S.BUS und Telemetrie im Fremdsystem jetzt über den selben I/O laufen, und der eben immer wieder umgeschaltet wird, hören-sprechen-hören-sprechen (wie Walkie-Talkie, Sprechtaste, aber unterschiedliche lang gedrückt/losgelassen) und nicht ständig beides bedient wird (wie am Telefon), ...

Man weiß es nicht.

OMPHOBBY weist aber auch drauf hin, schreibt explizit in deren Doku, dass man Telemetrie nur verwenden soll, wenn unbedingt benötigt (?) ... wo ist da der Witz, wenn man Telemetrie schon anbietet ... wenn man's dann nicht darf/soll. Honni soit qui mal y pense ...

Will jetzt nicht drauf rumhacken, sind nur meine Gedanken. Am Ende ist's halt keine Voll-Integration, sondern ein ext. Empfänger (wie ein originaler oder reverse-engineerter S.BUS oder anderer Empfänger auch). Originale S.BUS würden übrigens meine ich auch mit 7/14 ms daherkommen.

Eine VStabi stellt sich im Übrigen auf die Eingangs-Wiederholrate ein (weil sie's kann ^^), wenn man einen Fremdempfänger anschließt.

Grüßle

Eddi

Born to fly ...
forced to work.