Neuer Code

Nachdem ich noch eine Nacht drüber geschlafen habe, noch einen Fehler gefunden und behoben habe, kommt hier der Code für das Tool: https://github.com/SandraK82/hexGraph/tree/master

Somit lohnt mal wieder ein Blick auf die TODO-Liste:

  • BlueReader wartet auf die ersten Platinen, die passenden Chips liegen bereits hier
  • libLibre für iOS hat noch einige Bugs und hat nun eine sehr hohe Priorität
  • blueReader Firmware wartet gerade darauf, das ich ein neues Modul zusammen löte um zu sehen wie sich die neuen BLE-Module verhalten
  • iOS App wartet derzeit auf libLibre
  • libBlueReader für Android musste ich erstmal zurück stellen, zunächst erstmal die anderen Baustellen fertig bekommen
  • ChartStudio ist jetzt erstmal im kleinen als hexViz/Graph soweit Fertig, als nächster Schritt kommen da nun auch noch Graphen rein.

Daten und noch mehr Daten

Heute geht ein weiteres Projekt in die Öffentlichkeit:

HexGraph ein Tool um LibreDaten zu analysieren. Was benötigt man dazu? Dieses Tool (was es auch nach Überarbeitung openSource geben wird) möchte gerne eine Datenbank mit RawCaptures von Libredaten haben. Sowas erzeugt derzeit wahrscheinlich nur meine, noch nicht veröffentlichte, libLibre. Deswegen gibt es hier eine solche Beispielsdatenbank mit unregelmässigen Logs ( ~ alle 2 Minuten ) des Sensors ( 1967 Datensätze mit vollen Captures eines Sensors), ein passender Export der original Libre Software und ein wenig Geduld, ein gutes Auge und ein paar JavaScript Kenntnisse sind auch noch hilfreich…

Screen Shot 2016-05-22 at 23.32.52Links kann man sich die Interpretation der Daten basteln, diese Konfiguration kann man auch Speichern und Laden und jeden Block testen. Beim Start der App wird immer die gleiche Konfiguration geladen.

Oben kann man nach dem Start der App erstmal die Datenbank hoch laden und danach die Export-Daten aus der Libre App. Dann kann man noch aussuchen wie viele und welche Datensätze nun gezeigt werden sollen.

Wer jetzt in dem ganzen noch was Sinnvolles finden kann, der möge sich doch Bitte melden 🙂 Dann werde ich diese Daten zu den anderen ausgewerteten Daten hinzufügen.

Happy Hunting!

Fortschritte

Endlich habe ich angefangen die Sensordaten richtig aufzuzeichnen, schon kommt die nächste Nachricht: Es wurde die offizielle App entdeckt! Leider ist das nicht unbedingt ein Grund direkt in Jubelstürme auszubrechen, da ein Reverse Engineering der App zum einem nicht ganz trivial ist. Die Entwickler haben die interessanten Teilen, also die Auswertung der Rohdaten zu Zuckerwerten, in nativen Code geschrieben und somit kann man das nicht einfach mal so Nachlesen wie bei anderen Android Apps. Zum anderen ist es ein rechtliches Problem, da es hier nicht um irgendwelchen Code von irgendwelchen Entwicklern geht, sondern dahinter Firmen (Abbott und AirStrip) stehen die ein Interesse daran haben ihre Algorithmen zu schützen…

Die Zeit wird zeigen wie lange es dauert bis irgendwer den Code verstanden hat und eine entsprechende Lösung gebaut haben wird… Wahrscheinlich werde ich es nicht sein, da ich noch in der Abwägung schwanke, worauf ich mich mit so einem Unterfangen einlasse.

