Reverse Engineering Insulinpumpe für die DIY-Therapie

Vor ungefähr drei Jahren hörte ich von einer Website, die eine Belohnung dafür bietet, dass sie mir sehr am Herzen liegt: Reverse Engineering-Kommunikation mit einer Insulinpumpe. Ich habe bereits mitgeholfen, ein System für meine Tochter namens Loop mit einer Medtronic-Pumpe zu erstellen, für das ich die Kommunikation zurückentwickle (der größte Teil des Medtronic-Hauptkommunikationsprotokolls wurde von Ben West mithilfe des Carelink-USB-Geräts dekodiert, und ich habe die Funkfrequenzen herausgefunden und einige zusätzliche Arbeiten durchgeführt Protokoll). Die Medtronic-Pumpe musste jedoch während des Turnens für mehrere Stunden abgeschaltet werden. Das schlauchlose Design dieser Omnipod-Pumpe schien mir interessant zu sein, und ich hatte alle Werkzeuge, um zu arbeiten.

Das Omnipod-System besteht aus einer kleinen Einwegpumpe, die als Modul (Pod) bezeichnet wird, und einer Steuereinheit (PDM).



Da das PDM über Funk mit dem Modul kommuniziert und das Modul keine integrierte Schnittstelle hat, bedeutet dies, dass es vollständig funkgesteuert ist. Es besteht die Möglichkeit einer vollständigen Integration in Loop, wobei nur RileyLink oder seine modifizierte Version verwendet wird.

James Wedding ernannte eine Belohnung, die viel Aufmerksamkeit auf sich zog, und dann die richtigen Leute, die bei der Arbeit halfen.

Software Defined Radio

SDR ist ein großartiges Werkzeug . Er macht die verborgene Welt des Radios sichtbar. Es gibt eine Vielzahl von Arten von Nachrichten, die ständig in der Luft übertragen werden. Mit diesen Tools können Sie herumstöbern, Nachrichten anzeigen und nach einiger Arbeit die kleinen Blitze dekodieren, die Sie dort sehen. Wenn Sie nach Nachrichten von einem bestimmten Gerät suchen, müssen Sie wissen, in welchem ​​Bereich die Suche gestartet werden soll. Hier bieten sich öffentliche FCC-Dokumente an.

In der FCC-Dokumentation für PDM, RBV-019 , heißt es, dass das Gerät im 433-MHz-Band sendet. Nach der Konfiguration der SDR-Software für das Abhören im Bereich von 433 MHz werden die folgenden Signale angezeigt, wenn der Status von PDM ausgegeben wird:



Wie ich schließlich herausfand, zeigen diese beiden hellen Linien eine bestimmte Art von Modulation an, die als Frequenzumtastung oder FSK bezeichnet wird. Dies bedeutet, dass die Signalfrequenz abhängig von der übertragenen Information variiert. Bit 1 wird als höhere Frequenz (obere Zeile) und 0 mit einer etwas niedrigeren Frequenz (untere Zeile) gesendet. Mit dem Inspectrum- Tool können wir die Daten analysieren, um 1 und 0 klarer zu erkennen. Hier ist eine stark vergrößerte Ansicht der ersten Nachricht:



Ich habe ein Python-Skript geschrieben, um diese Bits zu extrahieren, damit wir sie als ganze Pakete betrachten können.



Es stellt sich heraus, dass dieses sich wiederholende Muster Teil der Präambel ist . Um Energie zu sparen, gehen Empfänger häufig in den Ruhemodus und wachen regelmäßig auf, um das Signal zu überprüfen. Der Sender sendet die Präambel so lange, dass der Empfänger sie während einer der kurzen Hörperioden abfangen kann. Wenn der Empfänger die Präambel hört, wird sie aktiviert, bis echte Daten angezeigt werden.

