Beurer GL50, Linux and Debug Interfaces

In the previous post when I reviewed the Beurer GL50, I have said that on Windows this appears as a CD-Rom with the installer and portable software to use to download the data off it. This is actually quite handy for the users, but of course leaves behind users of Linux and macOS — except of course if you wanted to use the Bluetooth interface.

I did note that on Linux, the whole device does not work correctly. Indeed, when you connect this to a modern Linux kernel, it’ll fail to mount at all. But because of the way udev senses a new CD-Rom being inserted, it also causes an infinite loop in the userspace, making udev use most of a single core for hours and hours, trying to process CD in, CD out events.

When I noticed it I thought it would be a problem in the USB Mass Storage implementation, but at the end of the day the problem turned out to be one layer below that and be a problem in the SCSI command implementation instead. Because yes, of course USB Mass Storage virtual CD-Rom devices still mostly point at SCSI implementations below.

To provide enough context, and to remind myself how I went around this if I ever forget, the Beurer device appears to use a virtual CD-Rom interface on a chip developed by either Cygnal or Silicon Labs (the latter bought the former in 2003). I only know the Product ID of the device as 0x85ED, but I failed trying to track down the SiliconLabs model to figure out why and how.

To find may way around the Linux kernel, and try to get the device to connect at all, I ended up taking a page off marcan’s book, and used the qemu’s ability to launch a Linux kernel directly, with a minimum initramfs that only contains the minimum amount of files. In my case, I used the busybox-static binary that came with OpenSuse as the base, since I didn’t need any particular reproduction case beside trying to mount the device.

The next problem was figuring out how to get the right debug information. At first I needed to inspect at least four separate parts of the kernel: USB Mass Storage, the Uniform (sic) CD-Rom driver, the SCSI layer, and the ISO9660 filesystem support — none of those seemed a clear culprit at the very beginning, so debugging time it was. Each of those appear to have separate ideas of how to do debugging at all, at least up to version 5.3 which is the one I’ve been hacking on.

The USB Mass Storage layer has its own configuration option (CONFIG_USB_STORAGE_DEBUG), and once enabled in the kernel config, a ton of information on the USB Mass Storage is output on the kernel console. SCSI comes with its own logging support (CONFIG_SCSI_LOGGING) but as I found a few days of hacking later, you also need to enable it within /proc/sys/dev/scsi/logging_level, and to do so you need to calculate an annoying bitmask — thankfully there’s a tool in sg3_utils called scsi_logging_level… but it says a lot that it’s needed, in my opinion. The block layer in turn has its own CONFIG_BLK_DEBUG_FS option, but I didn’t even manage to look at how that’s configured.

The SCSI CD driver (sr), has a few debug outputs that need to be enabled by removing manual #if conditions in the code, while the cdrom driver comes with its own log level configuration, a module parameter to enable the logging, and overall a complicated set of debug knobs. And just enabling them is not useful — at some point the debug output in the cdrom driver was migrated to the modern dynamic debug support, which means you need to enable the debugging specifically for the driver, and then you need to enable the dynamic debug. I sent a patch to just remove the driver-specific knobs.

Funnily enough, when I sent the first version of the patch, I was told about the ftrace interface, which turned out to be perfect to continue sorting out the calls that I needed to tweak. This turned into another patch, that removes all the debug output that is redundant with ftrace.

So after all of this, what was the problem? Well, there’s a patch for that, too. The chip used by this meter does not actually include all the MMC commands, or all of the audio CD command. Some of those missing features are okay, and an error returned from the device will be properly ignored. Others cause further SCSI commands to fail, and that’s why I ended up having to implement vendor-specific support to mask away quite a few features — and gate usage in a few functions. It appears to me that as CD-Rom, CD-RW, and DVDs became more standard, the driver stopped properly gating feature usage.

Well, I don’t have more details of what I did to share, beside what is already in the patches. But I think if there’s a lesson here, is that if you want to sink your teeth into the Linux kernel’s code, you can definitely take a peek at a random old driver, and figure out if it was over-engineered in a past that did not come with nice trimmings such as ftrace, or dynamic debug support, or generally the idea that the kernel is one big common project.

Glucometer Review: beurer GL50 evo

I was looking for a new puzzle to solve after I finally finished with the GlucoRx Nexus (aka TaiDoc TD-4277), so I decided to check out what Boots, being one of the biggest pharmacy in the country, would show on their website under “glucometer”. The answer was the Beurer GL-50, which surprised me because I didn’t know Beurer did glucometers at all. It also was extremely overpriced at £55. But thankfully I found it for £20 at Argos/eBay, so I decided to give it a try.

The reason why I was happy to get one was that the the device itself looked interesting, and reminded me of the Accu-Chek Mobile, with its all-in-one design. While the website calls it a 3-in-1, there are only two components to the device: the meter itself and the lancing device. The “third” device is the USB connector that appears when you disconnect the other two. I have to say that this is a very interesting approach, as it makes it much easier to connect to a computer — if it wasn’t that the size of the meter makes it very hard to connect it.

