Telemetriedaten von Betaflight

  • ThLehmann
  • ThLehmann's Avatar Offline
  • Platinum Mitglied
  • Platinum Mitglied
  • Beiträge: 390
  • Dank erhalten: 149

ThLehmann antwortete auf Telemetriedaten von Betaflight

Posted 15 Juni 2019 22:09 #49
so bin jetzut wieder auf RX1 zurück, anhand der BF Anleitung auch kein Problem den UART mit UDI zu betreiben:
github.com/betaflight/betaflight/blob/44...7aeea34d8/docs/Rx.md

@OpaMichi: die Uarts (zumindest beim F4) sind auch im one-wire Mode und half-duplex betreibbar, da die Kommunikation gesteuert abläuft kommt es bei geregeltem Betrieb auch zu keiner Kollision. Aus diesem Grund ist der Widerstand auch eigt. unnötig, schaden sollte er aber mE nicht.
Da es aber bei zB Roady123 bereits dauerhaft funktioniert habe ich wohl Pech gehabt. Keine Ahnung was dazu geführt hat das sich mein CPU Port veraschiedet hat. Beim nächsten Mal werde ich jedenfalls zum Schutz einen Widerstand einlöten.
immer schön vorsichtig landen
Gruß, Thomas
von ThLehmann

Bitte Anmelden oder Registrieren um der Konversation beizutreten.

  • OpaMichi
  • OpaMichi's Avatar Offline
  • Senior Mitglied
  • Senior Mitglied
  • Beiträge: 53
  • Dank erhalten: 3

OpaMichi antwortete auf Telemetriedaten von Betaflight

Posted 16 Juni 2019 15:52 #50
@ Christoph, schön zu lesen das wir doch auf einer Wellen länge sind ;) natürlich habe ich mit Bauanleitung Emfänger nur das Adapterkabel mit Widerstand gemeint.

@ThomasMiric, da Du ja einfluß auf die BF Software hast, hier mal etwas was mir aufgefallen ist.
Ich betreibe meinen Rsat2 am UART2 auch Spannungsmäßig.
Mir ist klar das er dann nur mit Spannung versorgt wird wenn ich den Akku anstecke.
Wenn ich jetzt Einstellungen vornehme ohne Akku kommt es nach einem Reboot vor, dass sich die Einstellung vom Empfänger selbstständig geändert hat und nach anlegen vom Akku Dauerpiepen kommt, weil kein Empfänger erkannt wird. Dies ist auch bei BF3.3.1 so.
Ich denke mal das die Software beim hochfahren feststellt kein EXBUS Empfang, da Empfänger nicht betriebsbereit und einen Default Wert Sektrum Empfänger einstellt und die alte Einstellung überschreibt.
Ich hoffe ich habe mich verständlich ausgedrückt.
Schönner wäre es wenn die Auswahl vom Empfänger dauerhaft bleibt und sich nicht selbständig ändert.

M.f.G. Opa Michi
von OpaMichi

Bitte Anmelden oder Registrieren um der Konversation beizutreten.

  • Buschpilot
  • Buschpilot's Avatar Offline
  • Senior Mitglied
  • Senior Mitglied
  • Beiträge: 45
  • Dank erhalten: 0

Buschpilot antwortete auf Telemetriedaten von Betaflight

Posted 28 Juli 2019 21:02 #51
Hallo zusammen,

nach längerer Abstinenz mangels Zeit habe ich nun endlich wieder einmal einen Moment gefunden, mich meinen unfertigen Drohnen zu widmen. Frage: ist die "widerstandsfreie" Unterstützung von Jeti ExBus nun per default in der aktuellen Betaflight Version enthalten?

Fliegerische Grüsse

Dominik
von Buschpilot

Bitte Anmelden oder Registrieren um der Konversation beizutreten.

  • ThomasMiric
  • ThomasMiric's Avatar Offline Autor
  • Junior Mitglied
  • Junior Mitglied
  • Beiträge: 34
  • Dank erhalten: 26

ThomasMiric antwortete auf Telemetriedaten von Betaflight

Posted 07 Okt. 2019 13:46 #52
Hallo Leute!
Da ich mit unserem Hausbau und umsiedeln beschäftigt war, hatte ich sehr wenig Zeit für BF.

Nun zu dem was ich „verbrochen“ habe:
Seit BF4.0 ist die neue Variante ohne Widerstand aktiv. Ich habe dies abgeändert weil der Aufwand mit dem Widerstand manche nicht machen wollten. Leider ist dadurch eine Möglichkeit entstanden der einen Empfang mit alter Verdrahtung nicht mehr funktionieren lässt.

Zur chronologischen Entstehung des Jeti Protokolls:
Die Erste Implementierung war einfach den Empfänger auf Rx eines Uart zu legen und den Empfänger auf Exbus konfigurieren (100Hz wurde damals schon unterstütz).

