Zuverlässigkeit muß sein, aber was wäre die Alternative, wenn man was ausgefallenes machen will ? Nur SW Änderung über den Hersteller ? Andere Sprache ? Irgendein grafisches Eingabesystem ? z.B. Android Apps reinladen ? Webanwendungen ?
RK
Sprachausgabe nach Werteintervallen - Lua Lösung?
- Ersteller onki
- Erstellt am
RK
Hallo,
Für mich ist das eher ein Fall für eine Firmwareerweiterung.
Lua nervt mich derzeit weil ich alle Nase lang wieder irgendwelche Skripte neu parametrieren muss.
Sicher bin ich davon auch nicht ganz befreit wenn es grundlegende Änderungen im Sender gibt aber diese Frequenz ist doch sehr, sehr gering.
Einerseits wird Jeti (zurecht) in die Premiumecke gestellt, dann ist es aber eher "Economy" so etwas über externe Lösungen zu erledigen.
Das ist keine Anwendung für einen kleinen Teil der Anwender sondern davon würden alle profitieren.
Die Sprachausgabe ist eine tolle Sache. Nur was bringen mir ständige Werteansagen, wenn sich der Wert selber nicht ändert.
Es gibt viele Anwendungen für Zeitintervalle und auch Alarme sind wichtig. Das gilt meiner Ansicht aber auch für Intervallwerte.
Nur so kann man vernünftig die Telemetrie nutzen (z.B. bei der Akkukapazität) ohne das sie einem auf den Geist geht.
Gruß
Onki
Für mich ist das eher ein Fall für eine Firmwareerweiterung.
Lua nervt mich derzeit weil ich alle Nase lang wieder irgendwelche Skripte neu parametrieren muss.
Sicher bin ich davon auch nicht ganz befreit wenn es grundlegende Änderungen im Sender gibt aber diese Frequenz ist doch sehr, sehr gering.
Einerseits wird Jeti (zurecht) in die Premiumecke gestellt, dann ist es aber eher "Economy" so etwas über externe Lösungen zu erledigen.
Das ist keine Anwendung für einen kleinen Teil der Anwender sondern davon würden alle profitieren.
Die Sprachausgabe ist eine tolle Sache. Nur was bringen mir ständige Werteansagen, wenn sich der Wert selber nicht ändert.
Es gibt viele Anwendungen für Zeitintervalle und auch Alarme sind wichtig. Das gilt meiner Ansicht aber auch für Intervallwerte.
Nur so kann man vernünftig die Telemetrie nutzen (z.B. bei der Akkukapazität) ohne das sie einem auf den Geist geht.
Gruß
Onki
Having telemetry data pronounced periodically has a major disadvantage for me. You get too much unchanged information. I would like to hear information when something has changed.
That's why I created an experimental Lua program "In Flight" that meets all my requirements. Among other things, it provides information about the altitude, distance to the starting point and battery capacity consumption at adjustable intervals. Furthermore, when the motor is released, the program checks whether the GPS is locked. If this is not the case, a warning will follow. There are also two alarms for capacity consumption.
This works well for me. The spoken information is limited as much as possible and only gives changes.
The Lua program is still under development. But creating such a program is not very complicated. Any interested should be able to do this with some study. On the site of RC-Toughts, https://www.rc-thoughts.com/ you can find a lot of Lua information and also fully elaborated programs. They are worth studying! That's how I learned programming in Lua and I am not a professional programmer.
Below a few screenshots of In Flight.
Sincerely,
Nico
That's why I created an experimental Lua program "In Flight" that meets all my requirements. Among other things, it provides information about the altitude, distance to the starting point and battery capacity consumption at adjustable intervals. Furthermore, when the motor is released, the program checks whether the GPS is locked. If this is not the case, a warning will follow. There are also two alarms for capacity consumption.
This works well for me. The spoken information is limited as much as possible and only gives changes.
The Lua program is still under development. But creating such a program is not very complicated. Any interested should be able to do this with some study. On the site of RC-Toughts, https://www.rc-thoughts.com/ you can find a lot of Lua information and also fully elaborated programs. They are worth studying! That's how I learned programming in Lua and I am not a professional programmer.
Below a few screenshots of In Flight.
Sincerely,
Nico
Anhänge
Manches, das viele wollen, kommt vermutlich mal in die Firmware. Aber vielleicht wollen viele etwas anderes als du ? Dort Änderungen zu machen und zu verteilen ist ungleich schwerer. Außerdem ist man dann entweder genau an die Ideen der Herstellers gebunden oder muß eine Menge Parameter einstellen, wobei der gewünschte meist wieder fehlt. Also sollten wir uns eher freuen, daß es die Möglichkeit gibt, so etwas individuell zu lösen. Alternativ einen Sender mit OpenTX - da kannst du es sogar selber in die Firmware reinbringen mit etwas Know-how.
RK
Gast_68494
Gast
OpenTx ist keine Firmware sondern das Betriebssystem des Senders, die Sender Firmware kommt ausschliesslich von FrSky. Und selber "reinbringen mit etwas Know-how" ist zum einen nicht nötig, da bereits vorhanden (siehe meinen Beitrag #7), zum anderen möchte ich das in der Praxis stark bezweifeln. Kein Mensch macht in der OpenTx Software selber was rum, dazu müsste er den gesamten Sourcecode runterladen, bearbeiten und selbst kompilieren, da wünsche ich dann viel Glück. Ach ja, in den freigegebene OTx Versionen kann keiner was rummachen sondern ausschliesslich nutzen.
Das sind die Macher von OpenTX aber anderer Meinung:
"OpenTX is a free and open-source software project that includes:
A piece of embedded firmware called OpenTX that is designed to serve as the operating system of a remote control system as is commonly used for hobby RC models and industrial applications, and supports a number of different hardware targets listed on the Radios page..."
Firmware und Betriebssystem ist hier nicht so getrennt wie z.B. bei Windows. Höchstens der Bootlader ist spezifisch für/von FrSky. Genauso wie es ja z.B. Projekte gibt, die die SW auf Mega2560 einsetzen.
Hier ging es nicht nur um eine spezielle Funktion, sondern um allgemeine Erweiterungen, die eben möglich sind.
Genau diese Möglichkeit ist ja das Reizvolle an OpenSource SW. Obwohl klar ist, daß man da schon etwas mehr Fähigkeiten braucht, als nur ein paar Variablen in LUA zu manipulieren. Andererseits ist LUA eben die Möglichkeit, solche Änderungen zu vermeiden und dafür einen weniger invasiven Weg zu wählen.
An den Binaries nicht. Aber man kann sich die entsprechenden Sourcen runterladen, ändern und für sich eine eigene Version machen. Oder, wenn die Änderungen gut genug sind und vom Team akzeptiert werden, auch wieder für eine zukünftige Release in die allgemeine Entwicklung einfliessen lassen.
RK
Ich habe mir die Sourcen mal angesehen, die Einstiegshürde ist schon sehr hoch, es ist schon ein umfangreiches Projekt.
Dazu kommt das die Quellcode Dokumentation gegen Null geht. Da hätte ich mehr erwartet, weit entfernt von kommerziellen Anforderungen in meinem ehemaligen Arbeitsleben im embedded Bereich.
Gruß Ingo
Dazu kommt das die Quellcode Dokumentation gegen Null geht. Da hätte ich mehr erwartet, weit entfernt von kommerziellen Anforderungen in meinem ehemaligen Arbeitsleben im embedded Bereich.
Gruß Ingo
Ich arbeite auch in dem Bereich und bevorzuge mehr Doku. Allerdings ist das zumindest bei Linux sowohl bei uns als auch in allgemeinen Sourcen eigentlich überall so. Dann hört man meistens "der Code ist die Doku" :-( Wobei das mit vernünftigen Namen und ohne Obfuscated-C-Contest durchaus geht.
RK