On my laptop, I can only use it on the USB plug on the right, because on the left, it would cover the USB-C plug I use to charge it. It’s also fairly tall, which makes it hard to use on chargers such as my trusted Anker 5-port USB-C (of which I have five, spread across rooms.) At the end, I had to remove two cables from one of them to be able to charge the meter, which is required for it to be usable at all, when it arrives.

To be honest, I’m not sure if the battery being discharged was normal or due to the fact that the device appears to have been left on shelves for a while: the five sample strips to test the device expire in less than two months. I guess it’s not the kind of device that flies off the shelves.

FreeStyle Libre, gl50 evo, GlucoRx Nexus

So how does the device fare compared to other meters? Size wise, it’s much nicer to handle than the GlucoRx, although it looks bigger than the FreeStyle Libre reader. Part of the reason is that the device, in its default configuration, includes the lancing device, unlike both of the meters I’m comparing it with above. If you don’t plan to use the included lancing device, for instance because you have a favourite lancing device like me (I’m partial to the OneTouch Delica), you can remove the lancing device and hide the USB plug with the alternative provider cap. The meter then takes a much smaller profile than the Libre too. I actually like the compact size better than the spread out one of the FreeStyle Precision Neo.

FreeStyle Libre, gl50 evo (without lancing device), GlucoRx Nexus

Interface-wise, the gl50 is confusingly different from anything I have seen before. It comes with a flush on/off switch on the side, which would be frustrating for most people with short nails, or for people with impeded motion control. Practically, I think this and the “Nexus” are at opposite ends of the scale — the TD-4277 has big, blocky display that can be read without glasses and a single, big button, which makes it a perfect meter for the elderly. The gl50 is frustrating even for me in my thirties.

The flush switch is not the only problem. After you turn it on, the control you have is a wheel, which can be clicked. So you navigate menus in up-down-click. Not very obvious but feasible. But since the wheel can easily be pressed in your purse, that’s why you got the flush switch, I guess. The UI is pretty much barebone but it includes the settings for enabling Bluetooth (with a matching Android app, which I have not checked out for this review yet), and NFC (not sure what for). Worthy of note is that the UI defaults to German, without asking you, and you need to manage to get to the settings in that language to switch to English, Italian, French, or Spanish.

Once you plug it into a computer with Windows, the device appears as a standard CD-Rom UMS device that includes an auto-started “portable” version of the download software, which is a very nice addition, again reminiscent of the Accu-Chek Mobile. It also comes with an installer for the onboard software. As a preview of the technical information post on this meter, it looks like that, similar to the OneTouch Verio, the readings are downloaded through UMS/SCSI packets.

I called out Windows above because I have not checked how this even presents on macOS, and on Linux… it doesn’t. It looks like I may have to take some time to debug the kernel, because what I get on Linux is infinite dmesg spam. I fear the UMS implementation on the meter is missing something, and Linux sends a command that the meter does not recognize.

The software itself is pretty much bland, and there’s nothing really much to say. It does not appear to have a way to even set or get the time for the device, which in my case is still stuck in 2015, because I couldn’t bother yet to roll the wheel all the way to today.

Overall, I wouldn’t recommend this meter over any of the other meters I have or used. If beurer keeps staying in the market of glucometers (assuming they are making it themselves, rather than rebranding someone else’s, like GlucoRx and Menarini appear to do), then it might be an interesting start of further competition in Europe, which I would actually appreciate.

Glucometer notes: GlucoRx Nexus

This is a bit of a strange post, because it would be a glucometer review, except that I bought this glucometer a year and a half ago, teased a review, but don’t actually remember if I ever wrote any notes for it. While I may be able to get a new feel for the device to write a review, I don’t even know if the meter is still being distributed, and a few of the things I’m going to write here suggest me that it might not be the case, but who knows.

I found the Nexus as an over-the-counter boxed meter at my local pharmacy, in London. To me it appears like the device was explicitly designed to be used by the elderly, not just because of the large screen and numbers, but also because it comes with a fairly big lever to drop out the test strip, something I had previously only seen in the Sannuo meter.

This is also the first meter I see with an always-on display — although it seems that the backlight turns on only when the device is woken up, and otherwise is pretty much unreadable. I guess they can afford this type of display given that the meter is powered by 2 AAA batteries, rather than CR2032 like others.

As you may have guessed by now from the top link about the teased review, this is the device that uses a Silicon Labs CP2110 HID-to-UART adapter, for which I ended up writing a pyserial driver, earlier this year. The software to download the data seems to be available from the GlucoRx website for Windows and Mac — confusingly, the website you actually download the file from is not GlucoRx’s but Taidoc’s. TaiDoc Technology Corporation being named on the label under the device, together with MedNet GmbH. A quick look around suggests TaiDoc is a Taiwanese company, and now I’m wondering if I’m missing a cultural significance around the test strips, or blood, and the push-out lever.

I want to spend a couple notes about the Windows software, which is the main reason why I don’t know if the device is still being distributed. The download I was provided today was for version 5.04.20181206 – which presumes the software was still being developed as of December last year – but it does not seem to be quite tested to work on Windows 10.

