M-Link goes Android: Betatester gesucht

Gast_7088

User gesperrt
jo

jo

Grob geplant ist die neue Version in ca. 5-6 Wochen. Ich weiß aber nicht, ob ich das tatsächlich schaffe. Hängt stark davon ab, auf welche Schwierigkeiten ich noch so stoße und wieviel Zeit ich habe.

Ciao, Udo
Das trifft sich gut ....
Ich bekomme diese Woche mein interface für den Sender, wegen update Sender ( könnte man doch mal drüber anch den das auch über Blauzahn zu tun)
dann den blauzahn einbauen ( ligt hier schon länger rum)

Was mit auf gefallen ist bei android ist, das die Sprachausgabe wohl mehr oder weniger systemimmernent Murx ist und das schmadfoon ( zumindest mein altes Wildfire) schnell an die Grenzen kommt.
Da muss eh bald neues her ( nur was)

vergrippte Grüsse
 

ubit

User
Was mit auf gefallen ist bei android ist, das die Sprachausgabe wohl mehr oder weniger systemimmernent Murx ist und das schmadfoon ( zumindest mein altes Wildfire) schnell an die Grenzen kommt.
Da muss eh bald neues her ( nur was)

Performance (auch) der Sprachausgabe hängt bei Android ziemlich am Hauptspeicher. Geräte mit 512 MB Hauptspeicher hakeln IMMER. Außerdem hängt das noch etwas von der Android-Version ab. Android 4.4 ist zum Beispiel für wenig Hauptspeicher optimiert. 4.3, 4.2 etc. sind da blöder. Android 2.3 läuft auch mit 512 MB noch einigermaßen flüssig.
Außerdem ist Android halt ein Multitasking-System. Es kann also jederzeit passieren, dass z.B. im Hintergrund E-Mails abgerufen werden. Hintergrund- und Vordergrundprozesse teilen sich dann den Speicher und den Prozessor. 512 MB und Single Core CPU kann da schnell zum Engpass werden.
Hat schon seinen Grund, warum z.B. ein Nexus 5 satte 2 GB Hauptspeicher hat. Wobei die Nexus-Smartphones mittlerweile einfach zu teuer sind und eine zu geringe Akkulaufzeit haben.
Preis-/Leistungssieger dürfte aktuell das Motorola Moto-G sein. Wenn man bei den technischen Daten darauf achtet, dass das Gerät mindestens 1 GB Hauptspeicher hat und mindestens Dual-Core, dann sollte das vernünftig laufen.
Hilfreich ist es aber auch ein möglichst "reines" Android zu verwenden. Manche Hersteller packen gerne etliche eigene Apps drauf die das System oft deutlich bremsen. Dagegen helfen dann Custom-Roms die man möglichst schnell nach dem Kauf aufspielen sollte bevor man das Gerät komplett auf seine persönlichen Bedürfnisse eingerichtet hat (später darf man sonst nochmal von vorne anfangen).

Ciao, Udo
 

Gast_7088

User gesperrt
das mit den

das mit den

Hintergrund prozessen bekommt man in den Griff.. leider ist das Ding mit allem Unfug vollgemüllt ( 1&1 branding) und root werden ist nicht ohne risikooooo :D

Das Moto gefällt ... wir brauchen eh drei neue Handy und für den Vater eine "Speed to txt software", der schreibt nur sms
weil ohne hören telefon wenig freude macht... :rolleyes:
 

Gast_7088

User gesperrt
na super

na super

also flott das fidi shield genommen mit BT Modul verdrahtet...
Binden zum Handy geht
mit mir reden will das ding ned.....

rätzels lösung
3V BT und 5V fidi :rolleyes::rolleyes::rolleyes::rolleyes:

2. Versuch mit dem MPX interface hat auch nicht geklappt....
da hat es wohl die schitte zerlegt. :cry:

Man sollte doch nicht mit Rüsselpest sowas machen vermutlich hat es sich mit dem BT modul...

