Danke. In Juggluco hatte ich die Akku Einstellungen tatsächlich vergessen.
Bis jetzt läuft es rund
Zu meiner zweiten Frage: Ist es möglich die verpassten Werte auch an xdrip weiter zu geben? In Juggluco sind diese ja vorhanden.
das ist noch offen in xDrip. Eine erste Version gibt es, leider ist diese noch nicht releast. Es fehlen noch einige Kleinigkeiten.
Wenn die Kalibrierung die Sensorwerte nicht verbessert, verbessert sie auch nicht die Pumpensteuerung.
Sie selbst sagten, dass Sie bei sehr wenigen Messungen kalibrieren sollten, während die Handbücher für die Kalibrierung von Sensoren, die kalibriert werden müssen, sagen, dass Sie drei- bis viermal am Tag kalibrieren müssen.
Die Standardkalibrierung von xDrip verwendet den letzten Wert, um alle folgenden Schätzungen zu erhöhen oder zu verringern. Es tut dies nicht, indem es feststellt, dass alle Werte etwas zu hoch oder zu niedrig sind, und diesen Betrag dann von der Schätzung abzieht oder hinzufügt. Wählen Sie eine spezielle Messgelegenheit aus, um dieses Ziel zu erreichen?
Hm, ich würde empfehlen, die xDrip Kalibrierung für die Datenquelle L3 so zu verwenden wie eingebaut. Also nur den Intercept anpassen. Die lineare Interpolation von xDrip+ (mit Intercept und Slope) scheint beim L3 nicht so gut zu funktionieren. Ich gehe nach meinen Tests davon aus, dass die Umrechnung der interstitiellen Glukosewerte in BG Werte nichtlinear ist. Soll heißen die App korriegiert je nach Wertebereich anders. Wenn ich dort volle Kalibrierung verwendet hatte, waren die Ergebnisse mau.
Mich hat die Version 3.4.0 gestern Nacht unerwartet erwischt. Ich hatte leider das Auto Update in Google Play nicht ausgeschaltet, da ich die Version 3.3.1 manuell installiert hatte. Das ist Google Play aber egal, sobald es die App findet wird upgedated. Bis auf die traege Reaktionszeit der L3 App hat alles seit April prima seinen Dienst getan. Ich loope damit und bin erfreut, wie genau die Werte bei mir sind. Deutliche Verbesserung zum L2. Vor allem sind die Delta über einen großen Bereich von 70 ... 200 bei mir meist nie größer als +-15 mg/dl.
Ich habe mit kompetenter Hilfe aus dem Forum einiges ausprobiert, um auf die 3.3.1 downzugraden. Man kann die alte Version zwar installieren, aber diese startet dann nicht mehr. Unabhängig, ob FreeThree läuft oder nicht. Es gibt immer die Meldung "L 3 keeps stopping". Die 3.4.0 dagegen startet und zeigt, wenn man FreeThree deaktiviert hat, Werte an. Das kann man mehrmals hin- und her machen, immer das gleiche Ergebnis.
Ich musste letztlich in der 3.3.1 App die App Daten loeschen (Cache und Daten), dann startete sie jungfraeulich und forderte Infos an. Leider vergisst die App damit aber den aktuellen Sensor und man muss einen neuen setzen. Der ist jetzt aktiv und liefert Werte ab. Ich arbeite im übrigen ohne LibreView.
Besonders wichtig: xDrip+ Kalibrierung: https://xdrip.readthedocs.io/en/latest/calibrate/101/
Alles anzeigenIn der Annahme, dass die K-Sensoren eh nicht funktionieren habe ich parallel am anderen Arm einfach mal einen gesetzt.
Versuch der Aktivierung mit neuen Mobiltelefon und offizieller LibreLink-App 2.4.0 (frisch aus dem Playstore). Fehlermeldung "Inkompatibler Sensor. Dieser Sensor kann nicht mit dieser Version der App verwendet werden." Soso.
Aktivierungsversuch mit dem Lesegerät (1.0.12 Version 1.03). Nach ein paar Minuten "Signalverlust" im Ereignisprotokoll stehen 2 Meldungen zur gleichen Uhrzeit 1) 49, 130 2) Er0, 2014 3) Er2, 266
q.e.d.
Ein paar weitere Gedanken zu unserem Thread.
Alles was wir hier posten ist offen ohne jegliche Anmeldung einsehbar.
Ich finde es toll, wie alle Mitarbeiten und wie unsere Datenbank wächst, aber ist es sinnvoll bei Abbott auf das Forum zu verweisen?
Einige Mitglieder posten volle Seriennummern. Einem Abbott-Mitarbeiter mit entsprechendem Zugriff ist es somit sehr leicht Bezug zu Realdaten herzustellen.
Ich möchte nicht, dass dies jemandem negativ ausgelegt wird ("Sie benutzen eine nicht genehmigte Version. blablabla").
Es kam eine Meldung "inkompatibler Sensor"? Höre ich zum ersten Mal. Das kann problematisch werden, wenn das bedeuten würde, das die Sensor Firmware angepasst worden wäre, um z. B. den Betrieb mit der patched App (2.3) zu unterbinden. Bedeutet, das neue Sensoren nur mit der V2.4 gestartet werden können. Dann wäre die patched App draussen, alle Nutzer müßten für Alarme ein Zwangsupdate auf 2.4 machen. Ein vorstellbares Szenario. Es war also ein K-Sensor, das mit der 2.4 gestartet wurde. Wurde der erste Sensor auch damit der 2.4 gestartet?
zurück haben wollte er die aber nicht.
dann wende dich doch mal an keencave er (?) sucht aktuell defekte Sensoren um zu schauen, ob sie was machen können
Danke, aber ich bin mittlerweile versorgt und habe zwei defekte Sensoren hier. Ein noch nicht gestarteter soll noch kommen. das sollte vorerst reichen. Wer trotzdem nch einen frischen übrig hat, bitte per PN melden.
Ist als letzte Rettung möglich. Unbedingt grosszügig desinfizieren! Nadel tut nicht weh obwohl Recht gross. Habe in einem Notfall (Reise, kein Ersatz dabei) Mal gemacht. Hielt dann weitere 6 Tage und war genau wie vorher. Würde ich aber nicht wiederholen.
Man kann auch einfach die Hohlnadel rauspopeln, desinfizieren und von oben in den Sensor/die Filament Halterung schieben. Es gibt eine Vorzugsrichtung. Das Filament muss dann im Spalt der Hohlnadel stecken. Rein in den Arm, Nadel rausziehen und Sensor verkleben. Empfehle ich zwar nicht ist aber
Du kannst in Android Studio links oben die ll App als Quelle angeben. Als Filter sollte "patched" ausreichen wenn ich es Recht erinnere . Man sollte dann eigentlich sehen wie die App die Verbindung zum Sensor aufbaut, sich authentifiziert und dann die ersten RAW Werte als lange Zahlenreihe kommen.
Hat jemand versucht einen logcat der gepatchten LL App mit einem K Sensor zu ziehen? Dort sollten Infos zum BT Verbindungsaufbau auftauchen, mglw. auch ein Indiz was da schiefgeht.
Danke, dass du dich hier mit einbringst. Ich starte den nächsten Sensor erst in einer Woche, dann werde ich die K-Reihe wieder testen und Logcat mitlaufen lassen. Gibt es außer der Fokussierung auf LL noch andere sinnvolle Filter, sonst kommen dabei unendliche Zeilen sonstiger events noch bei rum.
Stimmt, aber über Android Studio Silke es mit dem Device manager gehen auch wenn ADB um Backup kastriert wird.
Kappa Wenn keencave nicht nur den Namen aus der LC gekapert hat ( und einiges spricht dagegen), dann ist er (?) hier, um mehr Datenpunkte zum K-Problem zu sammeln. Dort drüben war das Problem bis vor kurzem noch nicht bekannt, scheint es, es gibt nicht so viele Looper mit Libre... Seid nett zueinander!
Jupp, das bin tatsächlich ich.
ach ja, kann jemand mal ausprobieren, ob ein neuer MiaoMiao2 (Firmware 7) mit OOP oder ein neuer blucon (braucht für OOP eine neuere Firmware) mit den K-Sensoren funktioniert? Das wäre eine Abhilfe. Wie weiter oben berichtet muss die Firmware der Transmitter mit dem neuen OOP zusammenarbeiten, damit auch Daten fliessen. Daher gehen alte MM1 oder alte blucons nicht. Sie verbinden sich zwar, es kommen nur keine Daten an.
Bedenklich. Gleiches wurde auf FB berichtet. Dort wurde die A***t Hotline sinngemäß zitiert mit den Worten: "Hoffentlich betrifft das nicht die ganze Charge..." Hat jemand versucht einen logcat der gepatchten LL App mit einem K Sensor zu ziehen? Dort sollten Infos zum BT Verbindungsaufbau auftauchen, mglw. auch ein Indiz was da schiefgeht. Ich denke da wurde an der Sensor Firmware geschraubt (was nicht mit dem MHD verglichen mit lauffähigen Sensoren zusammenpasst) oder die Charge hat einen Serienfehler in einer Komponente. Dazu wäre es hilfreich wenn jemand einen defekten K-Sensor knackt und ein Photo vom BT Chip auf der PCB machen würde. Wir würden uns das gerne näher ansehen - besteht die Möglichkeit einer "Spende" eines K-Sensors? Bitte PN dazu. Ansonsten müssen die Kundigen darauf warten bis sie selbst solche Sensoren zu bekommen. In jedem Fall ist das ein ernsthafter Produktfehler, da ein Kernmerkmal des Produktes fehlerhaft ist. Das sollte man evtl. auch an die zuständigen Stellen der Medizinüberwachung in D melden.
