Beiträge von emp00

Warum ist denn das ein Problem? Die Mittelung/Glättung hat ja gerade den Sinn, daß man nicht von Ausreißer-Einzelwerten zu falschen Reaktionen verleitet wird. Die Technik mit einem kurzen Faden im Gewebe und diversen Einflüssen hat ja prinzip-bedingt ein Rauschen (Signal noise). Ich bin froh, daß xDrip das Signal glättet - wüsste nicht, warum eine Zeitverzögerung von 10 Minuten ein Problem sein sollte. Zumal wie hier auch schon beschrieben ja noch die Verzögerung Gewebe<->Blut-BZ hinzukommt... Mit CGM muß und kann man mit Glättung doch super leben, wo ist das Problem?

Kappa: Die Glättung in xDrip+ kann man ein/ausschalten, nach Bedarf

https://androidaps.readthedocs…lucose-Data-in-xDrip.html

https://testaaps.readthedocs.i…od-Glucose-Data-in-xDrip/

Warum meinst Du, daß es "abgeschafft werden soll", Quelle? Der Nutzer entscheidet ja selbständig, ob er das nutzen möchte und ein "Ausrufezeichen" steht daneben. Ich wäre jedenfalls nicht happy, wenn das "abgeschafft" werden würde

Zitat von Marani

deswegen hab ich mit dem Pen trotzdem keine Hypo-Abschaltung. Was drin ist, ist drin und wenn es zuviel war, kann ich nicht einfach die Basalrate aussetzen. Ich glaub nicht, dass das ne echte Konkurrenz ist, eher eine Verbesserung der ICT

Naja, mit ICT und CGM bekommt man ja die Alarme, hier z.B. den Hypo-Alarm -- und dann korrigiert der ICT-Mensch eben "ganz einfach" mit Saft/Gummibären&Co (was ja jeder Diabetiker griffbereit hat). Da verstehe ich nicht, daß das ein Killer-Kriterium für die Nutzung einer Pumpe sein soll... Weiterhin kann eine Basal-Abschaltung doch wohl kaum eine Insulin-Überdosierung von sagen wir 3-4 IE kompensieren. Dafür brauchen doch wohl auch die "Pumpis" eine Gummibär-Korrektur...

Bin auch der Meinung, daß die aller-meisten Diabetiker mit ICT + CGM sehr gut leben können. Ausnahmen gibt's immer, das ist klar. Eine Hypo-Abschaltung bei langsam fallendem BZ in der Nacht fände ich aus Bequemlichkeit natürlich auch klasse - ich muß dann eben 1x aufstehen. Funktioniert genauso

Eine noch bessere und "lernende" Vorhersage wie vom TE 2021 angefragt wäre aber sicher eine tolle Sache. Würde ich auch testen/nutzen wollen - auch wenn ich mit der xDrip+ Vorhersage schon sehr gut leben kann. Es könnte bestimmt noch besser gehen. Es muß eben nur jemand in die Hand nehmen und programmieren - xDrip+ ist open source und jeder kann sich beteiligen.

Leila: Auf welcher NS version läuft denn deine Instanz? Vielleicht veraltet? Schau mal nach, bei sagt's "About nightscout -- version 14.2.6"

Die ist auch aktuell, siehe https://github.com/nightscout/cgm-remote-monitor/releases

Wenn man die changelogs nach "auth" durchsucht, findet man viele Treffer wo "issues" mit tokens & co gefixt wurden.

Leila: Mit der Einstellung ist Deine Nightscout-Instanz *für alle* komplett lesend offen, d.h. wenn irgendjemand die Adresse hat, dann sieht derjenige alle Deine Daten: ohne Token!

Probiere es aus, tippe Deine NS-Adresse in den Browser ein oder in einen Browser von einem Freund ...

AUTH_DEFAULT_ROLES⌁

Possible values readable, denied, or any valid role name. When readable, anyone can view Nightscout without a token. Setting it to denied will require a token from every visit, using status-only will enable api-secret based login.

Hier auch eine deutsche Beschreibung dazu: https://nightscout-user-guide.…tscout/azure_plugins.html

Genau so geht das - ein halber Tag Geduld ist gefragt, dann läuft's.

