Stabilität => 1066-1071

Hallo alle zusammen,

Da sich in letzter Zeit immer wieder Mails in meinem Postfach befinden, wo es um Einfrieren von CB oder den Absturz geht, habe ich versucht diese Informationen zu Bündeln und Auszuwerten.

Dabei ist mir aufgefallen, dass viele Abstürze erst im Feld passieren.

Was mich auf das GPS bringt.

Auch das Problem mit dem Aktualisieren der WP auf der Map könnte damit zusammen hängen.

HinterGrund:

Kommt ein GPS-Signal wird eine Liste abgearbeitet, welche, unteranderem einige Listen für die Bearbeitung sperrt. So wird die Liste der WegPunkte gesperrt, damit die Abstände neu berechnet werden.

Da ich keine Fehler diesbezüglich habe, gehe ich davon aus, dass auf Geräten, welche nicht so schnell Rechnen, das Sperren dieser Listen länger dauert, als die Zeit bis ein neues GPS-Signal kommt.

Damit bleiben die Listen eigentlich immer gesperrt.
Ich habe deshalb eine Settings Variable GpsUpdateTime eingebaut, mit der Ihr die Update Intervalle einstellen könnt (in ms [1000 = 1s]).

Diese Einstellung wird aber erst nach einem Neustart von ACB angewandt.

Um zu Kontrollieren wie lange die Abarbeitung der GPS-Liste dauert, habe ich in den Settings-DebugInfo ein Feld eingefügt, welches euch diesen Wert anzeigt.

Angezeigt wird der Maximale Wert innerhalb der Laufzeit. Die Abarbeitung der Listen sollte in der CacheList und der MapView am längsten sein.



Und damit kommen wir zum nächsten Punkt.

Die Settings werden gerade auf OpenGL umgebaut, ich bin zwar noch nicht fertig, aber es wird schon die neue Ansicht angezeigt. Damit ihr aber auch Zugriff auf alle Settings habt, habe ich in den GL-Settings einen Button „Alt Settings“ eingebaut.
Mit diesem könnt ihr die alte noch funktionstüchtige Settings Ansicht aufrufen.
Nur so zur Sicherheit.

Wenn ihr also auch zu denjenigen gehört, die Probleme haben, würde ich euch bitten diesen Wert zu verändern und zu testen, ob es besser wird.

Wahrscheinlich kann man hiermit auch eine bessere Akku-Laufzeit erreichen.
(Weniger GPS-Signale= weniger Rechen aufgaben).


Die Rev 1067 liegt in der DropBox!


Gruß Andre

PS.
Bei mir liegt die GPS Thread Time bei 76ms im Energiesparmodus des Handys.

Deshalb habe ich den Defaultwert auf 100ms gestellt. Ich denke aber dass ein GPS-Signal alle 300ms Volkommen ausreichend wäre!

Hi Andre

super, werde ich gleich morgen vormittag mal testen.
Bei meinen Abstürzen war aber immer seltsamerweise plötzlich mein Firefox aktiviert. So, wie wenn ich ein Cache Status Update laden wollte. Weitere Abstürze kamen gelegentlich wenn Cachebox versucht hatte Verbindung mit Geocaching.com aufzunehmen und kein gutes Signal zur Verfügung stand. Vielleicht ist das Timeout zu kurz oder ähnliches.

Gruß Wolli

Longri schrieb:

...
Deshalb habe ich den Defaultwert auf 100ms gestellt. Ich denke aber dass ein GPS-Signal alle 300ms Volkommen ausreichend wäre!

Zum Vergrößern anklicken....

Das meine ich auch. auch 500ms oder gar 1s sollten prinzipiell ausreichen.
Klar, wenn man genau nach einem "tick" die Richtung wechselt, wird das "erst" nach 500ms oder 1 Sekunde sichtbar aber wir rennen ja auch nicht mit 100km/h durch den Wald.

Eine Sache habe ich aber technisch nicht verstanden:
Es wird tatsächlich nach jedem GPS-Signalrefresh jeweils die Entfernung etc. in den Listen neu berechnet?
Oder nur falls ich auch in der Listensicht bin und dann auch nur für die 20 oder 30 Caches in der Umgebung?
Nicht falsch verstehen, ich finde es ja toll, dass das so flott funktioniert, könnte mir aber auch vostellen, dass das dann auf die Dauer an die CPU geht und somit an den Akku?

Nein natürlich nicht, aber dann gehe ich mal ein wenig ins Detail.

Eine View (CacheList, Map ,Kompass ….) hat jeweils zwei Methoden onShow und onHide.
Diese werden automatisch aufgerufen, wenn eine View sichtbar wird oder wenn sie wieder verschwindet.

In diesen Methoden melden sich die Views zum Empfang des GPS Signals an oder eben wieder ab.

