Ja, hatte ich gemacht. Nun habe ich die Batterie gewechselt. Und jetzt noch mehrfach ausprobiert. Weder Kalibrierung geht, noch bekomme ich Messwerte.

_________________
Meine Seite "Wer nicht tanzt, erkennt nicht, was sich begibt." ActJoh 95
Mit Töchterlein seit 04/15. Wieder freestylekurvend.

Was wäre denn das Symptom, wenn der Sensor nicht richtig angelötet wäre. Würde ich dann Daten bekommen? Drei Messwerte hatte ich schon mal, aber gerade geht gar nichts.

_________________
Meine Seite "Wer nicht tanzt, erkennt nicht, was sich begibt." ActJoh 95
Mit Töchterlein seit 04/15. Wieder freestylekurvend.

Das kommt darauf an, wo die fehlerhafte Verbindung liegt. Vielleicht mal auf den quadratischen Chip drücken beim Starten. Bis zum erwarteten ersten Messwert. Aber zwei mal gescannt hast Du?

Ja, das hatte ich nun verstanden.

_________________
Meine Seite "Wer nicht tanzt, erkennt nicht, was sich begibt." ActJoh 95
Mit Töchterlein seit 04/15. Wieder freestylekurvend.

Du kannst mir den Sensor zusenden, dann gucke ich mir Deine Chiplötung an.

Vielen Dank für deine Antwort, rbca! Dann hoffe ich, dass eine neue Batterie bei mir die Probleme löst. Vielleicht hat noch eine passende da, ansonsten bestelle ich mal eine (kennt ihr günstige Bezugsquellen?).

Beruhigend, dass das Batterieproblem auch die unterschiedlichen Missionsuhrzeiten erklärt. Vielleicht schaffe ich es mal, die Berechnung so anzupassen, wie du es vorgeschlagen hast. Ich will aber mit meinem Halbwissen auch nicht zu sehr in der App rumpfuschen.

Da ich beim iButton immer den Mittelwert der drei tiefsten Werte einer Nacht nehme, habe ich schon Ideen im Kopf, so was in der App auch zu ermöglichen. Der erste Schritt wäre, dass man die Werte nach Temperatur sortiert ausgeben kann (wobei man dann auch noch nach dem Tag trennen müsste, falls man über mehrere Tage am Stück misst) und vielleicht, dass man entscheiden kann, ob auf 0,05°C gerundet wird oder nicht, denn wenn man mehrere Werte mittelt, rundet man ja besser danach.
Aber dazu muss ich es erstmal hinkriegen, ohne große Java-Kenntnisse das zweidimensionale Array nach der Temperatur zu sortieren.

Ich hoffe, ihr habt bald wieder Internet, solche Geschichten sind ja echt nervig.
Und beim Still-Nichtzyklus kann ich mich anschließen , ich glaube (hoffe) aber, dass sich bei mir demnächst wieder was tut.

_________________
Mama von L. (11/2014) und J. (2/2017).
NFP per Trackle, aber aktuell zu faul zum Übertragen in myNFP.

Juhu, mit neuer Batterie geht's!
Die, die noch hatte, war aber schon weiß angelaufen, ich bestelle mir doch lieber noch eine neue.

_________________
Mama von L. (11/2014) und J. (2/2017).
NFP per Trackle, aber aktuell zu faul zum Übertragen in myNFP.

Juhu, ich habe in den letzten Tagen ein bisschen was an der App angepasst.
Leider habe ich Probleme beim Pushen (Hochladen) der Änderungen auf GitHub, weil anscheinend Berechtigungen fehlen - dazu habe ich dir eine PN geschrieben, rbca.
Wer schon Interesse an der neuen Version hat, kann sich die apk-Datei aus meiner Dropbox herunterladen: *klick*.

Folgende Änderungen habe ich vorgenommen:

1. Die App hat jetzt ein eigenes Icon (das bisher benutzte Android-Männchen ist das Standardicon, wenn man keines festlegt). Es ist aber nur ein Foto des Sensors, da darf gerne jemand was Hübscheres basteln, vielleicht mit einer schicken Temperatur-Nachtkurve oder so.
2. Da ich gerne mehrere Werte einer Nacht mittle, gibt es nun einen Schalter, mit dem man auswählen kann, ob die App die Werte schon auf 0,05°C rundet, oder ob sie sie ungerundet anzeigt (nach Umstellen des Schalters muss man nochmal auf "Auslesen" klicken, damit die Werte angepasst werden).
3. Für den unerwarteten Abbruch einer Mission habe ich rbcas Vorschlag eingebaut, so dass die Messuhrzeiten (die mich ja in meinem Post hier mit den Screenshots neulich sehr verwirrt hatten) bei Abweichungen von 10% oder mehr wieder genauso ermittelt werden wie bei weniger als 10 Werten. Die Uhrzeiten verrutschen also in dem Fall nicht mehr. Testen konnte ich das aber noch nicht, dazu muss meine Batterie erstmal wieder anfangen zu schwächeln.
4. Bei der Kalibration kann man jetzt auch Dezimalzahlen (mit Punkt als Trennzeichen, z.B. 5.3) eingeben. Was ich nicht lösen konnte: lässt man beide Felder leer und versucht, die Kalibration zu setzen, stürzt die App weiterhin ab.
5. Und jetzt kommt das Allerbeste: Man kann sämtliche Messwerte in die Zwischenablage kopieren! Das heißt, man kann sie sich selbst per E-Mail schicken, in einen Texteditor einfügen, was auch immer man will.
   Was für mich am besten funktioniert: Werte per Mail an mich selbst schicken, dann am PC aus der Mail kopieren, in den Windows-Editor einfügen, von da wieder kopieren und in Excel einfügen. Durch diesen Zwischenschritt schlägt Excel dann vor, den Textkonvertierungs-Assistenten zu verwenden. Dann kann man - ganz ähnlich wie beim Einfügen von Werten aus dem OneWireViewer (iButton) - auf "Feste Breite" klicken und die Spaltentrennungen nach Wunsch setzen.
   Das Datumsformat macht etwas Probleme, aber mir persönlich reichen gerade bei Werten von einer einzigen Nacht auch Uhrzeit und Temperatur aus. Das Datum erkennt man auch problemlos, es ist eben nur nicht richtig formatiert und verteilt sich auf mehrere Spalten.