Der Sensorfaden sitzt übrigens in der Injektionsnadel (es ist eine Hohlnadel) - noch ein Grund warum ich mir echt nicht vorstellen kann, daß es unter der Haut einen Knick geben kann...

Hier gibt's ein offizielles Video mit einer Schnittzeichung und Erklärungen dazu - wieder leider "nur" G5, aber siehe oben.

"Abgeknickter Faden unter der Haut" -- das kommt auch immer häufiger. Ich nehme an, das kommt daher, daß der Faden nach dem Entfernen/Rausziehen aus der Haut manchmal "geknickt" aussieht?

Wie der Faden mit dem Injektions-Mechanismus (Eine lange + schnurgerade Nadel sticht den Faden in die Haut und fährt wieder zurück) tatsächlich geknickt unter der Haut liegen kann, kann man das erklären? Wenn das wirklich so wäre, vielleicht weil der Faden beim Injizieren verrutscht (?) dann müsste das doch sowohl beim Injizieren als auch beim Rausziehen/Entfernen zu massiven Blutungen führen und das Gewebe auch ziemlich in Mitleidenschaft ziehen, was dann eigentlich tagelang weh tun+heilen müsste. Seid ihr daher sicher, daß "der Knick" nicht einfach beim Rausziehen/Entfernen entstanden ist? Dabei wird der Faden ja schon einiger Zugbelastung ausgesetzt, je nachdem wie man den rauszieht und ich denke dadurch wird so eine Krümmung dann entstehen.

So sieht jedenfalls die Injektions-Nadel aus (leider nur ein Bild vom G5 gefunden, aber beim G6 ist das ja mehr oder minder das gleiche, hier die Quelle davon)

Naja, das Produkt ist so gemacht, daß es mit möglichst vielen Menschen bestmöglich funktioniert und "Pre-Soaking" ist auch nicht das, was Dexcom eigentlich vorsieht. Wenn Du das machst, dann korrigiert der Transmitter die Werte ja falsch - denn er denkt, daß der Sensor frisch gesetzt wurde. Vielleicht ist das die Wurzel des Übels... Es wurden ja Unmengen an Tests gemacht und der Transmitter ist so programmiert, daß er bei Anwendung ohne Pre-Soaking best-möglich funktioniert. Ich mache das jedenfalls nicht - habe aber auch Sprünge oder dauerhaft zu tiefe Werte in den ersten ~24 Stunden. Das ist offenbar die Technik wie sie ist - besser geht's offenbar nicht, sonst würde Dexcom das schon entsprechend ändern. Es mag ein paar Tricks geben die bei dem einen oder anderen funktionieren aber ob das wirklich an den Tricks liegt, wie kann man das beweisen? Jeder Sensor läuft ja immer wieder etwas anders - das liegt an Mensch der dranhängt, der funktioniert eben jeden Tag ein bisschen anders. Das kann der Transmitter leider nicht 100%ig messen und drauf reagieren. Aber die Technik wird immer besser - und sie funktioniert ja nun auch so schon echt klasse, jedenfalls meine Meinung. Perfektion ist leider unerreichbar bei sowas, behaupte ich mal.

"Am nächsten Morgen passts wieder" - das hört sich an, also wenn Du hier einen frisch gesetzten Sensor meinst. Das ist dann auch wieder ganz normal - wegen dem Wundtrauma springt die Anzeige ja leider gottgegeben in den ersten ~24 Stunden, manchmal länger, meistens etwas kürzer. In dieser Phase macht kalibrieren auch keinen Sinn - ich kann mir vorstellen, daß der Transmitter das inzwischen auch genau deswegen blockiert. Schätze ich mal.

Wenn die Abwehrkräfte den Sensorfaden attackieren gibt's eben keine zuverlässige Messung - bei einer Kalibrierung würden dann die Werte "am nächsten Morgen" nicht mehr passen, daher macht's ja Sinn so eine Aktion zu blocken. Der Transmitter und Dexcom ist schlauer als wir denken!

Zitat von Marani

Die Anleitung kenne ich, die 20% halte ich bewusst ein. Meine Wartezeit ist vermutlich sogar länger zwischen den Kalibrierungen

