Beiträge von FraOrolo

    Es gibt dazu ein Issue auf Github auch mit Logfile und Bildern. Scheinbar merkt der loop sogar wenn sich der Wert gar nicht ändert aber in diesem Fall war wohl eine geringe Schwankung um wenige Punkte da.

    Das wollen sie jetzt korrigieren aber wenn der Fehler das nächste Mal etwas anders aussieht klappt es natürlich nicht mehr.

    Danke!


    Der Loop ist aber gar nicht der Kern dieses Problems. Jede Kalibrierung mit Regression sollte eigentlich 2 Schritte haben: Datenpunkte abgleichen (slope und intercept ausrechnen) und Validitaet pruefen. Wenn da BG [mg%] = 2 * isf + 100 rauskommt, brauch ich fuer einen 60er BG einen Rohwert von -20. Das ist unmoeglich, negativer Strom wird nie gemessen.

    Der technische Trick sollten also plausible Grenzwerte fuer die Parameter sein. Falls die Kalibrierung was anderes ausrechnet, leited xDrip die Werte nicht mehr weiter und zeigt selbst alle Zahlen in rot...


    LG

    Martin

    Aber man muss die Kalibrierung ernst nehmen und man kann sich natuerlich auch die Werte versauen



    Genauso scheinen auch die Vorfälle bisher passiert zu sein, zumindest einer der inzwischen reportet wurde: Dort hat der Sensor quasi dauerhaft LOW angezeigt hat und wurde dann (warum auch immer) einfach auf den (hohen) Blutwert kalibriert.

    Hast Du dafür einen Link / eine Quelle?

    Das Problem wäre ja sogar technisch vermeidbar...


    LG

    Martin

    Beim DIY-Closed-Loop gibt es mMn nach drei Fehlerquellen:


    1) Da der Umrechnungsweg von Sensor-Rohdaten zu Blutzuckerwerten nicht öffentlich bekannt ist, müssen DIY-Entwickler Formeln entwickeln die "so ähnliche und meistens passende" Ergebnisse liefern.

    So verkehrt sind die Formeln nicht. Aber bei jedem Closed Loop ist tatsaechlich das CGM ein wichtiger Fehlermode.
    Es ist mit einem Sensor sehr schwer automatisch zu prüfen, ob in den Messungen was falsch läuft. Das kann derzeit nur der Nutzer selbst tun (Gegenmessen am Finger).
    Und im Zweifel muss die Loop halt ausgeschaltet bleiben.


    Zitat

    3) In der Theorie ist es ein "Schutz" dass man die Apps selbst compilieren muss. Einmal ein rechtlicher Schutz und zweitens ein Zwang sich mit der Technik etwas zu beschäftigen bevor man sie verwendet ...

    Aber hier kann man es drehen und wenden wie man will: Es ist DIY -- entweder man weiss was man tut und hat das Hirn angeschaltet, oder man sollte DIY lieber lassen.

    Man kann sein Auto auch vom "Kumpel" im Hinterhof mit "Ersatzteilen fast wie neu" bei 'ner Kiste Bier reparieren lassen.

    Mit eingeschaltetem Brain 1.0 tut man das besser nicht ...


    LG

    Martin



    LG

    Martin

    Aber die Abweichungen ggü. blutigen Messungen waren bei mir teilweise extrem. Da kam es schon mal zu 120 blutig zu 300 libre.

    Sehr seltsam. Ich kann mit Glimp oder xDrip den Libre gut und sicher auslesen. Aber man muss die Kalibrierung ernst nehmen und man kann sich natuerlich auch die Werte versauen (z.B. Kalibrieren wenn der Sensor sich noch nicht gesetzt hat oder wenn der Faden durch Herausziehen/Mikrotrauma kaum Gewebskontakt hat).
    Und auch G6-Nutzer haben hier schon von wild springenden Werten berichtet -- das perfekte CGMs gibts leider noch nicht. Und für Reduntante Messungen sind die Dinger noch zu teuer.


    Und ja, bei DIY traegt man die Verantwortung für seine Fehler und sollte Doppelchecks und Checklisten kennen. Wenn man selbst die Lampe im Bad installiert oder die Bremsbelaege am Auto auswechselt, ist das genauso. Darf man alles legal machen -- ist aber sicher nicht jedermanns Sachen.
    (und ja, all das hab ich in meinem Leben auch schon gemacht).


    Für "ich hab da jetzt die App dafür, und brauch nicht mehr über den Diabetes nachdenken" stehen eigentlich zu viele Warnungen und Disclaimer in der Software und Dokumentation. Und bei OpenAps, AAPS und xDrip stehen die ja wirklich da, bei LibreLink steht nix, und da kommen trotzdem teilweise lausige Werte raus.


    LG,

    Martin

    Weiß jemand , ob der miaomiao durch den Anwender selbst für das libre 2 upgedatet werden kann ?

    -vorausgesetzt es gibt eine neue Firmware-

    Hat der miaomiao eine USB Schnittstelle?

    Bzw. Ist eigene Software zum miaomiao mit im Lieferumfang enthalten ?

    Der miaomiao basiert (wie der blueReader) auf einem Chip von NordicSemi. Dieser hat die Möglichkeit eingebaut, per Bluetooth eine neue Firmware aufzuspielen. Das geht dann einfach mit einer Standardsoftware von Nordic und einem Android-Smartphone.


    LG

    Martin

    Früher war das durch die 4 Jahre begrenzte Laufzeit vorgegeben, doch die Hersteller mussten umdenken und den Zwangstod ändern.

    Was passiert eigentlich, wenn der Laufzeit-Countdown (Tage) in der Insight auf <= 0 runter ist?

    Bleibt die dann stehen oder piept sie alle Stunde mal?


    LG

    Martin

    Hey,


    nur keine Ausreden bitte, man kann sogar ins nicht-EU Ausland taeglich mit dem Fahrrad zur Arbeit pendeln und seine Strecken dann hier bei BikeToWork mitloggen. ;)
    Zur Motivation brauch ich solche Aktionen eigentlich auch nicht, ich fahr meine 17km (single) eh an >200 Tagen im Jahr.
    "Wo waer ich nur ohne Fahrrad, bzw. wie kaem ich denn da hin"

    LG

    Martin

    Warten wir also weiter auf die Forscher, die vor der Publikation ihrer Dummheiten bis zum Ende nachdenken.

    Naja ich weiss nicht: Irgendwie praesentiert das Paper hinter dem Artikel aus #25 ja eine etwas andere Theorie, warum die Betazellen sterben.
    Eben nicht primaer externe Immunaktion durch T-Zellen sondern zellinternes Triggern von Apoptose, durch ueberexprimiertes Protein.
    Da das Immunsystem bei Gewebsumbauaktionen immer mithilft, den Schutt (tote / apoptotisierte Zellen) abzuraeumen, ist es nicht so einfach primaere Ursache und Wirkung zu unterscheiden.


    In den Maeusemodellen wurde als Trigger fuer die finale Betazellkrise gefunden, dass die Pankreas von sich aus in einer bestimmten Lebensphase Gewebsumbau betreibt und Betazellen dabei ordnungsgemaess absterben. Diese massenhaften toten Zellen sind dann aber der Anlass, warum T-Zellen sich deren Proteine als Antigen merken und spaeter diese Targets angreifen.

    Ob das jetzt fuer die Heilung von voll etabliertem T1D hilft? Fraglich!
    Aber wenn man den Zustand mit einem aussagekraeftigen Marker vor Etablierung finden und dann mit einem einfacheren Medikament die Entwicklung von T1D blocken kann...


    LG

    Martin

    Warten wir also weiter auf die Forscher, die vor der Publikation ihrer Dummheiten bis zum Ende nachdenken.

    Naja ich weiss nicht: Irgendwie praesentiert das Paper hinter dem Artikel aus #25 ja eine etwas andere Theorie, warum die Betazellen sterben.
    Eben nicht primaer externe Immunaktion durch T-Zellen sondern zellinternes Triggern von Apoptose, durch ueberexprimiertes Protein.
    Da das Immunsystem bei Gewebsumbauaktionen immer mithilft, den Schutt (tote / apoptotisierte Zellen) abzuraeumen, ist es nicht so einfach primaere Ursache und Wirkung zu unterscheiden.


    In den Maeusemodellen wurde als Trigger fuer die finale Betazellkrise gefunden, dass die Pankreas von sich aus in einer bestimmten Lebensphase Gewebsumbau betreibt und Betazellen dabei ordnungsgemaess absterben. Diese massenhaften toten Zellen sind dann aber der Anlass, warum T-Zellen sich deren Proteine als Antigen merken und spaeter diese Targets angreifen.

    Ob das jetzt fuer die Heilung von voll etabliertem T1D hilft? Fraglich!
    Aber wenn man den Zustand mit einem aussagekraeftigen Marker vor Etablierung finden und dann mit einem einfacheren Medikament die Entwicklung von T1D blocken kann...


    LG

    Martin

    Bin jetzt bei Ziel4 (5 Tage können lang sein), und immer wieder stellt mir das Programm automatisch auf TBR für 30 Minuten (meist zwischen 50-80%), auch wenn mein BZ um die 200 liegt. Logisch wäre doch die TBR nach oben anzuheben (z.B. +150% oder 200%), solange bis der Wert an die Norm rankommt (bei mir als BZ120 definiert). Hat jemand eine Idee wie ich auch mit AAPS in den Normbereich komme? Habe schon den ISF verändert aber der reagiert weiter so.

    Ohne jetzt Kurven zu sehen, ist es schwer was zu sagen. Vom Gefuehl wuerde ich denken dass ISF und IC die Schrauben sind, die da noch nicht stimmen. Schau die die Prediktorkurven an -- geregelt wird immer auf dem erwarteten Wert in der Zukunft (welche Werte genau steht auf dem Tab mit dem OpenAPS output).
    Bei abgesenkter TBR und 200 erwartet das Skript offenbar, dass Dein IOB noch maechtig reinhaut.
    Ich musste die Faktoren damals in Zeitbloecke aufteilen -- circadiane Hormonphasen analog dem Basalprofil.

    LG

    Martin

    Das ist alles nur teilweise richtig: AAPS ist ein Sammelsurium aus Plugins, die alle möglichen Pumpen, CGMS, externe APPS und Services verbindet.

    Allein die Kombinatorik aller dieser Teile (+ dutzende optionale Config) macht das Teil in Gänze ziemlich untestable.

    Mit jeder Release werden ein paar Bugs gefixed, und neue Features eingeführt (und der Code optimiert /refactored).
    So wie Bugfixing der Prozess ist, die Bugs rauszubekommen ist Programmieren der Vorgang neue Bugs reinzumachen.
    Ich nehm das ganze relativ ernst, weil ich selbst professionell seit 20 Jahren Software schreibe.
    Deswegen teste ich die Versionen selbst, bevor ich sie produktiv einsetze.

    Wenn das Entwicklerteam die alten Versionen nicht unterstützen mag, dann solln sie es eben lassen und entsprechende Issues mit Verweis auf 'latest stable' einfach schliessen.
    Und nein mit einer open source DIY Software ist normalerweise kein Updatezwang verbunden. Im Gegenteil -- Wenn ich eine Version habe, bei der die 6 aktiv von mir benutzen Plugins auf meiner Hardware fehlerfrei funktionieren, dann werd ich den Teufel tun und mir die neuen Bugs ohne Not runterladen.


    Und nicht missverstehn, nein AndroidAPS ist keine schlechte Software. Aber natuerlich hat es die QA eines guten Open-Source-Projektes mit Freizeitentwicklern.

    Und in dem Rahmen rolling release mit forced Update zu fahren ... halte ich ganz persönlich für deutlich übertrieben.


    Und ja ich kauf mir ein neues Handy, wenn das alte kaputt ist. Das kann durchaus 4-5 Jahre dauern...

    LG

    Martin

    ...

    Der Updateprozess dauert bei mir inkl. Update der App auf dem Smartphone vielleicht 5 Minuten. Aber ich habe auch die Version 2.2.2 gesichert und auf dem Smartphone als Back up, obwohl ich jedes Update sofort installiere.

    a) die Zeit glaub ich nicht ... und ich bin Vollzeitentwickler

    b) Allein schon die aktuelle Android Studio Version macht das Kompilieren ziemlich haklig, ohne UI funktionieren die gradle-scripte aber nicht.

    c) Mit fast allen Updates sind nicht nur Fixes sondern auch Refactorings und neue Features drin.
    E.g. bei 2.3 ist im Moment unklar, warum der Broadcast-Transfer von BG-Messungen aus Xdrip manchmal nicht geht...

    Insofern behalte ich mir auch die Moeglichkeit vor, auf einem alten Stand zu bleiben, bei dem alle fuer mich wichtigen/genutzten Features zufriedenstellend funktionieren. (Never change, what isn't broken)
    Bei einer Testcoverage von 15% und jeder Menge Abhaengigkeit von Hardware, anderen Apps und Netzwerk (Nightscout) glaub ich auch nicht, dass man den Code einfach sicher umbauen kann. Also bleibt wohl nur, dass ich Updates mit meiner Config kritisch teste, bevor ich sie produktiv einsetze. Und dafuer muss ich Zeit und Zeitpunkt planen koennen.
    Man kann mit Git durchaus einen Branch betreiben, in dem der VersionChecker aus ist und dann Rebase oder Cherry-Pick durchfuehren...
    (Details omitted)

    LG

    Martin

    Aber auch kein Abbau durch den Kontakt mit dem Gewebe?

    Du meinst sowas wie Proteolyse? Die eigentliche Kunst bei den Sensoren besteht wohl in der "Verpackung" der Elektroden + Enzym in einer Membran. Die sorgt dafuer dass Glucose nur langsam Richtung Elektrode diffundiert und haelt auch die Hilfsstoffe an der Elektrode fest. Es wuerde mich sehr wundern, wenn koerpereigene Enzyme (grosse Molekuele) diese Membran durchdringen und das ElektrodenEnzym zerstoeren.
    Was wohl eine Rolle spielt, ist die 'Korrosion' der Elektroden durch die intern entstehenden Reaktionsprodukte (H2O2), aber auch das wird wohl durch Hilfsstoffe unterdrueckt.


    LG

    Martin

    Ich hab das auch mehrfach schon beobachtet: 12 - 24 Stunden nach Ablauf sind die Sensoren am Ende und zeigen ab dann immer das selbe Niveau. Ich nehme an, die Enzyme des Fadens sind dann aufgebraucht.

    Nee, die Firmware des Sensors schaltet dann endgültig ab.
    Die Software im Lesegerät macht ja nach genau 20160 Minuten dicht und liest nichts mehr aus, die Firmware auf dem Chip hört 720 Minuten später auf.
    Die Alterung des Fadens und der Setzstelle ist ein kontinuierlicher Prozess, da ist nicht von einer Minute auf die andere etwas alle. Die Signale werden in den 14 Tagen aber schon etwas schwaecher (gegen Ende muss man die Rohwerte mit einem größeren Faktor multiplizieren). Meines Wissens nach ist Wundheilung ein wesentlicher Punkt.

    Das Enzym selbst ist im übrigen ein Katalysator, der verbraucht sich nicht. Was verbraucht wird sind eventuell ein paar Hilfsstoffe für den Elektronentransfer und aktive Bestandteile der Elektrodenmembran (die unter anderem die Wundheilung verlangsamen).


    Mutige Dexcom-Nutzer haben des öfteren die Sensorelektronik mehrfach auf dem gleichen Faden gestartet und damit Nutzungszeiten > 30 Tage erreicht (manuell kalibriert).

    Ich denke soo viel anders würde ein Libre-Sensor auch nicht reagieren, aber ein Restart der Firmware funktioniert bei dem Sensor nicht.


    LG,

    Martin

    mein Sensor ist gerade mal 7 Tage alt und zeigt bereits Sprünge nach oben und nach unten, die bei mir normalerweise erst nach 12-14 Tagen auftreten kurz bevor der Sensor sich verabschiedet.



    Wie geht ihr damit um, kalibrieren, einen neuen Sensor setzen oder eventuell abwarten, dass er sich wieder stabilisiert?

    Rechnet die original Dexcom Software diesen Verlauf aus, oder empfaengst Du dieses Signal direkt mit xDrip (nicht mit der "native" Methode? )
    Das sieht schon jumpy aus, ich dachte G6 waere besser als "raw Libre signal". Bei solchem Input hab ich SMB lieber ausgemacht.

    Lg
    Martin

    okay, die Werte sollten passen, da diese für jede Stunde hinterlegt sind und mit Autotune ermittelt wurden. Geringste ISF bspw. zwischen 20:00-21:00Uhr mit 0,7/mmol pro 1.0IE. Was habt ihr für Werte bei der Kohlenhydrat Aktivität? Ich habe 25g/ Std. bei 55kg, weibl. angegeben. Vielleicht liegt es daran. Aber die ISF werde ich auch noch einmal checken...

    Den Carb resorption factor in g/h kannst Du knicken. Laut Scott Leibrandt wird der in SMB nicht mehr genutzt (und der sollte das wohl wissen).

    Ich glaub die COB-Abschaetzung in Nightscout nutzt den Faktor noch.


    SMB mit UAM rechnet die COB aus den Sensorwerten und der erwarteten Absenkung nach ISF und IC Faktor aus. Die Faktoren sollten stimmen -- eventuell zeitabhaengig.
    Was sonst noch eine Rolle spielt ist der min_5m_carbimpact. Die Zahl bestimmt AFAIK die minimale Sinkrate fuer COB.


    LG

    Martin

    Nunja, fuer das BT-Protokoll brauchst Du ja auch kein kommerzielles Zwischenteil. (Transmitter)
    Wenn xDrip das Entschluesseln des BT-Protokoll beherrscht, waere der L2 der wahrscheinlich flachste Sensor wo gibt.


    LG,

    Martin

    ... beweisen dass die Behandlung mit Hitze (und wir reden ja in dem Fall von mehr als 40grad, was dem Standard Höchstwert für langzeit-versuche entspricht) die Messgenauigkeit des Sensors nicht beeinträchtigt.

    Seh ich nicht ganz so kritisch. Typische Elektronik kann 0-70 Grad einfach laut Datenblatt ab. Sonst koenntest Du die SMD-Platine auch nicht loeten. Den Sensorfaden steckt ja sowieso erst der Anwender an die Elektronik, der ist nicht betroffen.


    LG

    Martin

    Warum auch? Hat Abbott mich gezwungen den Sensor zu tragen?

    Laut der hier besprochenen chemischen Analyse verwendet Abbot zum Verkleben des Sensorgehaeuses das Monomer Isobornylacrylat, was durchaus als Allergen bekannt ist. Wenn das offiziell und gewollt waere, muesste das wohl im Beipackzettel stehen.


    Das Problem wurde von Benutzern duch "Abdampfen" des Sensoroberteils geloest. Das waere ja durchaus auch in der Produktion bei Abbot implementierbar.

    Bisher blocken die aber einfach nur ab.


    LG

    Martin