Jetzt kann man auch schöne Vergleichskurven erstellen (hier in Blau der iButton und in Orange der up-Cyclino):

Die Kalibration ist noch etwas unterschiedlich, aber dafür kann man die Kurven optisch auch besser trennen.


Noch eine Frage an dich, rbca: Was hat es mit der Messwerteanzahl von 908 auf sich? Die ist ja in der App (im XML) standardmäßig vorgegeben und im Code (in HandleTag.java) habe ich zusätzlich die folgende Stelle gefunden:
Was passiert da genau bei über 908 Messungen?
Ich würde ja eigentlich gerne den Default-Wert auf eine rundere Zahl setzen - oder, was noch besser wäre, die letzte Eingabe des Users als Vorschlagswert nehmen (aber ob ich das hinkriege, weiß ich eh noch nicht).

_________________
Mama von L. (11/2014) und J. (2/2017).
NFP per Trackle, aber aktuell zu faul zum Übertragen in myNFP.

Waaah, danke Wega! Ich bin innerlich noch dabei, warte nur auf eine Woche ohne kranke Kinder - seit Dezember.
Ich hab noch nie ne App programmiert, aber ich würde sehr gerne einbauen, dass gleich der Mittelwert der 3 (oder n ...) tiefsten Werte angezeigt wird. Wenn ich mal Zeit habe ...

_________________
Reflector
kurvt seit September 2014 mit kleinem Glückskeks
und seit November 2016 mit kleiner Milchgurke.

Ja, das wäre super, reflector!
Man muss die interne Tabelle umstrukturieren, damit man sie nach der Temperatur sortieren kann, aber mit meinen geringen Java-Kenntnissen tue ich mich da schwer und fand das mit der Zwischenablage dann einfacher.

_________________
Mama von L. (11/2014) und J. (2/2017).
NFP per Trackle, aber aktuell zu faul zum Übertragen in myNFP.

Wega, Du bist der Knaller!!!! Da werde ich direkt wieder motiviert!
Auch das Reflektor noch dabei ist
Vielleicht wird das ja doch noch...


Das ist nur ein billiger Trick um beim erstmaligem Nutzen des Sensors einen Absturz zu verhindern. Da behauptet der Sensor nämlich mehr Werte gespeichert zu haben, als der Speicher umfasst, obwohl noch gar keine Messungen erfolgt sind.
Die maximale Anzahl von 908 Werten wird an anderer Stelle gesetzt, nämlich in HandleTag.java, in den ersten beiden Bytes von cmd in cmdBlock8() (gemäß Tabelle 128 im Firmware User Guide PDF): 0x38C sind gerade 908 Werte. Mehr als 912 geht nicht, ohne den Sensor zu schrotten. Und statt vier weiterer Werte nutze ich den freien Speicher für Kalibration/Zeitstempel. Der Sensor würde auch ein Rollover erlauben, wenn Du das noch programmieren würdest, wäre das natürlich auch toll

Alles so weit klar?

Den calibrationButton clicklistener in MainActivity.java muss man nur ein bisschen abändern, damit die Kalibration nicht mehr abstürzt wenn keine Eintragungen gemacht werden. Wega, Ich schick es Dir per PN, dann kannst Du es bei Dir einbauen und nachher auf github hochladen.

Vielen Dank für die Infos und PNs, rbca! Ich habe heute leider nichts geschafft, aber in den nächsten Tagen versuche ich weiter, das GitHub-Problem zu lösen und füge dann auch deine Anpassung für die Kalibrations-Eingabefelder ein!

_________________
Mama von L. (11/2014) und J. (2/2017).
NFP per Trackle, aber aktuell zu faul zum Übertragen in myNFP.

Soooo, rbca und ich haben die neueste Version der App auf GitHub hochgeladen.

