M-Link goes Android: Betatester gesucht

hiwi

User
Speed

Speed

Hat eigentlich schon mal jemand den Unilog mit Staudruckrohr probiert? Auch das dort eingebaute Vario ist sehr präzise.
Man könnte dann für jedes Modell eine Minimalgeschwindigkeit definieren oder erfliegen und sich dann kurz vor unterschreiten z.B. ein "Achtung Stall"
ansagen lassen. Mit GPS geht das ja nicht wegen fehlender Luftgeschwindigkeit.
Gruss Ralf
 

ubit

User
So einfach geht das leider nicht. Stall hängt nicht nur von der Airspeed ab. Da bräuchte man noch mehr Sensoren die auf Grund der geringen Daten Räte dann auch besser schon im Modell verrechnet werden.
Gibt auch ein paar Threads im Netz zu dem Thema.
 
SM-Pitotrohr

SM-Pitotrohr

Moin, ich habe das SM_Modellbau Pitotrohr in einem Kunstflieger drin, das hängt aber an einem
wstech Vario ( was ja auch als Multisensor geht - in diesem Falle so genutzt ) .

In meiner Wiedereinstiegsphase habe ich schon die Geschwindigkeitsansage als Anhalt genutzt um
im Landeanflug nicht zu schnell/langsam zu sein, aber die Ansage ist wegen Sprache noch viel träger.

Die Speed mit einer Art Varioton schneller zu ver/übermitteln ging mir auch durch den Kopf damals.
Natürlich ist das nicht ganz korrekt - aber ne Hilfe ist es schon, man muss halt langsam die Speed ändern.

Ein geübter Pilot braucht das wohl nicht, wstech hat es wohl auch eher wegen der Gefahr in großer
Höhe die Speed zu UNTERschätzen als Sensoroption.

Gruß Bernd
 

ubit

User
Hi,

im Übrigen: Wenn Ihr noch Ideen habt - ich bin da ganz offen... Ist zwar nicht garantiert, dass ich Eure Ideen auch umsetze *g* Aber ich würde sie schon gerne lesen und schauen ob sich was draus machen lässt. Manchmal kann es auch eine Weile dauern bis ich eine Idee habe etwas umzusetzen. Wie z.B. bei der GPS-Ortung die in einem anderen Thread als Wunsch aufgekommen ist. Dazu brauche ich auch noch etwas Input. Im Moment ist mir nur der SM GPS-Logger bekannt der nach der Landung (und auch nur dann) GPS-Koordinaten überträgt. Und das auf eine Art die vom M-Link Protokoll "eigentlich" nicht vorgesehen ist. So langsam wird mir aber klar, wie ich das in die Souffleuse einbauen könnte. Problem ist halt immer die Benutzeroberfläche. Im Fall GPS-Logger müsste ich eine "Speziallösung" einbauen damit die App weiß welche Sensoradressen die GPS-Koordinaten übertragen. Eine manuelle Auswahl ist hier natürlich einfach zu programmieren - aber halt auch unkomfortabel. Ich denke, dass in der nächsten Version (leider erst irgendwann im Winter zu erwarten) eine automatische Erkennung für den GPS-Logger drin sein wird inkl. "Übertragung" der Daten z.B. an Google Maps als Hilfe bei der Suche nach außengelandeten Modellen.

Weitere Features die aktuell in der Mache sind:

* Alarmschwellen in der App einstellbar
* Flugprogramm-Ansagen inkl. speziellem Trainingsmodus (lasst Euch überraschen)
* Unterschiedliche Warntöne mit denen man dann akustisch die "Wichtigkeit" eines Alarms unterscheiden kann (z.B. ein einfaches "Beep" bei Überschreiten einer Flughöhe von 100 m und ein dezenter Alarmton bei Erreichen einer bestimmten Akkukapazität und ein schriller Alarmton bei Unterspannung).
* Eingebaute Hilfefunktion (deutsch, englisch) um die Funktionalitäten direkt in der App besser zu vermitteln (viel Arbeit...)