Aber auch bei mir geht es weiter: Quasi zeitgleich mit einer anderen Person habe ich scheinbar aus meinen aufgezeichneten Daten angefangen die SensorID zu extrahieren (Die die auch das Messgerät für den aktiven Sensor anzeigt). War nicht besonders schwer nur etwas seltsam, da Abbott eine Seriennummer gewählt hat, die fast direkt aus der Tag-UID zu lesen ist, wenn man das Alphabet mit den Zahlen kombiniert und dabei die Buchstaben B,I,O,S weg lässt (also diese Zeichenfolge erhält: 0123456789ACDEFGHJKLMNPQRTUVWXYZ ). Dann muss man nur noch die UID in 5 Bit Schritten lesen und den entsprechenden Buchstaben aus der Liste wählen. Dann kommt noch eine 0 davor und man hat die Seriennummer. Soweit so schön, aber nicht vollständig. Ein Blick in die LibreLink Sourcen verrät das die 0 nicht fest da drin steht, sondern von dem System abhängt. Zwar scheint es derzeit nur Systeme im Umlauf zu geben die dabei eine 0 erzeugen, aber es kann in Zukunft auch jeder Buchstabe sein, der in der obigen Zeichenfolge enthalten ist.

An diesem kleinen Beispiel sieht man schon, wie kompliziert es eigentlich ist, ein solches System zu verstehen. Mein nächstes Ziel ist es jetzt die Version des Sensors zu finden und zu verstehen.

Dazu kommt noch, dass ich glaube ich einige Sachen gefunden habe, wie ich die restlichen Daten in einem Sensor beeinflussen kann (Also die Daten die bei den bisherigen Algorithmen keine Berücksichtigung fanden). Eventuell werd ich mal einen Blick in die Sourcen wagen, was der original Source damit macht, aber eigentlich möchte ich das lieber weiter selber herausfinden.

Wer sich wirklich für die Sourcen der offiziellen App interessiert dem sei hier eine kleine Übersicht gegeben wie man generell an eine solche Analyse gehen kann. Dies ist nicht der einzige, der beste oder der richtige Weg, es ist meiner der mir in der Vergangenheit oft geholfen hat Probleme in Apps die ich verwenden musste, ohne in die original Sourcen schauen zu können, zu Debuggen:

  • Man entzippe das APK und kann sich dann schon mal eine Übersicht über die Struktur der Anwendung erstellen
  • Man benutze einen dex/apk-decompiler um sowas wie Sourcen zu erhalten
  • Man lädt diese Sourcen in sein Entwicklungstool der Wahl (meist Eclipse bei mir) und fängt an den Code zu „Massieren“, also durch jede Datei zu gehen und zu schauen wo es Probleme gibt, was für Probleme das sind (schlechter Decompile, fehlende Abhängigkeiten, …)
  • Wenn man den Code soweit durch gegangen ist, schaut man sich gegebenenfalls die native Libraries an
    • Wieder verschafft man sich zunächst einen Überblick per ObjDump oder ähnlichen Tool
    • Dann geht es in einen Disassembler
    • Jetzt fängt der Spass an, je nach dem was für einen Binärcode man gerade in den Disassembler geschickt hat, hat man nun Assemblercode in ARMeabi, ARMeabi-v7a, ARM64-v8a, intel irgendwas, x86 oder x86_64. Wer nicht weis wie sowas aussieht:
         XOR	EAX, EAX	; zero out eax
         MOV 	ECX, 10 	; loop 10 times
      Label:			; this is a label in assembly
         INX 	EAX   	; increment eax
         LOOP 	Label		; decrement ECX, loop if not 0

      aus der Intel x86-64 Assembler Einführung. Eine Lib wie die der LibreLink-App hat dann gerne mal zehntausende solcher Zeilen die man sich mühsam und mit viel Hintergrundwissen erstmal erarbeiten muss…

Da ich nicht spezialisiert auf Reverse Engineering bin, sondern nur hin und wieder mal was nachschauen muss, überlasse ich diese Arbeit gerne anderen, die sich dann auch mit den rechtlichen Problemen die daraus entstehen auseinander setzen können.