also oacht immer schööön auf diepegel achten---
alle mpx intefaces arbeitet mit 3V wobei sie mit Transistoreingangs stufe arbeiten und dadurch nicht so empfindlich sind.
also neues BT interface.
 
Vario Ausgabe - altes Problem wieder neu

Vario Ausgabe - altes Problem wieder neu

Hallo,
nachdem der Winter überstanden (was man so Winter nennt!) habe ich heute einem Flugkollegen und mir die App neu installiert (Vers. 0.72). Nun tritt auf beiden Handy das gleiche Problem auf:

Die Schalter für die Vario Tonausgabe ( steigen - nullschieber - sinken ) lassen sich nicht einzeln abschalten. Optisch wird die Abschaltung im Schalter angezeigt. Schalte ich den Ton für Nullschieber aus, wird trotzdem ein Ton bei null ausgegeben (gleichmäßiges piepen!). Schalte ich zusätzlich noch den Ton für steigen aus, wird nur das Sinken akkustisch ausgegeben (so sollte es bei der Schalterstellung auch sein). Steigen und null ergeben keine Tonausgabe. :confused:
Zusätzlich lassen sich die einzelnen Lautstärken für die Töne >sinken - null - steigen< nicht einzel regulieren. Die Lautstärke der Töne bleiben immer gleich laut.:(

Ich meine mich zu erinnern, daß das im letzten Jahr funktioniert hat (zumindest bei mir, aber da hatte ich eine andere Firmware auf dem Handy!) Bei dem Vereinskamerad war die App noch nie installiert. Sein System ist quasi jungfräulich.
Kann es sein , das ich eine Einstellung in der App oder in der Systemeinstellungen des Handys übersehen habe?
Hat noch jemand das Problem?

Vielen Dank für die Hilfe

maikatze
 
Einen Fehler gefunden

Einen Fehler gefunden

Hallo
ich habe einen Fehler gefunden . Die Schwelle für das Steigen war auf 0 eingestellt . Ich habe also immer den Ton n für Steigen gehört . Wozu die Fahrt zur Arbeit alles taugt.
 

Puschi

User
Hi,

gestern einen längeren Thermikflug gemacht und dabei das Vario nutzen
wollen mit Souffleuse V0.72 alpha.

Der Vario-Ton war leider nur für ca. eine halbe Sekunde oder Sekunde zu hören
und verstummt dann.
Im Vario-Test Modus, aber auch über Aktivierung des Vario über einen Schalter das gleiche Verhalten.
Bei jeder Schalteraktivierung ist der Varioton sehr kurz hörbar und verstummt dann.
Sprachansagen laufen aber korrekt.

Auf dem Samsung S2 (Modell GT-I9100) hab ich das ROM CyanogenMod 11 (M4
Snapshot aus dem März) basierend auf Android Kitkat 4.4.2 laufen.

Ich hab nun gestern abend testweise ein anderes CustomROM installiert
(BeanStalk das ebenfalls auf Android 4.4.2 basiert).
Auch hier geht der Varioton nicht.

Danach hab ich das StockROM von Samsung geflasht, in diesem Fall Android 4.1.2.
Dort lief Souffleuse dann korrekt und der Varioton war im Testmodus und auch per Schalter sauber und konstant
hörbar.


Insofern die folgenden Frage:
- Ist Souffleuse V0.72alpha die aktuellste Version?
- Betreibt jemand von euch Souffleuse auf Android 4.4.2 und der Vario-Ton funktioniert korrekt?
- Ist dies evtl. ein generelles Problem mit Android 4.4.2 (KitKat) oder muss ich eher nach einem lokalen Problem mit irgendeiner SoundEngine suchen?

Gruß
Andreas
 

ubit

User
Yepp. 0.72alpha ist aktuell.

Mit Android 4.4 geht das Vario nicht. Sorry. Nächste Version wird das wieder klappen. Kann aber noch ne Weile dauern.

Ciao, Udo
 

Puschi

User
Hi,

eine Frage zum M-Link Protokoll (nicht direkt Souffleuse), aber mit dem Ziel öfter ein Varioupdate zu bekommen.

Laut den öffentlich zugänglichen Quellen sendet das M-Link-Verfahren immer 5 Uplink-Frames und dann 1 Downlink-Frame.
Nach jedem Frame gibt es ein Kanalwechsel (Frequenzwechsel).
Die Uplink-Frames haben ohne aktiviertem Fast Response eine Länge von 21ms und mit aktiviertem Fast Reponse eine Länge von 14ms.

Das bedeutet doch, daß bei aktiviertem Fast Response in 1 Sekunde öfters ein Downlinkframe gesendet wird, als ohne FastResponse.
Falls dies Regel immer gilt, daß 5 Up und 1 Down gesendet wird.
Daher mit aktiven PRIO für den Vario-Sensor würde ich ohne FastResponse ca 9-10 Variowerte pro Sekunde am Sender bekommen.
Mit aktivem FastResponse rein rechnerisch 13-14 Variowerte pro Sekunde.

Hat das schon mal jemand überprüft, ob dem so ist?
Ist evtl. nicht wirklich relevant, aber technisch interessiert es mich, ob es denn so ist. Und für diejenigen, die das letzte Quentchen an
Schnelligkeit auf dem Downlink rausholen wollen, vielleicht auch.
Kann man dies evtl. dann an der Schnittstelle des HFM-Modul messen?

(Quelle Modell-Zeitschrift 2/2010 Artikel von Karl-Heinz Keufner "Markreif: Vorstellung 2,4-GHz-M-Link-Verfahren von Multiplex").

Gruß
Andreas
 

Puschi

User
Hi,

vielleicht ist die Antwort, daß, selbst wenn es technisch bei M-Link mit Fast Response so läuft, der MSB gar nicht alle 70ms (5 Up-Frames*14ms) neue Variodaten vorlegen kann.

Der MSB fragt alle 6ms eine Sensoradresse ab und da er ja die Runde über alle 16 möglichen Sensoradressen macht, liegen ja für das Vario nur alle 96ms ein neuer Wert am Empfänger vor, damit könnte die mögliche Downlinktaktrate von 70ms auf M-Link gar nicht bedient werden.

Hm...

Gruß Andreas
 
Prio

Prio

.. müsste man mal schaun wie er die PrioSensoradresse realisiert.

Prio macht ja nur Sinn wenn er den Priosensor am MSB öfter anpollt als die anderen.

´Glaube aber das dieses auch irgendwo dokumentiert ist.
( Oder ubit und andere das eh genau wissen :D )

´Les das aber nur mit, da bei meinen Hubschraubern Vario echt nervt :eek: .

Frohe Ostern !

Bernd
 

Puschi

User
Hi,

pro Downlink-Frame werden 2 Sensorwerte bei M-LINK übertragen. Daher ohne PRIO bei 16 belegten Sensorwertadressen sind nach 8 Downlink-Frames alle Werte einmal an der Fernsteuerung aktualisiert
(Vorausgesetzt es sind keine Frames aufgrund von Funkstörungen verlorengegangen).

Seit der Empfängerfirmware 1.20 kann man eine PRIO Sensorwertadresse definieren. Diese wird dann jeden Downlinkframe übertragen. Das bedeutet aber auch, das pro Downlink-Frame nur noch jeweils 1 weitere Sensorwert mitgeschickt werden kann. Die anderen 15 Sensorwerte werden dadurch an der Fernsteuerung nicht mehr so oft aktualisiert.

Für die Empfängerfirmware 1.26 gibt es den Hinweis, daß der Telemetrierückkanal verbessert wurde und leere Sensorwerte nicht mehr übertragen werden.
Daher wird es wohl so sein, daß die Sensorwerte öfter über M-LINK an der Fernsteuerung aktualisiert werden können, vorausgesetzt man hat nicht alle Sensorwertadressen belegt.

In dem von mir zitierten Zeitungsartikel wird im Endeffekt die Aussage gemacht, daß bei aktivem Fast Response die Frames in einem schnelleren Takt geschickt werden.
Daher meine (theoretische/technische) Frage, ob das jemand schon mal irgendwie nachgemessen/geprüft hat, ob bei FastResponse tatsächlich die Downlinkframes in einem
schnelleren Takt bei der Fernsteuerung eintreffen. Wobei in einem Werbeprospekt zu M-LINK von Multiplex drin steht, daß diese schnelle Taktung nur bei der RoyalPro 9 und RoyalPro 12 erfolgt.
Die RoyalPro 16 ist dort ausgenommen, ich vermute bei der schnellen Taktung können sonst nicht mehr alle 16 Kanäle übertragen werden.

Für diejenigen, die gerne das letze Millisekündchen herausholen wollen (z.B. beim Vario) wäre das sicher interessant. Im Endeffekt wäre dann für eine super schnelle Übertragung die folgenden Einstellungen zu machen:
- Fast Response aktiv
- PRIO Kanal gesetzt
- Und möglichst wenig Sensorwertadressen belegen, damit die restlichen nicht PRIO-Sensorwerte auch weiterhin nicht zu sehr ins Hintertreffen geraten.

PRIO im Empfänger ändert m.E. nicht das Polling auf dem MSB.
Rein theoretisch fragt der Empfänger alle 6ms einen Sensortwertadresse ab.
Daher nach 16* 6ms gehts wieder von vorne los.Oder hat jemand andere Erkenntnisse dazu?

Gerade von einem schönen 45min Thermikflug mit dem MPX Sozius zurückgekehrt :-)
Frohe Ostern!

