Beiträge von keencave

Jupp! Man muss das LibreView Konto in den Sensoreigenschaften eintragen und dann scannen.

Hallo zusammen,

bei mir ist erneut ein FSL3 nach rd. 10 Tagen ausgefallen. Grund war "ausser Reichweite zum Phone" für 15 - ... Minuten, weil ich an die Haustür musste und alles stehen und liegen liess. Auch das Loophandy. AAPS hat danach gedudelt, weil keine neuen Werte mehr kamen. Ich setze FreeThree ein.

Los ging der Test: In der LibreLink App keine Verbindung zum Sensor. Über BT-Scan war der Sensor nicht mehr zu sehen. Normalerweise sieht man die Kennung des Sensor oder die MAC ID, beginnend mit A4:7E:36:.... nach ein oder zwei Minuten. Juggluco und eine L3 Testversion von Diabox konnten ebenfalls keine Verbindung aufbauen. Handy reboot, BT aus/an, Rescan per NFC, alles hat nichts geändert. Der Sensor war BT maessig tot. Einige Stunden gewartet, keine Änderung.

Dann neuen Sensor gesetzt und gestartet, allerdings mit einem zweiten LibreView Account, um mit dem toten Sensor weiter zu testen.

Und siehe da, am nächsten Morgen nach dem Aufwachen kurz auf BT gescannt (nRF App) und Bingo: Sensor war nach rd. 18 Stunden wieder sichtbar. Juggluco war auf einem anderen Handy mit diesem Sensor verbunden und zeigte dann sofort Werte an. Ebenso die L3 Testversion von Diabox.

Das habe ich jetzt schon zum 3 Male beobachtet. Kennt das sonstjemand auch?

Ärgerlich ist die lange Zeitdauer ohne Werte, weswegen man einen neuen Sensor setzen muss. Wenn es eine Möglichlichkeit geben könnte, den Sensor gezielt zu wecken, dann wäre das unnötig.

Ich kann bestätigen, dass eine Testversion von Diabox ohne Probleme mit dem FSL3 läuft. Noch müssen aber wohl noch Änderungen an der App vorgenommen werden.

Zitat von keencave

Juggluco funktionert prima auf meinem Testhandy. Wenn ich mein gerootetes Motorola One verwenden will, dann wird der Sensor beim Scannen erkannt. Er verbindet sich auch mit dem Phone per BT, leider wird das Streaming nicht gestartet. Bei Handshake sehe ich unter Sensorstatus, sowohl mit Version 4.2.8 und der 4.5.3, immer: SEC_CHAR_CHALLENGE_DATA. Die LibreView ID wurde korrekt gelesen und ist identisch zu der auf dem Testhandy.

Was kann das Problem sein?

Gelöst: Es lag an der Rootumgebung auf dem Handy. Sobald man Juggluco dort verbirgt läuft alles ohne Probleme.

Done. Sent you PM with the logcat output.

Mache ich, danke! BTW: Das Umschalten auf die Libre3 App klappt problemlos, hatte ich falsch bedient.

Habe den Sensor jetzt an das Motorola One (Testhandy) gebunden, der schickt die Daten vorerst an Nightscout, was dann den Loop füttert. Hier ebenfalls beim ersten Versuch der SEC_CHAR_CHALLENGE_DATA. BT aus/an, neu gescannt und dann war der Sensor verbunden. Und die Libre3 App auf dem Handy, was Probleme macht, hat sich nach dem Ende des Tests nicht wieder mit dem Sensor verbinden wollen, daher bin ich auf das Testhandy ausgewichen.

Ich hatte schon im letzten Jahr einige Ausfälle (ohne Juggluco) der Sensorverbindung, die im längsten Falle 26 Stunden gedauert hatte. Grund wr immer unklar.

richtige application?

identischer Fehler mit Version 4.6.0b, leider.

Ich sehe keinen logcat output fuer tk.glucodata?

kein Veraenderung, schade. Ich probiere morgen weiter. Danke für die Hilfe! Macht Juggluco logcat output?

1.) Korrekt. Hatte ich schon einige Male, die Libre3 App war nach einigen Stunden wieder verbunden

2.) Ja, Account gelöscht, neu eingegeben und per NFC gescannt.

3.) Juggluco war auf allen Telefonen destoppt.

4.) Neustarts unsystematisch, aber meist ja.

Für mich sieht das nach einem Fehler bei der Sensorkopplung / Challange/Response Fehler aus oder einem Timingfehler aus. Kann man den Bindungsvorgang manuell neu starten? Also mit BT aus, Forget, Reenable und wieder BT an?

1.) Ja, Bildschirm wurde erst vor dem Erstellen des Screenshots geöffnet.

2.) Nein, keine Änderung in dem Zeitraum

3.) Ja, hier wurde der letzte Scan gemacht

4.) Hat er bis zur Aktivierung von Juggluco (7 Tage Laufzeit). Dann Test mit Juggluco. Erneut mit Libre3-App verbunden, über 30 Minuten keine Werte (Signal Loss). Dann erneut mit dem Motorola One Phone verbunden - Werte wurden gelifert. Danach der Test mit dem Motorola One Vision Plus, Screenshot oben.

So, hier der neue Versuch:

During test I observed the same behavior which is persistent also on the Motorola One testphone. After clearing cache/data and rescanning it worked again.
Do I have to scan one time (which results in a checkbox saing the the sensor will now be connected) or twice with getting the yellow screen indicating sensor will deliver data?

neu installiert und neu gescannt. Ich lasse es jetzt 20 Minuten laufen, bis ich den Screenshot mache.

