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
Meine Tochter hat mal Apfelspalten auf einen Obstkuchen gepackt, die ich vorher gegen Braunfärbung mit Vitamin C behandelt hatte.
Danach hatten wir Fingerwerte 50mg% unter Sensormessung. Nach Händewaschen wars wieder normal.
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.
Zitat3) 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
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
Alles anzeigen1. es gibt neue Features /Verbesserungen und vor allem Bugfixes
2. der Support der alten (und oft wirklich sehr alten Versionen) ist nicht zu leisten
3. es hat Sicherheitsgründe...denn es soll niemand durch ein veraltetes System zu schaden kommen ...
...Oder kauft euch neue Handys, wenn es Zeit dafür ist! Software entwickelt sich nun mal schnell und daher sind die Abstände zwischen einzelnen Entwicklungen entsprechend kurz.
Wenn man sich für ein DIY System entscheidet, dann muss einem klar sein, dass man auf dem Laufenden bleiben muss
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
wird dieser Wert irgendwo ausgewertet? Bei mir steht 90-100 mg/dl
Ja, das ist bei AAPS der Zielbereich, aus dem die Regelung des Loops abgeleitet wird (NightScout Profil). OpenAPS wird wahrscheinlich aehnlich reagieren.
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
Alles anzeigenAlles anzeigendas L2 schein entschlüsselt zu sein
Wunderbar! Herrlich! Der erste Teil ist vollbracht. Freut mich außerordentlich!
Was auch immer Abbott damit erreichen wollte. Es führt nicht zwangsweise dazu, dass kreative Lösungen mit Umstellung auf Libre 2 eingestampft werden müssen. Selbst wenn, was ich vermute, die Übertragungshardware neu angeschafft werden muss, ist das ein guter Schritt vorwärts.
Dann lasst uns jetzt gemeinsam die Daumen drücken für die Bluetooth-Entschlüsselung.
Liebe Grüße vom Arbyter
naja, kommerzielle Produkte, die eine Verschlüsselung umgehen, haben es in der EU schwer. Während wenn etwas offen ist, kann das jeder anzapfen ohne dass man einen Euro daran verdient.
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