Die App ist jetzt unter https://github.com/KoopCoop/Cyclino/blo ... -debug.apk zu finden (vorher war der Pfad etwas kürzer, da sie nicht im "Debug"-Ordner lag, also nicht verwechseln; die alte apk-Datei liegt noch unter dem alten Pfad).

rbca hatte mir noch Code geschickt, um den Absturz bei Eingabe von leeren Kalibrationswerten zu beheben, den habe ich auch erfolgreich eingebaut. Alle anderen Änderungen hatte ich ja schon weiter oben beschrieben.


Mir ist inzwischen aber noch ein seltsamer Effekt aufgefallen: wir hatten ja gesagt, wenn die Mission unerwartet abbricht, driften die Messzeiten immer weiter auseinander, also nimmt man besser die Messabstände, die der User vorgegeben hatte.
Ich konnte das jetzt auch testen, weil ich neulich die alte Batterie in den Sensor gesteckt habe, die noch rumliegen hatte, und diese jetzt schon schwächelt. Die Zeiten, die dabei herauskommen, sind genauso, wie sie sein sollten (mein Code tut also, was er soll), aber ich bin mir nicht sicher, ob der Sensor vielleicht bei schwächelnder Batterie nicht doch tatsächlich mit größer werdenden Zeitabständen misst.

Der Grund für meine Vermutung ist diese Nachtkurve (Blau: iButton, Orange: up-Cyclino):

Als ich morgens gegen 7 Uhr die Werte per App ausgelesen habe, endete die Mission (unter der im Code gemachten Annahme, dass die Messungen weiter im vorgegebenen Messintervall erfolgten) um ca. 3 Uhr nachts, wie man auch an der Grafik sieht. Es würde allerdings besser zur iButton-Kurve passen, wenn man größere Messabstände annimmt und dadurch die orange Kurve weiter nach rechts "streckt". Oder der Sensor spinnt, wenn die Batterie so schwach ist, und misst plötzlich höhere Werte.

Was aber noch interessanter war: beim Auslesen um 7 Uhr sahen die Messwerte zunächst so aus (ich füge nur die Links ein, die Bilder sind irgendwie zu groß):
https://imgur.com/0aSrn29
Beim erneuten Auslesen um kurz nach 9 Uhr (ich hatte die Mission nicht gestoppt) dann so - es sind noch Werte dazugekommen:
https://imgur.com/ztqhJis

Und als ich heute (zwei Tage später) nochmal ausgelesen habe, gab es noch mehr Werte:
https://imgur.com/Mh0nUsB

Die Messzeiten verschieben sich im Nachhinein noch um ca. 1,5 Minuten, aber vor allem werden es immer mehr Werte.
Entweder hat der Sensor durchs Auslesen jedes Mal einen kleinen Schubs bekommen und nochmal angefangen zu messen, oder er misst tatsächlich in größeren Abständen als vorher, wenn die Batterie nicht mehr so richtig will. Aber im zweiten Fall hätten wir keine Möglichkeit, diese Zeitabstände herauszufinden, oder?

Als einfachste Lösung würde mir jetzt einfallen, die Mission automatisch zu stoppen, sobald beim Auslesen der Daten auffällt, dass die Mission unerwartet abgebrochen (oder in zu großen Abständen gemessen oder was auch immer es war) wurde, d.h. wenn der Fall eintritt, dass die vorgegebene Frequenz und die sich aus der aktuellen Messzeit, der Startzeit der Mission und der Anzahl der Werte ergebende Frequenz um mehr als 10% voneinander abweichen.

_________________
Mama von L. (11/2014) und J. (2/2017).
NFP per Trackle, aber aktuell zu faul zum Übertragen in myNFP.

Du hast Recht, das scheint tatsächlich so zu sein, dass der Sensor durch den Energieimpuls des Auslesens noch einmal versucht zu starten, wenn die Batterie vorher versagt hat. Ganz unabhängig von der Batteriespannung (und auch Temperatur) sind die Resonatoren nie, meine Stoppuhr Experimente haben im zulässigen Spannungsbereich aber keine großen Zeitdrifts aufgedeckt. BatError wird auch immer noch keiner angezeigt?

Ich würde es auch so wie Deine vorgeschlagene Lösung handhaben.
Siehst du es als Problem an, dass man die Zeitabstände nicht mehr überprüfen kann, wenn die Mission laut Sensor erfolgreich beendet wurde (Data available in Frau)? Dann sollte man nämlich meiner Meinung nach davon ausgehen können, dass alles geklappt hat, oder?

Aber auch bei unter zehn Werten sollte man dann auf jeden Fall testen, ob die Toleranz nicht überschritten wurde.

Bei den Zeitverläufen sieht es für mich zusätzlich zu Deiner Vermutung aber so aus als wäre der iButton insgesamt träger (besser isoliert, größere Zeitkonstante), obwohl ich anderes erwartet hätte. Wie waren die denn verpackt ? Mich würden mal kontrollierte Bedingungen bei voller Batterie interessieren. Also zum Beispiel beide Sensoren im Kühlschrank auf Gleichgewichtstemperatur bringen, rauchigen und dabei bis zum Raumtemperatur-gleichgewicht von beiden Sensoren Temperaturkurve im 30s Takt aufzeichnen lassen.