The first problem is that that the Windows Defender malware detection tool actually considers the installer itself as malware. I’m not sure why, and honestly I don’t care: I’m only using this on a 90-days expiring Windows 10 virtual machine that barely has access to the network. The other problem, is that when you try to run the setup script (yes, it’s a script, it even opens a command prompt), it tries to install the redistributable for .NET 3.5 and Crystal Reports, fail and error out. If you try to run the setup for the software itself explicitly, you’re told you need to install .NET 3.5, which is fair, but then it opens a link from Microsoft’s website that is now not found and giving you a 404. Oops.

Setting aside these two annoying, but not insurmountable problems, what remains is to figure out the protocol behind the scenes. I wrote a tool that reads a pcapng file and outputs the “chatter”, and you can find it in the usbmon-tools repository. It’s far from perfect and among other things it still does not dissect the actual CP2110 protocol — only the obvious packets that I know include data traffic to the device itself.

This is enough to figure out that the serial protocol is one of the “simplest” that I have seen. Not in the sense of being easy to reverse, but rather in term of complexity of the messages: it’s a ping-pong protocol with fixed-length 8-bytes messages, of which the last one is a simple checksum (sum-modulo-8-bit), a fixed start byte of 0x51, and a fixed end with a bit for host-to-device and device-to-host selection. Adding to the first nibble of the message to always have the same value (2), it brings down the amount of data to be passed for each message to 34-bit. Which is a pretty low amount of information even when looking at simple information as glucose readings.

At any rate, I think I already have a bit of the protocol figured out. I’ll probably finish it over the next few days and the weekend, and then I’ll post the protocol in the usual repository. Hopefully if there are other users of this device they can be well served by someone writing a tool to download the data that is not as painful to set up as the original software.

A FreeStyle Libre Update

The last time I wrote anything interesting about Abbott’s flash glucose monitor (don’t call it a CGM) was when I compared it with the underwhelming Dexcom G6. I thought it would be a good time to provide an update, what with Abbott sending a number of email reminding you to update their FreeStyle LibreLink app in the past couple of weeks.

First of all, there’s the matter of supplies. Back in January, I decided to test Dexcom’s CGM because Abbott’s supply issues bit me in the backside, as I could not get new sensors to keep up with my usage — particularly as the more active life in London with my girlfriend meant losing a couple more sensors to mistakes, such as bumping into the doorframe. For a while, you could only buy three sensors every 25 days, and even then, sometimes the lead time to fulfill the order would be over a week; nowadays this appears to be much better, and the time limit for the orders was removed recently.

Since I was not particularly thrilled to switch to the Dexcom G6, I had to find a way around these limits, beside counting on the two extra sensors I “gained” by not using the Libre for a month. Luck was that a friend of my girlfriend found the Libre sensors on sale in a brick-and-mortar store in Sharjah, and managed to send me six of them. The store had no limits on how many sensors you could buy, despite the FreeStyle UK website only allowing orders of three at most, and only to already-established customers.

The UAE-bought sensors are effectively the same as the British ones, with the same manufacturing information printed on them, and even similar enough lot numbers. The most visible difference is that the two alcohol-soaked tissues, provided for cleaning the insertion point, are missing.

The other difference is not visible in the packaging, or indeed on the hardware itself: the sensors are region-locked. Or maybe we should say that the app is. As it is, my (UK) FreeStyle LibreLink install did not want to set up the UAE-bought sensors. The reader device had no such concern and both initialised and read them just fine. I was originally a bit concerned and spot-checked the values with fingersticks, but it looked like there was no issue with the sensors at all.

I’ve been wondering just how much the supply problem connects with the region locking. Or just how fine-grained the region locking is: my Irish sensors worked perfectly fine with the UK app, although by that point, the app was not available in Ireland at all. But possibly all of these problems are gone.

Now, to go back to Abbott’s email messages to update their LibreLink app. The reason for this update is not much about the UI of the app itself – although that did change a bit, in subtle and annoying ways – but rather a change in their algorithm for turning the sensors’ readings into a human-understandable blood glucose reading. The “curve”, as it’s sometimes referred to. It’s important to note that what the sensors communicate with either the app or the reader device are not “fully cooked” blood sugar readings, but rather a set of different sensors reading, and that the app and reader will then apply some formulas to provide an equivalent reading to a fingerstick.

Much more interesting to me, in the announcement of the new curve, is that they also suggest users to update the firmware of reader devices to make use of the new fine-tuned algorithm. This is interesting because it makes the FreeStyle Libre the first glucometer with an upgradeable firmware. I have not actually run the update myself, yet. It needs to be done just before changing the sensor, as the reader will forget about its last sensor at that point, and I’m a bit worried that it might not work with UAE-bought sensors anymore after that. So I’m instead waiting to finish the supply of those sensors, and maybe get another one later to test after the update.

I also want to try to get a usbmon trace of the whole procedure for the firmware update. I’m not sure when Abbott will ever publish another update for the reader, but at least starting collecting the protocol would be interesting. Once I do that, you can expect another blog post on the topic.

