Nightscout bei 10BE jetzt kostenpflichtig! Und nun? [DE]

Ich bin seit vielen Jahren zufriedener „Kunde“ des kostenlosen Nightscout-Service von 10 be. Ich fand den Service immer sehr praktisch, zuverlässig und nobel! Das veranlasste mich auch regelmäßig eine kleine Spende abzugeben.

Anfang der Woche erreichte mich eine Email vom Support-Team in dem mir angekündigt wurde, dass 10BE quasi ab sofort kostenpflichtig wird. Die Begründung in der Mail erscheint mir nachvollziehbar und es ist auch ein erwartbarer Schritt. Ich habe mich auch schon die letzten Jahre gefragt wie das finanziell aufgeht, aber es war wohl immer ein Zuschuss-Geschäft. Ich denke niemand erwartet, dass so ein Server auf kosten von wenigen Privatleuten bereitgestellt wird.

ABER, ich habe natürlich etwas zu meckern:

• Die Deadline ist zu kurz: Die Deadline zum 1.10.21 finde ich relativ knapp. Als normaler Arbeitnehmer bleibt mir quasi keine Zeit darauf zu reagieren. Klar wollen sie schnell ihre Verluste minimieren aber es kommt mir so vor als ob hier druck aufgebaut werden soll.
• Exports sind kostenpflichtig: Der Export meiner Datenbank in eine andere MongoDB soll 15 EUR kosten. Warum?? Das wird doch automatisch erledigt, warum soll das Geld kosten ?! Ein Export ist wohl kostenlos, aber wer weiß was passiert, wenn der schief geht. Ich finde das unnötig und nicht sehr Benutzerfreundlich.
• Hohe Betriebskosten: Den Preis finde ich auch sehr hoch gewählt. Ich habe mal kurz überschlagen was der Betrieb eines Clusters bei AWS oder AZURE kosten würde und bin auf ein Bruchteil gekommen. Ja man kann noch etwas Personalkosten ansetzen. Aber von „null“ auf „so teuer wie Netflix“ finde ich schon hart. Ich hätte einen Selbstkostenbeitrag fair gefunden. Hier muss man aber von gewinnorientiertem Business ausgehen. Schade!
  Ich habe eine länger Diskussion in der Community gelesen, in der Martin (der Betreiber) erklärt, dass der Beitrag scheinbar nicht kostendeckend ist. Ich verstehe nicht ganz warum, denn aus meiner (über 10 jährigen) Erfahrung in dem Bereich müsste das problemlos möglich sein. Eventuell spielt die suboptimale Softwarearchitektur eine Rolle. NS ist eben nicht als Hyperscaler gebaut, sondern ein Open-Source-Community Projekt.
• Geschmäckle: Die Kundenstruktur von 10BE sind bestimmt hauptsächlich nicht-technik-affine Menschen, die zum Loopen eine NS Instanz brauchen. Für diese Leute gibt es quasi keine Wahl als die Kosten zu akzeptieren, denn in der Zeit kann man nicht schnell Urlaub nehmen, einen Helfer organisieren und den Umzug durchziehen.

Ich sehe ein, dass es sich hier um Jammern auf hohem Niveu handelt. Sicher gibt es gut Gründe für die genannten Punkte aber die sind nunmal nicht kommuniziert worden.

Was jetzt?

Ich denke seit der E-Mail nach, was für mich eine gute Strategie ist. Als Informatiker stehen mir ja quasi keine technischen Hürden im Weg. Allerdings habe ich auch nur begrenzt Zeit. Wahrscheinlich werde ich mir ein Jahresabo gönnen und in der Zeit an einer Alternative arbeiten. Im moment sehe ich folgende Möglichkeiten:

• Umzug zu kostenlosen Hosting-Angeboten: Das wäre der Standard-Weg, wie er auch in der OpenAPS Doku vorgeschlagen wird. Finde ich aber nicht optimal, da meine Daten dann im Ausland liegen. Außerdem können die sich auch jederzeit überlegen den Service einzustellen.
• Selbst hosten: Natürlich kann man sich immer einen Server mieten und NS installieren. Das wäre aber wirklich teuer im vergleich zum 10BE Angebot. Alternativ kann man es auch zuhause auf einem PC installieren der immer läuft. Kann man machen. Vermutlich würde sogar die tolle, deutsche, super langsame Internetanbindung ausreichen. Allerdings kümmert man sich dann auch selbst um Backups usw.
• Was neues bauen: Solche Umbrüche sind ja immer eine Gelegenheit. Immer wenn WhatsApp seine AGB ändert, gibt es andere Messenger die plötzlich Kunden bekommen. Ich habe einige Ideen wie man NS optimieren (und damit deutlich billiger betrieben) kann. Wenn ich die Zeit finde könnte es sein, dass ich einen eigenen Service anbiete 🙂

Was macht ihr mit euerer NS instanz? Bezahlen oder umziehen?

Completing AndroidAPS objectives – the developer way

Note: I will not answer any questions how to skip the objectives. If you are a developer I’m sure you figure it out within a few hours, but if not, you probably should complete them as you need a basic understanding how the system works.

Currently I’m testing Android APS with a second pump to get some experience with it and to evaluate if we can use it for our research. Apperently it has an education feature called „Objectives“ which teaches basic knowlege about the system. Even though I think the basic idea is very good, I don’t like the implementation. I thought I should try it, just in case there is something for me to learn but after I finished the first two of them (which were indeed interesting) they asked me questions about their documentation… Yes maybe people should be encuraged to read the documentation, but why should I know how to monitor children?? Or how the documentation author wants me to backup my data ??? And why are the answers written to confuse the reader instead of making the user think about the question ?!

I hated this part so much that I went straight to the AndroidAPS gitter room and complained to the developers that they are wasting my lifetime (and theirs too) with these questions. In my rage I totally fogot that they are nice people, spending their free time to write this application… Well, I apologized a short time later, but my point holds true. These „Objectives“ are a complete waste of time (in my optinion). We as developers are not in charge to keep stupid people from doing stupid things. We should warn them, but that’s all. We should not annoy other interested developers / scientists… I went to the code and looked up the answers to pass this objective.

Afterwards, I came back to my „maybe I should try it“ mode. But the next objective wanted me not only to enact some temporary basals by hand, but also to wait several days … Why should I do the looping by hand??? I do this 30 years by now. That’s what the looping software is supposed to do… And the waiting time serves no reason at all (in my oppinion). But the objective says I could ask for a shortcut code … and now the interesting part … when the developers *review my data* and think I’m experienced enough to start looping. I immediately entered rage mode again: „Who are they to decide if I’m good enough to use this software!“ I thought (Obviously this violated my professional integrity). But ok … I went back to the code to find out how they generate their shortcut code. After finding the respective code I used some standard tools to generete the code by myself. Done. It can be so easy 🙂

FAQ Miniloop

Some people liked my board and got a free sample 🙂 Unfortunately, I’m now faced with some support issues and want to summarize the most important aspects for getting started:

• First of all: You do this at your own risk! I can’t give any kind of guarantees or support for the board or what you do with it. Please respect local law and regulations when you build your board.
• NEVER power your Pi with a power supply when the board is connected. The board has no safety functions at all and I have no idea what happens with the voltage regulator or the connected battery when you connect a power supply to the Pi.
• You have to solder one jumper on the board which was not described in the previous post. I made a picture to show you how to connect. However, in general you should consult the schematic to answer such questions.

• The oref0 setup doesn’t support the board directly, but you can follow the install instructions for general RFM69HCW radio modules here.

 

BUT NOTE: I stopped working on this board, as Adafruit released the RFM69HCW Bonnet board, which is a Pi HAT with a radio transceiver and a OLED display. It’s also supported by the oref0-setup. I’ll post some more information about it soon.