Sie müssen eine andere Ebene durchlaufen, bevor Sie die tatsächlichen Chargendaten erhalten. Sie können Ihre Daten nicht genau wie die Originalbits über Funk senden, da der Empfänger Übergänge verwendet, um die Zeit zu synchronisieren, in der auf das nächste Bit gewartet werden soll. Wenn Sie einen langen Satz von Nullen oder Einsen haben, ist der Empfänger möglicherweise nicht mehr synchron. Daher verwendet die Funkkommunikation normalerweise eine Codierung, um zu überprüfen, ob genügend Übergänge vorhanden sind. Omnipod-Kommunikation verwendet die sogenannte Manchester-Codierung . Jedes Bit ist in zwei Bits codiert. 1 wird als 10 und 0 als 01 codiert.

Es hat lange gedauert , es herauszufinden, und es gab viele Theorien auf dem Openomni-Kanal in Slack, als wir versuchten, die ursprünglichen Teile zu wiederholen. Mark Brighton , Dan Caron und @larsonlr haben mit RFCat und Ti Stick einige Erfolge bei der Erfassung von Paketen erzielt. Evarist Kurgio hat schließlich ein Tool namens rtlomni geschrieben . Er verwendet den rtl-sdr-USB-Empfänger, um Pakete abzuhören und zu dekodieren. Dies erwies sich als sehr praktisch und zuverlässiger als Methoden, die auf TI Stick basieren.

Paketdecodierung

Nachdem wir die tatsächlichen Bits erhalten hatten, begannen wir, die Struktur des Pakets zu untersuchen. Basierend auf den Änderungen zwischen verschiedenen Modulen und verschiedenen Teams haben wir eine Struktur erstellt, die folgendermaßen aussieht:

CRC8

Radio ist weit entfernt von einem idealen Übertragungsmedium. Es gibt viele verschiedene Störquellen, durch die der Empfänger 1 hört, wenn 0 gesendet wird, und umgekehrt. Es ist wichtig zu wissen, wann dies passiert ist, daher verwenden die meisten Protokolle eine Prüfsumme, die häufig als CRC bezeichnet wird. Der Empfänger berechnet die CRC, wenn Daten empfangen werden, und das letzte Byte des Pakets enthält die vom Sender berechnete CRC. Wenn sie nicht übereinstimmen, verwirft der Empfänger das Paket und wartet auf die erneute Übertragung.

Das Omnipod-Protokoll verwendete die Standard-8-Bit-CRC. Als wir ihn fanden, entschieden wir, dass wir dem Verständnis der Botschaften sehr nahe waren. Wie wenig wir wussten ...

Nachrichten, CRC16

Einige Nachrichten sind zu groß, um in ein Paket zu passen, sodass sie in mehrere Pakete aufgeteilt sind. Wir fingen an, das Nachrichtenformat zusammenzusetzen, und bemerkten am Ende jeder Nachricht einen weiteren Satz von Bits, der wie eine 16-Bit-CRC aussah. Aber es war seltsam: 5 von 16 Bits wurden nie gesetzt. Wir haben viele verschiedene Methoden ausprobiert , um herauszufinden, wie dies codiert ist, aber nichts hat funktioniert.

Dies war das erste große Problem: Wir konnten weiterhin an anderen Bits in den Nachrichten arbeiten, aber es wird nicht viel helfen, zu verstehen, was gesendet wird, und wir werden nicht in der Lage sein, selbst neue Pakete zu generieren, sodass der Fortschritt verlangsamt wird.

Mehrere Monate vergingen fast ohne Erfolg. Schließlich berichtete ein Mitglied der Gruppe unter dem Spitznamen @lorelai im Winter 2016, dass sie die Firmware erfolgreich von einem größeren ARM-Chip auf PDM kopiert und den langwierigen Demontageprozess gestartet hatte: Akzeptieren von CPU-Anweisungen und Verwandeln in lesbaren Code mit semantischen Variablen und Funktionsnamen. Sie hat großartige Arbeit geleistet und herausgefunden, mit welchen verschiedenen Methoden Daten übertragen wurden.

Ich habe mir eine der Routinen ohne Titel angesehen und festgestellt, dass sie wie eine Standardimplementierung der CRC-Berechnung aus einer Tabelle aussieht. Und die Tabelle hatte Werte für die Standard-16-Bit-CRC. Ich habe meine eigene Implementierung auf Tabellen geschrieben und sie wurde wie ein normaler CRC getestet. Dann habe ich mir genau angesehen, wie die Funktion geschrieben wurde. Eine normale CRC-Implementierung sieht folgendermaßen aus:

while (len--) { crc = (crc << 8) ^ crctable[((crc >> 8) ^ *c++)]; } 

Ihre Implementierung sah folgendermaßen aus:

 while (len--) { crc = (crc >> 8) ^ crctable[((crc >> 8) ^ *c++)]; } 

Beachten Sie den Unterschied? Was eigentlich ein bitweiser Linksverschiebungsoperator sein sollte, wurde irgendwie als Rechtsverschiebung codiert. Das ist ein Fehler; Es gibt keinen Grund, Ihren eigenen CRC-Algorithmus zu lähmen, da dies die Identifizierung beschädigter Nachrichten erschwert.

Wir sind wieder in Betrieb! Und sie nahmen die Arbeit an der Dekodierung von Nachrichten wieder auf, zeichneten Sitzungen von PDM für die Abgabe von Boli [Drogen] und temporären Basen auf [Die temporäre Basalrate bestimmt eine Zunahme oder Abnahme der Insulinabgabe - ca. Spur], Aussetzung der Einreichung usw.

Einwegnummer

Alle Insulinabgabeteams hatten am Anfang der Nachricht ein 4-Byte-Datenelement, das wie eine Art Kryptographie aussah. Wieder haben wir viele verschiedene Möglichkeiten ausprobiert, es im Kontext der Nachrichten, in denen es gesendet wurde, zu interpretieren und zu analysieren, aber es war kein CRC (manchmal sahen wir die gleichen 4 Bytes sogar in verschiedenen Nachrichten). Und manchmal sahen wir, wie sich das Bild wiederholte. Es sah vielleicht als Teil eines Protokolls aus, um die Datenwiedergabe zu verhindern. In anderen Protokollen wird eine ähnliche Funktion als nonce bezeichnet .

Eine der Optionen, die wir in Betracht gezogen haben, war das Aufzeichnen einer Nachrichtenbasis für die Wiedergabe bestimmter Befehle. Selbst wenn die Adresse jedes Moduls unterschiedlich war, wussten wir jetzt, wie man eine CRC generiert, damit wir die vorherige Kopie des Befehls nehmen, die neue Adresse in die Nachricht einfügen und die CRC nachzählen können. Nur diese Nonce hat uns daran gehindert, diese Strategie anzuwenden. Unabhängig vom Befehl akzeptierte das Modul nur die nächste Nonce in der Sequenz, und wir wussten nicht, wie die nächste Nonce generiert werden sollte.

Aber! Immerhin haben wir eine dekompilierte PDM-Firmware, wir können einfach da schauen! Also haben wir die PDM-Firmware untersucht, die Generierung von Nachrichten im Code verfolgt und herausgefunden, wo diese vier Bytes sein sollten. Anstelle einer Methode, die eine kryptografische Nonce berechnet, haben wir nur vier INS. Zeichen gefunden INS. . Was für ein Unsinn?!?! Nun, irgendwie muss dieser Nachrichtenbereich später in der Pipeline aktualisiert werden.

Auf dem PDM befand sich ein weiterer Chip, näher am Radio. Es war derselbe Chip, der in den Modulen verwendet wurde, mit der Kennung SC9S08ER48, die im Internet nicht dokumentiert war. Es wurde wahrscheinlich auf Bestellung für das Insulet angefertigt. Vielleicht können wir die Firmware von diesem Chip entfernen. Leider war der Chip blockiert, was das Kopieren der Firmware verhinderte.



Die Arbeit verlangsamte sich wieder ... es war wie eine echte Sackgasse. Wir haben alle unsere mentalen Anstrengungen in diese Nonce gesteckt, und wir hatten keine guten Hinweise in der Mathematik dahinter. Und der ER48-Chip, der (möglicherweise) Geheimnisse bewahrt hat, wurde blockiert, und es ist schwierig, öffentliche Informationen zu finden, die helfen könnten, ihn zu knacken.

Röntgenstrahlen

Einige Mitglieder der Slack-Community versuchten, ER48 zu verstehen, und schlugen vor, Röntgenaufnahmen zu machen. Es war wirklich cool, hat aber leider keine neuen Möglichkeiten eröffnet.