And as a final note, glucomterutils is being updated as I type this to support reading and setting patient names. While I would not suggest people to use that field for their own personal glucometer, I thought it would be nice to provide the building block for more doctor-focused apps to be built out of it. As a reminder, the code is released under the MIT license, because using it to build something else is a primary focus of it — we need better tooling for glucometers, and not just in the Free Software world, but in the world in general!

Dexcom G6: new phone and new sensor

In the previous posts on the Dexcom G6, I’ve talked about the setup flow and the review after a week, before the first sensor expired. This was intentional because I wanted to talk about the sensor replacement flow separately. Turns out this post will also have a second topic to it, which came by by chance: how do you reconfigure the app when you change phone or, like it happened to me this time, when you are forced to do a factory reset.

I won’t go into the details of why I had to do a factory reset. I’ll just say that the previous point about email and identities was involved.

So what happens when the Dexcom is installed on a new phone, or when you have to reinstall this? The first thing it will ask you is to login again, which is the easy part. After that, though, it will ask you to scan the sensor code. Which made no sense to me! I said “No Code”, and then it asked me to scan the transmitter code. At which point it managed to pair with the transmitter, and it showed me the blood sugar readings for the past three hours. I can assume this is the amount of caching the transmitter can do. If the data is at all uploaded to Dexcom system, it is not shown back to the user beside those three hours.

It’s important to note here that unless you are at home (and you kept the box the transmitter came with), or you have written down the transmitter serial number somewhere, you won’t be able to reconnect. You need the transmitter serial number for the two of them to pair. To compare again this to the LibreLink app, that one only requires you to log in with your account, and the current sensor can just be scanned normally. Calibration info is kept online and transmitted back as needed.

A few hours later, the first sensor (not the transmitter) finally expired and I prepared myself to set the new one up. The first thing you see when you open the app after the sensor expired is a “Start new Sensor” button. If you click that, you are asked for the code of the sensor, with a drawing of the applicator that has the code printed on the cover of the glue pad. If you type in the code, the app will think that you already set up the whole sensor and it’s ready to start, and will initiate the countdown of the warm up. At no point the app direct you to apply the new sensor. It gives you the impression you need to first scan the code and then apply the sensor, which is wrong!

Luckily despite this mistake, I was able to tell the app to stop the sensor by telling it I’d be replacing transmitter. And then re-enrolling the already present transmitter. This is all completely messed up in the flow, particularly because when you do the transmitter re-enrolment, the steps are in the correct order: scan then tell you to put the transmitter in, and then scan the transmitter serial number (again, remember to keep the box). It even optionally shows you the explanation video again — once again, totally unlike just starting a new sensor.

To say that this is badly thought out is an understatement to me. I’ll compare this again with the LibreLink app that, once the sensor terminates, actually shows you the steps to put on a new sensor (you can ignore them and go straight to scanning the sensor if you know what you’re doing).

On the more practical side, the skin adhesive that I talked about last week actually seems to work fine to keep the sensor in place better, and it makes dealing with my hairy belly simpler by bunching up the hair and keep it attached to the skin, rather than having it act as a fur against the sensor’s glue. It would probably be quite simpler to put on if they provided a simpler guide on the size of the sensor though: showing it on the video is not particularly nice.

The sensor still needed calibration: the readings were off by more than 20% at first, although they are now back on track. This either means the calibration is off in general, or somehow there’s a significant variation between the value read by the Dexcom sensor and the actual blood sugar. I don’t have enough of a medical background to be able to tell this, so I leave that to the professionals.

At this point, my impression of the Dexcom G6 system is that it’s a fairly decent technical implementation of the hardware, but a complete mess on the software and human side. The former, I’m told can be obviated by using a third-party app (by the folks who are not waiting), which I will eventually try at this point for the sake of reviewing it. The latter, probably would require them to pay more attention to their competitors.

Abbott seems to have the upper-hand with the user-friendly apps and reports, even though there are bugs and their updates are very far in between. They also don’t do alerts, and despite a few third-party “adapters” to transform the Libre “flash” system into a more proper CGM, I don’t think there will be much in the form of reliable alerts until Abbott changes direction.

glucometerutils news: many more meters, easier usage and Windows support

You probably have noticed by now that I write about glucometers quite a bit, not only reviewing them as an user, but also reverse engineering to figure out their protocols. This all started four years ago when I needed to send my glucometer readings to my doctor and I ended up having to write my own tool.

That tool started almost as a joke, particularly given I wrote it in Python, which at the time I was not an expert in at all (I have since learnt a lot more about it, and at work I got to be more of an expert than I’d ever expected to be). But I always known that it would be for the most part just a proof of concept. Not only exporting CSV is mostly useless, but the most important part in diabetes management software is the analysis and I don’t have any clue how to do analysis.

At first I thought I could reuse some of the implementation to expand Xavier’s OpenGlucose but it turned out that it’s not really easy for those meters that are using serial adapters or other USB devices beside the HID ones that he implemented already. Of course this does mean it would probably work fine for things like the FreeStyle Libre which I appear to have written the only Linux software to download from, but even in that case, things are more complicated.