Miniloop v0.1 Daughter Board

Since three month, I spend some time in the OpenAPS community. Of course I build some rigs and I try to find the optimal configuration for me at the moment. My design goals are clear:

• I want a super small rig, to carry it around all the time.
• It should run for at least one working day (10 hours).
• It should be super cheap to build, since it is a commodity item and may get damaged regularly.
• I don’t want to spend to much time to care about software issues.

Thankfully, the OpenAPS community has nearly the same design goals, and thus, there is lot’s of soft- and hardware around the RaspberryPi Zero. The current state-of-the-art solution is the Pi0 together with a communication board called 900MHZ Explorer HAT. It offers a radio chip, a step-up converter to use 1S Li-Po batteries to power the pi, a charging circuit to charge the 1S Li-Po, some LEDs and a display. It works quite well, but let’s face it: I hate it! I have lots of complains about that board, but that’s a topic for a different post. The important points are:

• It’s way to expensive! (~180 EUR inkl. tax, toll and shipping).
• I don’t need the display.

So .. typical (maybe German) reaction from my side: „Hold my beer for a moment, I can do that!“. I thought a bit, how to make it super small and easy to build at the same time (since I have no clue about electrical engineering). My solution was to build a daughter board, holding a RF module, a chip antenna, the Pi0, a buck-boost regulator and a ADC for measuring battery voltage. I also added some buttons and some LEDs just in case …

After some work making a schematic and a board design, I simply ordered everything and tired to build it up. The board came as 3 in 1 panels, so I had so separate them first. The quality looks decent and it seems to have enough space for all components.

Motivated from this first success I started soldering. As one of my design goals was easy to build, I used 1206 SMD components, since they are pretty easy to solder but keep the design small. As power plug I used a XT40 connector, since I have a lot of 2S batteries from my drones (caution: the voltage regulator destroys itself and every other component on the board including the Pi0 if you put more voltage than 11V). The RFM69 is place able as SMD component out of the box. For the voltage regulator I had to cut the board a bit, to be able to solder the through hole connections to my daughter board, but wasn’t any of an issue.

BTW: As minimal version, it’s enough to solder the voltage regulator, the radio board and a power plug along with some pin headers for the PI0. As Antenna a piece of wire with a length of 86 mm (for 868 MHz) is good enough.

As always in my hardware projects, I had some issues while placing the components. I figured, the SD-card slot is unreachable if I solder the buttons and the Pi und the bottom layer.

To fix this, I put the Pi0 on the upper layer. The result isn’t as thin as it was supposed to be, but still ok (and still thinner as the Explorer HAT 😀 ). For now, it’s good enough as development platform and for testing. When the main problems are solved and the software is ported, maybe I’ll update the design to match the original design goals.

I put together some affiliate links if you want to gather the parts at Amazon:

• RFM69 Module 868 MHz
• Chip Antenna for 868 MHz
• Pololu Buck-Boost-Converter

One word on software support: Since the OpenAPS usually uses a different (and lot more expensive) radio device, the RFM69 is not supported out of the box. At the current time, it’s possible to run this board with the oref0 version 0.7.0-dev, if the corresponding communication programs (programmed in GO-lang) are compiled with the tag „-tags rfm69“. More information about this is shown on github. I’ll work on this and write an update when the software is full compatible.

PS: I have some left over boards, which I’ll give away for free (except shipping). Just ask if you like to have one 🙂

Contour NEXT Link & Link 2.4 Teardown

Für die Insulinpumpen von Medtronic gibt es schon einige Jahre lang Blutzuckermessgeräte die das Messergebnis per Funk an die Pumpe übertragen können. Laut Hersteller braucht man das, um weniger Eingabefehler zu machen 😀 . Ich fühle mich zwar im Stande eine 2-3 stellige Zahl abzuschreiben aber finde es dennoch sehr praktisch, da es viel schneller und bequemer ist. Die aktuelle Reihe dieser Geräte sind die Contour NEXT Link für Paradigm Insulinpumpen und die Contour NEXT Link 2.4 für die neuen 600er Insulinpumpen. Ich habe mich immer gefragt warum man den Nachfolger 2.4 und nicht 2 nennt aber dazu gleich mehr!