Vor ca. einer Woche hat die Souffeuse übrigens die "magische" Marke von 100 "Downloads auf aktive Geräte" geknackt. Also Android-Geräte die aktuell benutzt werden und auf denen die App installiert und nicht wieder gelöscht wurde. Wieviele Leute die App tatsächlich aktiv nutzen kann ich leider nicht herausfinden.

Immer wieder gibt es Probleme mit der Hardware bzw. mit der "alten COM-Schnittstelle" die eines HW-Updates bei Multiplex bedarf. Das schlägt bei mir dann meist per Mail auf.

@Bernd: Du hattest da mal etwas geschrieben wie man das relativ einfach selbst lösen kann? Wäre super, wenn jemand von diesem "Umbau" mal ein paar brauchbare Fotos und einen kurzen Beschreibungstext machen könnte mit der Freigabe das als "Hardware-Hilfe" in die App einbauen zu dürfen.

Ciao, Udo
 
Hardwareupdate

Hardwareupdate

Hallo Udo,

die Info wie das gemacht wird ist mir nicht gestattet das weiterzugeben.
Die Spannung am "ComPort" bricht unter geringster Last ein, eine einfache Lösung
wäre sich die Versorgungsspannung von woanders zu holen ( evt. auf 5V runtersetzen ) .
Man sollte sich aber immer bewusst sein das man auch was falsch machen kann, und dann
ist das Geschrei groß - ich übernehme für die Info keine Verantwortung, wer nicht genau weiß
was er da macht soll es lassen !

Bzgl. GPS Ortung sind die ja im anderen Treath echt nervös :D .

Wie dort schon geschrieben macht wstech mit GPS das ähnlich wie SM-Modellbau, ich habe
aber für wstech kein GPSModul. Was da übertragen wird steht aber in der Anleitung zum
Linkvario. Wenn das also aktuell wird bekommen wir das schon hin.

GPS Logger hab ich ja auch liegen, selten in Benutzung, und Schande über mein Haupt, ich hab
letzt die wstech Groundunit in meinen 2. Sender eingebaut - die Souffleuse nutze ich aktuell gar nicht.

Aber wenn man mich nervt kann ich mit ausprobieren was passiert :rolleyes: .

Gruß Bernd
 

Maggi

User
Nervös würde ich das nicht nennen, eher erstaunt wie niedrig die Erwartungshaltung zu einer Legende ist
 

endi

User
Hardwareupdate

Hardwareupdate

Moin Jungs!

Die Spannung am "ComPort" bricht unter geringster Last ein, eine einfache Lösung
wäre sich die Versorgungsspannung von woanders zu holen ( evt. auf 5V runtersetzen ) .
Man sollte sich aber immer bewusst sein das man auch was falsch machen kann, und dann
ist das Geschrei groß - ich übernehme für die Info keine Verantwortung, wer nicht genau weiß
was er da macht soll es lassen !

Bernd, was meinst Du mit 'geringster Last'? - Mein Bluetooth-Modul (BC04-B mit max. 20mA Stromaufnahme und empfohlener Betriebsspannung 2,2-4,2V) schien in meiner wohl recht alten Cockpit SX (#77****) einwandfrei zu laufen, nach dem HF-Modul Firmware-Update auf v0.44 via MPX-Launcher. - Habe allerdings nur mal kurz (einige Minuten) im Keller getestet.

Ich werde mir in den nächsten Tagen einen Unisens-E bestellen und Euch dann berichten, ob es im wirklichen (Segler-)Leben auch funktioniert.

Gruß,
Andreas
 

hiwi

User
speedsensor

speedsensor

War ja auch nur eine Idee, deren Grundlage eher eine Spielerei ist, stellt Euch mal die Kollegen vorm wenn die Dame ruft "Attention Stall" :-)

Wird eigentlich bei dem Vario schon die Knüppelthermik wie im echten Flieger rausgerechnet? (Wenn man also keine Thermik hat, sondern gesteuert hat)