Indeed, as I have noted here and there previously, we need a better format to export glucometer data, and in particular the data from continuous or mixed meters like the Libre. My current out format for it only includes the raw glucose readings from the meter that are not marked as errors; it does provide an unstructured text comment that tells you whether the reading is coming from the background sensor, an explicit scan or a blood sample, but it does not provide all the level of details of the original readings. And it does not expose ketone readings at all, despite the fact that most of the FreeStyle-line devices support them and I even documented how to get them. But this is a topic for a different post, I think.

On the other hand, over the past four years, the number of meters increased significantly, and I even have a few more that I only have partially reversed and not published yet. Currently there are 9 drivers, covering over a dozen meters (some meters share the same driver, either because they are just rebranded versions or simply because they share the same protocol). One is for the InsuLinx, which also loses a bunch of details, and is based off Xavier’s own reverse engineering — I did that mostly because all the modern FreeStyle devices appear to share the same basic protocol, and so writing new drivers for them is actually fairly trivial.

This would make the project an interesting base if someone feels like writing a proper UI for it. If I ever tried to look into that, I may end up just starting an HTTP server and provide everything over HMTL for the browser to render. After all that’s actually how OpenGlucose is doing things, except there is no server, and the browser is embedded. Alternatively one could just write an HTML report file out, the same way Accu-Chek Mobile does using data URLs and JavaScript bundles.

One of the most important usability changes I have added recently, though, is allowing the user not to specify the device path. When I started writing the tool, I started by looking at serial adapter based devices, which usually come with their own cable, and you just access it. The next driver was for the LBA-over-SCSI used int he OneTouch Verio, which I could have auto-detected but didn’t, and the following ones, mostly based off HID, I just expected to be given an hidraw path.

But all of this is difficult, and indeed I had more than a few people asking me which device are they meant to use, so over the past few months I adapter the drivers to try auto-detecting the devices. For the serial port based meters, the auto-detection targets the original manufacturer’s cable, so if you have a custom one, you should still pass them a path. For HID based devices, you also need the Python hidapi library because I couldn’t bother writing my own HID bus parsing on Linux…