Allgemeiner Schuss


Detaillierte Aufnahme

Autopsie und Schießen

Dan Caron beschloss, sich an einen Forscher zu wenden, Dr. Sergey Skorobogatov von der Universität Cambridge in Großbritannien. Dan las, dass er Erfahrung mit dem Extrahieren von Code aus gesperrten Chips hat, und überzeugte ihn, sich unser Problem anzuschauen. Dr. Skorobogatov forschte auf dem Gebiet der Verwendung von SEM (Rasterelektronenmikroskop) für das Reverse Engineering von Mikroschaltungen. Er schlug vor, dass es möglich ist, aber es wird teuer sein, teure Ausrüstung erfordern und kein Ergebnis garantieren. Joe Moran , der vor kurzem mit Loop angefangen hat, nachdem wir uns im Herbst 2016 beim Nightscout-Hackathon getroffen hatten, erklärte sich bereit, bei dem Projekt zu helfen. Er stimmte mit einem Unternehmen aus dem Silicon Valley, Nanolab Technologies, überein, die Chips zu öffnen und zu fotografieren, und finanzierte freundlicherweise die Arbeit von Nanolab und Dr. Skorobogatov (sowie seine persönlichen Module).

Dr. Skorobogatov bat Nanolab, verschiedene bildgebende Verfahren anzuwenden, um herauszufinden, ob es möglich ist, den Schutz mit bekannten nicht-invasiven oder semi-invasiven Methoden zu knacken. Infolgedessen erschienen viele Bilder, von denen einige sehr schön waren. Dies sind optisch mikroskopische Bilder einer Siliziummatrix.


Gesamtansicht der Mikroschaltung unter einem optischen Mikroskop


Gesamtansicht der Mikroschaltung unter einem optischen Mikroskop

Es wurden auch Bilder von bestimmten Bereichen der Matrix unter Verwendung eines Rasterelektronenmikroskops aufgenommen. Mit unterschiedlichen Spannungen, unterschiedlicher Oberflächenvorbereitung und unterschiedlicher Ausstattung.


REM-Aufnahme von Flash-Zellen. Zeigt keine Daten an

Leider zeigte keines dieser Bilder den tatsächlichen Inhalt des Flash-Speichers.

Dr. Skorobogatov hatte eine letzte Methode, die nur im Falle eines Versagens angewendet werden kann. Dies war eine patentierte Methode, deren Verwendung die Erlaubnis der Universität einholen musste. Dr. Skorobogatov führte den ersten Test durch und bestätigte, dass er Daten auf diesem Chip lesen konnte. Bevor jedoch fortgefahren werden konnte, musste die NDA unterzeichnet werden. Daher wurden Verhandlungen darüber geführt, wer den Inhalt der extrahierten Firmware erhalten würde.

Letztendlich unterzeichnete die NDA die Nightscout-Stiftung und übernahm die Verantwortung dafür, die unbefugte Offenlegung von Methoden und Ergebnissen zur Speicherextraktion zu verhindern.

Das Ergebnis dieser Vereinbarung und Arbeit war ein unglaublicher Artikel von Dr. Sergei Skorobogatov sowie der Firmware-Code. Vom ersten Mal an gab es einige Fehler im Code, aber dies war genug, um loszulegen. Beim Nightscout Spring Hackathon wandte sich Joe an die Jungs, wenn jemand eine Demontage durchführen möchte. Niemand hob die Hände. Prozessoranweisungen in etwas Verständliches zu verwandeln, ist mühsame Arbeit, und nur sehr wenige Menschen wissen, wie es geht. Ich habe versucht, mithilfe der CPU-Dokumentation in Assembler einzutauchen, aber ich habe sehr wenig erreicht und war enttäuscht. Andere fragten optimistisch nach dem Firmware-Code mit der Erwartung eines schnellen Fortschritts, erkannten dann den Umfang und die Komplexität der Aufgabe - und fielen leise ab.


Beispiel für die Demontage von SC908-Anweisungen

