Telemetriedaten von Betaflight
- ThLehmann
- Offline
- Platinum Mitglied
- Beiträge: 390
- Dank erhalten: 149
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.
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
Gruß, Thomas
von ThLehmann
Bitte Anmelden oder Registrieren um der Konversation beizutreten.
- OpaMichi
- Offline
- Senior Mitglied
- Beiträge: 53
- Dank erhalten: 3
@ 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
@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
- Offline
- Senior Mitglied
- Beiträge: 45
- Dank erhalten: 0
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
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
- Offline Autor
- Junior Mitglied
- Beiträge: 34
- Dank erhalten: 26
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.
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]
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.
@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
- Offline
- Platinum Mitglied
- Beiträge: 603
- Dank erhalten: 157
Hi Thomas vielen Dank für deine umfassende Erklärung
Hast ne PN von mir.
Grüße Christoph
Hast ne PN von mir.
Grüße Christoph
von Roady123
Bitte Anmelden oder Registrieren um der Konversation beizutreten.
- RainerZ
- Offline
- Neues Mitglied
- Beiträge: 4
- Dank erhalten: 0
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
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