Beiträge von FraOrolo

    ist zwar hier ein wenig off-topic, aber ... wie machst Du das?

    Da ich ja vom Bubble (Transmitter) mit dem Libre 2 kam, hatte ich auch mit dem Libre 3 in xDrip den BT-Watchdog mit 10 Min. noch an (ebenso auch die Option "Aggressive Diensteneustart"). Aber mit dem Wechsel der Datenquelle von "Libre Bluetooth" auf "Libre2 (patched App) scheint bei mir der BT-Watchdog nicht mehr anzuschlagen, auch nicht bei 20 Min. Timeout.

    Ich habe XDrip schon mit vielen Configs probiert, Bluereader, MiaoMiao, Libre2Patched laufen gehabt dann sehr lange xDrip follower.
    Im Moment ist bei mir der BT-Watchdog und aggressive restarts an. Und beobachtbar geht das BT aus wenn mehrere Minuten die Daten fehlen.
    Allerdings geht es in der L3 App nach dem BT-Reset trotzdem nicht automatisch weiter...
    Aber warum das bei Dir nicht geht, kann ich nicht sagen. Der Xdrip code ist auch nicht wirklich einfach zu verstehn in diesem Subsystem.

    LG
    Martin


    Insofern könnte es vielleicht mal ein Versuch wert sein, einen BT-Reset in juggluco einzubauen. Bei mir (Patched-L3-App, Juggluco 4.2.7, Samsung Galaxy S20-5G mit Anroid 13) hat bisher immer ein einfaches aus- und einschalten von BT dazu geführt, dass wieder Werte ankamen. Wäre halt schön, wenn man das automatisieren könnte.

    Bei mir macht XDrip das im L2-Patched App modus auch. (also nach einer Weile wird BT runtergefahren und ein paar Sekunden spaeter wieder angeschaltet). Allerdings ist das Timeout dafuer mindestens 10-15 Minuten. Das heisst eine Luecke hat man in jedem Fall.
    Im Uebrigen brechen bei mir die Verbindungen zwischen Sensor und L3App auch unter Android 9 weg.


    LG
    Martin

    Ein Benutzer hat ein ähnliches Problem geschildert: Verbindung i.O. aber keine Werte in Juggluco. Schien an der neusten Juggluco Version (4.2.7) gelegen zu haben, nach dem installieren der alten Version & resync klappte alles.


    Hier alle Tipps: Link englisch

    Oder der direkte Download der älteren (2.x) Juggluco Version: Downloadlink

    Ich habs eine Stunde spaeter auch mit der neuen Version hinbekommen.
    Es fuehlte sich so an, als wenn in der App staendig Exceptions passieren, die Menues wurden nur manchmal gezeigt und manchmal wurde die App ganz geschlossen.
    Ich hab dann USB-ADB angeschlossen um mir zumindest das Log anzuschauen, Grmpf -- dann gings ploetzlich und ich hatte Werte.


    Also bei mir laeuft jetzt 4.2.7 mit dem Mirror feed aus der Libre3 app.
    Allerdings hab auch ich mit BT connection drops zu kaempfen. Eigentlich sind alle Akkuoptimierungen von Libre3, Juggluco und XDrip entfernt.
    Gefaellt mir noch nicht fuer den Produktiveinsatz mit Loop. Xdrip mit MiaoMiao war da stabiler (vielleicht auch durch die ganzen Auto-Restart und BT Reset timer).

    LG
    Martin

    Nur für Leute, die 2 Apps nutzen wollen (wie ich):

    LibreApp patched + juglucco funktionieren auch gemeinsam.


    Die Libreapp ist zwar nicht besonders toll und leider Akkufressend, aber vom Handling (für mich) immer noch angenehmer, als juglucco.

    OK, ich wollte das gerade auch probieren und hab die Ports und Addressen nach Anleitung eingestellt.
    (Und ja, das zurücktauschen des Sensors zu Librelink hat gut funktioniert.)
    DIe gepatchte Libre-App sagt mir dann auch dass Daten an den Port gesendet werden ...
    Und im Mirror-Menu zeigt Juggluco auch eine aktive Verbindung an


    Aber: Juggluco hat jetzt aber nur noch einen weissen Plot und xdrip bekommt keine Werte.

    Benutzt Du irgendwie eine ältere Version, oder die non-Play-Store Version von der Homepage?

    Bevor jemand fragt:
    Natürlich scheint die Übernahme der BT-Verbindung durch Juggluco vorteilhaft, ich versuche aber vielleicht die Möglichkeit zu behalten auch Sensoren bei Abbot reklamieren zu können.
    Bisher brauchte man dazu die Statuscodes aus der LL-App, sprich wenn der Sensor stirbt sollte er den Status dort hinterlassen.


    LG
    Martin

    Wenn man viele Pointer verwendet, ist es klar dass diese nun 64 statt 32 bit verwenden und damit nun 8 statt 4 byte pro Pointer verwenden, aber im großen und ganzen macht das gar nicht so viel aus. 32 bit Datenstrukturen können weiterhin 32 bit bleiben. So "VIEL" weniger ist es gar nicht, aber ein großes Problem ist dass Programme allgemein über die Jahre mehr und mehr Ram brauchten (Java hat viel Schuld daran), der Schritt zu 64 bit ist allerdings nicht der direkte Auslöser.

    Android-Prozesse laufen nun mal in einer VM. Damit sind alle Pointer doppelt so gross, und alle Objekte werden ueber Pointer addressiert (wobei der Objectheader auch noch minimal um Faktor 1.5 waechst). Sprich: wenn man nur normale Apps und keine riesigen Spiele programmiert, ist auf low power SOCs unter 64bit Architektur deutlich früher Schluss.
    Auf der anderen Seite: die meisten Java oder Kotlin Apps für Android muessen von der Programmierung gar nicht weiter geändert werden, ob sie nun für 32 oder 64 bit gebaut sind.
    Nur Librelink hat hier einen Caveat, weil die Lib zum decoding der Sensordaten obfuskierter Maschinencode in einer ELF-Lib ist -- sprich da muss die Variante zum Chip passen.


    LG
    Martin -- der schon seit der Zeit programmiert, als die Chips noch 8bit Register hatten

    Hi,


    ich hatte mich ja lange drum gedrückt, aber nun sind nur noch 2 L2 Sensoren übrig und ich muss wohl mal unseren Technologiestack auf L3 umstellen.
    Zum Testen hab ich (und nicht meine Tochter) jetzt einen Sensor am L3 und Juggluco auf dem Handy. Ich seh auch meine Werte in XDrip und auf meiner Uhr. Soweit, so gut.

    Die Anleitungen und dieser Thread haben mich ein wenig schlauer gemacht, aber ich such noch die Bestätigung für ein paar Dinge die ... sich vielleicht auch mit den Versionen veraendert haben:
    * Die gepatchte Libre APP hat ein wenig TCP Sender code eingebaut und kann Scans mit History und/oder Minute-Stream Werte an einen (beliebigen ?) Empfaenger verschicken
    (grade an dem Punkt waren die meisten Anleitungen ein bisschen 'Cargo-Cult', und die Bedeutung der Felder und Checkboxen des Configdialogs ist mir nicht 100% klar)

    * Juggluco kann mit einem NFC Scan auch eine direkte BT-Verbindung zum Sensor aufbauen und dann den Stream selbst auswerten und decodieren. Die 1-Minuten Werte werden an XDrip weitergereicht und dort mit dem Code für die patched L2-App weiterverarbeitet. History wird aber nicht aufgefüllt (bei vorrübergehendem Kontaktverlust).
    * XDrip kann die Daten (eingeschränkt wie bei L2App) kalibrieren. Weiterleiten an Watchfaces, AAPS und Nightscout scheint soweit auch zu klappen.
    * In der Juggluco-Anleitung las es sich so, als wenn es einen Mechanismus gibt um laufende Sensoren mit Assoziation zu einem Librelink-Account zwischen verschiedenen Librelink-Apps, Smartphones etc zu übergeben. Juggluco würde quasi das Takeover mit dem Scan durchführen.

    Hat schon mal jemand erfolgreich den Sensor wieder von Juggluco an die L3-App zurück übergeben? (Ich möchte das gern probieren aber eigentlich sagt die L2-App, dass der Sensor danach Toast ist und ich möchte ungern noch mal einen Sensor in den Sand setzen).

    LG
    Martin

    Wenn die Funktion für den BZ brauchst musst du vielleicht auf ein Produkt wechseln welches das anbietet.

    Und da man mit dieser Funktion kein Geld verdient, bzw. eher noch Gewinne mindert (weil man ja die Patientendaten exclusiv in der eigenen Cloud sichert und als Exclusivdaten weiterverkaufen will), wird es in kapitalistischen Unternehmen diese Geschichte nie geben.
    Das beste was einem passieren kann ist ein Produkt mit einfacher Software, die (noch) hackbar ist.


    LG
    Martin

    Die Heinis von Ypsomed sind älter als viele hier im Forum. Angefangen haben die 1984 als Disetronic und haben damit mehr Erfahrung mit Pumpen als die meisten Mitbewerber.

    Für mich kam die nur deshalb nicht in Frage, weil deren Reservoir für meinen Bedarf viel zu klein ist.

    Trotzdem sie so viel Erfahrung haben, kuendigen sie seit Jahren die Steuerung ihrer Pumpe mit dem Handy an und haben es nicht hinbekommen.

    Sie integrieren auch den Dex nur zum anschauen und nennen das ganze schon mal "Assist".

    Grmpf.


    Martin

    Wir haben vor kurzem mit der Insight auf Stahl gewechselt.
    Wir hatten dieses Jahr auch haeufiger Probleme mit den Teflonkathedern -- Die Diabetesberaterin und ich haben die Vermutung, dass es an den Kathedern liegt. Wir haben die Pumpe seit 2017 und vorher gabs das nie.
    Bei uns wars immer gleich nach dem Setzen und es ging scheinbar gar nichts durch (BG auf 350).


    Die Verstopfungsmeldung der Pumpe kam (wenn ueberhaupt) dann erst bei Korrekturversuch mit 2-2.5 Einheiten.


    LG
    Martin

    ich geb nach dem Wechsel immer 3 IE hab, dann seh ich relativ schnell, ob das Insulin ankommt wie gewünscht

    Gemerkt haben wir das auch bei der nächsten Malzeit. 3IE ist bei nem Kind aber eben ziemlich dick.
    Die Warnung von der Pumpe kommt aber auch mit einer 1IE Korrektur.
    Nur warum so häufig?


    LG

    Martin

    Hi,


    wir hatten bei unserer Insight mit Teflonkathedern in letzter Zeit (2Wochen) mehrfach Verstopfungsfehler (also Fehlermeldung von der Pumpe wegen Gegendruck beim Pumpen), meist direkt nach Kathederwechsel.
    Die letzten 3 Jahre gab es das nie.


    Ich versuch grad ein bisschen einzugrenzen, ob es vielleicht eine besondere Ursache geben könnte. Offensichtliche Ursachen sehe ich keine:
    * Flocken o.ä. im Insulin

    * geknickter Katheder-Teflonschlauch, nicht richtig in die Haut eingedrungen

    * undurchlässiger Adapter oder Schlauch (hab zumindest nach einem Bolus Tropfen in der Steckkupplung gesehen)

    Behoben haben wir das durch noch einen Katheder + Schlauchwechsel. Meist mit schlechter Laune als Bonus.
    Kann das sein, das Kathederserien Fehler haben ? Fehlt mir noch ein Punkt auf der Checkliste?

    Klar kann es sein, dass wir jetzt 3 mal verschiedene "schlechte Stellen" erwischt haben. Aber diese Häufung widerspricht der Wahrscheinlichkeit.


    Liebe Grüße

    Martin

    Der Sensor selbst stellt das Senden nach 14.5 Tagen ein. Der Spielraum ist absichtlich eingebaut, weil der Timer im Sensorchip eher ungenau ist und eigentlich das Lesegeraet oder die Librelink APP das Lesen nach genau 14 Tagen (oder besser 20160 Minuten) einstellen . Der Sensor sollte diese Zeit garantiert ueberleben und senden, auch wenn sein Timer mal 4% vorgeht.


    Doof an deiner Methode ist natuerlich, das alle Plots, Logs in Nightscout, Reports und Statistiken auch durch die Verstellte Uhrzeit versaut sind. Von sowas wie Kalender oder Wecker auf dem Handy ( wenn mans nicht nur fuer Diabetes nutzt) will ich gar nicht reden.


    Du kannst den Effekt von 14.5 Tagen Nutzungsdauer einfacher haben, wenn Du einen MiaoMiao2 zum Auslesen nutzt. Weitere Vorteile sind, dass man bei kurzen Unterbrechungen der BT-Verbindung die Werte wieder auffuellen kann, und dass der BT-Sender deutlich staerker ist, als der Libre2 Sensor. Der uebertraegt auch noch Werte wenn das Handy ein Zimmer weiter liegt oder das Handy meiner Tochter in meinem Rucksack ist (8-10m Abstand), wenn wir Radfahren.


    LG

    Martin

    leider basiert dieses Ergebnis auf je 1 Batterie pro marke die getestet wurde also Statistisch gesehen hat diese Studie kein Wert (schlechtes Ergebnis = dumm gelaufen).

    Naja mein Duchschnitt kommt aus der Nightscout Datenbank der letzten 1.2 Jahre. Aber eben nur mit Lithium Zellen.

    Ich hatte nach diese Abbrüche mal gemessen und bekam noch immer 1,42V was eigentlich gar nicht schlecht war. Die Abstürze waren auch innerhalb von 5 Stunden ohne das es außer Basalrate Abgabe gar nix passierte (auch keine Boli !).

    Ich trickse jetzt mit meine neue Pump herum zu schauen ob er auch 2,5 Wochen durchhalt wie der Combo damals. Die erste Batterie hält zeit 30. März (Tag der Inbetriebnahme).

    Die Leerlauf-Spannung von 1.42 V an einem (10MOhm) Voltmeter sagt nix aus, die Frage ist wieviel Milliwatt der Spannungswandler der Pumpe in dem Zustand noch aus der Zelle rauslutschen kann, ohne das diese kollabiert.


    LG
    Martin

    Übrigens beobachte ich mittlerweile auch, dass die Kalibrierungen bei relativ hohen oder niedrigen Werten auf eine Steigung ungleich eins hindeuten. (Dass die gleich eins sein soll, ist allgemeiner Konsens, woher kommt der eigentlich?)

    Nicht von mir! || Allerdings kann das eben auch an der Physiologie des Traegers liegen. Unkalibriert sind unsere Werte auch oft niedriger als die Accu-Check Werte.

    Wir sind ja immer noch mit dem MiaoMiao (2) unterwegs und da kann man die volle Kalibrierung nutzen. Ein typischer Sensor hat bei uns einen Slope von 0.75 - 0.8, nur zum Ende der Laufzeit geht der Slope dann auf 1 - 1.1. Das kommt aber auch auf die Setzstelle an.


    Mit fixem slope 1 und korrekten Kalibrierungen im unteren Normbereich (== korrekter intercept) werden dann aus 200 schnell mal mehr als 240. Da kann einen ein SMB Loop schon zu heftig runterpushen.


    LG
    Martin

    Nun ja, das geht schon:

    SMB aufgrund UAM oder aufgrund nicht mit Insulin abgedeckter COB -> Bolus

    SMB ohne UAM und ohne Bezug zu COB -> Basal

    Nope, dabei fallen schon die folgenden ZT unter den Tisch. Mal abgesehen davon dass die COB Rechnung nur mehr oder weniger gut funktioniert (und FPE noch nicht beinhaltet).

    Hormonschwankung wird dir auch immer als UAM zu Buche schlagen.

    Die derzeit verwendete Modellierung kann Deviations sehr haeufig nicht einem bekannten Zustand zuordnen: Da kannst Du genausogut Muenzen werfen.


    LG

    Martin

    Es geht weiter. :thumbup:

    http-Zugriff geht (reicht für isolierte Anwendung zu Hause), https braucht ein Zertifikat, hab noch keines.

    Daten(bank)import aus 10be funktioniert, Profilübernahme noch nicht.

    An DB-Zugriffsrechte habe ich mich noch nicht rangewagt, alles ist noch offen wie ein Scheunentor.

    /TBC/

    DB-Zugriff kannst Du offen lassen. Konfigurier Nightscout auf auf den Zugriff nach http://127.0.0.1:27017 .

    Mongo stellst Du mit net.bindIp im configfile auch auf 127.0.0.1. (Sollte default sein).

    Dann ist das dicht genug.


    Nightscout muss dann mit Admin Keys gesichert werden (uebers env), und du erstellst im Menue neue (NormalUser-) Subjects. Danach AUTH_DEFAULT_ROLES auf denied stellen.