Es stellt sich heraus, dass Joe auch umfangreiche Erfahrung in der Arbeit mit Assembler hatte und begann, diese schwierige Aufgabe auszuführen. Im Juli schloss Dr. Skorobogatov eine zweite Speicherextraktionsoperation mit viel weniger Fehlern ab. Während des Sommers arbeitete Joe Moran unermüdlich daran, eine große Anzahl von Prozessoranweisungen anzuzeigen und diese schrittweise in das Gesamtbild des Modulpseudocodes zu integrieren.

Am Ende kam Ken Shirriff , ein Experte für Hardware-Reverse Engineering, zu uns und beschleunigte den Prozess erheblich. Zusammen übersetzten Joe und Ken genug Code, um eine Funktion zu finden, die Nonce codiert. Dies geschah im September 2017.

RileyLink und Loop

Wir haben die Python-Skripte von openomni aktualisiert, aber jetzt ist es Zeit, sich auf RileyLink + iOS zu konzentrieren. Deshalb habe ich begonnen, an OmniKit- und Firmware-Updates für RileyLink zu arbeiten. Ich glaubte, dass wir die Grundlagen des Protokolls hatten, und der Rest waren nur Details. Wieder völlig unterschätzt, wie viel noch kommen wird.



Ich musste eine neue Firmware schreiben, die die Modulation und Codierung des Moduls übernimmt. Ich musste auch umschreiben, wie zwei Chips auf RL miteinander sprechen, um Nullen zu verarbeiten, da in Medtronic Nullen das spezielle Ende des Paketmarkers waren. Ein Großteil der Schleife musste neu gestaltet werden, um mehrere Pumpen zu unterstützen, sowie neue Schnittstellen, um das Pairing, Deaktivieren und die Fehlerbehandlung zu unterstützen. Glücklicherweise hat Nate Racklift bei Loop ein solides Fundament gelegt, um dies alles zu ermöglichen.

In der Zwischenzeit wurde weiter daran gearbeitet, das Format der Teams zu verstehen. Alles wurde sorgfältig im openomni-Wiki dokumentiert, der umfassendsten Dokumentation des Protokolls. Joe, Evarist und Elke Jäger haben im Laufe der Zeit wirklich gute Arbeit geleistet, um Nachrichten zu dekodieren und Seiten zu aktualisieren. Verschiedene Slack-Channel-Mitglieder haben zur Erfassung von PDM-Paketen und des Moduls beigetragen, um die gesamten Decodierungsbemühungen zu unterstützen.

Das Dekodieren war ein lustiger Job mit vielen kleinen Siegen, da jede Komponente jedes Teams entschlüsselt, und ich habe es wirklich gemocht, an diesem Teil zu arbeiten und Loop schrittweise Code hinzuzufügen. Im April 2018 teilte ich bei Slack mit, dass ich „eine primäre Kanülierung, die über iPhone + RL gemäß dem programmierten Grundplan gepaart wurde, durchgeführt habe und dann 5 Einheiten krank wurden“.

Die RL 2.0-Firmware wurde im Juli 2018 fertiggestellt, und neue Lieferungen wurden bereits durchgeführt. Es wurde gehofft, dass diese Karten mit Loop und Omnipod verwendet werden könnten, aber die vorhandene 915-MHz-Antenne war zu schlecht, um effektiv mit 433 MHz zu arbeiten.

Die Dekodierung und Implementierung hat im Sommer erhebliche Fortschritte gemacht, und Loop nähert sich allmählich der Leistung. Joe hat das Erstaunliche getan, indem er mir Geld gegeben hat, also habe ich meinen Job gekündigt und mich auf dieses Projekt konzentriert, und schließlich bin ich dem wunderbaren Tidepool-Team beigetreten. Natürlich gab es im Bereich DIY und der gesetzlichen Regelung für medizinische Geräte weitere Ereignisse, die ich nicht behandeln werde, aber es war ein sehr interessanter Sommer!

Schreier

Als weitere Funktionen im Treiber angezeigt wurden, habe ich ihn mit Loop verbunden und die Möglichkeit aktiviert, die Lieferung pünktlich automatisch zu konfigurieren. Zu diesem Zeitpunkt wurden häufig „auffällige“ Module erhalten, wenn bei einigen internen Modulprüfungen ein Problem festgestellt wurde und er die Insulinabgabe einstellte.