Es gibt eine unsichtbare View, welche alle GPS Signale empfängt, diese überprüft aber nur die Aktuelle Distanz zum gewählten Weg Punkt um gegebenen Falls das Annäherungs Signal abzuspielen.

Bei der Automatischen Sortierung, gibt es schon etwas mehr zu tun. Hier werden die Distanzen der ersten 50 Caches aktualisiert und wenn sich hier eine Abwechslung in der Reihenfolge ergeben hat, wird die Gesamte CacheList neu Sortiert und alle Distanzen neu berechnet.

Morgen werde ich dann noch einbauen, das, wenn das Display ausgeschalten wird, nur noch die Distanzen für das Annäherung Signal angesprochen wird, alle anderen Views brauchen das GPS Signal dann nicht mehr. (Da wo das Annäherungs Signal berechnet wird, sitzt auch die Track-Aufzeichnung, diese wird, wenn sie läuft immer eine GPS-Signal empfangen)

Gruß Andre

Longri schrieb:

... Ich denke aber dass ein GPS-Signal alle 300ms Volkommen ausreichend wäre!

Zum Vergrößern anklicken....

Zu WinMob Zeiten kam von der GPS-Maus jede Sekunde ein NMEA String, ich könnte mich nicht daran erinnern im Feld jemals eine schnellere Reaktion gebraucht zu haben

Gruß, André

Hallo und danke für die 1066.
Gibt es eigentlich irgendwo eine changelog?

Nur das SVN auf SourcrForge.

Ist ja auch noch nicht fertig.

SVN?

Homer-S schrieb:

SVN?

Zum Vergrößern anklicken....

SVN=Subversion, so nennen die Programmierer "Testversionen".

Subversion war richtig, aber die Beschreibung nicht ganz

http://de.wikipedia.org/wiki/Apache_Subversion


Jede, oder fast jede Änderung bekommt hier ein Kommentar!

Heute als Beispiel. => http://droidcachebox.svn.sourceforge.net/viewvc/droidcachebox?revision=1066&view=revision
+ fix ImageButton rotation
+ delete Image from Button => use Image Button
+ add PositionCalltime to DebugInfo
+ add GPS update time settings
+ change to GL-Settings with Button for Android Settings
+ fix CacheList.update() returns if LastPoint Null
+ fix IndexOutOfBoundsException at TextField with text is empty
+ fix parsing error at NumerickInputBox

Ja, ich schau immer gerne auch mal zwischendurch in den SVN browser.
Mit klick auf den Link einer Versionsnummer bekommt man dann auch eine Liste aller Änderungen, nach Version absteigend sortiert.

GPS hatte ich auch im Verdacht, allerdings nutze ich kein GPS auf dem Tablet - zieht mir zuviel Strom - ich nutze das Teil als mobile Datenbank und alles was mit Navigieren zu tun hat, macht das Etrex. Ist außerdem genauer und schneller als mein Tablet. Reagiert ACB empfindlich auf abgeschaltetes GPS? Ich dachte aber auch eher ans WLAN was draußen fehlt oder ans fehlende UMTS/GSM Netz.
Mit ohne WLAN (an Fritz abgeschaltet) gehts zu Hause aber auch, da ist aber auch noch GSM. Wenn nun beides fehlt...? Werds am Wochenende wissen

viele Grüße und danke für die 1066
Holger

Ich habe noch einmal ein paar Messungen gemacht und dabei Festgestellt, dass die Events im Minimum im 6 ms Abstand kommen.

Und bei ausgeschaltetem GPS lag der Wert bei 229 ms, wobei hier dann der Magnetische Kompass die Ursache ist.
Dieser liefert zwar keine Position aber einen Richtungswert, welchen wir auf die letzte bekante Position legen und dann durchreichen.

Ich kann mir zwar nicht erklären, wie das GPS auf die Idee kommt eine Position im 6 ms Abstand zu schicken, aber das ist definitive zu kurz.

Ich habe den Test jetzt mehrfach wiederholt und das Minimum waren 6ms, wobei ich auch schon bei unter 50 ms ein Problem sehe und dies hatte ich bei allen Tests mit eingeschaltetem GPS.

Desweiteren habe ich mal gemessen, wie die Durchlaufzeit mit Track Aufzeichnung ist.
Diese hat sich deutlich erhöht, ja sogar fast verdoppelt und liegt jetzt bei 126 ms.

Sodas ich den Default Wert für die Update Time auf 150 ms erhöhen werde.

Gruß Andre

Longri schrieb:

...
Sodas ich den Default Wert für die Update Time auf 150 ms erhöhen werde.

Gruß Andre

Zum Vergrößern anklicken....

Hochinteressant, darauf wäre ich nie gekommen dass die Geräte hier die Position so schnell hintereinander aktualisieren.