Zu Deinem Datenbankupdate: das Problem kenne ich und ich mache das immer so:
Ich lege eine Tabelle mit der version der DB an (Könnte man auch in einem internem File oder auf sdcard machen) , dann prüfe ich beim Start diese Version mit der im Code hardgecodeten Versionsnummer.Wenn die neue geforderte Version höher ist wird die Datenbank gepatched, so kann man auch mal ein Update auslassen und die Daten bleiben erhalten.
Die Update, create, add column etc statements habe ich ich in einer Arraylist gespeichert, die dann einfach durchgeloopt wird.
Darüberhinaus baue ich eigentlich immer gleich ein backup der sqllite-DB ein und einen excelExport mit dem man die daten ebenfalls wieder importieren kann.

Gruss Ralf
 

ubit

User
Hi Ralf,
DER Teil ist ja bei einem DB-Update nicht das Problem *g* In der Vergangenheit hat sich halt die interne Struktur der Datenbank teilweise erheblich geändert so dass man eine "Migration" der Daten hätte programmieren (und testen) müssen. Den Aufwand spare ich mir für so frühe Versionen einfach *g*

Knüppelthermik beim Vario rausrechnen könnte man im Prinzip innerhalb der App machen. Ist aber nicht wirklich sinnvoll, da die Telemetriedaten dazu einfach zu langsam eintrudeln. Wenn ich 10 Sensoren aktiv habe + Vario, dann bekomme ich bei priorisiertem Vario-Sensor zwar 10 Variowerte pro Sekunde, aber nur einen Speedwert pro Sekunde. Da ist die zeitliche Auflösung einfach zu gering. Sowas gehört in/an den Variosensor, samt Auswertelogik.

Ciao, Udo
 

hiwi

User
Hi Udo,
Die Strukturen mache ich auch damit, man kann die vorhandenen Daten ja temporär auslagern in eine Tabelle und entsprechend mit einem insert select wieder einfügen. Beim Entwickeln trace ich mit, welche Updates norwendig sind, auch für Änderungen die ich über die Sql Oberfläche mache erzeuge ich gleich passendes SQL. Ich habe gelernt, dass gerade in einem so frühen Stadium solche Basics wichtig sind, auch wenn man als Entwickler immer ganz aufgeregt ist, was man alles noch so einbauen kann. Ich habe z.B. ein Flugbuch geschrieben und ich glaubte gar nicht, wie intensiv die Leute das benutzen und was die alles an Daten da reinhauen.

Ich hatte im letzten Winter für meine Hitec Aurora 9 auch eine TelemetryApp geschrieben.
Nach jetzt etwa einem halben Jahr Test habe ich auch ein paar Erfahrungen gemacht:

1.) Ich bin vom modellbasiereten Konzept abgekommen und habe nur noch sog. Profile, also Segelflieger, Hangfliger, Helikopter, E-Antrieb, Verbrenenr etc.

2.) Es sollte eine Copy Funktion geben, die alle Einstellungen von einem Modell kopiert, damit musst Du nicht alles mehrfach eingeben, weil in der Regel ja nur wenige Parameter geändert werden. Ich habe etwa 60 Moddelle, davon fliege ich etwa 20 aktiv :-)

3.) Du baust ja noch Alarme ein, hier solltest Du gleich eine konfigurierbare Hysterese für Spannung / Strom einplanen

4.) Der Alarm sollte mit einem onTouch Event quittierbar sein. (Sound off, damit es nicht nervt) Ich habe die alarmgebenden Werte zusätzlich farblich markiert, dann sieht man sofort wer es war. Alarme würde ich mit einem Ton signalisieren nicht mit einer Ansage. Das ist unmissverständlich. Verschiedene Alarme halte ich der Praxis nicht für gut. Jeti macht sowas ja schon mit einer Art Morsecode. Ich kann die meistens nicht auseinanderhalten. (wohl schon zu alt) Im Grunde habe ich ohnehin nur ein oder 2 Alarme programmiert, meistens Spannung und verbrauchte Kapazität. Oder was Spezielles, wenn ich z.B. mal eine Luftschraube teste, dann die aktuelle Leistungsaufnahme oder die Drehzahl. Aber da hat jeder wohl seine persönlichen Vorlieben.

5.) Ich logge inzwischen im logview Format, da gibt es ein open format, sodass die universell ausgewertet werden können. Man kann die Logdateien auch wegspeichern, laden oder weiterloggen.

Das Konzept mit den Events gefällt mir gut, nutzt Du hiefür Threads oder Timertasks?
Wie ist die Performance, wenn man ganz viele Events hat?

