Warum lässt sie sich nicht ds jetzt erhältliche Abbott-Empfangsgerät (wie beim Libre 2) verschreiben?
Beiträge von dideldum
-
-
Das liegt noch im erlaubten Toleranzbereich der DIN-Norm.
Für GZ-Sensoren gibt es keine DIN-Norm, nur für BZ-Messgeräte.
-
Die Diabetologin behauptet die Kasse lügt
Die Diabetologin lügt.
-
Das wird technisch wahrscheinlich nicht gehen. Das 2er liest doch per NFC Chip aus und das 3er über Bluetooth
Natürlich geht das.
Das 2er Lesegerät empfängt ja schon per Bluetooth die minütlichen Werte vom 2er Sensor. Es braucht nur ein Firmware Update, um sie auch anzuzeigen.
-
Bedenke aber, dass die eingebauten Beschränkungen für das Libre einen Grund haben
Ganz und gar nicht. Die Libre2-Werte sind vom ersten Moment bei meiner Tochter und mir absolut zuverlässig, sie setzen die Kurve des alten Sensors direkt fort. Sehr viel präziser als der bei so vielen am ersten Tag unzuverlässige Dexcom. Und von Rauschen kann beim Libre2 auch keine Rede sein. Die Beschränkung in AAPS für den Libre 2 ist unsinnig und nicht nachvollziehbar. Sage und schreibe ich schon mit begründeter Erfahrung schon seit Jahren, wird aber vom in mancher Hinsicht sehr bornierten Milos weiter ignoriert. Ich hatte für uns die Codebeschränkung vor Jahren schon entfernt und nie schlechte/gefährliche Erfahrungen mit dem Libre2 und SMBs gemacht.
Dieses ganze Nachplappern der angeblichen Beschränkungsbegründung entbehrt jeder Grundlage.
-
es gab sehr wohl früher xdrip ohne +
Lang ists her.
Dieses alte xDrip (ohne +) wurde doch aber seit 2015 nicht mehr weiter entwickelt. Diese ganz alte xDrip-Version konnte natürlich noch ohne Standortfreigabe arbeiten, sie basierte noch auf Android 4.3 und der Standortzwang für Bluetooth wurde von Google in Android eben erst ab Version 5 oder 6 eingeführt.
Ich kann mir aber nicht vorstellen, dass diese Uralt-Version mit den aktuellen Dexcom-Transmittern funktioniert, da ja xDrip+ spätestens seit den G-Versionen der Transmitter immer der Dexcom-Anbindung hinterher arbeitet. Ich denke, man kann deshalb davon ausgehen, dass mit "xDrip" schon seit mehreren Jahren immer das xDrip+ gemeint ist.
Leider benutzen ja aber auch (durch Schuld des entsprechenden Entwicklers) Leute für die iOS-App "xdrip4ios" die Abkürzung xdrip. Die iOS-App hat nur leider gar nichts mit der Original-Android-App xDrip bzw. der Weiterentwicklung xDrip+ zu tun und der Name xdrip ist vom iOS-Entwickler einfach nur geklaut und mißbräuchlich verwendet. Finde ich unmöglich und sorgt für viel Verwirrung. Die iOS-App sollte eigentlich im Namen gar nicht xdrip führen, das ist einfach Namensdiebstahl und Irreführung der Nutzer. Sorry fürs Off-Topic, das hat mit dem eigentlichen Problem hier natürlich nichts zu tun.
-
Grundsätzlich hat dein Mann Recht!
Das hat gar nichts mit Dexcom oder Libre zu tun, sondern damit, dass Android seit Android 5 oder 6 (das weiß ich nicht mehr so genau) für eine Bluetooth-Verbindung verlangt, dass die entsprechende App Zugriff auf den Standort hat. Ohne der App (xDrip+, BYODA, Dexcom App für den Dexcom. (gepatchte) LibreLink, Juggluco, Diabox, xDrip+ für den Libre) den Standort-Zugriff zu erlauben, wirst du also IMMER Probleme mit dem Werte-Empfang des Sensors haben. Diese Berechtigung zum Standortzugriff MUSST du deiner verwendeten App geben!
-
Könntest du mir verraten wie dein Setup aufgebaut ist?
Ich habe mir meine eigene App gemacht, die von einer modifizierten gepatchten LibreLink die Libre 2 (!) Werte bekommt. Da meine Tochter und ich noch bis Februar 2023 mit den Libre 2 versorgt sind, habe ich mich um die Anbindung vom Libre 3 noch nicht gekümmert. Ich werde im Winter aber sicherlich mit der letzten noch funktionierenden Libre 3 App und Free Three die Anbindung an meine App realisieren, wenn es bis dahin noch nichts einfacheres (ohne Internet-Anbindung) gibt (der LLU-Client kommt für uns nicht in Frage, eine Anbindung an Abbott-Server wird es bei uns nicht geben). Leider kann ich meine App noch nicht veröffentlichen, da es dort noch Fehler und Macken gibt, mit denen ich zurecht komme, die ich anderen aber nicht zumuten möchte. Eine minütliche Loop-Steuerung damit funktioniert aber ohne Probleme in Bezug auf die Datenmenge! Wir haben den Loop nun eben schon seit anderhalb Jahren mit minütlichen Werten laufen (deshalb gibt es bei uns seitdem auch kein xDrip+ mehr, weil das eben nicht nur mit der linearen Mittelung unbrauchbar ist, sondern eben auch völlig unnötig auf 5min-Intervalle verzögert).
Einzige (aber unwichtige) Einschränkung ist die Reduzierung der Laufzeit der Dana-RS-Batterie von ca. 35 Tagen bei 5minütigen Werten auf ca. 28 Tage bei minütlichen Werten.
-
hast du Erfahrung wie man die Vorteile des libre 3 mit seinen 1 minütigen updates für den loop zu nutzen. Ich weis nicht wie sich die Komplexität bei so einem Datenaufkommen für ein Loop ergeben, fände es aber schade die Vorzüge des libre 3 nicht für meinen Loop nutzen zu dürfen...
Ich benutze die minütlichen Werte des Libre 2 seit anderthalb Jahren zum Loopen (ohne xDrip+) mit einer vernünftigen und nicht besonders aufwendigen Filterung (minütliche exponentielle Mittelwertsbildung über die einzelnen Minutenwerte der letzten 5min). Meine App hat mit anderthalb Jahren Laufzeit für die BZ-Werte jetzt ein paar MB in der Datenbank stehen, das ist also kein großer Datenaufwand. Wie das in anderen Apps (wie xDrip+) aussieht, kann natürlich davon abweichen.
-
die Verzögerung ist extra fürs Loopen in xDrip integriert worden. Es ist ein Mitttelwert der letzten 20 Minuten.
Nein, die Verzögerung ist ganz und gar nicht wegen des Loopens in xDrip+ integriert. Die war für den Libre schon immer da, noch bevor Leute überhaupt darauf kamen, den fürs Loopen zu verwenden. Und sie ist absoluter Mist!
Durch die 20minütige Mittelwertsbildung ist eine Verzögerung des Libre-Wertes (und ich sage bewusst nicht "Rohwert", denn die Rohwerte sieht man nirgends, auch nicht mit der minütlichen Anzeige der Libre-Endwerte in xDrip+!) um ca. 15min. Das zusammen mit der ca. 15min Verzögerung von BZ zu GZ hat man eine ca. halbstündige Verzögerung der BZ-Werte zum Loop. Und das ist genau für den Loop absolut unbrauchbar. Die Verzögerung ist also mitnichten "extra fürs Loopen" da, sondern im Gegenteil absolut kontraproduktiv fürs Loopen.
Ich verwende bei mir eine exponentielle Mittelwertsbildung über 5min, habe dadurch eine Verzögerung zum von der Libre-App berechneten Wert (eben nicht "Rohwert"!) um 1-2min und dann läuft der Loop auch mit vertretbar aktuellen Werten. Mit den xDrip+-Werten loope ich glücklicherweise schon seit anderthalb Jahren nicht mehr und würde das mit dem gängigen xDrip+-Mittelwerts-Algorithmus auch nicht tun. Anders sieht es mit den xDrip+-Modifikationen mit z.B. dem Savitzky-Golay-Filter aus. Das kann man gleich viel besser zum Loopen verwenden. Aber bloß nicht den schlechten linearen 20min-Mittelwert von xDrip+.
-
Ich gebe zu, die Fastclix kenne ich nicht.
Aber die beste Stechhilfe meiner Kenntnis nach ist die
Terumo Finetouch
-
Verstehe irgendwie nicht wie das zustande kommen kann, dass ein Sensor derartig falsch misst die ganze Zeit. Bin nur am Gegenspritzen und Gegenessen, das ist so frustrierend.
Wenn der Sensor deiner Meinung nach falsch misst, wieso isst und korrigierst dann auf Basis dieser Werte? Scheint mir kein sinnvolles Verhalten zu sein.
-
Es war einmal im Jahr 2010: https://www.helmholtz-hzi.de/d…g-zur-insulinherstellung/
Da hat auch nie wieder jemand was von gehört. Auf meine Anfrage im Jahr 2019 an das Helmholtz-Institut, ob ihre Forschungsergebnisse irgendwo Anwendung finden, habe ich nicht mal eine Antwort erhalten. Da geht es auch nur darum, Forschungsgelder zu kassieren. Einen echten Nutzwert muss die bezahlte Tätigkeit dann gar nicht haben. Man präsentiert sich, aber damit ist es auch gut.
Warum sollte man auch billig was herstellen (und dann auch so verkaufen!), was überteuert verkauft werden kann.
-
drück-ess-Abstand
Was für eine doofe Bezeichnung. Käme mir nie in den Sinn, von einem Drück-Ess-Abstand zu reden. Auch mit Pumpe ist es für mich ein Spritz-Ess-Abstand, weil der Bolus nunmal zusätzlich zum laufenden Basal als Einzelabgabe gespritzt wird.
Ein DEA ist für mich (mit informatischer Ausbildung) ein "Deterministischer Endlicher Automat". Kann man auch im Loop verwenden (allerdings nur aus Programmierer-Sicht...).
-
seit 27.06. / 09:00 dran.
Ich zähle da erst 9 Tage. Der wird ganz regulär noch bis morgen senden.
-
Zur Konstanz der Libre2-Sensoren mal ein Bildschirmfoto.
Heute um 09:59 waren die 14 Tage + 12 Stunden meines noch laufenden Sensors um.
Um 08:57 habe ich daher einen neuen Sensor gesetzt und gestartet.
Da ich dafür immer ein Backup der LibreLink-Daten des alten Sensors mache, nach dem Starten des neuen Sensors wieder ein Backup der LibreLink-Daten des neuen Sensors und dann die alten wieder einspiele, habe ich die Werte des alten Sensors weiter verfügbar, bis der neue Sensor wirklich läuft.
Ich habe dann um 09:50 das Backup des neuen Sensors wieder eingespielt und so direkt auf den neuen umgeschaltet, ohne dass es also eine nennenswerte Unterbrechung in den Libre-Werten gibt. Meine Aufwärmzeit beträgt verkürzte 45min statt der eigentlichen 60min, ich erhalte also bereits 45min nach dem Sensorstart Werte des neuen Sensors. Das ist der Grund, warum der neue Sensor um 09:51 (also nur 54min nach dem Start) bereits Werte geliefert hat.
Das Bild zeigt einen nahtlosen Übergang, dem man den Sensorwechsel gar nicht ansieht.
Das mal für alle jenen, die von Hüpfern und unzuverlässigem Verlauf am ersten Tag / in den ersten Stunden berichten. Oder für all jene, die die ersten 1-2 Tage unter dem unzuverlässigen Verhalten des Dexcom G6 leiden.
Der Libre2 ist definitiv ein sehr präziser und zuverlässiger Sensor.
Nebenbei bei meinem Diabetologen vorgestern: Labor 192mg/dl, Fora 6 BZ-Meßgerät: 190mg/dl, Libre2: 187mg/dl. Ja, die Werte waren schlecht. Vorher 2 große Milchkaffee ohne Bolen getrunken. Aber die Präzision aller beteiligten Geräte war sehr gut!
P.S.: Ich muss noch dazu schreiben, dass ich diesen direkten Übergang zwischen altem und neuen Sensor nun bereits seit einigen Monaten mache, und zwar sowohl bei mir als auch bei meiner Tochter. Insgesamt also nun ca. 15-20 Sensorwechsel mit nur 1-3 Minuten Ausfallzeit. Bei praktisch allen war der Übergang so fließend wie hier.
-
Für mich benötigt mein FSL1-Reader wenig Blut.
Ganz nüchterner Vergleich:
Bei den BZ-Teststreifen gibt Abbott noch die praktisch gleiche Blutmenge an wie andere Hersteller. Abbott angeblich 0,6µl, Contour Next ebenso 0,6µl, Fora 0,5µl. Die Angabe von Abbott halte ich für gelogen, weil auch die BZ-Streifen deutlich mehr Blut verlangen, als ich es für Contour-Streifen zur Verfügung stellen musste.
Bei den β-Keton-Streifen gibt Abbott 1,6µl an, die Fora-Streifen begnügen sich 0,8µl, also schon mal offiziell mit der Hälfte (und nur unwesentlich mehr als die BZ-Streifen). Real halte ich die Angabe von Abbott wieder für geschönt. Die 0,8µl der Fora-Streifen bekomme ich mit meiner normalen Stechtiefe locker hin, bei den Abbott-Streifen habe ich gefühlt wesentlich mehr als "nur" das Doppelte an Blut spenden müssen und dafür auch eine erheblich höhere Stechtiefe gebraucht.
Man kann also allein von den offiziellen Zahlen ausgehend sagen, dass zumindest die β-Keton-Streifen von Abbott wesentlich mehr Blut brauchen, als das heutzutage nötig wäre, gefühlt sehe ich Abbott da noch mehr im Hintertreffen.
-
meine Interpretation der roh Daten
Welche "Rohdaten"? (Die Rohdaten des Libre 2 und 3 sind meiner Kenntnis nach NIRGENDWO sichtbar/verfügbar. Das was - fälschlich! - immer mal hier als Rohdaten bezeichnet wird, sind die fertig berechneten minütlichen Endergebnisse der Libre-App, die haben mit Rohdaten nichts zu tun!)
in der CSV Datei
Welche CSV-Daten? (Ich vermute mal, du beziehst dich auf den CSV-Export aus Libreview. Daraus Schlüsse auf das Sendeverhalten des Sensors zu ziehen, ist mehr als wagemutig.)
interpolierter den 5-Min-Wert.
Die Libre-App interpoliert keinen 5min-Wert. Sie benutzt die letzten 15 minütlichen (für keine externe App sichtbaren) Rohwerte, um aus diesem Verlauf einen geschätzten aktuellen Wert zu EXTRApolieren (also die noch rückständigen ca. 15min Verzögerung zwischen BZ- und GZ-Wert zu "überspringen" und den jetzt aktuellen BZ-Wert aus den zurückliegenden GZ-Werten zu schätzen). Diese Extrapolierung findet minütlich statt. Da ist nie was mit 5min! Und die für diese Extrapolation verwendeten 15 rohen Minutenwerte sind leider aufgrund der Verschlüsselung für keine externe App sichtbar, auch für xDrip+ mit OOP2 nicht, soweit ich weiß. Weil die Entschlüsselung und Extrapolation der Werte eben in einer Original-Abbott-Library stattfindet.
nach einer rekalibrirung aufgrund „falscher Werte“ 10 min weg
Da man meines Wissens mit den Libre-Apps den Libre-Sensor gar nicht kalibrieren kann, kannst du hier nur von einer Fremd-App wie xDrip+ sprechen. Was auch immer Fremdapps für "Einschränkungen" oder sonderbare Verhaltensweisen haben, mit dem minütlichen Senden des Libre hat das nichts zu tun!
Ich bitte dich inständig (insbesondere aufgrund deiner noch nicht so lange vorhandenen Erfahrung), derart falsche Informationen nicht, wie hier kontinuierlich geschehen, zu verbreiten. Noch unerfahrenere Leute als du nehmen so etwas sonst für bare Münze.
-
Der Libre Sensor (2 und 3) sendet stupide jede Minute seinen Wert.
Ich weiß nicht, wie du auf 5min oder gar "10min Rebootzeit" kommst. Du hast hier schon mehrfach diesen 5min-Quatsch geschrieben. Wie kommst du nur auf diesen Unsinn?
-
Ich sehe in deinen beiden Vergleichskurven deutlich, dass dein Gewebezucker definitiv schwankt. Die beiden Sensoren weisen unterschiedliche Stärken auf, da gibt es mal +-20mg/dl Unterschied, aber die Bewegung ist bei beiden ziemlich übereinstimmend.
Damit ist deine Vermutung (mehr ist es ja nicht!), dass die Sensoren durch andere Einflüsse wie z.B. Armbewegungen falsche Schwankungen haben, offensichtlich falsch, denn dass am linken und rechten Arm die gleichen mechanischen Falsch-Einflüsse wirken, ist doch sehr unwahrscheinlich.
Ich sehe bei uns eben nachweislich gleichartige Schwankungen, die nicht auf "falsche" Messungen/Berechnungen des Sensors (bzw. der damit verbundenen App) zurückzuführen sind, sondern auf nachprüfbare Vorkommnisse (Träume bei meiner Tochter z.B. beobachte ich im Schlafverhalten und sehe dann unmittelbar die GZ-Schwankungen. Bei mir ist eine völlig stabile Gerade, während ich auf dem Sofa hänge, dann stehe ich auf und habe unmittelbar die Beule in der GZ-Kurve). Auch wenn du das negierst, sag ich's mit der Maus: "Klingt komisch, is' aber so!".
Für einen Loop ist das gar nicht so dramatisch. Selbst wenn ich bei der Aufstehbeule ein oder 2 SMBs bekomme, gleicht er das durch abgeschaltetes Basal im weiteren Verlauf aus.Deine durch die Kurven gelegte Gerade ist jedenfalls völlig unrealistisch und allenfalls eine theoretische Annäherung an den realen BZ-/GZ-Verlauf.
