Beiträge von dideldum

    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+.

    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...).

    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.

    klausiklaus

    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?

    Aox


    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.

    Gedacht habe ich genau das gleiche, wollte nur nicht rumunken.:bigg:ren

    Ja, wegen des Nicht-Rumunken-Wollens hatte ich auch erst nicht geschrieben.


    Muss aber doch mal was loswerden, weil du auch gerade die FDDB erwähnt hast.


    Ich denke nicht, dass es sinnvoll ist, eine eigene Datenbank aufzubauen, da die zwangsläufig über einen längeren Zeitraum noch sehr dünn bestückt sein dürfte. Da macht die Nutzung einer bereits sehr umfangreich gefüllten Datenbank wie FDDB viel mehr Sinn.


    Auch Apps wie die hier vorgestellte gibt es ja schon, z.B. wetid (die benutzt die FDDB im Hintergrund). Die Frage stellt sich deshalb, ob hier etwas sinnvoll Neues entsteht oder die Kräfte nicht vielleicht anderweitig sinnvoller eingesetzt werden könnten. Der Entwickler von wetid ist meines Wissens z.B. noch auf der Suche nach Native-App-Entwicklern, weil die Android-/iOS-Apps wohl in Wirklichkeit nur Webseiten-Abbildungen sind. Ich muss aber zugeben, dass ich weder wetid noch eine andere gleichartige App je probiert habe, weil ich mit Wiegen, gKH/100g-Angaben und Dreisatz gut genug zurecht komme.

    Kannst du noch sagen, ob es auch ohne extra App funktioniert.

    Ich habe die App gar nicht. Das Messgerät ist wie ein normales Messgerät verwendbar (Bluetooth habe ich auch nicht an) und alle gemessenen Werte sind auf dem Gerät ablesbar.


    Bei "App" fällt mir aber noch dazu ein:

    Da meine Nutzung von xDrip+ bei Nutzungsbeginn vom Fora 6 schon in den letzten Zügen lag, habe ich leider nie probiert, ob die Bluetooth-Verbindung vom Fora 6 zu xDrip+ gehen würde. Grundsätzlich ist ja eine Übermittlung der BZ-Werte von einem Bluetooth-BZ-Gerät zu xDrip+ möglich. Ich glaube, mit dem Contour Next One hatte ich das sogar irgendwann mal gemacht, mit dem Fora 6 aber dann eben nicht mehr probiert.

    FSL1-Reader [...]

    Die benötigte Blutmenge empfinde ich als recht gering.

    Oha, dann hast du da keine großen Ansprüche. Ich habe schon einige BZ-Messgeräte durch. Vor ca. 20 Jahren hatten die damals noch in Deutschland erhältlichen Messgeräte noch relativ großen Blutbedarf. Damals hatte ich durch Aufenthalt in Spanien Glück, dass ich ein dort standardmäßig verschriebenes Gerät von Menarini bekam. Das hatte damals schon einen äußerst geringen Blutbedarf, der dem von heutigen Messgeräten (außer den Abbott-Geräten) gleicht.

    Die Abbott-Geräte (ich habe sowohl Libre1 als auch Libre2-Geräte mal als BZ- und Keton-Messgerät probiert) sind echt erbärmlich mit ihrem Blutbedarf im Vergleich z.B. zum Contour Next One oder eben auch dem Fora 6. Wie gesagt: für die Precision-Teststreifen müssen wir viel tiefer stechen, um genug Blut zu bekommen. Nein danke, die Abbott-Geräte sind da echt schlecht, sie liegen aus meiner Sicht auf dem Stand wie die Geräte vor 20 Jahren.

    Was die Präzision angeht, habe ich aufgrund dieses riesigen Blutbedarfs die Abbott-Geräte nicht weiter unter die Lupe genommen. Vergleichsmessungen mit Contour Next One, Contour Next Link und Fora 6 (je 3 Messungen aus demselben Blutstropfen - und ja, DAFÜR habe ich mal richtig tief gestochen!) zeigten die beste Konstanz beim Contour Next One, dicht gefolgt vom Fora 6. Am schlechtesten davon war das Contour Next Link. Vergleichsmessungen mit dem Laborgerät bei meinem Diabetologen zeigen das Contour Next One und Fora 6 mit sehr geringen Abweichungen jeweils etwa gleichauf. Die Libre-Lesegeräte habe ich (eben aufgrund des hohen Blutbedarfs und daraus folgender Nicht-Nutzung) nie mit dem Diabetologen-Gerät verglichen.


    Kann das Fora auch Cholesterin zu messen?

    Ja.


    Hier die Herstellerseite: https://www.smart-otc.de/produkte/fora-6-connect/ (leider kriege ich keine Provision, aber bin überzeugter Nutzer)

    Der Unterschied beträgt 37 mg/dl. 20% von 142 sind 28mg/dl - der Unterschied ist also wirklich zu hoch (ein BZ-Messgerät kann bis zu 20% schief liegen.)

    Hier stimmt mehreres nicht.

    Erstens kann der BZ in dieser Situation "in echt" z.B. bei 163 gelegen haben. Dann war das BZ-Gerät 15% zu niedrig (also im Rahmen der Abweichungsregelung) und der Sensor 10% zu hoch (wobei es hier keine Festlegung für die Abweichung gibt).

    20% ist grundsätzlich erstmal keine erlaubte Abweichung bei BZ-Messgeräten, bei über 100mg/dl gilt eine mögliche Abweichung von 15%. ABER: die gilt nur für einen bestimmten Anteil der Messwerte. Ein geringer Anteil der Messwerte (ich hab grad nicht im Kopf, wieviel) darf auch außerhalb dieser 15% liegen und da ist nicht definiert, wie falsch die sein dürfen.


    Man kann bei so einer Einzelmessung eh nie sagen, welcher Wert denn nun wirklich "richtig" ist. Im echten Zweifel machen wir dann 3 blutige Messwerte und wägen ab, was für einen Wert wir dann für richtig halten. In Ermangelung eines Laborgeräts können wir das sowieso immer nur vermuten.

    und dann unterzucker ich weil er eigentlich 142 war.

    Genau das weißt du eben nicht. Wie oben geschrieben, könnte dein echter BZ 163 gewesen sein und dein BZ-Messgerät hat eine erlaubte Abweichung gehabt. Tatsächlich könnte dein echter BZ sogar 123 gewesen sein und das BZ-Gerät hätte im normalen Rahmen gemessen. Weißt du`s?


    Ich finde es immer wieder erstaunlich, dass Leute eine BZ-Messung vornehmen und das grundsätzlich für den "richtigen" Wert halten.