AAPS kriegt die Werte von xDrip (bei mir), das glättet doch schon, von daher erschhließt es sich mir nicht
AndroidAPS und Closed Loop
-
-
AAPS kriegt die Werte von xDrip (bei mir), das glättet doch schon, von daher erschhließt es sich mir nicht
Bei mir auch, aber es hängt damit zusammen, dass man nicht G6 in AAPS auswählt.
-
Die Entwickler sagen, dass der Libre zu oft ein Rauschen hat. Der G6 nicht. Da sollen die Werte stabiler sein. Ich kann das bisher nicht so sehen. Ganz selten zeigt der Libre beim Auslesen über NFC einen nicht plausiblen hohen Wert an. Dies ist mir nur aufgefallen wenn der BZ am steigen war. Kurz darauf bei der nächsten NFC Messung war der Wert weg und taucht auch nicht in xdrip oder in LibreLink auf.
Finde die Entscheidung der Entwickler nicht gerade toll. Rauschen lässt sich ja in den Daten erkennen. In so einem Fall könnte man die SMB Funktion zeitweise automatisiert deaktivieren...da sollte man in meinen Augen mehr Zeit reinstecken als in neue Fragen...
Ich finde ja gerade dieses Verhalten ist ein Feature, das für den Libre spricht! Man bekommt immer den aktuellsten Wert und kann so Trends frühestmöglich erkennen. Zur Sicherheit kann man trotzdem die Werte glätten, muss dafür aber eben eine leichte Verzögerung in Kauf nehmen.
Beim Dexcom habe ich diese Möglichkeit garnicht. Das ist eine Schwarze Box und irgendwann kommt dann ein Wert herausgepurzelt der irgendwie gefiltert wurde und irgendwie dem realen Wert hinterherhinkt. Über die Qulität des Filters kann man auch keine Aussagen treffen (und der ist keinesfalls unfehlbar!)
Von daher finde ich diese Blockade gegen den Libre auch echt widersinnig.
-
Alles anzeigen
Die Entwickler sagen, dass der Libre zu oft ein Rauschen hat. Der G6 nicht. Da sollen die Werte stabiler sein. Ich kann das bisher nicht so sehen. Ganz selten zeigt der Libre beim Auslesen über NFC einen nicht plausiblen hohen Wert an. Dies ist mir nur aufgefallen wenn der BZ am steigen war. Kurz darauf bei der nächsten NFC Messung war der Wert weg und taucht auch nicht in xdrip oder in LibreLink auf.
Finde die Entscheidung der Entwickler nicht gerade toll. Rauschen lässt sich ja in den Daten erkennen. In so einem Fall könnte man die SMB Funktion zeitweise automatisiert deaktivieren...da sollte man in meinen Augen mehr Zeit reinstecken als in neue Fragen...
Ich finde ja gerade dieses Verhalten ist ein Feature, das für den Libre spricht! Man bekommt immer den aktuellsten Wert und kann so Trends frühestmöglich erkennen. Zur Sicherheit kann man trotzdem die Werte glätten, muss dafür aber eben eine leichte Verzögerung in Kauf nehmen.
Beim Dexcom habe ich diese Möglichkeit garnicht. Das ist eine Schwarze Box und irgendwann kommt dann ein Wert herausgepurzelt der irgendwie gefiltert wurde und irgendwie dem realen Wert hinterherhinkt. Über die Qulität des Filters kann man auch keine Aussagen treffen (und der ist keinesfalls unfehlbar!)
Von daher finde ich diese Blockade gegen den Libre auch echt widersinnig.
Auf FB habe ich schon von rauschenden Sensoren gesehen. Sowohl Libre als auch Dexcom. Ich bin mit dem Libre zufrieden und bei mir rauscht bisher nichts. Man muss halt seien stellen finden und am besten noch ein bisschen in xdrip kalibrieren.
Ich kann mir auch nicht vorstellen, dass der G6 wirklich soviel besser ist als der Libre. Aber muss sagen, dass ich persönlich keine Erfahrung mit dem G6 habe.
-
AAPS kriegt die Werte von xDrip (bei mir), das glättet doch schon, von daher erschhließt es sich mir nicht
Das hab ich mir auch gedacht.In der Dokumentation ist auch angeführt (https://androidaps.readthedocs…/Open-APS-features.html):
"Für andere CGM/FGM wie das Freestyle Libre ist die SMB-always-Option deaktiviert, bis xDrip+ ein Glättungs-Plugin beinhaltet, das verrauschte Werte besser filtert. Weitere Informationen dazu findest du hier."
Im Link ("hier") wird dann auf die Möglichkeit der Glättung der Werte mit xDrip hingewiesen:
xDrip+ mit Freestyle libreWenndu xDrip+ als Datenquelle für Freestyle Libre nutzt, dann kannst du bis jetzt beim SMB “Verwende SMB immer” und “Verwende SMB nach Kohlenhydraten” nicht aktivieren, weil die BZ-Werte nicht glatt genug sind. Abgesehen davon gibt es aber ein paar Dinge, die du tun kannst, um Rauschen in den Daten zu reduzieren.
Smooth Sensor Noise. In den xDrip+ Einstellungen > xDrip+ Anzeigeeinstellungen muss “Smooth Sensor Noise” aktiviert sein. Dadurch wird versucht, verrauschte Daten zu glätten.
Smooth sensor noise (Ultrasensitive). Wenn du weiterhin verrauschte Werte in xDrip+ hast, dann kannst du sie noch aggressiver glätten, indem du die Einstellung “Smooth Sensor Noise (ultrasensitiv)” verwendest. Das wird auch dann eine Rauschglättung auslösen, wenn nur geringes Rauschen erkannt wird. Dafür musst Du zuerst den Entwicklermodus in xDrip+ aktivieren. Gehe dann zu Einstellungen > xDrip+ Anzeigeeinstellungen und aktiviere “Smooth Sensor Noise (ultrasensitiv)”.
-
-
ich HABE keine verrauschten Werte
die Rohdaten ja, aber in xDrip hab ich schöne Kurven...btw bin ich grad schwer begeistert von der (wenn auch noch manuellen) "Hypoabschaltung". Im Gegensatz zum Medtronic-Algorithmus hab ich danach keine nennenswerten Anstiege (ok, ich muss natürlich mit ner TBR etwas gegensteuern, aber alles in allem geht's ganz gut auf)
-
Habe ja nicht gesagt Du hast verrauschte Werte, sondern es besteht die Möglichkeit verrauschte Werte zu glätten.
-
ich nehm das einfach raus und gut... ich steck ja eh grad fest, weil die Dana noch fehlt, also ist das Problem für mich noch akademischer Natur
-
Warum man mit aktiven KHs und bei temporären Zielen trotzdem SMBs nutzen kann, ist mir auch nicht ganz klar. Zumindest bei temp. Zielen erschließt sich mir nicht, warum die Genauigkeit der Werte nicht so wichtig sein soll...
Die Idee dahinter ist vermutlich, dass man zu diesen (begrenzten) Zeiten eh etwas aufmerksamer ist. Die "Angst" bei den Entwicklern dürfte eine Situation sein, in der z.b. nachts eine Fehlmessung auftritt und der Loop bis ans Limit insulin pumpt.
Finde die Entscheidung der Entwickler nicht gerade toll. Rauschen lässt sich ja in den Daten erkennen. In so einem Fall könnte man die SMB Funktion zeitweise automatisiert deaktivieren...da sollte man in meinen Augen mehr Zeit reinstecken als in neue Fragen...
Es gibt nicht den oder die Entwickler, sondern ganz verschiedene Gruppierungen, die jeweils ihre eigenen Gebiete bearbeiten. Auch AAPS und xDrip werden (mit Überschneidungen) seperat entwickelt, der Libre2-Part von xDrip stammt afaik auch von anderen Leuten als der Dexcom-Part.
Ein Grund für die große Skepsis gegenüber dem Libre (2) wird sicher der beinahe tödliche Zwischenfall mit dem Libre 1 gewesen sein, der zu sehr unrühmlichen Schlagzeilen und einer Warnung der FDA geführt hat.
Auch wenn ich selbst meine Libre-Kurven glatter finde als vieles, was so vom G6 gepostet wird, so hat der Libre seit diesem Zwischenfall irgendwie das Image als "Frickelsystem" wegbekommen. Das Chaos mit den sprunghaften Werten beim MiaoMiao2 etc. als sie ganz neu rausgekommen waren, hat es auch nicht besser gemacht.
Tendenziell scheint aber schon der Wunsch der Libre-Entwickler zu sein, die SMB-always auch mittelfristig mit dem Libre zu erlauben. Daher auch der relativ zähe Glättungsalgorithmus und die stark eingeschränkte Kalibrierbarkeit.
Finde die Entscheidung der Entwickler nicht gerade toll. Rauschen lässt sich ja in den Daten erkennen. In so einem Fall könnte man die SMB Funktion zeitweise automatisiert deaktivieren...da sollte man in meinen Augen mehr Zeit reinstecken als in neue Fragen...
Genau dafür gibt es aktuell auch einen Pull-Request, den z.b. Hubi gerade austestet. Aber dieser "wartet" halt schon ein paar Monate darauf, eingebaut zu werden. Man muss eben auch bedenken, dass die ganze Software in der Freizeit von den Leuten entwickelt wird und da sicher in der aktuellen Zeit auch andere Dinge auf der Prioritätsliste stehen.
-
in der z.b. nachts eine Fehlmessung auftritt und der Loop bis ans Limit insulin pumpt.
ja aber dafür kalibriert man doch, damit's keine oder möglichst keine Fehlmessungen gibt (und ich dachte, der Loop gibt "höchstens" SMBs ab und leert nicht gleich das ganze Reservoir... hey, da ist dann das brennen von manchen Insulinen ja vielleicht ne Sicherheitseinrichtung
)der beinahe tödliche Zwischenfall mit dem Libre 1 gewesen sein, der zu sehr unrühmlichen Schlagzeilen und einer Warnung der FDA geführt hat.
ui, was war denn da?
-
-
ja aber dafür kalibriert man doch, damit's keine oder möglichst keine Fehlmessungen gibt (und ich dachte, der Loop gibt "höchstens" SMBs ab und leert nicht gleich das ganze Reservoir... hey, da ist dann das brennen von manchen Insulinen ja vielleicht ne Sicherheitseinrichtung
)Naja, der Loop sollte ja genug Insulin abgeben können um eine Mahlzeit abzudecken (insbesondere beim "Kein-Bolus-Betrieb). Wenn ich mir die nötige Insulinmenge für eine volle Mahlzeit auf leeren Magen reinhaue dann sollte mein BZ rechnerisch weit im negativen sein.
ui, was war denn da?
Es gab nur die Warnung ohne genaue Fallbeschreibung. Was man aus den Infos rekonstruiert hat:
Jemand hatte einen Libre+MiaoMiao der dauerhaft zu tief gemessen hatte (vermutlich gezogener Sensorfaden). Dieser wurde dann auf den aktuellen (hyperglykämen) BZ kalibriert. Der Libre hat danach dann ne Flatline bei >200 gezogen und der Loop fleißig gegengesteuert. Bei der ersten symptomatischen Hypo hat die Person noch gegensteuern können, bei der zweiten ist sie dann aber in der Klinik gelandet.
-
Naja, der Loop sollte ja genug Insulin abgeben können um eine Mahlzeit abzudecken (insbesondere beim "Kein-Bolus-Betrieb). Wenn ich mir die nötige Insulinmenge für eine volle Mahlzeit auf leeren Magen reinhaue dann sollte mein BZ rechnerisch weit im negativen sein.
Du redest hier von UAM oder? Auch dort sind die SMB doch begrenzt auf die nächsten x Minuten Basalrate, d.h. der Loop haut dir eben nicht auf einmal die volle Insulinmenge für die Mahlzeit rein.
-
Könntest du das bitte nochmal genauer erklären, ich habe das so noch nicht verstanden.
Bisher habe ich immer den Code angepasst um mit dem Libre SMB immer nutzen zu können, Heißt das, das ist gar nicht nötig?
das habt ihr auf "true" umgestellt oder?
// public final static boolean enableSMB_always = false -
Auch dort sind die SMB doch begrenzt auf die nächsten x Minuten Basalrate, d.h. der Loop haut dir eben nicht auf einmal die volle Insulinmenge für die Mahlzeit rein.
Das stimmt, allerdings kann diese Menge dann alle 5 min abgegeben werden, d.h. ein einer Stunde kann der Loop im Extremfall 12x MaxBolus (SMB Minuten x Basalrate) abgeben. Wenn der BZ dann wie bei dem Vorfall der FDA einfach bei 280 "fest hängt" dann füllt der Loop so lange auf, bis maxIOB erreicht ist.
-
Auch dort sind die SMB doch begrenzt auf die nächsten x Minuten Basalrate, d.h. der Loop haut dir eben nicht auf einmal die volle Insulinmenge für die Mahlzeit rein.
Das stimmt, allerdings kann diese Menge dann alle 5 min abgegeben werden, d.h. ein einer Stunde kann der Loop im Extremfall 12x MaxBolus (SMB Minuten x Basalrate) abgeben. Wenn der BZ dann wie bei dem Vorfall der FDA einfach bei 280 "fest hängt" dann füllt der Loop so lange auf, bis maxIOB erreicht ist.
Okay, wir reden glaube ich aneinander vorbei. Wenn die Sensorwerte komplett falsch und extrem zu hoch sind, kann es natürlich vorkommen, dass der Loop einem viel zu viel Insulin gibt.
Ich war gedanklich eher noch bei den angeblich verrauschten Libre-Werten.
-
-
Wenn der BZ dann wie bei dem Vorfall der FDA einfach bei 280 "fest hängt" dann füllt der Loop so lange auf, bis maxIOB erreicht ist.
dann sollte man vielleicht in xDrip das Snooze bei hohen Werten auf 1h runter setzen, oder?
-
Naja, es ging in dem Fall nicht nur darum, dass der Loop allein etwas gemacht hat, die Person hat auch selbst Insulin gegeben (weil der BZ ja nicht fiel), so etwas kann halt auch normal passieren....
-
Naja, es ging in dem Fall nicht nur darum, dass der Loop allein etwas gemacht hat, die Person hat auch selbst Insulin gegeben (weil der BZ ja nicht fiel), so etwas kann halt auch normal passieren....
Das ist mir auch schon ein paar mal passiert. Mit Humalog ganz fies, mit Lyumjev händelbar... Mit viiiiiiel aufgelöste TZ an der Seite. 😉
Man lernt eben nie aus.
Und wie war das noch, der Fehler sitzt vor dem PC /der Technik. 🥴😜
-
Alles anzeigen
Warum man mit aktiven KHs und bei temporären Zielen trotzdem SMBs nutzen kann, ist mir auch nicht ganz klar. Zumindest bei temp. Zielen erschließt sich mir nicht, warum die Genauigkeit der Werte nicht so wichtig sein soll...
Die Idee dahinter ist vermutlich, dass man zu diesen (begrenzten) Zeiten eh etwas aufmerksamer ist. Die "Angst" bei den Entwicklern dürfte eine Situation sein, in der z.b. nachts eine Fehlmessung auftritt und der Loop bis ans Limit insulin pumpt.
Finde die Entscheidung der Entwickler nicht gerade toll. Rauschen lässt sich ja in den Daten erkennen. In so einem Fall könnte man die SMB Funktion zeitweise automatisiert deaktivieren...da sollte man in meinen Augen mehr Zeit reinstecken als in neue Fragen...
Es gibt nicht den oder die Entwickler, sondern ganz verschiedene Gruppierungen, die jeweils ihre eigenen Gebiete bearbeiten. Auch AAPS und xDrip werden (mit Überschneidungen) seperat entwickelt, der Libre2-Part von xDrip stammt afaik auch von anderen Leuten als der Dexcom-Part.
Ein Grund für die große Skepsis gegenüber dem Libre (2) wird sicher der beinahe tödliche Zwischenfall mit dem Libre 1 gewesen sein, der zu sehr unrühmlichen Schlagzeilen und einer Warnung der FDA geführt hat.
Auch wenn ich selbst meine Libre-Kurven glatter finde als vieles, was so vom G6 gepostet wird, so hat der Libre seit diesem Zwischenfall irgendwie das Image als "Frickelsystem" wegbekommen. Das Chaos mit den sprunghaften Werten beim MiaoMiao2 etc. als sie ganz neu rausgekommen waren, hat es auch nicht besser gemacht.
Tendenziell scheint aber schon der Wunsch der Libre-Entwickler zu sein, die SMB-always auch mittelfristig mit dem Libre zu erlauben. Daher auch der relativ zähe Glättungsalgorithmus und die stark eingeschränkte Kalibrierbarkeit.
Finde die Entscheidung der Entwickler nicht gerade toll. Rauschen lässt sich ja in den Daten erkennen. In so einem Fall könnte man die SMB Funktion zeitweise automatisiert deaktivieren...da sollte man in meinen Augen mehr Zeit reinstecken als in neue Fragen...
Genau dafür gibt es aktuell auch einen Pull-Request, den z.b. Hubi gerade austestet. Aber dieser "wartet" halt schon ein paar Monate darauf, eingebaut zu werden. Man muss eben auch bedenken, dass die ganze Software in der Freizeit von den Leuten entwickelt wird und da sicher in der aktuellen Zeit auch andere Dinge auf der Prioritätsliste stehen.
Hallo,
von diesem Zwischenfall habe ich bislang nichts gehört. Aber allem Anschein nach, lag hier auch ein Fehlverhalten des Benutzers vor. Wenn der G6 (warum auch immer) dauerhaft falsche Werte liefert, kann ich als Nutzer mir auch zu viel Insulin verabreichen.Ich weiß, dass die Programmierer hier dies alles in ihrer Freizeit machen oder zumindest zum größten Teil. Ich bin dankbar für deren Arbeit. Wenn es sich nicht gerade um Java/Kotlin handeln würde, sondern um Python, würde ich sogar meine Hilfe anbieten und unterstützen. Trotzdem fände ich es schön, wenn man den Libre 2 hier anders behandeln würde.
Grüße
-
von diesem Zwischenfall habe ich bislang nichts gehört. Aber allem Anschein nach, lag hier auch ein Fehlverhalten des Benutzers vor. Wenn der G6 (warum auch immer) dauerhaft falsche Werte liefert, kann ich als Nutzer mir auch zu viel Insulin verabreichen.
Dazu hatten sich die Entwickler von AAPS/xDrip im Looper Forum geäußert. Es war angeblich ein Kind mit Loop, dessen Eltern falsch gehandelt hatten. Die Ursache des Vorfalls lag eindeutig zwischen den Ohren. Es war aber der Grund, weshalb danach die Kalibrierung des Libre begrenzt wurde. Das Problem ist halt, dass es weltweit auch Looper gibt, die nicht genau wissen, was sie da machen.
Das Rauschen bzw. die Glättung der Werte des Libre und die damit begründete Limitierung der SMB ist aber ein anderes Thema, das auch in der Looper Community
https://de.loopercommunity.org/t/fsl-2-limitierung-smb/4538
heftig diskutiert wurde. Dort sind auch einige der Meinung, dass die Limitierung nicht mehr zeitgemäß ist. Insbesondere dideldum hat dort (und auch hier in ähnlichen Posts) eine Lanze für den Libre2 gebrochen, nachdem er auch den Dex verwendet hatte und keine Nachteile beim Libre sehen kann. Man hat aber als außenstehender Beobachter etwas den Eindruck, dass das bei den Entwicklern auf taube Ohren trifft.
Vielleicht versteht ich auch die Hintergründe und Details nicht vollständig. Soweit ich mich erinnere, soll der Dex eine bessere integrierte Plausibilitätsprüfung haben, der die Übertragung von fehlerhaften Werten ggf. abbricht, während der Libre auch unsinnige Werte weiter senden soll. Es stellt sich aber die Frage, ob das für den Libre2 auch noch gilt.
-
