ob ich mir noch ein Jahr diese Riesendinger ankleben will
Pest oder Cholera trifft es nicht ganz - den L2 kennen wir halbwegs, aber welche Macken der L3 bei z.B. der Temperaturkorrektur hat?
Freilich wäre ohne wagemutige Forscher nicht nur der Südpol ein weißer Fleck auf der Landkarte - es sind aber auch etliche auf der Strecke geblieben :'-(
Das passt wie die Faust aufs Auge - scheint aber kein Allgemeinwissen zu sein. Danke fürs Rauskramen.
Ich werde mal bei LineageOS persönlich vorstellig werden 
Nachtrag zum Handy-Thema: die BYODA wollte ja auf keinem meiner Galaxy S4mini laufen (LineageOS von 16.0 bis 18.1), ich bin dann notgedrungen auf das Alltags-Xiaomi umgestiegen, das noch mit originaler Firmware läuft.
Ich habe das gleiche Experiment jetzt mit einem Sony Xperia XA2 durch - LineageOS 18.1 - gleiches Problem, "FATAL EXCEPTION: CgmServiceThread", eine "null pointer exception" in einer Funktion getRecordedTimeStamp().
Ich bekomme das ungute Gefühl, dass das alle LineageOS-Systeme betreffen könnte...
Da im Call-Stack als nächstes XDripCgmDataUpdateCallback.java auftaucht, scheint es auf die gepatchte App beschränkt zu sein.
Die Verlängerung, sofern der Sensor so lange durchhält, werde ich mit xDrip machen, den zweiten Sensor womöglich auch.
Jetzt grüble ich, ob (und wie) das irgendwie gefixt werden kann... Gibt es zur BYODA jemanden, den/die man ansprechen kann?
Tipp, etwas mehr am Tag trinken. 🥛☕🍺
Noch mehr???
Hat sich das Pflaster etwas gelöst?
Nein, das sitzt bombenfest und vom Verlängern bin ich noch ein Stück entfernt.
Steve8x8 meinst du Linux als Partition?
Als Live-System von CD/DVD, als das eingebaute WSL oder wie das Microsoft-Linux heißt, als virtuelle Maschine (VirtualBox), DualBoot, whatever.
Vermutlich würde für die meisten Dinge ein RasPi reichen, der hat eh nur USB 2
Für Android Studio würde ich aber was Besseres als nen Pi nehmen 
bierernst Fürs nächste Mal denk' über Linux oder notfalls auch MacOS nach, das Handling von Androiden damit ist deutlich einfacher (kein Treiber-Stress, kein Mäusegeschubse).
Und ein USB-2.0-Anschluss (notfalls -Hub) ist auch Gold wert.
Inzwischen quittiert mir der Sensor jede Fahrradfahrt mit fake-Lows.
Auf dem Nachhauseweg gab es -32, danach +23, dann -76 und zum Schluss +90 - die 100 stimmt dann wieder:
Wir werden wohl keine Freunde mehr :'-(
In dem Fall würde ich die Daten der App löschen (dann "vergisst" sie sowohl Sensor als auch Transmitter) und das Bluetooth-Pairing entfernen. Oder das Handy ausschalten.
Nach dem Stoppen des Sensors.
Wenn du den alten Sensor stoppst, sollte die App beim nächsten Lauf nach dem neuen Sensor-Code und danach nach dem Transmitter fragen - du hast doch zwei Sensoren getestet, wie war das denn da? (Ich bin noch nicht so weit...)
Es reicht halt nicht, innovativ zu sein, man muss auch destruktiv agieren.
Kaum habe ich den Fragebogen ausgefüllt (nachdem die dritte oder fünfte Mail "wir schreiben schon die Rechnung" kam), ruft mir xDrip heute auf dem Nachhauseweg erst -23 und dann noch mal -20 zu (bei minimalem IOB), also vom Rad gesprungen und blutig gemessen: alles okay... na gut, ein Traubenzucker geht immer... kurz darauf nur noch Fragezeichen auf der Uhr.
Zu Hause angekommen (ohne Symptome):
Na toll (3 Stunden? den Libre darf man schon nach 2 Std. vergessen).
Aber der Sensor ist noch, wo er hingehört, das Pflaster klebt, wird nur am Rand langsam hässlich... also erst mal duschen, und siehe, ein Alarmton und die Uhr meint +92 (von 10 - ?!? die sehe ich weder bei xDrip noch bei NS - auf 102):
Ursachenforschung ist noch nicht beendet, vermutlich war die "Schweißnaht" unterm Rippenbogen doch nicht die beste Idee, aber weiter unten ist der Hosenbund, und bei einem Testsensor hat man eben keine zwei Versuche...
Ich muss wohl das alte Liegerad wieder rauskramen, oder im Homeoffice bleiben.
Die ganz kleinen Intels gibt es aber nicht mehr, dafür kann der RasPi ab 3B richtiges 64-bit
Einfach mal "sysctl -a | grep ipv6" laufen lassen und allen "disable"-s eine 1 geben. Evtl ist ein Neustart fällig.
So etwas wie
net.ipv6.conf.all.disable_ipv6
unter /etc/sysctl.d ?
Da es "nur" NFC ist, hängt das eher von der evtl. Verschlüsselung ab - und ob sich der Pen irgendwie mit dem Libre beißt.
Welchen Weg hast du für den "feature request" gewählt?
Gerade habe ich die Verlautbarung gefunden, in der die Zusammenarbeit von Novo und Abbott angekündigt wird.
Die ist vom 21.2.2019. Die LL-App 2.3.0 vom April... hat also vermutlich keine Unterstützung, und bei Novo steht immer noch "kommt demnächst".
Anders herum: da die Kommunikation zwischen Pen und Smartphone offline, per NFC-Scan, erfolgt: wie sehen denn die gescannten Daten dann aus? Um NFC auszulesen, gibt es ja etliche Apps, wie NFC Reader oder TagInfo...
Ich kann noch nicht viel mitreden, aber meine Dexcom-App glättet nicht viel - die ersten 6 Stunden oder so waren gruselig, und auch jetzt, wo sich alles "eingeschwungen" hat, gibt es immer noch unvermittelte Sprünge über 15-20 mg/dl, sowohl rauf als auch runter.
Die hatte der Libre auch, aber da sah man das noch besser (in den Minutenwerten, die ich jetzt schon vermisse) und konnte sich seinen Reim drauf machen.
Über die App mit den dunkelgrauen Punkten auf dunklem Hintergrund sage ich besser nichts, das würde sehr unhöflich ausfallen. (Okay, keine Unterstützung für "dark mode". Mein Pech.)
Dass die Daten nach 24 Stunden futsch sind (wenn kein Clarity hinten dran hängt) - nun ja. Vielleicht bekomme ich die verschlüsselte Datenbank ja doch noch geknackt...
Das wäre dann ein dritter Programmschnipsel, der irgendwie in die App reingeklebt wird. Ich glaube nicht recht dran.
Dann doch lieber xDrip-Unterstützung - ist das Protokoll überhaupt schon bekannt, evtl ähnlich zum Pendiq?
Funktioniert der Pen denn auch mit deutschen Apps? Insbesondere mit der Libre App auf Android?
Glaubst du allen Ernstes, dass die LL-App von April/Mai das Ding unterstützt?
K@rline Nutze die Lupe oben auf der Haupt-Einstellungsseite, suche nach "Steigung" (wenn deutsch) oder "slope".
Der Punkt heißt "keine festen Libre-Steigungen" ("no fixed slope")