Es gibt ein nette freie Grafiklibrary (graphview), damit erzeuge ich dann gleich aus den geloggten Daten eine grafische Darstellung für wichtige Parameter z.B.Spannung/Strom Drehzahl/Strom und 2 Temperaturen. Hört sich wie Spielerei an, ist aber immer ganz informativ gewesen.

Auf meinem SonyEriccson bekomme ich ständig eine "Willkommen"-ansage, das sollte m.E. nur beim Start kommen, bei mir ist das auch so, wenn ich z.B. die Info anzeigen lasse, oder die MainActivity wieder im Vordergrund geholt wird, hast Du wahrscheinlich im onResume.


Gruss Ralf
 

ubit

User
Hi Udo,
Die Strukturen mache ich auch damit, man kann die vorhandenen Daten ja temporär auslagern in eine Tabelle und entsprechend mit einem insert select wieder einfügen. Beim Entwickeln trace ich mit, welche Updates norwendig sind, auch für Änderungen die ich über die Sql Oberfläche mache erzeuge ich gleich passendes SQL. Ich habe gelernt, dass gerade in einem so frühen Stadium solche Basics wichtig sind, auch wenn man als Entwickler immer ganz aufgeregt ist, was man alles noch so einbauen kann. Ich habe z.B. ein Flugbuch geschrieben und ich glaubte gar nicht, wie intensiv die Leute das benutzen und was die alles an Daten da reinhauen.
Ist halt alles zusätzlicher Aufwand ;-) Solange das "Alpha" ist, spare ich mir das. Ab "Beta" wird das dann "orgentlich" gemacht *g*

1.) Ich bin vom modellbasiereten Konzept abgekommen und habe nur noch sog. Profile, also Segelflieger, Hangfliger, Helikopter, E-Antrieb, Verbrenenr etc.
Geschmackssache. Ich finde Modellbasiert schon wichtig, da ich doch teils erhebliche Unterschiede habe. Vermutlich werde ich aber eine Hierachie einbauen: Modell -> Variante. Damit kann der Anwender dann entscheiden und auch das "Profil-Modell" nachbilden, wenn er mag. Dann halt Modell "Heli", Variante "T-Rex 500", "Logo 600"...

2.) Es sollte eine Copy Funktion geben, die alle Einstellungen von einem Modell kopiert, damit musst Du nicht alles mehrfach eingeben, weil in der Regel ja nur wenige Parameter geändert werden. Ich habe etwa 60 Moddelle, davon fliege ich etwa 20 aktiv :-)
Yepp. Wird es sicher geben.

3.) Du baust ja noch Alarme ein, hier solltest Du gleich eine konfigurierbare Hysterese für Spannung / Strom einplanen
Yepp. Viel wichtiger noch z.B. für Höhenansagen "alle 50 m", wenn man im Nullschieber um 100 m herum hängt *g* Es wird auch für die Alarme die via Sensoralarm gemeldet werden eine Möglichkeit geben den Alarm nach der Ansage für eine gewisse Zeit zu unterdrücken, damit nicht dauernd z.B. die Restkapazität gemeldet wird und damit die Sprachausgabe "verstopft".

4.) Der Alarm sollte mit einem onTouch Event quittierbar sein. (Sound off, damit es nicht nervt) Ich habe die alarmgebenden Werte zusätzlich farblich markiert, dann sieht man sofort wer es war. Alarme würde ich mit einem Ton signalisieren nicht mit einer Ansage. Das ist unmissverständlich. Verschiedene Alarme halte ich der Praxis nicht für gut. Jeti macht sowas ja schon mit einer Art Morsecode. Ich kann die meistens nicht auseinanderhalten. (wohl schon zu alt) Im Grunde habe ich ohnehin nur ein oder 2 Alarme programmiert, meistens Spannung und verbrauchte Kapazität. Oder was Spezielles, wenn ich z.B. mal eine Luftschraube teste, dann die aktuelle Leistungsaufnahme oder die Drehzahl. Aber da hat jeder wohl seine persönlichen Vorlieben.
Töne für unterschiedliche Alarme wird man auswählen können. Da werden schon sehr unterschiedliche Töne zur Auswahl stehen die man gut auseinanderhalten kann. Quittung über Touch finde ich nicht so toll. Hat man während des Fliegens weder Auge noch Ohr für. Stattdessen wird es eine Quittung über einen Schaltkanal der Funke geben. Das geht bei M-Link im Gegensatz zu anderen Sendern.