Zu guter letzt gibt es auch noch Neuigkeiten für den BlueReader. Gestern gab es ein weiteres Planungstreffen und jetzt wird in dem nächsten Schritt eine gewisse Anzahl von ersten Prototypen gebaut um Erfahrungen mit dem Design sammeln zu können. Ich hoffe das wir diese Geräte in den nächsten zwei Wochen dann endlich haben werden und mit den Tests anfangen können.
Sobald diese erste Serie getestet wurde, wird wahrscheinlich noch eine zweite Serie produziert um Fehler aus der ersten Serie ausmerzen zu können und Features einzubauen die wir jetzt in der ersten Serie noch weggelassen haben.
Dieser Prozeß wird sich dann so lange wiederholen bis wir dann keine Fehler mehr sehen. Danach wird es wahrscheinlich schon die erste Serie geben!

kleiner Schritt

Heute gibt es endlich eine vereinheitlichte Bibliothek für den BM019, zumindest für UART-Verbindungen -> bm019-library

Ist nichts wirklich spektakuläres, nur etwas was ich einigen Personen die Interesse an der Entwicklung eigener Lösungen haben, versprochen habe. Der Vorteil dieser Bibliothek ist, dass man sie für die Entwicklung von Arduino und ble basierten Anwendungen gleichermaßen einsetzen kann und für beide Umgebungen die gleichen Funktionen und Features bereit stellt. Dazu gibt es auch noch eine kleine Demo für Arduino die die wichtigsten Befehle in ihrer Anwendung zeigt dazu.

Um mal die alte TODO-Liste aufzugreifen:

  • BlueReader geht weiter, es wurden noch einige Änderungen von mir beauftragt, da ich durch meinen Prototypen noch einige neue Erfahrungen sammeln konnte
  • libLibre für iOS hat noch einige Bugs und hat nun eine sehr hohe Priorität
  • Klassen und Beispiele für Arduino Entwicklungen kommen Der Punkt ist jetzt endlich mal getan
  • Neue blueReader Firmware ist zu einem Teil schon Fertig und getestet (Updated über Bluetooth), aber noch nicht alle Funktionen sind drin die ich gerade noch gerne hätte
  • iOS App wartet derzeit auf libLibre
  • libBlueReader für Android musste ich erstmal zurück stellen, zunächst erstmal die anderen Baustellen fertig bekommen
  • ChartStudio wuchs und gedieh und steht nun auch im Schatten, zumindest bis die libLibre stabil funktioniert, zudem habe ich viele neue Ideen für dieses Projekt die ich jetzt erstmal in das Konzept einbauen muss

Der Stand des Prototypen ist derzeit sehr befriedigend. Derzeit hängt er über einen Velcro-Klettverband, welches auf einem Curapor über dem Sensor klebt und begleitet mich jeden Tag und jede Nacht. Wenn ich nur jetzt schon die libLibre hätte, dann könnte ich schon so viele schöne Daten aufzeichnen, aber was noch nicht ist wird noch werden 🙂 Direkt auf dem Sensor das Velcro zu kleben war mir auf Dauer zu risikoreich.

Klobiger geht immer…

Letzte Woche habe ich mal wieder fast meinen Prototypen geschrotet, dachte ich zumindest… War aber nicht so.
Die Woche war so Lala, mein Zucker macht mal wieder was ihm gerade so einfällt und mir ging es dementsprechend. Somit blieb auch das Modul in der Ecke liegen.
Mittlerweile sind aber auch endlich die USB-Lade-Module angekommen (zusammen mit weiteren Bluefruits, weil ich ja dachte auch mein zweites ist defekt). Heute wollte ich dann mal schauen ob das Modul noch zu retten ist und bei der Gelegenheit auch direkt mal den USB-Lader einfügen (und nen größeren Akku). Dabei rausgekommen ist:
IMG_1635

Naja, wie schon in der Überschrift gesagt: Klobiger geht immer…
Am Arm sieht es dann so aus:
IMG_1636Aber warum schwebt es am Arm? Zu den ganzen Problemen mit dem Modul, hatte ich auch immer wieder Probleme mit der Position des NFC-Readers über dem Sensor. Leider kann ich scheinbar nur zwischen Pest und Cholera wählen: Entweder stelle ich 100% Leistung auf dem Modul ein, muss dann aber einen Abstand zu dem Sensor einhalten (nicht zu groß, nicht zu klein), oder ich betreibe es bei 10% Leistung, dafür muss es dann sehr genau auf dem Sensor liegen… In einer Diskussion über das LimiTTer-Projekt wurde mir Velcro-Tape empfohlen um die Fixierung zu erleichtern. Gesagt getan 🙂 hält Bombe! Und es gibt nun auch einen Schalter um das Modul ohne Fummeln am Kabel an und auszuschalten.

