Beiträge von FraOrolo

    Jede Minute wird mit Fehlern gefüllt,

    Aber es läuft alles fehlerfrei, bin nur per Zufall auf das log gestossen.


    Also mit MiaoMiao ist das bei mir nicht so. Da gibts am Ende auch den 1-Minute Trend und keine solchen Fehlermeldungen. Der LibreBlock enthaelt eigentlich alle bytes, die per NFC aus dem Sensor gelesen werden koennen, das ist die Grundlage fuer die weitere Anzeige und Uploads von xDrip.


    Eigentlich ist dabei auch "egal auf welchem Weg", also mit direktem Scan durch das Smartphone

    oder ueber einen Transmitter, der alle NFC-Daten weiterreicht.

    Das sollte also eigentlich mit BlueCon und MiaoMiao auch funktionieren.

    Ich such mal nach dem Logtext, wenn ich das naechste mal in die Sourcen schaue.


    LG

    Martin

    3. Generate a Signing keystore

    Wenn Du zum Bauen von AndroidAPS schon Android Studio installiert hast, da ist

    eine halbwegs brauchbare Oberflaeche fuer Keystores drin.


    Ansonsten sollten diese Parameter schon funktionieren:

    keytool -genkeypair -keyalg RSA -keysize 2048 -alias key0 -keystore myKeys.jks


    LG

    Martin

    Was hat Askorbat für eine Bedeutung bei Diabetes? Und warum könnte der Wert erhöht sein?

    Wenn jemand schon seinen Arzt darauf angesprochen hat, würde ich mich über Erklärungen freuen,

    Mein Arzt ist leider im Urlaub.

    Ich denke, das gleiche wie Vitamin-C an den Fingern: die Messung wird Richtung zu niedrig verfaelscht.

    Die Teststreifen oxidieren Glucose katalytisch und messen radikale Zwischenprodukte (H2O2). Antioxidantien reagieren mit den Zwischenprodukten , bauen sie ab und damit sieht der Messwert (falsch) zu tief aus.


    Dieses Paper hat das mal als Einzelfall dokumentiert, da wurde hochdosiertes Vitamin C als Therapie eingesetzt.


    LG

    Martin

    Der Nightscout Reporter braucht zb jede Stunde einen Eintrag in Nightscout ansonsten spinnt dieser.


    Hmm: Nein bei uns nicht.

    Wir haben tagsueber einen Block von 5 Stunden mit konstanter Rate.

    Nightscout Reporter macht daraus prima plots und kann auch BR-Diffs

    damit erstellen.


    LG

    Martin

    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