Dies schien jedoch ein lösbares Problem zu sein, da wir beim manuellen Senden von Befehlen weiterhin kleine Abweichungen in den Loop-Paketen und im ursprünglichen PDM fanden und ich davon ausging, dass die „Schreie“ aufhören werden, wenn wir sie alle beheben.

Arbeitsschleife!

Am 3. Oktober 2018 zog Joe das von Loop verwaltete Modul an und wurde der erste Loop Omnipod-Benutzer, obwohl er es mir nicht sofort sagte, weil er wusste, dass ich mir Sorgen machen würde. Als er es mir sagte, war ich immer noch besorgt. Wir haben gesehen, wie das Modul funktioniert, und die Funktionalität verstanden, und der grundlegende Algorithmus wurde lange getestet, aber immer noch ...



Einen Monat später, beim Nightscout-Hackathon im November 2018, beschlossen mehrere weitere Abenteurer, es selbst zu versuchen, und wurden Teil einer kleinen geschlossenen Testgruppe, die vor Veröffentlichung des Codes auf mehr als 30 Personen anwachsen wird.

Leider sind wir immer noch auf Modulschreie gestoßen, die häufig vor Ablauf der gesamten drei Tage auftreten, und wir haben Loop-Befehle sorgfältig mit PDM-Beispielen verglichen. In diesem Prozess war Elke besonders nützlich: Er schrieb ein Skript zum automatischen Überprüfen von Befehlen mit Originalversionen. Ich begann mir Sorgen zu machen, dass der intermittierende Betrieb der Module durch erhöhte Batterieanforderungen für die Kommunikation alle fünf Minuten verursacht wurde.


Gewindebohrer des Spannungsreglers im Modul, gebohrt durch den Kunststoff der Rückwand, auf Sekundenkleber

Daher begann ich, die Versorgungsspannung des Moduls mit Arduino zu messen, Daten zu schreiben und zur Visualisierung in einer lokalen Datenbank zu speichern. Ich habe PDM und Loop verglichen.


Langzeitänderung der Modulversorgungsspannung

Leider stellte sich heraus, dass dies auch eine Sackgasse war; Mit PDM und Injektion einer großen Menge Insulin konnte ich das Modul auf eine niedrigere Spannung bringen als während der gesamten Lebensdauer des Loop-Moduls und das Modul nicht zum „Schreien“ bringen. Es schien, dass Stress kein Problem war, es muss etwas anderes geben.


RileyLinks mit 955 MHz (links) und 433 MHz Spulenantennen (rechts)

Irgendwann bemerkte ich, dass das Modul, wenn der Austausch von Nachrichten mit dem Modul fehlschlug, manchmal weiterhin versuchte, den Austausch zu beenden, indem Pakete immer wieder erneut gesendet wurden. Die Testerprotokolle zeigten auch viele Störungen, so dass ich anfing, mit Antennen zu experimentieren. Beide Probleme sollten mit der Qualität der Kommunikation zusammenhängen. Ich hatte vor, verschiedene Antennen auszuprobieren und sie an verschiedenen Stellen im Internet zu bestellen, hatte aber keine Zeit, sie zu testen, bis dies zu einer Priorität wurde.

Ich hatte mehrere flexible 433-MHz-Antennen, die an der Innenseite des RL-Gehäuses angebracht werden können. In einigen Szenarien zeigen sie häufig eine bessere Leistung, in anderen jedoch nicht. zu unzuverlässig. Als ich zur Rolle kam, zeigte sie sehr konstant gute Leistung und auf sehr erstaunlichen Reichweiten. Zeit, einen neuen Fall für RileyLink zu machen.

Mit einer neuen Antenne und einigen Optimierungen, die das Messaging reduzierten und dennoch alle 5 Minuten Anpassungen vornahmen, wurden Schreie sehr selten. Wahrscheinlich vergleichbar mit der üblichen Verwendung von Modulen mit PDM. In den letzten 7.500 Stunden Echtzeit-Tests wurden 94% der Module ohne Fehler abgeschlossen.