Dann noch der "letzte" wichtige Aspekt: Nur dann kalibrieren, wenn der BZ-Verlauf "Flatline" ist, d.h. in den letzten und darauffolgenden ~15 Minuten nicht mehr als ca. 10 mg/dl steigt oder fällt (diese Zahlen sind nur aus meinem Bauch, die genauen Grenzwerte sind ja leider nicht dokumentiert). Der Transmitter akzeptiert jedenfalls keine Kalibrierung wenn die Werte zu stark steigen oder fallen. viel mehr Kriterien zusammen mit denen da aoben gibt's dann aber nicht... Dann muß es klappen.

Die "Kalibrierungs-Tabelle" ist bei aktuellen G6-Transmittern (seit ~2 Jahren) nicht mehr relevant, da die Kalibrierung inzwischen nur noch in der Transmitter-Elektronik abläuft. Früher wurden noch "Raw" Werte von den ersten G6-Transmittern (80/81-Generation) geliefert und xDrip hat die Werte dann "selbst" kalibriert/umgerechnet. Das läuft seit langem nur noch in der Transmitter-Black-Box.

Marani: Das nicht Annehmen von Kalibrierungen mit xDrip betrifft bei Dir das "runterkalibrieren" beim verlängern, oder?

Das geht leider nicht ganz ohne Komplikationen (weil der Transmitter das nur unter strengen Randbedingungen zulässt - wenn das nicht passt, dann wird die Kalibrierung ignoriert). Hier steht wie das nach Erfahrungen vieler User geht - es geht tatsächlich kaum anders, also ganz genau befolgen. Dann geht's - das ist auch meine Erfahrung. Beachte v.a. auch die Wartezeiten, nicht nur 20% (!)

https://navid200.github.io/xDr…rate-after-G6Restart.html

Herr Sommer : Hab's gelesen, aber das ist ja keine Antwort auf die Frage, warum "Cache löschen" für die hier thematisierten Bluetooth-Verbindungsprobleme die Problemlösung sein soll... Ich bin halt fest überzeugt, daß das dagegen technisch garnicht helfen kann. Beziehungsweise nur dann, wenn die App einen dicken Programmfehler hat und veraltete Cache-Daten für Bluetooth-Verbindungs-Aktivitäten verwendet obwohl sie schon ungültig sind. Daß der User oder Spezial-Reinigungsprogramme sowas machen müssen ist aus meiner Sicht nur für eins gut -> für die Supporter die den Kunden abgewimmelt haben und für die Firmen, die solche Lösch-Programme sogar für Geld verkaufen. Sowas würde ich jedenrfalls nicht kaufen und ich lösche auch meinen Browser-Cache nie. Das macht der Browser vollautomatisch im Hintergrund, jedenfalls meiner Im Browser kann ich übrigens auch einstellen, daß kein Cache benutzt werden soll. Das wäre dann auch hier in der App zumindest eine Lösung, die dem User die unsägliche Aufgabe abnimmt den Cache manuell zu löschen (weil die App falsch damit umgeht) ... Man beweise das Gegenteil

Ich frage mich immer ob "Cache leeren" tatsächlich irgendeinen technischen Sinn hat. Der Cache ist ja nur ein temporärer Zwischenspeicher. Der wird vom Betriebssystem voll-automatisch gemanaged, d.h. geleert wenn der Platz knapp wird. Wenn die App auf den Cache zugreift aber falsch damit weiterrechnet, weil die Daten z.B. veraltet/ungültig sind, dann ist das doch klar ein Fehler in der App - wenn das wirklich das Problem ist, dann kann und muß der App-Hersteller den Bug fixen. Im einfachsten Fall, wenn der Fehler erstmal nicht anders behoben werden kann (was ein Unding wäre) dann könnte die Cache-Nutzung der App komplett abgeschaltet werden -- oder der User sollte wenigstens die Möglichkeit haben die Cache-Nutzung "mit Schalter" abzuschalten. Aber dann eben nur 1x und nicht "immer wenn mal wieder die BT-Verbindung abbricht"...

Ich habe jedenfalls immer das Gefühl, daß die Support-Empfehlung "Cache leeren" nur eine leere Farce ist - bringt wissentlich gar-nichts, außer daß der User erstmal "ruhig" ist, weil er hat ja eine Aktion gemacht hat. Ein technischer Wirk-Mechanismus gegen solche BT-Probleme durch Cache leeren, außer siehe oben = krasser Programmfehler, keine Idee... Oder kann das jemand noch anders fachlich erklären?