Auch bei dem Prototypen des BlueReaders geht es weiter. Heute wurden noch einige Details geklärt und eventuell gibt es diese Woche schon den ersten Entwurf für das Board. Ich bin gespannt wie es wird 🙂

Langsamer…

Es geht weiter, leider nur im Schneckentempo 🙁

Letzte Woche habe ich meinen Prototypen leider geschrottet, die BLE-Antenne riss bei der Anprobe der Armbinde ab. Leider war es unser einziges Bluefruit Modul und somit musste ich erstmal auf Ersatz warten…

Bei dem Einlöten, Umlöten und fröhlichen basteln mit dem neuen Modul verging dann auch noch der Lipo-Loader durch einen Kurzschluss in einer stinkender Rauchwolke…

Aber diesen hatten wir zumindest noch einmal hier rumliegen 🙂

IMG_1542

Diesmal habe ich die Boards ordentlich verlötet bekommen und Schritt für Schritt auf Fehler geprüft und mit guten stinkie Zweikomponenten-Kleber gegen weitere Schäden (hoffentlich) gesichert…

Bei dem ganzen Neuaufbau habe ich jetzt auch viel über die Kosten Nachgedacht. Nicht ganz billig bisher die gesamte Idee.

Ich habe mal versucht die Kosten aufzuschlüsseln:

(Im Link hinter dem Bild noch mal als PDF)Kosten Prototyp

Ja das ist ein Brocken 🙂 Aber was habe ich seit der Verfügbarkeit des Libre für die Sensoren bezahlt? Die erste Bestellung finde ich am 30.10.2014, somit trage ich seit 78 Wochen, wenn ich mich nicht verrechnet habe, Sensoren. 78 Wochen heisst etwa 39 Sensoren, plus oder minus ein paar weil Bestellungen zu spät angekommen sind, oder Sensoren frühzeitig verstorben sind. 39 Sensoren bedeutet gut 20 Bestellungen á 125,75 €, also  ca 2515 € die ich bis heute eh schon für die Sensoren ausgegeben habe 🙂 Immerhin sind die ja jetzt günstiger durch die Möglichkeit bis zu 6 auf einmal Bestellen zu können und somit viel Versandkosten zu sparen 🙂

Was sind jetzt die nächsten Schritte in diesem Projekt?

  • Nächste Woche geht es weiter mit den Gesprächen über die BlueReader Hardware (Seufz, noch mehr kosten…)
  • Die erste Version der libLibre steht in den Startlöchern für iOS
  • Klassen und Beispiele für Arduino Entwicklungen kommen
  • Neue blueReader Firmware mit mehr Optionen und der Möglichkeit über eine App die Firmware einspielen zu können kommt.
  • Eine weiter Entwickelte iOS App wird langsam
  • Erste Sachen funktionieren jetzt auch stabil in der libBlueReader für Android, aber das wird noch dauern bis es dort Code zum benutzen geben wird
  • ChartStudio wächst und gedeiht. Ein kleines Nebenprojekt um noch mehr Personen die Möglichkeit zu geben neue Interpretation für die Libre-Daten auszuprobieren und für die libLibre bereit zu stellen.

Für das ChartStudio wäre es noch Hilfreich Daten zu bekommen. Daten von Blutzuckermessungen über normale Geräte. Derzeit lese ich nur die Daten aus meinem Aviva Combo über SmartPix und die Libre-Exportdaten als Referenzen zu den Algorithmen. Für Geräte die das SmartPix unterstützen wäre es interessant die xml-Dateien zu bekommen, für alle anderen Geräte bin ich gerne offen für Vorschläge wie man die Daten am besten einfügen kann.