THEMA:

Hier ist wohl des Rätsels Lösung


Interesting. There is a Gap required between the packets, since there is no other means for framing. VBar needs 2ms minimum. Unfortunately there is no Value fixed in the Spec, since at this time, the timing was quite stable.
If the Gap is too small, there is the risk to confusion between only slower outputs or a real new packet, thats the reason for the 2ms

The shown behaviour seems to be sort of not right, since the transmission probably is not that random. I cannot see a reason why packets shall arrive back to back, or random.

Jeti has got a VBar (back at 2012) to test everything with it, so they shall be able to verify whats wrong there, it shall be easy to fix for them.

I am still not convinced, that this is the reason for some mysterious loss of signals. I am pretty sure the problem in most cases is a bad connection or some added inteference into that connection.

If Jeti cannot solve this for you, we may contact them an find a solution here.

so long ... Uli
www.vstabi.de
Beitrag antworten Beitrag zitieren Beitrag melden

MarkusD schrieb:

Hier ist wohl des Rätsels Lösung


I am still not convinced, that this is the reason for some mysterious loss of signals. I am pretty sure the problem in most cases is a bad connection or some added inteference into that connection.

Lösung kann ich hier keine herauslesen, wo doch der Uli von Mikado eindeutig geschrieben hat, dass er nicht davon überzeugt ist, dass das Problem vom Jeti Empfänger kommt, sondern eher von schlechten Akku / Servoverbindungen oder irgendwelchen anderen Störeinflüssen ...

Trotzdem gut, dass dem Phänomen nachgegangen wird.

Stimmt - da steht aber auch das er mindestens 2ms abstand benoetigt.....dies aber in der udi Spezifikation nicht festgelegt hat....

Er hat jedenfalls seine Hilfe angeboten

Hallo,

Sieht mir also nach einer unvollständigen Spezifikation des UDI-Formats aus. Wahrscheinlich hat zum Zeitpunkt der Formulierung keiner gedacht, dass die 2mm wohl infolge der neuen schnellen REX-Empfänger nun unterschritten werden können. Man sollte jetzt auf jeden Fall die Spezifikation ergänzen.

Optimal wäre es, wenn die Firmware für die REX-Empfänger die Einstellung einer Framerate / eines Frameabstandes ermöglichen würde, weil somit die Option bleiben würde, diese an zukünftige - schnellere - FBL-Systeme anpassen zu können und für die aktuellen eben etwas drosseln zu können.
Auch wenn man demnach hier Jeti nicht die Schuld geben kann, wäre es die kundenfreundlichste Lösung.

viele Grüße

Wolfgang

Hallo Wolfgang,

einfach mal als Tipp:

all das mal nett und freundlich in Englisch zu Jeti schreiben. dass es da aktuell einen "Konflikt zwischen FBL Systemen und REX UDI" gibt.

Vielleicht hilft ja auch ein netter Brief von Jeti Usern.


Gruss

PW

Hallo Peter,

vielen Dank für den Tipp.

Habe ich gerade mal gemacht:

Hello,

on helifreak there a discussions about problems between REX receivers and some flybarless systems when using digital protocols (EX BUS or UDI):

EX BUS and Spirit: helifreak.com/showthread.php?t=712741
UDI and Mikado VStabi neo: helifreak.com/showthread.php?t=720049

The issue with the Spirit is fixed by an update from Spirit, as far as I know. But the issue with the VStabi is still not solved. As stated by Mikado the gap between two data packets must be not less than 2ms for the VStabi. I don’t know, what other flybarless controllers need there.

My suggestion would be, to provide a setting in the REX receivers to set a minimum gap for the data packets. So the user can set this value to a time, that is sufficient for his flybarless system and we have the possibility to speed this up if newer systems can handle faster data streams.

Another question for me is, if there are any known issues with BeastX (Microbeast or Microbeast plus).

A feedback is much appreciated.

Ergänzung: Ebenso habe ich eine Mail an Frakware/BeastX geschickt, da ich wissen möchte, ob es da auch Infos zu diesen Problemen gibt.

viele Grüße

Wolfgang