Allerdings habe ich mich immer gefragt was technisch hinter dem Zauber steckt. Meine Annahme war, ein Standard-Prozessor der die Messung erledigt, ein Funk-Chip zur Übertragung und ein rieeeeesiger Akku. Ich wollte es dann doch aber etwas genauer wissen und hab mal eins auseinander genommen:

Mein erster Eindruck war etwas ernüchternd. Der Akku ist winzig (!!) und es ist noch jede Menge Luft im Gehäuse. Nicht das mir die Akkulaufzeit nicht reicht, ganz im Gegenteil. Aber man hätte das Ding halb so dick bauen können …. Ok weiter im Text: Man sieht eine schöne Platine mit integrierter Antenne, auf der anderen Seite das Display. Also mal weiter auseinander nehmen:

Unter dem Display findet sich ein Slot für die Teststreifen, zwei Mikrocontroller und jede Menge Kleinkram. Ich war etwas überrascht, dass es gleich zwei Mikrocontroller sind. Google lieferte mir auch keine belastbaren Informationen. Der eine ist ein „Toshiba T5DB0“ der vermutlich der Hauptprozessor ist, denn in einem Forum habe ich gelesen, dass der gleiche Chip in älteren Geräten zu finden ist. Der andere Chip mit dem formschönen Namen „F3796 018 usw“ scheint mir ein Displaycontroller zu sein, da er mit dem Display-Connector verbunden ist.

Hätte man sich meiner Meinung nach alles sparen können, denn ich benutze das Gerät nur um einen Teststreifen einzustecken und Blut drauf zu geben wenn ich dazu aufgefordert werde. Den Wert lese ich auf der Pumpe ab. Früher haben die Geräte auch schneller gebootet, da man kein Farbdisplay hatte auf dem 100 Logos eingeblendet wurden bevor man messen kann … Aber gut, lass sie machen.

Kommen wir zum interessanten Teil: Der Funkübertragung! Unter dem EM-Shield findet man einen Funk-Chip von Texas Instruments, den CC2430 (müsst Ihr mir jetzt glauben, ich habe das EM-Shield nicht vollständig entfernt da ich das Gerät noch brauche und konnte deshalb kein Foto machen). Das Datenblatt sagt, dass es sich um einen ZigBee-Chip auf dem 2.4 GHz Band handelt. Ahaaaa 2.4!!! Ich bin ein wenig überrascht, warum Medtronic von ihrem 868 MHz Band auf das 2.4er gewechselt sind. Aus meinen Vorlesungen habe ich noch im Hinterkopf, dass niedrige Frequenzen (im Vergleich zu hohen Frequenzen) weniger Energie brauchen und höhere Reichweite haben. 2.4 GHz hat den Vorteil, dass man die Antenne kompakter bauen kann und man mehr Bandbreite hat. Beide Punkte werden von dem Gerät nicht genutzt .. also … WTF! Man hat sich jetzt ein Band ausgesucht, dass dank WLAN total überlastet ist, mehr Energie verbraucht oder kürzere Reichweite hat und sich damit sicherlich einige Störungen eingehandelt …

Die einzigen beiden plausiblen Gründe die mir für so eine Entscheidung einfallen sind:

• Lizenzkosten für das 868 MHz Band (keine Ahnung was das kostet, aber soweit ich weiss ist 2.4 GHz weltweit kostenlos da es ein ISM Band ist und 868 MHz nicht).
• Man wollte diese (völlig nutzlose) „ich kann jetzt von meiner Pumpe aus einen manuellen Bolus geben“-Funktion einbauen, hat aber keine Lust gehabt das eigene Protokoll zu erweitern und hat ZigBee eingekauft. WTF ZigBee … das Protokoll über das es mehr security-break-Paper gibt als Bibeln im Jahr verkauft werden. Für ein lebenswichtiges Gerät!! Gäbe es doch nur ein Protokoll auf dem 2.4 GHz Band, dass halbwegs sicher und energiesparend ist und bereits für den Gesundheitseinsatz Protokolle definiert hat … Aber auf der anderen Seite ist das ganz nett, denn ZigBee ist deutlich leichter abzuhören als das 868 MHz Band, denn das Protokoll ist bekannt und die Hardware ist billig (das riecht nach einem Projekt).

Mich hat dann doch noch interessiert was die „alten“ Geräte zu bieten haben. Der Aufbaut ist prinzipiell identisch. Aber es ist natürlich kein ZigBee-Chip verbaut, sondern ein Funk-Chip der das 868 MHz Band unterstützt: Der CC1110 von Texas Instruments. Bei dem alten Geräte haben ich dann natürlich für ein Foto den EM-Shield entfernt 😉 .

Wir werden sehen wo das alles noch hin führt. Ich würde ja gerne mal in so ne Entwicklungsabteilung schauen und die Leute fragen was sie eigentlich so den halben Tag rauchen 😀 .

Freestyle Libre Sensor

Erster Urlaubstag seit langem, wunderbares Wetter und was macht man da ? Genau, ausschlafen und man bastelt ein wenig an Elektronik rum 😀

Ich habe mir mal den Freestyle Libre Sensor angesehen. Es handelt sich um einen sogenannten CGM Sensor, der kontinuierlich den Glokosewert in der Gewebsflüssigkeit bestimmt. Dieses Messverfahren brachte auch die Firma Medtronic vor einigen Jahren auf den Markt.

Das besondere an dem Sensor ist, dass er sehr, sehr preiswert ist, sich über NFC auslesen lässt und sich selbst kalibrieren kann. Diese Kombination möchte ich fast einen Geniestreich nennen. Durch den geringen Preis sehen sich einige Patienten in der Situation, die Sensoren aus eigener Tasche zu bezahlen. Die Datenübermittlung über NFC erspart teure Transmitter und Stromversorungslösungen. Dadurch wird natürlich der Sensorpreis gesenkt und der Sensor wird jedesmal komplett (samt Elektronik) entsorgt was den Aufbau sehr einfach macht und somit Entwicklungs- und Herstellungskosten senkt. Durch die innovative (und bei Medtronic fehlende) eigenständige Kalibrierung, ist das Messsystem eigentlich idiotensicher.

Der Aufbau ist wie folgt: In der Mitte befindet sich der Messfaden (und vermutlich minimale Messelektronik) in einem Kunststoffgehäuse. Die Platine besteht aus einer NFC Antenne, einer Varta V377 Knopfzellen Batterie (1,55 V 27 mAh) und einem Microchip. Leider ist die Modellnummer auf dem Microchip nicht wirklich lesbar. Aus den Zeichen die ich lesen konnte, bin ich über Google auf den RF430FRL152H von Texas Instruments gekommen. Das würde gut passen, denn es ist ein NFC Chip der bei 1,55 V arbeiten kann und dafür gedacht ist Sensoren auszulesen. Die orange Fahne scheint ein Temperatursensor zu sein, denn der Sensor kann sich melden wenn ihm zu warm oder zu kalt wird.

Aus meiner Sicht hat das Konzept aber drei Probleme:

1. Müll: Ein Sensor verursacht sehr, sehr viel Müll. Beim Anlegen kriegt das grüne Gewissen schon einen Herzinfarkt, da die Applikationshilfe (aus stabilem Kunststoff) weggeworfen wird. Natürlich kann man so sicherstellen, dass das Ding sauber ist, aber ist das nötig? Die Antwort ist nein, denn Medtronic hat das besser gelöst. Dazu kommt der Sensor selbst, der wiederum ein recht stabiles Kunststoffgehäuse hat und offensichtlich einiges an Elektronik.
2. Messgenauigkeit: Der Sensor kalibriert sich selbstständig. Das ist eigentlich auch eine super Sache, aber bei mir waren die Messwerte nicht immer exakt (und damit meine ich Messunterschiede von bis zu 60 mg/dl). Eine Möglichkeit zur Nachkalibrierung durch eine Blutmessung wäre schon sinnvoll.
3. Geplante Obsoleszenz: Der Sensor zählt intern bis 14 Tage rum sind und meldet sich dann als verbraucht. Allerdings meldet er sich auch schon früher als verbraucht, wenn er eben früher verbraucht ist und keine sinnvollen Messungen mehr möglich sind. D.H., dass der Sensor sich selbst testen kann ob er noch funktioniert. Ich finde, damit ist der Zähler überflüssig und grenzt an Geldmacherrei … wieso sollte ich den Sensor denn nicht einen Tag länger nutzen wenn er einen Tag länger funktionieren kann…

Meine Ideen zur Version 2 (die nebenbei auch den Verkaufspreis senken könnten) wären daher:

1. Applikationshilfe extra verkaufen und nicht als Einmalprodukt verwenden. Als Zwischenschritt vllt einen 6er Sensorpack (Quartalspacket) anbieten, dass nur einen Applikator hat.
2. Nochmal ein paar Minuten Nachdenken und die Elektronik besser vom Messfaden trennen. Die zwei Teile sind ja bereits getrennt. Wieso kann ich keinen Mechanismus haben um die Elektronik ein paar mal zu verwenden. Nach meiner Schätzung, kann der Chip die Batterie noch nicht völlig entleert haben. Man könnte aber auch eine etwas stärkere Batterie einbauen und wieder einen 6er Packe mit nur einem Elektronikboard anbieten. Das würde schon einiges an wertvollen, seltenen Ressourcen schonen.
3. Stromversorung durch Akkus. Wenn die Elektronik sinnvoll vom Messfaden getrennt ist, könnte die Stromversorgung auch direkt durch Akkus erfolgen, die in einer Ladestation geladen werden. Dadurch würde eine Menge Giftmüll eingespart werden.
4. Händisches Nachkalibrieren. Die angezeigten Werte sind natürlich niemals gemessene Werte. Die Messung der Gewebeflüssigkeit ist stark verzögert (15-30 min). Daher sind die gezeigten Werte eher geraten als gemessen (der Fachmann spricht von extrapolieren). Man kann jedoch die Messkurve auslesen und anzeigen und dann vergleichen wie genau die echt gemessenen Werte waren. Ok wenn ich jetzt sehe, dass schon die Basis der Raterei nicht stimmt, wie sollte dann das Gerät jemals etwas richtiges anzeigen. Genau .. keine Chance … Es wäre aus meiner Sicht nicht besonders aufwändig, einen Referenzwert einzugeben der die Messwerte korrigiert.

Freestyle Libre ist ein wirklich schönes System, das bei mir zumindest zu deutlich höherer Messfrequenz führt und damit die Therapie und Lebensqualität verbessern kann. Offenbar hat Abbott aber noch etwas Arbeit vor sich, um die genannten Schwächen auszubügeln. Desweiteren sollten sie eine Kooperation mit einem Insulinpumpenhersteller anstreben, um die Werte direkt an die Insulinpumpe zu übertragen. Ich bin gespannt was da noch kommt.

Cheers!

 

PS: Wer jetzt mehr Infos über den Sensor will, dem empfehle ich die Herstellerseite und den Blog von Marcel Klug, denn der kluge Mann (haha was ein Wortspiel, ist bestimmt ganz neu 😀 ) hat sich mal die Speicherstruktur des Sensors genau angesehen und eine Leseapp gebastelt 🙂