Die zweite Änderung betraf die Telemetrie. Es wurde ein Widerstand benötigt, der zwischen Rx & Tx verlötet wurde, um einen one wire bus zu erhalten. Ich weiß nicht mehr genau welche Werte ich damals übertragen habe, aber es wurden auch Debugwerte übertragen (die auch in INAV übernommen worden sind). Es hat damals Spekulationen gegeben was die Werte zu bedeuten haben, die waren jedenfalls nur für mich.

Dann habe ich das Protokoll überarbeitet und gleichzeitig den one wire modus mit nur einem Pin eingeführt. Und da ist mir ein möglicher Fall durchgerutscht denn ich aus Entwicklerblindheit nicht bedacht habe.
Seit BF4.0 ist nur noch ein Pin vom Uart zu verwenden, dies ist aber der Tx des uarts und nicht wie gewohnt der Rx.
Der STM32 bietet eine one wire Hardwareunterstützung an wobei intern die Verbindung zwischen Rx und Tx erfolgt. Diese Verbindung wird aber nur am Tx Pin herausgeführt. Wenn nun ein Widerstand zwischen Rx und Tx vorhanden ist, ändert dies nichts vom Verhalten des FCs. Somit ist eine Abwärtskompatibilität gegeben.
So und das war mein Fehler, ich bin davon ausgegangen, wer Jeti benutzt, nutzt auch die Telemetrie. Wenn jemand aber den Empfänger nur auf den Rx angeschlossen hat, und keinen Widerstand verbaut hat, der hat nun ein Problem mit BF4.x.

Lösung: den Empfänger auf einen freien Tx verlöten, fertig.

So, nun zu einigen Erklärungen zu den Fragen die ich gelesen habe:[/size]

  • Stört der Widerstand in der neuen Konfiguration
  • Nein, der Widerstand war nur deshalb vorhanden um einen möglichen Kurzschluss zwischen Rx & Tx zu verhindern. Wenn er verbaut bleibt gibt es keine Auswirkungen.

  • Wird der Tx nun auch zum Lesen verwendet
  • Ja, dies ist wie oben beschrieben der one wire bus. Dadurch erhält man aber keine Nachteile. Das Jetiprotokoll überträgt die Geberwerte, jede zweite Übertragung bekomme ich eine Anforderung die Telemetriedaten zu übertragen. Dies geschieht genau in der Pause der Geberwerte. Somit hat man keine Kollision. Weiters werte ich die Zeit aus wann die Anfrage gekommen ist, ist diese zu lange her, werden in diesem Zyklus keine Daten übertragen (dies kommt nur sehr selten vor, sieht man wenn die Logs ansieht).

  • Werden immer alle Telemetriedaten gleichzeitig übertragen
  • Nein, die momentane Übertragungsvariante ist folgende:
    Es können maximale 32 Werte übertragen werden, wobei diese in zwei Bereiche aufgeteilt werden (Jeti Protokoll abhängig)
    Beim Telemetrieprotokoll von Jeti ist eine max. Payload der Werte mit 29 Byte pro Antwort möglich. Ich habe es aus Sicherheitsgründen auf 26 Byte reduziert.
    Die Werte werden nacheinander gesendet.

  • Latenz
  • Wenn man im Sender auf 100Hz stellt, hat man genau 10ms (+/- 0,2ms Jitter).


    @OpaMichi
    Es gibt keine Erkennung ob der Empfänger vorhanden ist oder nicht, geschweige eine automatische Änderung des Empfängerprotokolls.
    Last Edit:07 Okt. 2019 13:52 von ThomasMiric
    Letzte Änderung: 07 Okt. 2019 13:52 von ThomasMiric.
    Folgende Benutzer bedankten sich: Roady123, bangkokpete

    Bitte Anmelden oder Registrieren um der Konversation beizutreten.

    • Roady123
    • Roady123's Avatar Offline
    • Platinum Mitglied
    • Platinum Mitglied
    • Beiträge: 603
    • Dank erhalten: 157

    Roady123 antwortete auf Telemetriedaten von Betaflight

    Posted 07 Okt. 2019 16:57 #53
    Hi Thomas vielen Dank für deine umfassende Erklärung :)

    Hast ne PN von mir.

    Grüße Christoph
    von Roady123

    Bitte Anmelden oder Registrieren um der Konversation beizutreten.

    • RainerZ
    • RainerZ's Avatar Offline
    • Neues Mitglied
    • Neues Mitglied
    • Beiträge: 4
    • Dank erhalten: 0

    RainerZ antwortete auf Telemetriedaten von Betaflight

    Posted 09 Okt. 2019 21:26 #54
    Hallo,

    Ich bekomme alle Telemetriedaten bis auf die GPS Werte.
    Im Betaflight Configurator wird eine gültige GPS Position angezeigt.
    Hat mir jemand einen Tip, was ich falsch gemacht haben könnte ?

    Habe 4.0.6 drauf.

    Gruß
    Rainer
    von RainerZ

    Bitte Anmelden oder Registrieren um der Konversation beizutreten.

    Ladezeit der Seite: 1.003 Sekunden