Another status update

With today’s ready-packed devices, now 34 blueReaders have been shipped and actually one has already been exchanged.

All who are waiting now: It’s going forward! Every day we are getting slightly better, find new details in production and continue to optimize!

Actually, we had hoped for 5-10 devices a day, but unfortunately we do not make it yet :/ Why?


  • Problems in potting and a possibly poor batch of silicone have generated almost 30 damaged blueReaders we needed to unpack and prepare for another round..
  • Due to too much use of release agents during soldering, components on almost 20 boards were damaged, all had to be checked manually and defective components replaced.
  • Poor pigments have led to bleed out of colors from some blueReaders.
  • A few changed details in the components of the blueReader, which help us to improve the current flow while charging, required a revision on nearly 40 blueReader boards and almost all wireless loader boards that had already been manufactured.

So as always: plenty to do 🙂

Also at the software I am still working on, unfortunately still not completely presentable, but hopefully more in the next days …

The current state is that we still have problems with few devices on Android 7. However, it is still not quite clear whether there are errors in xDrip+ or the Android or something else. But we’re working on it!

folge dem Wert…

Heute erreichten mich auch nachfragen zu dem Thema:

Wie kann ich die Werte auf einem anderen Gerät verfolgen?

Für ein lokales Netzwerk geht das recht einfach zwischen zwei Android Handys. Dazu einfach einen Blick in die Video-Anleitung von jamorhan werfen:

Wenn es auch über das Internet gehen soll oder mit iOS, dann muss man Nightscout benutzen. Ein Diabetes-Management-System in der Cloud. Eine ausführliche deutsche Anleitung gibt es unter zu finden, inklusive des Einrichtens der xDrip-App um die Daten in die Cloud zu bekommen. Für die iOS-blueReader-App wird dies analog sein.

Um den Daten dann zu folgen gibt es neben der eigenen NightScout-Webseite auch verschiedene Apps:

Beispiele für iOS:

Beispiele für Android:

A little more…

Today, I received first alerts, as there are maybe Android 7 related problems. Unfortunately, I can not yet explain anything, since we have a mobile where it works without any problems and a another mobile where no stable connection seems possible. Apparently it is connected to the greater errors in the Android 7 regarding bluetooth connectivity, but as soon as I find something more accurate, I will report: /

Something about the Software…

Now that the first 16 devices are shipped, it is also time to write something about the software:

Currently there is an integration for Android in the quite popular xDrip-plus, which is developed by outstanding people completely OpenSource.

The current releases of xDrip + are available here:

Once the app is installed, select the “LimiTTer” under “Settings” -> “Hardware Data Source”, then simply search for the blueReader under “Bluetooth Scan” and wait until the first values arrive. If necessary, select “Start sensor” in the main menu and enter a calibration value.

For iOS I will publish in the next days more Information.


Number One…

Without to much words:

The package list for the first has been completed!


and labeled with the all you can eat label package  🙂

The first boxes will start the journey tomorrow to Germany, Switzerland, Slovakia and to England! I also hope that I get the order system adjusted today to send the tracking codes to the first customers!

What is in the box?

1x blueReader colored as ordered (and with or without magnets)

1x wireless Charger, in the ordered color

1x Micro-USB-Kabel if chosen

1x Short manual in german and english: blueReader short manual

1x Holder v3: same color as the wireless charger.

I hope this increases still a little more the anticipation 🙂

MIstakes found…

A week search is now behind me, but I have found crucial errors.

Now the delivery is close!

What was going on this time?

  • Saving energy on the edge of the game has a massive impact on the stability of the chip.
  • There are many possibilities to realize uart communication on the chip, but apparently only one that really works.

The result is a much slimmer and faster firmware which unfortunately needs more energy as I had hoped (in comparison to the last post), but still low enough to have probably energy for up to 7 days. The energy levels of this one measurement described in the last post could not be reached again, unfortunately. But if the tests are good, and up to 7 days are possible, this is still a very good result in my opinion, especially if the runtime is reproducible.

Now comes the finishing touches for the transfer of the commands and the devices will go into shipping. I will avoid a longer test period, since  the firmware can be renewed at any time via a mobile phone. 🙂

The final sprint is here!

The final Countdown…

…starts now!

Why did I not report back for so long?

Because I’ve worked a lot! But what had to be done?

We have still found one or the other small problem with the hardware and I have started with the final firmware for the blueReader. There was also one or the other problem with the software and many small surprises:

Most of the headaches had always been the energy consumption, so we measured, tweaked and tried out to find out where the whole energy went, although we still use one of the most energy-efficient chips available on the market (The nRF52 is of course much better, but was not yet available at the start of the project).

The answer was not so easy, we first decomposed the hardware step by step (or equipped boards only partially) to determine the real consumption of individual components.

This brought only a small improvement: A redundant diode could be deleted from the placement plan and brought us minimal more energy when loading the blueReader, but nothing that is of real significance.

So I have continued with the software. Where can energy be wasted? A few minor things are noticeable, as on page 41 of the reference documentation of the NFC chip, a footnote to a table describing a function that simply is missing in the documentation of the protocol and helps saving a lot of energy. These and many other minor changes brought me to a stable runtime of two days with one load.

That was still not in the range of what I wanted or regarded as something acceptable. After this, an odyssey lasting over a week started with me versus the internals of the BLE chip …

After a short time, it was clear that a mistake in the management of the connection between BLE and NFC chip caused a far too much energy need for nothing, and even more because it was sometimes the reason because of which the NFC chip was not sleeping. Result: over 3 days running time are possible. However, during those tests there were always errors in the timers, which are code blocks which are executed after a certain time or at certain intervals. This took me eventually to the finish line …

After devouring incredible amounts of documentation on the subject of the timer, I was able to re-structure the code and went expectantly into the initial measurements:

For all those who only see a colorful picture: This is a measuring device, actually a quite expensive one, but this one is self built by us 🙂 For all others: A measurement with a 10Ohm shunt, resolution 20ms / 0.1V, large plateau is read out of the Libre-Sensor, small plateau transfer of the data to the mobile phone, tail is standby with active BLE connection …

The energy requirement is now negligible! Negligible? Yes! The system should now run over 25 days with just one load: D But I will not wait until it is empty before I deliver the first devices … But I will write a post of course as soon as I have the first reliable data!

If the calculation should coincide with the reality, it is enough to charge the blueReader during the warmup time of a new sensor to get enough energy for the next 14 days, but as I said, first wait for data!

Oh so, the data also refer to some changed parameters.. so far, all solutions have read the sensor at top every 5 minutes, but the sensor itself stores a new value every minute! So I have reduced the interval to one minute for these tests and calculations 🙂

What’s up next?

  • A few small changes are still necessary in the firmware to be able to deliver the first devices.
  • These changes I intend to have completed by Monday.
  • Here are now waiting almost 20 devices to get their release firmware (all transparent, with and without magnets) which are then to be sent directly to you all  🙂

So let’s see if this weekend brings even more joyful surprises!