Gruß
Andreas
 

Puschi

User
Hi,
gestern mal mit meinem Scanner die Downlinkburst und Uplinkburst pro Datenframe nachgemessen.
Jeweils mit FastRespone ON und OFF.

Es ist also tatsächlich so, daß bei aktivem FastResponse pro Datenframe nur 2 Datenburst je 4ms (8ms Kanalbelegung, 14ms Datenframelänge/Servoimpuls) gesendet werden. Bei deaktivem FastResponse hat ein Datenframe 3 Datenburst je 4ms (12ms Kanalbelegung, 21ms Datenframelänge/Servoimpuls).

[An dieser Stelle vielleicht noch der Hinweis das FastResponse für 16 Kanalbetrieb nicht genutzt werden kann. Nur für 12 Kanal oder weniger.]

Bei aktivem FastResponse kommen daher alle 70ms ein Downlinkframe (mit 2 Sensorwerten) am Sender an. Bei deaktivem FastResponse alle 106ms.

Der MSB liefert nur alle 96ms ein Update pro Sensorwert an den Empfänger. Der schnellere Downlink bei aktivem FastResponse hat aber den Vorteil, daß bei Nutzung des Vario mit aktiviertem PRIO, die übrigen Sensorwerte etwas schneller am Sender ankommen. Vorrausgesetzt man belegt nicht alle 16 Sensorwerte.