5.) Ich logge inzwischen im logview Format, da gibt es ein open format, sodass die universell ausgewertet werden können. Man kann die Logdateien auch wegspeichern, laden oder weiterloggen.
Open Format von Logview komme ich nicht mit klar. Da hat Logview offenbar noch Fehler und LogView wird auch nicht mehr weiterentwickelt. Ob das mit Window 9/10/11 noch laufen wird? Außerdem sind die Telemetriedaten bei M-Link für einen Zeitpunkt nicht "komplett" sondern immer nur maximal 2 Werte. Damit kommt Logview auch nicht wirklich klar. Es gibt im Prinzip 3 Zustände für einen Telemetriewert:
- Sensor liefert keine Daten
- Sensorwert
- Sensor wurde nicht abgefragt
Die Unterscheidung zwischen "liefert keine Daten" und "nicht angefragt" ist bei M-Link wichtig.

Das Konzept mit den Events gefällt mir gut, nutzt Du hiefür Threads oder Timertasks?
Wie ist die Performance, wenn man ganz viele Events hat?

Events werden immer erzeugt, wenn sie auftreten, also wenn z.B. der Timer anschlägt (Thread) oder ein Alarm auftritt (Daten kommen rein, Hintergrundthread). Es wird dann in einer beim Verbindungsaufbau erzeugten "Tabelle" nachgeschaut ob Aktionen für dieses Event hinterlegt sind. Wenn nein, passiert nix, sonst werden die Aktionen der Reihe nach abgearbeitet. Performance ist dabei relativ unkritisch, wenn nicht 100 Aktionen gleichzeitig ausgelöst werden. Aber auch dann kommt nichts "ins Stocken", weil die App auf etliche Threads verteilt ist (Sprachausgabe, Display, Datenempfang) und die Sprachausgabe z.B. auch über Prioritäten verfügt so dass Alarme sich in der Schlange der anstehenden Sprachausgaben vordrängeln können.

Es gibt ein nette freie Grafiklibrary (graphview), damit erzeuge ich dann gleich aus den geloggten Daten eine grafische Darstellung für wichtige Parameter z.B.Spannung/Strom Drehzahl/Strom und 2 Temperaturen. Hört sich wie Spielerei an, ist aber immer ganz informativ gewesen.
Yepp - ist auch geplant. Wobei ich vermutlich selbst was dazu programmiere. Ist ja recht simpel.

Auf meinem SonyEriccson bekomme ich ständig eine "Willkommen"-ansage, das sollte m.E. nur beim Start kommen, bei mir ist das auch so, wenn ich z.B. die Info anzeigen lasse, oder die MainActivity wieder im Vordergrund geholt wird, hast Du wahrscheinlich im onResume.
Yepp. Und ist im Moment auch absichtlich bei jedem Resume, weil es manchmal Probleme mit der Sprachausgabe gab/gibt. Einige der Einstellungen verwenden ebenfalls die Sprachausgabe und manchmal klappt die Sprachausgabe dann anschließend in der Main-Activity nicht. Daher das "Willkommen" als akustische Kontrolle. Hört man das nicht, wenn der Hauptbildschirm sich öffnet, klappt die Sprachausgabe nicht und es würden im weiteren Verlauf auch keine weiteren Sprachansagen kommen.

Ciao, Udo
 

hiwi

User
Hi Udo,
prima und danke für die Info, dann brauchst Du noch ein bisschen Zeit und eine verständnisvolle Familie :mad:

Ich arbeite auch nicht mehr mit logview, sondern mit dem Dataexplorer, weil ich kein Windows, sondern nur einen Mac habe.
Ist aber von der Oberfläche nicht besonders intuitiv.