Sensor Menue nach 10 Minuten. Es ist ein gerootetes Motorola One Vision Plus. Ohne Probleme ein Samsung A8 sowie ein Motorola One.

Juggluco funktionert prima auf meinem Testhandy. Wenn ich mein gerootetes Motorola One verwenden will, dann wird der Sensor beim Scannen erkannt. Er verbindet sich auch mit dem Phone per BT, leider wird das Streaming nicht gestartet. Bei Handshake sehe ich unter Sensorstatus, sowohl mit Version 4.2.8 und der 4.5.3, immer: SEC_CHAR_CHALLENGE_DATA. Die LibreView ID wurde korrekt gelesen und ist identisch zu der auf dem Testhandy.

Was kann das Problem sein?

jka: Ist bekannt, ob die Libre3 App die Roh-Daten des L3 Sensors noch bearbeitet? Liefert juggluco die Roh-Daten des Sensors?

Halte ich für eher unwahrscheinlich. Im L3 Sensor läuft ein EM9304 Baustein, um die BT Kommunikation abzuwickeln. Das ist einer der besten (Connectivity, Laufzeit, Strombedarf) BT Bausteine am Markt. Leider nicht sehr gut dokumentiert ... Das da ein RC Teil reinstreuen und den Sensor lahmlegen soll - nicht ausgeschlossen, aber sehr unwahrscheinlich. Ich tippe eher auf die eingebaute Batterie vom Typ SR716W, Silberoxid, z. B. für Uhren eingesetzt, die aufgibt.
Ich habe mittlerweile einige L3 vorzeitig verloren. Einigen Exemplaren kann man danach noch per NFC scannen, andere nicht. Beim L1/L2 wurde der zentrale Prozessor bei jedem NFC Scan über das Antennenfeld mit Energie versorgt. BT fiel da auch aus, das war aber nicht zu merken. Man kann diese Sensoren noch Jahre später scannen, ohne das die Batteire läuft. Beim L3 wird ein unbekannter (wahrscheinlich herstellerspezifischer) NFC Baustein eingesetzt, der das wohl nicht kann.

Meine Theorie bisher ist, dass die Batterie mglw. als Sekundäreffekt bei dauernden BT Störungen oder permanent ausser Reichweite schneller geleert wird. Von einigen frühen BT Transmittern wie dem Blucon Device, welches mit einer Knopfzelle lief, wissen wir, dass dort manchmal die BT Kommunikation nach 10 - 12 Tagen etwas zaeher wurde und nur noch sporadisch Werte empfangen werden konnten. Wurde immer schlechter bis zum Stillstand. Leider brauchen die BT Bursts viel Strom. Wenn der Innenwiderstand der Zelle steigt, dann geht das immer schlechter. Nachdem wir in xDrip dann den Blocklesemodus eingebaut hatten, war das weg. Blucon wollte uns seinerzeit nicht das Protokoll geben, daher hat es gedauert, bis wir den Modus detektiert hatten. Einzelblocklesen hat viel Strom verbraucht. Aehnliches meine ich bei einem L3 Sensor auch beobachtet zu haben, als er nach 8 Tagen ausfiel. Vorher immer mehr Blackouts, dann nichts mehr. Leider ist das in der App wegen das Backfilliungs nicht gut zu bemerken. Die Lücken werden einfach gefüllt. Wir konnen n. m. A. aber zu Recht annehmen, das der Uebeltaeter wahrscheinlich die Batterielebensdauer ist. Ist BT dauerhaft gestoert oder der Sensor älter, dann kann die Batterie vor dem Ende der Laufzeit aufgeben.

Bis zum Gegenbeweis habe ich das Handy jetzt immer möglichst an der Person, um solche Effekte zu vermeiden. Ich werden mir einige alte Sensoren mal vornehmen, wenn ich über die Tage Zeit finde, die Batterie zu vermessen.
Im Log der App wird in einem solchen Fall nach rd. 2 Stunden ein Error 57 angezeigt. Fragt die Hotline ab. Der Doppelblindtest mit einem 2. Handy und der Übergabe der Verbindung an dieses hat übrigens kein Ergebnis erbracht. Auch diese konnte keine Verbindung zum Sensor herstellen.

Ich hatte ebenfalls einen Sensor, der nach 2 Tagen ausgestiegen ist. Ich tippe derzeit auf die Batterie im Sensor (fest verbaut, Silberoxid), die schlapp macht. Neben den üblichen Bluetooth Tricks habe ich final ein Übertragen des Sensors auf andere Handys versucht, das klappte leider auch nicht. Der Sensor liess sich auf einem neuen Handy nicht scannen. Als Doppelblindtest habe ich dann 4 weitere tote Sensoren untersucht: 2 liessen sich scannen, 2 nicht. Und der aktuelle tote ebenfalls nicht.

Aus der Zeit der Selbstbautransmitter für den Libre1 ist bekannt, dass eine schlappe Batterie (des Transmitters) zu immer unzuverlässerigen Datenverbindungen führte. Das deckt sich mit dem Fehlerbild, was hier von Einigen beschrieben wurde. Merkwürdig ist nur, das ein NFC Scannen nicht mehr geht. Beim Libre1 (und 2) reichte die NFC Feldstärke aus, um den Sensor mit Strom zu versorgen. Das lag am Microprozessor, der speziell diese Eigenschaft hatte. Beim Libre3 kommt ein anderes Konzept zum Einsatz. Dort wird NFC mit einem unbekannten Chip angebunden. Kann also durchaus sein, dass Batterie Low dazu führt, das Scannen nichtmehr geht.