z.B. bei 6 genutzen Sensorwerte hat man dann für das Vario ~10 Updates pro Sekunde und die restlichen 5 Sensorwerte ~3mal pro Sekunde refresht. Ist ja besser als die restlichen Werte nur alle 1,5 Sekunden geupdatet zu bekommen.

Vielleicht interessant für diejeniegen, die das letzte Millisekündchen herausholen wollen.

Gruß
Andreas
 
Zuletzt bearbeitet:
Simprop GigaBlueCard Nutzer ohne Varioton

Simprop GigaBlueCard Nutzer ohne Varioton

Hallo Udo,

zuerst einmal auch von mir ein herzliches Dankeschön für diese tolle App und deinen enormen Aufwand.

Ich bin erst vor 3 Tagen auf Deine HP und diesen Thread gestossen. Nach nur 2 Tagen ist es mir gelungen, alle Sensorwerte des Gigascan Vario und des Unisens-E von SM auf das Display zu bekommen.

Wie aber schon vorher bemerkt, funktioniert die Bedienung über die Kanäle beim Simprop leider nicht. Die Sprachausgabe/Vario kann auch nicht per "AN" Aktion aktiviert werden. Vario Test, Begrüßung usw. werde aber über die TTS wiedergegeben. Seltsamerweise werden die Sensorwerte ausgegeben, wenn ich im Empfänger die Alarmfunktion entsprechend setze. Dann "babbelt" das Mobile wie ein Wasserfall.