… and the library also brings another important feature: it works on non-Linux operating systems. Indeed I now have not one but two confirmed users that managed to use the tool on Windows, for two separate FreeStyle devices (at the time of writing, the only ones implementing HID-based protocols, although I have another one in the pipeline.

Supposedly, all of this should work fine on macOS (I almost called it OS X), though the one person who contacted me trying to have it working there has been having trouble with it — I think the problem has something to do with the Python version available (I’m targetting Python 3 because I had a very hard time to do the right processing with Python 2.7). So if you want to give it a try feel free.

And yes, I’m very happy to receive pull request, so if you want to implement that HTML output I talked above about, you’re awesome and I’m looking forward to your pull request. I’m afraid I won’t be much help with the visualisation though.

Glucometer Review: Contour Next One

In my current quest for documenting glucometer protocols and implementing tooling to download data I ended up ordering myself a Contour Next One glucometer, currently marketed by Ascensia Diabetes Care, but originally developed by Bayer (to the point that devices and manuals still mostly refer to Bayer).

The Contour Next One is marketed as a smart glucometer that can connect to an app on a smartphone, as it supports Bluetooth Low Energy. I have not tried that yet because I already have an app I care about on the phone. In addition to that the physical device is very small, but includes a nice, complete and bright display, a three way buttons, a coloured LED for the strip port device, and a beeper.

The size of the device reminds me closely the OneTouch Ultra Mini, which is quite favourable, as every other device I have is significantly bulkier, and for the most part using a different form factor that I don’t particularly enjoy.

The strip port has a coloured LED as I said, and it’ll be white to tell you where to insert the strip, and then turn either green or red depending on the value. You can associate one out of three states for meal information, represented by an apple (why is it always an apple?) crossed out (fasting), full (before meal) or taken two bites of (after meal).

If there is one thing that I can complain about is that the first-time setup is a bit tricky. I have received the meter a couple of months ago, but since I’ve been travelling so much, I have not managed to try it out until earlier this month. When I finally put the strip into the device, and provided blood to it, I found it wanted to confirm date, time and settings… and did not actually give me a result, oops!

On the practicality, the device is really the kind of size I’d like to keep around, if it wasn’t for the fact I switched to the Libre. While it is not all-in-one like the Accu-Chek Mobile, it is small and compact, and looks sleek for a device.

I have installed the Irish app – it seems they have separate app entries for multiple countries, although it does not appear to have country limitations, as I could ask for it to be installed on my Italian SIM device – the first thing it asked me was the country or region, and Ireland was not in the visible list. Turns out the problem is that the list is actually very long and the app’s scrolling is misconfigured, as scrolling up appears to only scroll a third of a row at a time, so scrolling down to Ireland takes quite a while. For United Kingdom I don’t even want to consider the idea. Looks like Ascensia does have some rough edges with testing the first-time setup of their systems.

The setup process is a bit bothersome, if what you want to do is just downloading the data. It tries to convince you to set up an account to back up your data (this appears to be more and more common), and then it goes through give or take the same first-time setup as happens on the meter. In addition to the meter’s own settings, it also allows you to define time bands to divide your meals into breakfast, lunch and dinner, which I liked: instead of just assuming, it asks you to confirm the expected ranges.

There is also a request to configure two phone numbers: the local emergency number, and a personal emergency contact, so that if you have a low-blood-sugar event you can make a call directly. While the idea is interesting on principle, since it already asked me for my region I wonder why it can’t just default to 999. Finding the contact by name in the list is also extremely hard because of the scrolling issue above. I ended up just typing my own name and phone number, as there is never anyone who could actually help me if I have a sugar low, and the request is unskippable.

The app itself appears very simple, showing by default your last reading and a small graph of your recent readings. If you turn your phone or click on the graph, a more detailed (but still rough) graph appears:

The probably most interesting thing about this the app is that if you take a reading on your meter it will be “pushed” to the device, and appear in real-time. It also allows you to set the markings and a number of comments straight from the app, well exceeding the amount of details that the device can set for you, particularly given it’s a three-buttons device.

It reminds me of the iHealth Align but in a much less clumsy way. It also requires significantly less bother with the strips, and there is no validation of when the bottle was open or whether the strips expired, which makes it probably a better choice for those people who only test occasionally.

On more technical sides, the device uses two CR2032 batteries, which while beefier than the iHealth, need to sustain a full BLE connection – which by the way I couldn’t figure out how to turn off at first try – and are at the same time easier to find replacements for (though not as easy as the AAA batteries used by more clunky meters). It has a micro USB connector on the back, behind a rubber seal, and it uses an HID-based protocol to communicate. I’m halfway through reversing and documenting it of course.

Chinese Glucometer Review: Sannuo

As I start this draft I’m in Shanghai (mainland China), for a work trip. I have visited Shanghai before, but this time I have some more random time around, and while I was browsing stores with a colleague also visiting the city, we ended up in a big (three, four stories) pharmacy. We would have left right away if it wasn’t that I noticed a big sign advertising a Countour by Bayer glucometer, and I decided to peek around.

I found indeed a whole floor dedicated to health hardware, including, but clearly not limited to, glucometers. It had a long series of Omron hardware, blood pressure measurements, thermometers, etc. And a few desks of glucometer, some from brands that are established and known in the West, and a few I never heard of.

I looked around for the prices, and the meters are more expensive than in Europe, but about on par with the US, between ¥150 and ¥400. I asked if any of the ones they had that I did not recognize would allow downloading to the computer, and they showed me one for ¥258 (around €35), branded Sannuo and manufactured by Sinocare. I decided to buy it for the sake of figuring out how things differ in China for diabetes.

Before getting to the device itself, a few words of the act of buying one. First of all, as it appears to be common in China, or at least in Shanghai, buying something is a bit of a trip around: you select what you want, they send you to the cashier, you pay, and then you go back to the clerk who you chose the item with. If you’re lucky, you’ll be able to pay with card, and if you’re really lucky, they will accept yours. In this case the store accepted my Tesco Visa, but not my Revolut MasterCard, which means it probably costed me closer to €40, but it’s okay.

After I paid for the device, the clerks assisted me not only by giving me the box of the meter, but configuring it up, particularly date and time. You’d think this would be obvious to do (and it is) but one of the things that kept surprising me in Shanghai is that every time you buy something, the seller will configure it for you, and make sure it works at least to a point, the same was true when I bought a SIM card at the airport. They did not ask me to take blood there and then, but they showed me how to set up the date and time.

Finally, they gave me a box of two bottles of strips, told me there were two bottles in the box, and even warned me to use them one bottle at a time (valid warning for glucometers’ reactive strips). And just to make a point here: only one of the two clerks who assisted me spoke any English, and even she didn’t speak it very well. They still did quite a bit to make me understand and explain how to use it.

Now to go back to the meter itself, the €40 got me a fairly clunky meter, a box of lancets and 50 test strips, which declare themselves having a fairly wide range (from 1.1 mmol/l). In the box with the device came the usual (by now) carrying case, and a lancing device. The lancets appear to be “standard” or at least as close as that word as can possibly be used for lancets and lancing devices.

What became very obvious both on the box of the meter, and on the wall ads of all the other meters, is that China, like the UK and Ireland, use mmol/l measurement for blood sugar. I honestly thought that was just a UK (and Ireland, Australia) thing, but clearly it is much more common. Since I’m writing this before getting back to Europe, I cannot tell whether the meter uses this in the wire protocol or, like all the western meters, uses mg/dL internally.

The meter itself feels clunky and it’s fairly big, just shy of the size of an Accu-Chek Mobile. It uses two AAA batteries, and that has only three buttons: power and up/down arrows. The display is a monochrome LCD, but it also has two LEDs, red and green, to tell you whether you’re in range or not. Oh, and it speaks.

It felt funny when I arrived at the hotel and tried it with a blood sample (it seems consistent with the variation of other meters), and it started announcing… something. I don’t speak Chinese so I have not understood anything, I should probably start Google Translate next time I try it. Part of the reason why this feels funny is because it reminded me of the i-ching calculator from Dirk Gently: The Long Dark Tea-Time of the Soul radio series, which was effectively a calculator that spoke the results out loud. I did not make much of a parallel until this, but it then reminded me of the devices in the taxis I took last year, too.

Unfortunately even though I’m now at home, I have not been able to start on the reverse engineering, because I can’t seem to get the device to work on my laptop. According to Linux, the device is not accepting the assigned address. I should wire it up to the proper logic analyzer for that.

Glucometer Review: Abbott FreeStyle Precision Neo

During my December trip to the United States, I did what I almost always do when I go there: I went to a pharmacy and looked through the current models of glucometers that are for sale there. Part of the reason is that I just got to the point I enjoy a challenge of figuring out what difference in the protocol the various manufacturers put version after version, and part of it is that I think it is a kind of a public service that we provide tools not only for the nice and fancy meters but also for those that most people would end up buying in store. I have one more device that I got during one of my various trips that I have not written about, too, but let’s not go there.

This time around the device I got is an Abbott FreeStyle Precision Neo device. The factors I used to choose, as usual, were price (I didn’t want to spend much, this one was on sale for less than $10), and the ability to download the data over direct USB connection (the device I have noted above requires a custom cradle which I have not managed to acquire yet). In addition, while the device did not come with any strip at all, I (mistakenly) thought it was a US brand for the Optium Neo, which looks very similar and is sold in Europe and Canada. That meter I knew used the same strips that I use for the FreeStyle Libre, which means I wouldn’t have to pay extra for it at all. As I said I was wrong, but it still accepted the same strips, more on that later.

The device itself is fairly nice: at first it may appear to share a similar shape as the Libre, but it really seems to share nothing with it. It’s significantly flatter, although a bit wider. The display is not LCD at all, but rather appears to be e-ink and reminded me of the Motorola FONE. The display is technically a “touchscreen” but rather than having a resistive or capacitive display on the device, it appears to just have switches hidden behind the screen.

Given the minimal size of the device, there is not much space for a battery and charging circuitry, like there is in the Libre, instead the device is powered by a single CR2032 battery which is very nice as they are cheap enough, and easy to carry around, although you’re not meant to leave them in checked-in luggage.

Overall, the device is flatter than my current smartphones, and extremely light, and that gives it a significant advantage over a number of other meters I tried in the past few years. The e-ink display ha very big and easily readable numbers, so it’s ideal for the elderly or those who need to take the test even without their glasses.

Putting aside the physical size factor, the package I bought contained a small case for the meter, a new lancing device, and some lancets. No strips, and I guess that explains the very low price point. I would say that it’s the perfect package for the users of previous generations’ FreeStyle devices that need an upgrade.

As I said at the start, the main reason why I buy these devices is that I want to reverse engineer their protocol, so of course I decided to find the original software from Abbott to download the data out of it. Unfortunately it didn’t quite work the way I was expecting. I expected the device to be a rebranded version of the Optium Neo, but it isn’t. So the software from the Irish Abbott website (Auto-Assist Neo, v1.22) tried connecting to the meter but reported a failure. So did the same software downloaded from the Canadian website (v1.32).

Given that this is a US device, I went to the US website (again, thank you to TunnelBear as Abbott keeps insisting with the GeoIP-locking). The US version does not offer a download of the simple desktop software I was looking for, instead pointing you to the client for their online diabetes management software. What is it with online systems for health data access? I decided not to try that one, particularly as I would be afraid of its interaction with the FreeStyle Libre software. I really should just set up a number of virtual machines, particularly given that the computer I’m using for this appears to be dying.

On the bright side it appears that, even though the software declares the device is not compatible with it, the USB capture shows that all the commands are all being sent and responded to, so I have a clear trace for at least the data download. The protocol is almost identical to the Insulinx that Xavier already reverse engineered in parts, and both seem to match the basic format that Pascal found how to dump from the Libre so it was easy to implement. I’ll write more about that separately.

So what about the strips? Since the device came with no strips, I assumed I would just use the strips I had at home, which were bought for my Libre device and were of the Optimus series, and they worked fine. But when I looked into completing the reverse engineering of the protocol by figuring out which marking is used for the β-ketone readings, the device reported E-2 on the screen. So I looked into it and I found out that the Precision Neo device is meant to be used with Precision series strips. Somehow the Optimus blood glucose strips are compatible (I would guess they are effectively the same strips) while the β-ketone strips are not. So I still don’t have data of how those readings are reported. But this put a final nail in the coffin to the idea that this is the same device as the one sold outside of the USA.

Having this device was very useful to understand and document better the shared HID protocol that is used by Abbott FreeStyle devices, which made it very easy to implement the basic info and data dump from the Libre, as well as an untested InsuLinux driver, in my glucometerutils project. So I would say it was $10 spent well.

Glucometer Review: iHealth Align

You’d expect that with me being pretty happy with the FreeStyle Libre, new glucometer reviews would be unlikely. On the other hand, as you probably noticed as well, I like reverse engineering devices, and I have some opinions about accessing your own medical data (which I should write about at some point), so when I drop by the United States I check if they have any new glucometer being sold for cheap that I might enjoy reversing.

The iHealth Align is a bit special in this regard. Usually I just buy what’s on offer at Walgreens or CVS (sometimes thanks to Rebate just paying taxes for it), but this time I ordered it straight from Amazon. And the reason whas interesting: I found it with a “heavy” discount (the page I ordered it from is gone, but it was something along the lines of 30%), and I guess this is because the device is mostly advertised to be for iOS, and since it uses the TRRS (headphone) jack, it will not work on the more recent devices. On the other hand, it still works fine on Android.

Originally I wanted to wait to go back home to look into it, as I also bought some TRRS breakout connectors to be able to run my newly-bought Saleae Logic Pro 16 onto it, but a funny accident got me to open it while on my trip, in Pittsburgh, and try it out already.

As for the funny accident, I am not entirely sure how that happened but after dinner with Rick, after I went back to my room, my FreeStyle Libre reported a fall from 10 mmol/L (138mg/dL) to LO within two readings (and missing a few data points after that), and then reported me as being having a low blood sugar event. I was not hypoglycemic at that point, as I can feel it, so I double checked with the new meter, that showed me just fine in the 7 mmol/L range, which meant I was good. After an hour or two the self-calibration of the sensor went back to normal and it aligned again with the other meter.

My doctor suggests that the -15℃ weather outside would affect the chemical reaction, and make even blood testing unreliable. On the other hand, I had a second happening of the same failure mode after a shower last night, it might be a defect of this sensor.

I’ll start with a first impression before actually going onto the details of what I found in deeper inspection of the device, mostly out of need since I’ve started the post while travelling through airports.

The device is very small and it’s an active device: it has a button cell inside, and it comes with replacement ones, likely because they are not very common ones: CR1620 — not to be confused with CR2016! The package I got had no strips, but came with “sanitary phone covers” — I think they meant it to be for medical professionals rather than self-use, but that might explain the cheaper price.

To use it with your phone, you obviously have to install the iGluco application from iHealth, and that application needs obviously permission to listen to your microphone to use the audio jack. What surprised me was that just plugging the device in opens the application. I was scared that the application was constantly listening to the microphone waiting for a magic handshake, but a friend suggested that they may just be registering an intent for the jack-sensing, and playing back a handshake when they receive that. Plugging in a pair of headphones doesn’t do anything, and I have yet to fire up the analyser to figure out if something else may be going on.

Before you can take a reading you have to sign up for the iHealth remote service, and provide it with a valid email address. It also asks a couple of basic questions meant to be useful to track your health in general, found those a tad creepy too but I understand why they are there. It’s not surprising, given that the LibreLink does something very similar (without the questions though). It does give me a bigger incentive to try to figure out the device, although I’m also concerned it might be too locked in for the vendor. On the bright side, I confirmed all the communication with the remote service happens over HTTPS; what I did not confirm is whether the app is validating certificates correctly so don’t trust my word for it.

There is a blast from the past when I tried using it the first time: the strips are coded. I have not seen a device using coded strips in years by now. The OneTouch Ultra strips have been coded in the past, but over the past four years or so, they only sell code 25 — and they stopped selling them altogether in the UK and Ireland. To code the strips in, the strip bottles come with a big QR code on the top. This QR code embeds the date of issue and expiration of the strips, and appears to provide a unique identifier on the bottle, as the application will keep track of a shorter expiration time for the bottle when you start using it, which means it’s hard (or impossible) to use two bottles (like I used to do, one at home and one at the office).

The app includes some interesting metadata with the reading, but that’s nothing new. It’s definitely easier to write notes or select pre- or post-meal readings than with a normal glucometer, but again, this is not really exciting. It does, though, allow you to select in which measurement unit you want your readings in, whether mg/dL or mmol/L. This marks a first in my experience; as far as I knew, it is against regulation in most countries to let the user switch units, as the risk of a patient to misconfigure the glucometer makes it a deadly risk. But who am I to complain? I have written my tools because I needed to dump an Italian meter in a way that my Irish doctor liked.

As for the testing strips, they are huge compared to anything else I’ve used, although they don’t require so much blood as they may look like doing. They are a bit difficult to fit properly into the meter at first, requiring a bit more force than I’m used to either, and sometimes the app gets stuck if you don’t fit them in properly. All in all this makes it a bit of a shoddy meter on the practical level in my opinion.

From what I can tell, iHealth has a newer model of their meter that uses Bluetooth instead of the audio jack, and is thus compatible with the new iPhone models, and that may be more user friendly with regard to the app freezing, but I would expect the issue with the force needed to fit the strip to still exist.

I have not yet started looking into the communication between device and phone yet, although I have all the pieces I need. This weekend I think I’ll be soldering up a couple of things I need and then post pictures of the resulting breadboards, I’m sure it’s going to be a funny one.