Wichtig für die App ist am Ende aber, dass das ganze bedienbar bleibt. Selbst als Entwickler geht es mir teilweise so, dass ich nicht mehr genau weiß, wie das eigentlich so funktionierte. :-) Vielleicht kann man auch eine easy und eine profi Oberfläche implementieren.

Den ganzen "Telemetrie Krempel" sehe ich eher mit einem gewissen Augenmaß. Ich war z.B. diesen Monat mit 10 Modellen Hangfliegen in Dänemark und mit allen Sensoren, Telemetrieboxen und Apps sozusagen bis an die Zähne bewaffnet und hatte mir fest vorgenommen alles zu loggen, auszuwerten zu überprüfen.... Aber was war?

Nix. Wahrscheinlich hatte ich das vor lauter Glücksgefühlen beim Hangfliegen ausgeblendet, ich hatte mir gerademal einen Timer (2 Stunden nicht Minuten) programmiert. Dann Kaffepause und weiter. Die einzige App, die wichtig war, war der Windfinder.

Für mich persönlich bleibt das Sinnvollste an der Telemtrie aber die Variofunktion und die hast Du prima gelöst. Danke!

Wir gehen ja auch nicht mit einem nicht oder nur halb geladenen Empfängerakku in die Luft. Ich weiß ganz genau - der hält x Flüge.
Wie auch immer, ich will jetzt nicht über den Sinn der Telemetrie diskutieren, auch wenn aus meiner Sicht der Hype darum grenzenlos überzogen zu sein scheint. Es bleibt sicher der technische Aspekt der interessanteste. Also wenn Du Unterstützung brauchst - derThread hieß ja nicht umsonst "Beta Tester gesucht".

Bei der iMSB Anwendung gibt es schöne analoge Instrumente, das wär noch mal was. Hast Du da schon mal sowas als android classes gesehen?

Gruss Ralf
 

ubit

User
"Schöne Instrumente" sind sicher nett anzuschauen, aber eigentlich.... Wozu? Während des Flugs schaue ich eh nicht auf's Display *g* Sowas frisst auch ziemlich viele Ressourcen für das Rendering. Wenn, dann kommt das irgendwann mal in einer Tablet-Version.

Ansonsten find ICH Telemetrie für mich sehr, sehr wichtig. Telemetrie bringt mir massive Vorteile bei der Flugzeit - insbesondere bei meinen Helis. Je nach Flugprogramm (Drehzahl, "Style") fliegt mein T-Rex 500 z.B. mit einer Akkuladung zwischen 10 und 20 Minuten. Mein Logo 600 zwischen 11 und 19 Minuten. Wenn ich mit Timer fliegen würde, müsste ich entweder vor dem Flug den Timer auf den "zu erwartenden" Wert einstellen (was unsicher ist, wenn ich mich mitten im Flug entschließe etwas zu "heizen") oder den Timer konservativ auf den niedrigsten Wert einstellen. Was dann bedeutet, dass ich im "Schwebetraining" beim T-Rex die halbe Akkuladung "verschenke". Mit Telemetrie fliege ich halt bis der Akku leer ist, was meine Flugzeiten bei gleicher Anzahl genutzter Akkus deutlich verlängert.

Ciao, Udo
 
Telemetrie

Telemetrie

Zitat > Ansonsten find ICH Telemetrie für mich sehr, sehr wichtig. Telemetrie bringt mir massive Vorteile bei der Flugzeit -

Eben... ich nutze den Timer praktisch gar nicht mehr, keine Gedanken ob ich nur soft oder nur stromfressend fliege - egal
Labermat sagt einfach wenn ich so viel Strom verballert habe das der Accu leer wird.

Und dito: aufs Display schaue ich nicht im Flug, die Warnungen müssen klar per Audio kommen und gut.

Daten vom Antrieb kontrollieren kann man besser mit logging, aber wenn man vorher schaut was man zusammenbaut
läufts doch eh ;-) .

Aber auch die Telemetrieskeptiker in meinem Umfeld schwenken jetzt um :D .

Gruß Bernd
 

ubit

User
Hi,

yepp. Mit der Zeit wird man halt minimalistischer bei der Nutzung speziell der Sprachansage. Wobei ich mir aktuell in der Regel beim Heli immer noch folgende Werte ansagen lasse:

  • Verbrauchte Kapazität
  • Kleinste Zellenspannung
  • Reglertemperatur