Vielleicht hilft dir der Hinweis, falls Du überhaupt nocht etwas an der App machst, um in diesem Punkt weiterzukommen. Morgen werde ich mal versuchen, über intelligente Programmierung des Empfängers eine halbwegs vernünftige Ausgabe zu schaffen.

Bei der Simprop App geht mir das permanente Statusmelden ("Datenverbindung verloren" / "Datenverbindung wieder hergestellt") auf die Nerven, was alle 2-3 Sekunden kommt. Das nervt und lässt sich nicht abstellen.

Also nochmals ein Lob und ein Dankeschön an dich,

Roland.
 

ubit

User
Aktueller Status

Aktueller Status

Hi zusammen,

ich lebe noch *g* Leider fehlt mir die Zeit allzu viel zu programmieren. Trotzdem geht es langsam aber sicher weiter. Hier mal der aktuelle Status:

Seit Android Kit Kat funktioniert das Vario nicht mehr. Letzte Woche habe ich endlich herausgefunden warum... Die nächste Souffleuse wird also wieder ein funktionierendes Vario bekommen *g* Google hat still und heimlich und völlig undokumentiert das Verhalten des Audiosystems an einer kleinen aber entscheidenden Stelle geändert...

Außerdem habe ich in den letzten Wochen das gesamte Ereignis/Aktionssystem zum 1001. Mal überarbeitet und habe jetzt endlich einen Stand mit dem ich zufrieden bin. Die "Events" werden verschwinden. Stattdessen wird man Bedingungen und Aktionen haben. Bedingungen sind dabei z.B.:

Kanal geht von Min auf Max
Sensor Alarm geht an
Sensor Alarm IST an
Sensorwert in einem bestimmten Intervall (also z.B. Geschwindigkeit zwischen 0 und 30 km/h)
Neuer Maximalwert vom Sender
und etliche mehr...

Wenn (und solange) eine Bedingung erfüllt ist, wird die entsprechende Aktion aktiv. Manche Bedingungen sind dabei nur kurz aktiv (z.B. Sensor Alarm geht an, Kanal schaltet). Andere können für eine längere Zeit aktiv bleiben (z.B. Sensorwert in einem Intervall oder Kanal ist auf Max). Für jede Aktion die man einstellt kann man eine Zeitspanne angeben nach der sie wiederholt wird. Das funktioniert natürlich nur bei "langen" Bedingungen. Man kann also z.B. folgendes Einstellen:

WENN Geschwindigkeit zwischen 0 und 30 km/h, DANN sage alle 5 Sekunden die Geschwindigkeit und die Höhe an.
WENN die Akkukapazität zwischen 1000 und 5000 mAh beträgt, DANN sage die Kapazität alle 60 Sekunden an
WENN die Akkukapazität zwischen 0 und 999 mAh beträgt, DANN sage die Kapazität alle 10 Sekunden an
WENN Kanal 10 auf Max ist, DANN sage die Höhe alle 30 Sekunden an
WENN Timer 60 Sekunden, DANN sage alle Sensordaten an

Timerbedingungen können dabei beliebige Intervalle (in Sekunden) haben. Die Widerholung bei "langen Bedingungen" kann Intervalle von 0 Sekunden (Ansage so schnell wie möglich) ebenfalls in Sekundenschritten haben.

Weitere Features an denen ich in letzter Zeit gearbeitet habe:

Ermittlung von Maximal- und Minimalwerten der Sensoren. Beide Werte gibt es zweimal: Absolute Maximal- und Minimalwerte seit Verbindungsaufbau sind "normal". Zusätzlich gibt es lokale Min/Max-Werte. Mit diesen lokalen Min/Max-Werte kann man z.B. beim HLG die Wurfhöhe ermitteln (und ansagen lassen) oder beim herumheizen die maximale Geschwindigkeit - ohne zwischendurch manuell die Min/Max-Werte zurücksetzen zu müssen.