Zitat von Nomis

Medikamente allgemein: So wie ich das verstanden habe gibt es auf dem Markt genug, nur die Pharma verlangt 50% mehr Geld und die Krankenkassen setzen das um.

Woher kommt denn diese konkrete Information? Bitte um Quellenangabe mit Beweisen/Fakten. Danke.

Matthias80: Ich habe keine WearOS Smartwatch aber kennst Du das hier? Zur Schrittlängen-Einstellung steht da glaube ich nichts - ich vermute, daß Du das in der WearOS-Smartwatch-App direkt einstellen musst, da xDrip+ nur die Daten darstellt, die es von dort bekommt. Lies mal, vielleicht kommst Du damit weiter:

- https://xdrip.readthedocs.io/e…st/smartwatch/smartwatch/

- https://xdrip.readthedocs.io/en/latest/smartwatch/wear/

Zitat von Mati

Kann es sein, dass nach meiner Erkältung die Bauchspeicheldrüse ihre Insulinproduktion ganz aufgegeben hat?

Hast Du denn noch eine Restfunktion? Laut Profil TypI seit 5/2019, das sind drei-einhalb Jahre. Ich dachte die Remissionsphase dauert maximal 2 Jahre.

Aber grundsätzlich ja, eine Krankheit inkl. Erkältung kann durchaus den Insulinbedarf beeinflussen, Da macht jeder mal so seine Erfahrungen. Bei Dir das erste Mal?

Zitat von Joerg Moeller

Ich stand heute Morgen z.B. kurz vor einer UZ und hab neben dem Traubenzucker auch meine Basalversorgung für drei Stunden auf 70% gesetzt.

Nur für mich als unwissenden Standard-ICT'ler: Hätte dafür nicht eine etwas höhere TZ-Dosis oder noch besser einfach das Essen einer simplen Banane oder das ganz normale Frühstück mit reduzierter Insulindosis genau den gleichen Effekt gehabt? Das erscheint mir jedenfalls viel einfacher als umständlich die Dosis an der Pumpe "auf Gut Glück" auf 70% zu reduzieren und dann dran denken zu müssen rechtzeitig wieder auf 100% hochzudrehen.

Was ich verstehe: Eine Pumpe macht Sinn, wenn sich der Basalbedarf mit den Verzögerungsinsulinen nicht ausreichend nachbilden lässt weil der Bedarf stark tageszeitabhängig ist. Aber für obiges 3h-Beispiel hätte ich einfach passend Kohlenhydrate eingeworfen - dafür bräuchte ich keine Pumpe.

Zitat von jebir

https://amp.focus.de/gesundhei…-menschen_id_9964610.html

Wenn man jetzt weiß, das es in 12 Jahren Engpässe geben wird, muss man noch nicht handeln...

Focus

Hast Du den "Lancet" Artikel gelesen? Der Titel der Studie lautet "Estimation of global insulin use for type 2 diabetes, 2018–30: a microsimulation analysis" - mit anderen Worten werden dort aktuelle Schätzungen zum Anstieg der TypII-Fälle und dem zugehörigen Insulinbedarf skizziert und simuliert.

Daß Focus das nun in dem verlinkten, reißerischen Artikel mit der Überschrift "Rasanter Anstieg von Diabetes: Insulin-Engpass bedroht 40 Millionen Menschen" verpackt - ist ja bezeichnend...

Natürlich ist es eine seit Jahrzehnten bekannte Entwicklung, daß die Diabetesfälle steigen und weiter steigen und damit natürlich auch der Insulinbedarf steigt. Daraus auf Basis der Lancet-Veröffentlichung einen "Engpass" zu konstruieren ist super um die Klickzahlen zu erhöhen - aber was hat das mit seriösen Fakten zu tun?

Die Insulinhersteller kennen die Marktentwicklung (besser als wir und jeder andere) und werden sich freuen, diesen wachsenden Markt durch Expansion weiter bedienen zu können. Die "Profitgier" der Hersteller soll laut Focus einen Engpass erzeugen? Na, dann wissen wir ja jetzt Bescheid und wir werden alle sterben. Die hier gemeldeten Engpässe in den Apotheken sind der Anfang vom Ende

Leute, nehmt es locker