Das reicht völlig um auf der sicheren Seite zu sein beim Fliegen. Ansage habe ich beim Heli alls 60 Sekunden eingestellt. Dazu kommen dann noch Alarmwerte auf Empfängerspannung, Gesamtspannung des Akkus und Spannung beim Start des Systems (Unilog warnt mich dann, falls ich einen halbleeren Akku anstecke).

Beim Flächensegeln ist die Ansage bei mir:
  • Höhe
  • Höhengewinn (in den letzten 10 Sekunden glaub' ich)
  • Und natürlich Varioton

Warnungen auf Akkuspannung, Empfängerspannung, Höhe, kleinste Zellenspannung, Akkuspannung beim Start, Geschwindigkeit je nachdem, was ich im Modell halt an Sensoren verbaut habe.

Ich habe mich bei meinem Neueinstieg in die RC-Fliegerei ganz bewusst für Telemetrie entschieden und damit damals eigentlich nur die Wahl zwischen dem unfertigen "von einer Bastelklitsche" vertriebenen Jeti (Hacker hat das damals glaube ich noch nicht vertrieben) und M-Link gehabt. Und die Entscheidung war richtig. Heute würde ich zwar vermutlich Hott nehmen, aber das gab es damals halt noch nicht und es hat auch ein paar Nachteile.

Ciao, Udo
 
Unterbrechung bei der Datenanzeige / Keine aktuellen Werte

Unterbrechung bei der Datenanzeige / Keine aktuellen Werte

Hallo Udo !

Erst einmal Gratuliere ich Ihnen zu diesem grandiosen Projekt.
Als ich vor einigen Tagen davon hörte und Ihre Internetseite zu Ihrem Projekt duchstöberte, war ich gleich FEUER und FLAMME.
Ich habe mir sofort ein BT-Adapter für meine MPX Royal Pro 16 (von Flyduino) zugelegt und dann gings los.
Etwas ernüchternd war, daß der Adapter mit den 3,3V aus dem Tx nicht zurechtkam und ich erst mal provisorisch eine LiPo-Zelle anschließen musste.
ABER nach einigen Anfangs (Verständnis-) problemen klappte alles, dem frühen Entwicklungsstand der App angemessen: PHANTASTISCH !!!

Ich habe jedoch folgendes Problem:
Nach Aktivierung der BT-Verbindung durch die Souffleuse werden alle Telemetrie-Daten vom Empfänger einwandfrei angezeigt (und angesagt)
und auch aktualisiert. Nach einigen Minuten friert die Aktualisierung allerdings ein. Auch die DOTS die die Aktivität der Kanäle anzeigen sollten
bleiben im letzten Zustand hängen.

An der BT-Verbindung scheint es nichtzu liegen. - Wenn ich z.B. SENA BTerm verwende um den Datenstrom vom BT-Adapter zu empfangen
kann ich keine Unterbrechung des Datenstroms erkennen - da kommen auch nach 15-30 Minuten immer noch Daten an.

Ist diesen Phänomen bereits bekannt ?

Liegt es vielleicht an meinem recht preiswerten Smartphone (Simvally SP-120) ?

Weiterhin viel Erfolg bei der Weiterentwicklung.
Ich werde sicherlich jedes weitere UPDATE begeistert ausprobieren und wenn gewünscht auch einen Testbericht einstellen.

Herzliche Grüße
Werner
 

ubit

User
Hi,

das Problem kenne ich bislang nicht. Die aktuelle Version geht allerdings etwas verschwenderisch mit Ressourcen um - insbesondere auch mit dem Hauptspeicher. Kann sein, dass da einfach eine Garbage-Collection passiert und das Handy den Hauptspeicher aufräumen möchte. Das Handy hat offenbar nur 512 MB Hauptspeicher, was schon recht wenig für Android 4 ist.

Eine andere Möglichkeit wäre, dass das Handy schlicht einen Bug irgendwo in der Firmware hat. Ggf. im Zusammenhang mit der Sound- oder Sprachausgabe. Genaueres könnte ich versuchen herauszufinden, wenn ich so ein Handy hätte *g*

Möglich wäre auch eine besondere Stromsparfunktion die in dem Handy integriert ist und die irgendwann die CPU drosselt.

Auf jeden Fall mal ausprobieren, ob die Anzeige irgendwann (ggf. auch erst etliche Minuten später) vielleicht doch wieder aktualisiert wird.

Mit instaliertem Andriod SDK und dem darin enthaltenen Debugger ADB kann man während des Betriebs des Handy's auch Informationen anschauen die von der App ausgegeben werden. Ein entsprechendes Logfile könnte helfen - ist aber nicht ganz einfach das SDK/ADB ans laufen zu bekommen, da man meist noch einen zusätzlichen speziellen Treiber für das Handy braucht der bei "exotischen" Geräten nicht immer einfach zu finden ist.

Ciao, Udo
 

hiwi

User
Hi,

das Problem kenne ich bislang nicht. Die aktuelle Version geht allerdings etwas verschwenderisch mit Ressourcen um - insbesondere auch mit dem Hauptspeicher. Kann sein, dass da einfach eine Garbage-Collection passiert und das Handy den Hauptspeicher aufräumen möchte. Das Handy hat offenbar nur 512 MB Hauptspeicher, was schon recht wenig für Android 4 ist.
Das ist nicht ganz richtig. Der garbage collector arbeitet ständig im Hintergrund und sorgt auch dafür dass schlechter Programmierstil "ausgebügelt" wird.
Es ist also gut wenn er was tut :-)
Der sorglose Umgang mit Strings z.B. erzeugt reichlich garbage, der aber wahrscheinlich bei Deiner Anwendung unter 1MB / s liegt . Strings in Java sind immutable, deren instanz kann nicht verändert werden. So wird gerne sowas verwendet TextView.setText("" + IntValue) um einen Integer oder andere nicht StringTypen als String in einem Textview anzuzeigen. Das ist schlecht, aber für den garbage collector kein Problem.
Sog. memory leaks wären da schon problematischer, das ist ein häufiger Fehler bei nicht statisch instanzierten Handlern. Linklint, wenn installiert sollte allerdings warnen.
Wenn das aber das Problem wäre, müßten die anderen das Problem früher oder später auch bekommen. Ich habe die Anwendung auf einem Xperia mini laufen, das auch nur 512MB Hauptspeicher hat.
Vielleicht ist die CPU etwas überfordert. Es nutzt die Version 4.1 da ist vieles anders. Im Manifest könnte man probieren, die min und traget sdk Version beide auf 10 zu setzen, damit hatte schon einige Probleme lösen können, ohne dass die Anwendung Probleme auf 4.x machte.
Da greift der Kompatibil. Modus.