Außerdem wird die Begrenzung auf 16 Sensoradressen teilweise aufgehoben. Das könnte für Eigenbau-Sensoren interessant sein. Wenn ein Sensor nun z.B. abwechselnd die Spannung in Volt und die Stromaufnahme in Ampere misst und überträgt, so wird Souffleuse das als ZWEI getrennte Sensoren behandeln. Wenn man entsprechende Sensoren entwickelt, lassen sich auf diese Weise mehrere "unwichtigere Daten" mit geringer Updatefrequenz auf einer einzigen Sensoradresse übertragen. Einzige Voraussetzung dazu ist, dass unterschiedliche Sensorklassen (Maßeinheiten) genutzt werden. Das Senderdisplay zeigt die Werte dann halt abwechselnd an - die Souffleuse kann die Werte gleichzeitig anzeigen und mit unterschiedlichen Aktionen verknüpfen.

Das Ganze funktioniert in meiner Testversion mittlerweile endlich gut und zuverlässig. Diese Testversion hat allerdings momentan keine wirkliche Benutzeroberfläche und keine Datenbank. Da muss ich jetzt noch einige Arbeit reinstecken, damit das Ganze wieder "normal" bedienbar wird. Zum Testen programmiere ich momentan meine Bedingungen und Aktionen im Quellcode rein :-(

So - das wär's erstmal von mir als kurzes Lebenszeichen. Wird leider noch eine Weile dauern bis es eine neue öffentliche Version geben wird. Warten lohnt aber. Versprochen *g*

Ciao, Udo
 

Gast_7088

User gesperrt
ok dann muss ich

ok dann muss ich

wohl mir jetzt endlich ein neuen BT interface besorgen ( das alte hat die 5 V signale von meinem adruino nicht so ab gekonnt)
und neues Handy ist auch fällig
die empfehlung moto g ist gut, ich habe es mir gestern an geschaut.... taugt auch als Handy

Die Überarbeitung ist super ....
 
Lästermodus an

Lästermodus an

Jan... mach doch einfach - sonst schick ich dir mein BT Modul mit der Auflage dir innerhalb 2 Wochen ein eigenes zu holen
um mir meines zurückzuschicken nachdem du merkst das es einfach funktioniert :D .

Ich brauch das aktuell ja nicht mehr ( weil wstech und jetzt eh PTX ) - das BT Modul hatte ich ja mal wegen VSTabi geholt.
( Und dafür wird es auch AB UND ZU mal genutzt )

@ ubit - cool Work !

Bernd
 

Gast_7088

User gesperrt
boahhhh

boahhhh

ich habe auch noch ein paar andere Baustellen....
smilie_sax_.gif



smilie_ga_010.gif
 

Horbi

User
Hallo zusammen,

ist das das richtige BT-Modul für meine MPX Royal pro 9 : http://flyduino.net/Serial-Bluetooth-Adapter-PlugnPlay-fuer-Android-App

Gruß
Horst

Habe gerade festgestellt, dass bei mir in der Royal auf dem HFM4 M-Link-Modul der kleine Aufkleber Pus/Minus/Signal fehlt, da bin ich hardwaremäßig wohl nicht auf dem neuesten Stand und kann das mit der Souffleuse wohl vergessen.
 
Doch das geht...

Doch das geht...

Das Modul kann bei MPX ein Hardwareupdate bekommen.

Mit etwas Knew How kann man das auch selber durchführen.

( Das ist aber nur was für Leute die davon genug verstehen )

Doku dazu gabs hier glaub ich schon mal.

In der Praxis würde ich aber zum Souffleur von MPX tendieren, da musst du nichts
umbauen, und die Lebensdauer eines Smartphone liegt wohl unter der des Souffleur.

ABER Ubit´s Souffleuse ist ein tolles Projekt !


Gruß Bernd
 
Ansicht hell / dunkel umschalten
Oben Unten