Test und Dokumentation

Die Testgruppe wuchs langsam: Es kamen ständig neue Benutzer hinzu, die mit einem frischen Aussehen beurteilen konnten, welche Teile verwirrend aussehen. Diese Tester haben viele auffällige Module in Kauf genommen und einen großen Beitrag zur Verbesserung der Leistung von Loop mit Omnipod geleistet. Grundsätzlich haben sie Problemberichte und Arbeitsprotokolle gesendet.

Diese Berichte enthalten ein Protokoll mit Nachrichten, die mit einem von Elke erstellten Tool analysiert werden können. Es gibt eine Vorstellung davon, ob wir verzerrte Befehle erhalten, und ermöglicht es Ihnen, Statistiken über bestimmte Teile der Interaktion von Loop mit Modulen zu sammeln.

Marion Barker trat der Testgruppe bei und fügte spezielle Berichte und zusätzliche Statistiken zum Testfortschritt hinzu - und wir konnten ihre Statistiken über erfolgreiche Module gegen Fehler verwenden, um eine Vorstellung von Fortschritten auf hohem Niveau zu bekommen.

Am Ende trat Katie DiSimone der Testgruppe bei. Sie begann eine umfassende Umstrukturierung von loopdocs.org mit einer Dokumentation zur Verwendung von Loop mit mehreren Geräten. Das Warten auf die Version von Loop, die mit Omnipod funktioniert, war unglaublich hoch, und ohne gute Dokumentation war klar, dass wir mit denselben Fragen überfordert sein würden.

Neue Loop-Funktionen

Die Integration mit Omnipod erforderte ein Überdenken einiger Schnittstellenelemente und das Hinzufügen neuer Steuerelemente. Das Modul meldet den Akku nicht und der Benutzer kann in diesem Fall mit einer geringen Ladung wenig anfangen. Daher ist die Anzeige des Widgets für den Akkuladestand nicht sinnvoll. Darüber hinaus sollte der Benutzer ohne eine Benutzeroberfläche an der Pumpe in der Lage sein, den Bolus schnell abzubrechen. Das Panzersymbol zeigte den Medtronic-Panzer, daher wollten wir ihn neu gestalten. Vielen Dank an Paul Forgione für die Entwicklung des Logos des Moduls, das jetzt den Füllstand des Tanks anzeigt.

Danksagung

Vielen Dank an alle, die uns geholfen haben, diesen langen Weg zu gehen, damit wir das Ziel verwirklichen, das wir uns vor langer Zeit gesetzt haben. Ich weiß, dass ich nicht alle Beteiligten und nicht alle Ereignisse erwähnt habe. Dies ist in einem Artikel nicht möglich, und ich habe nur persönliche Erfahrung. Es ist schwer vorstellbar, wie viele Stunden es gedauert hat. Wenn Sie alle zusammenzählen, ist das sicher eine schockierende Zahl. Ganz zu schweigen von der Arbeit an der Schaffung des Omnipods selbst, die meines Erachtens all diese Bemühungen überschattet. Also vielen Dank an alle. Außerdem wären viele dieser Stunden sonst mit Familien verbracht worden. Ich schätze das Verständnis meiner Frau und meiner Kinder aufgrund der Zeit, die ich damit verbracht habe, sehr und möchte ihnen auch danken.

Anmerkungen

Ich sollte Joachim Ornstedt als einen der Mitwirkenden an der Openomni-Dekodierung sowie als den Schöpfer der wahrscheinlich ersten Integration mit Omnipod erwähnen. Er baute ein Gerät, das optische Zeichenerkennung (OCR) verwendete, um Daten aus dem PDM zu extrahieren, und verband die Zifferntasten über einen anderen Mikrocontroller mit dem physischen PDM. Dieser Ansatz ist schwer zu skalieren, aber er ist sehr intelligent und umgeht viele der Probleme, mit denen wir uns bei einer auf RE basierenden Lösung befassen mussten. Ich bewundere wirklich, wie er mit dem Problem umgegangen ist und die Arbeit für einen winzigen Bruchteil der Zeit eingerichtet hat, die erforderlich war, um das Gerät mit Loop zum Laufen zu bringen.