Gruss Ralf
 

ubit

User
Hi,

ich weiß, dass die Souffleuse ein (kleines) Speicherleck hat ;-) Ich weiß auch woran es liegt, aber der Umbau ist etwas aufwändiger. Dazu kommt, dass das Android ziemlich stark davon abhängig ist, was der Hersteller so am geändert/erweitert hat. Da können durchaus auch Fehler sein.

512 MB Hauptspeicher für Android 4 ist halt sehr, sehr wenig. Mein G300 hat auch so wenig und das ist ziemlich am Anschlag. Je länger es läuft, desto träger wird es außerdem - das ist bei Android aber "normal".

Um genaueres zu sehen, müsste man halt wirklich das konkrete Gerät am ADB betreiben und ggf. zusätzliche Debug-Ausgaben in das Programm einbauen. Target SDK wird auf jeden Fall nicht auf 10 runtergenommen, weil die nächste Version etliche Features der aktuellen Android-Version nutzen wird (insbesondere ActionBar-Compatibility).

Ciao, Udo
 

Gast_7088

User gesperrt
hm

hm

ich bin ja immer etwas konservativ...
HTC mit android 2.2 ;) falls da nicht wer heimlich geupdatet hat...
sollte das vielleicht auch gehn?
BT Teil hab ch jetzt werde aber wohl parallel meinem Display weiter machen....
so für on borad ( als MSB) und für an HF mdul...
 
Ansicht hell / dunkel umschalten
Oben Unten