Meiner Meinung nach könnte der Default Wert gerne auch auf 1000 ms erhöht werden. Ich gehe meistens mit externer BT-Maus cachen und die sendet ja sowieso nur 1 Position jede Sekunde.

Ich muss da direkt mal testen, wie sich diese Aktualisierungsrate mit der externen BT-Maus verhält.

Ging-Buh schrieb:

Meiner Meinung nach könnte der Default Wert gerne auch auf 1000 ms erhöht werden.

Zum Vergrößern anklicken....

Bei 1000 ms sollten wir dann aber noch trennen zwischen Position und Richtung.

Das Karte drehen im Sekunden Takt sieht bestimmt sehr abgehackt aus.

Aber man hätte evtl., falls das technisch machbar wäre, die Möglichkeit die GPS-Position und vor allem die Richtung besser zu glätten...
Also aus den letzten Werten, die aus dem GPS kommen, jeweils über mehrere Messungen hinweg dann gleitend einen Durchschnitt zu berechnen? Vielleicht wird das ja in Cachebox schon gemacht, man könnte dann aber eben noch mehr Positionsmessungen dafür heranziehen.
Wie gesagt, bei abrupten Richtungsänderungen mit hoher Geschwindigkeit wäre das dann etwas "nachziehend".... Aber bei Geocachen doch allermeist eher von Vorteil.

Longri schrieb:

Ging-Buh schrieb:

Meiner Meinung nach könnte der Default Wert gerne auch auf 1000 ms erhöht werden.

Zum Vergrößern anklicken....

Bei 1000 ms sollten wir dann aber noch trennen zwischen Position und Richtung.

Das Karte drehen im Sekunden Takt sieht bestimmt sehr abgehackt aus.

Zum Vergrößern anklicken....

Ich habe den Wert bei mir testweise auf 1000 ms gesetzt, da meine Karte mit Kompaßausrichtung bis dato mir zu unruhig war. Ja es ist etwas abgehakt, eben nicht kontinuierlich. Dafür dreht die Karte auch nicht mal schnell 20° nach links weil die GPS-Position meinte sie müsse einen Hüpfer machen und dann wieder zurück, obwohl ich geradeaus laufe. Imho beruhigt die Möglichkeit mit 1000 ms die Karte - die macht jetzt keinen Eiertanz mehr.
Was ich nicht ganz verstehe ist wieso die GPS-Position öfter als 1x Sek. erneuert werden sollte, das alte NMEA 0183 Protokoll kennt nur 1 Hz. Oder wurde das inzwischen aufgebohrt? Techniken mit 5Hz oder mehr kenne ich nur für Lösungen aus Wissenschaft und Sport - macht imho zum cachen auch keinen Sinn.

Da ich auch von Abstürzen geplagt bin, habe ich gerade auch schon mal etwas getestet (GalaxyS). Habe die Einstellung auf 1000ms gestellt.

1. Versuch mit internen GPS im Auto und CarMode für ca. 20 Minuten: so wie es sein soll. Habe anschließend die Rate ausgelesen: 449

2. Versuch zu Hause mit BT-Maus und angeschlossenem Stromkabel. Was auffiel war, dass trotz Stromkabel offensichtlich Akkuleistung verbraucht wurde. Nicht viel, aber es ging in ca 15 Minuten 1% runter. Das hab ich vorher noch nie gesehen... Nach ca 15 Minuten wurde der Kartenaufbau träge und es folgte der ernüchternde Absturz Der Handy Startbildschirm zeigte sich kurz, dann folgte ein Reboot. Die Rate zeigte zwischendurch etwas über 800ms an.

Feldeinsatz steht noch aus, ich hoffe, dass ich am Wochenende Zeit finde.

Gruss
Heiko

Hi
Heute wie angekündigt die Version 1066 getestet.
Folgendes ist aufgefallen. Nach Eingebabe der Fiednotes kommt anschließend wieder das Auswahlmenue zur Eingabe der Fieldnotes "Nicht gefunden, Bedarf Wartung, Schreib Notiz...."
Der Bug ist wie ich eben sehe in Version 1067 nicht mehr vorhanden.

11 Cache habe ich heute mit der Version 1066 gefunden. Bei einer Eingabe einer Fieldnotes ist CB abgestürzt. War dabei in einer offenen Wanderhütte. Nach dem Neustart von Cachebox zeigte der Positionspfeil ca 150 Meter Entfernung an. Dies scheint darauf hinzuweisen,dass der Absturz tatsächlich was mit dem GPS Signal zu tun hat.

Gruß Wolli

Das was wolli über die Fieldnotes gschrieben hat ist bei mri auch (1066) zusätzlicvh ist es nicht möglicjh die Fildnotes zu verwalten, also nicht hochladen.

Ich teste nachher die 1067 ...