Tag: Diabetes

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.

Dexcom G6: week 1 review

Content warning, of sorts. I’m going to talk about my experience with the continuous glucose monitor I’m trying out. This will include some PG-rated body part descriptions, so if that makes you awkward to read, consider skipping this post.

It has now been a week since I started testing out the Dexcom G6 CGM. And I have a number of opinions, some of which echo what I heard from another friend using the Dexcom before, and some that confirmed the suggestion of another friend a few years back. So let me share some of it.

The first thing we should talk about is the sensor, positioning and stickiness. As I said in the previous post, their provided options for the sensor positioning are not particularly friendly. I ended up inserting it on my left side, just below the belly button, away from where I usually would inject insulin. It did not hurt at all, and it’s not particularly in the way.

Unfortunately, I’m fairly hairy and that means that the sensor has trouble sticking by itself. And because of that, it becomes a problem when taking showers, as the top side of the adhesive strip tends to detach, and I had to stick it with bandage tape. This is not a particular problem with the Libre, because my upper back arm is much less hairy and even though it can hurt a bit to take it off, it does not hurt that much.

As of today, the sensor is still in, seventh day out of ten, although it feels very precarious right now. During one of the many videos provided during the original setup, they suggest that, to makes it more stable to stick, I should be using skin adhesive. I had no idea what that was, and it was only illustrated as a drawing of a bottle. I asked my local pharmacy, and they were just as confused. Looking up on their supplier’s catalogue, they found something they could special order, and which I picked up today. It turns out to be a German skin adhesive for £15, which is designed for urinary sheaths. Be careful if you want to open the page, it has some very graphical imagery. As far as I can tell, it should be safe to use for this use case, but you would expect that Dexcom would at least provide some better adhesive themselves, or at least a sample in their introductory kit.

I will also have to point out that the bulge caused by the sensor is significantly more noticeable than the Libre, particularly if you have tight-fitting shirts, like I often do in the summer. Glad I listened to the colleague who thought it would look strange on me, back a few years ago.

Let’s now talk about the app, which I already said before was a mess to find on the store. The app itself looks bare bones — not just for the choice of few, light colours (compare to the vivid colours of LibreLink), but also due to the lack of content altogether: you get a dial that is meant to show you the current reading, as well as the direction of the reading between “up fast” and “down fast”, then a yellow-grey-red graph of the last three hours. You can rotate the phone (or expect the app to read it as a rotation despite you keeping your phone upright) to see the last 24 hours. I have not found any way to show you anything but that.

The app does have support for “sharing/following”, and it does ask you if you want to consent to data sharing. Supposedly there’s an online diabetes management site — but I have not found any link of where that is from the app. I’ll probably look that up for another post.

You’ll probably be wondering why I’m not including screenshots like I did when I reviewed the Counter Next One. The answer is that the app prevents screenshots, which means you either share your data via their own apps, or you don’t at all. Or you end up with taking a picture of one phone with another one, which I could have, but I seriously couldn’t be bothered.

The Settings menu is the only interaction you can actually spend time on, with the app. It’s an extremely rudimentary page with a list of items name-value pairs effectively. Nothing tells you which rows are clickable and which ones aren’t. There’s a second page for Alerts, and then a few more Alerts have their own settings page.

Before I move onto talking (ranting?) about alerts, let me take a moment to talk about the sensors’ lifetime display. The LibreLink app has one of the easiest-to-the-eyes implementation of the lifetime countdown. It shows as a progress bar of days once you start the sensor, and once you reach the last day, it switches to show you the progress bar for the hours. This is very well implemented and deals well with both timezone changes (I still travel quite a bit) and daylight savings time. The Dexcom G6 app shows you the time the sensor will end with no indication of which timezone is taken in.

The main feature of a CGM like this, that pushes data, rather than being polled like the Libre, is the ability to warn you of conditions that would be dangerous, like highs and lows. This is very useful particularly if you have a history of lows and you got desensitised to them. That’s not usually my problem, but I have had a few times where I got surprised by a low because I was too focused on a task, so I was actually hoping it would help me. But it might not quite be there.

First of all, you only get three thresholds: Urgent Low, Low and High. The first one cannot be changed at all:

The Urgent Low Alarm notification level and repeat setting cannot be changed or turned off. Only the sound setting can be changed.

The settings are locked at 3.1mmol/L and 30 minutes repeat, which would be fairly acceptable. Except it’s more like 10 minutes instead of 30, which is extremely annoying when you actually do get an urgent low, and you’re trying to deal with it. Particularly in the middle of the night. My best guess of why the repeat is not working is that any reading that goes up or stays stable resets the counter of warning, so a (3.1, 3.2, 3.1) timeseries would cause two alerts 10 minutes apart.

The Low/High thresholds are used both for the graph and for the alert. If you can’t see anything wrong with this, you never had a doctor tell you to stay a little higher rather than a little lower on your blood glucose. I know, though, I’m not alone with this. In my “usual” configuration, I would consider anything below 5 as “out of range”, because I shouldn’t linger at that value too long. But I don’t want a “low” alert at that value, I would rather have an alert if I stayed at that value for over 20 minutes.

I ended up disabling the High alert, because it was too noisy even with my usual value of 12 ­— particularly for the same reason noted above about the timeseries problem: even when I take some fast insulin to bring the value down, there will be another alert in ten minutes because the value is volatile enough. It might sounds perfectly reasonable to anyone who has not been working with monitoring and alerting for years, but to me, that sounds like a pretty bad monitoring system.

You can tweak the alerts a little bit for overnight alerts, but you can’t turn them off entirely. Urgent Low will stay on, and that has woken me up a few nights already. Turns out I have had multiple cases of overnight mild lows (around 3.2 mmol/L), that recover themselves without me waking up. Is this good? Bad? I’m not entirely sure. I remember they used to be more pronounced years ago, and that’s why my doctor suggested me to run a little higher. The problem with those lows, is that if you try too hard to recover from them quickly, you end up with scary highs (20mmol/L and more!) in the morning. And since there’s no “I know, I just got food”, or “I know, I just got insulin” to shut up the alerts for an hour or half, you end up very frustrated at the end of the day.

There is a setting that turns on the feature called “Quick Glance”, which is a persistent notification showing you the current glucose level, and one (or two) arrows determining the trend. It also comes with a Dexcom icon, maybe out of necessity (Android apps are not my speciality), which is fairly confusing because the Dexcom logo is the same as the dial that shows the trend in the app, even though in this notification it does not move. And, most importantly, it stays green as the logo even when the reading is out of range. This is extremely annoying, as the “quick glance” to the colour, while you’re half asleep, would give you the totally wrong impression. On the bright side, the notification also has an expanded view that shows you the same 3 hours graph as the app itself would, so you rarely if ever see the app.

Finally, speaking of the app, let me bring up the fact that it appears to use an outrageous amount of memory. Since I started using the Dexcom, I end restarting Pokémon Go every time I switch between it and WhatsApp and Viber, on a Samsung S8 phone that should have enough RAM to run all of this in the background. This is fairly annoying, although not a deal breaker for me. But I wouldn’t be surprised if someone using a lower-end phone would have a problem trying to use this, and would have to pay the extra £290 (excluding VAT) for the receiver (by comparison, the Libre reader, which doubles as a standard glucometer – including support for β-ketone sticks – costs £58 including VAT).

Since I just had to look up the price of the reader, I also have paid a little more attention to the brochure they sent me when I signed up to be contacted. One of the thing it says is:

Customize alerts to the way you live your life (day vs night, week vs weekend).

The “customization” is a single schedule option, which I set up for night, as otherwise I would rarely be able to sleep without it waking me up every other night. That means you definitely cannot customize them the way you live your life. For instance, there’s nothing to help you use this meter while going to the movies: there’s no way to silence the alerts for any amount of time (some alerts are explicitly written so that Android’s Do Not Disturb do not block them!), there’s no silent-warning option, which would have been awesome together with the watch support (feel the buzz, check the watch, see a low—drink the soda, see a high—get the insulin/tablet).

A final word I will spend on the calibration. I was aware of the Dexcom at its previous generation (G5) required calibration during setup. As noted last week, this version (G6) does not require that. On the other hand, you can type in a calibration value, which I ended up doing for this particular sensor, as I was worried about the >20mmol/L readings it was showing me. Turns out they were not completely outlandish, but they were over 20% off. A fingerstick later, and a bit of calibration, seem to be enough for it to report a more in-line value.

Will I stick to the Dexcom G6 over the Libre? I seriously doubt so by now. It does not appear to match my usage patterns, it seems to be built for a different target audience, and it lacks any of the useful information and graphs that the LibreLink app provides. It also is more expensive and less nice to wear. Expect at least one more rant if I can figure out how to access my own readings on their webapp.

Testing the Dexcom G6 CGM: Setup

I have written many times before how I have been using the FreeStyle Libre “flash” glucose monitor, and have been vastly happy with it. Unfortunately in the last year or so, Abbott has had trouble with manufacturing capacity for the sensors, and it’s becoming annoying to procure them. Once already they delayed my order to the point that I spent a week going back to finger-pricking meters, and it looked like I might have to repeat that when, earlier in January, they notified that my order would be delayed.

This time, I decided to at least look into the alternatives — and as you can guess from the title, I have ordered a Dexcom G6 system, which is an actual continuous monitor, rather than a flash system like the Libre. For those who have not looked into this before (or who, lucky them, don’t suffer from diabetes and thus don’t spend time looking like this), the main difference between these two is that the Libre needs to be scanned regularly, while the G6 sends the data continuously from the transmitter to a receiver of some kind.

I say “of some kind” because, like the Libre, and unlike the generation I looked at before, the G6 can be connected to a compatible smartphone instead of a dedicated receiver. Indeed, the receiver is a costly optional here, considering that already the starter kit is £159 (plus VAT, which I’m exempt from because I’m diabetic).

Speaking of costs, Dexcom takes a different approach to ordering than the Libre: it’s overly expensive if you “pay as you go”, the way Abbott does it. Instead if you don’t want to be charged through the nose, you need to accept a one year contract, for £159/month. It’s an okay price, barely more expensive than the equivalent Abbott sensors price, but it’s definitely a bit more “scary” as an option. In particular if you don’t feel sure about the comfort of the sensor, for instance.

I’m typing this post as I opened the boxes that arrived to me with the sensor, transmitter and instructions. And the first thing I will complain about is that the instructions tell me to “Set Up App”, and give me the name of the app and its icon, but provides no QR code or short link to it. So I looked at their own FAQ, they only provide the name of the app:

The Dexcom G6 app has to be downloaded and is different from the Dexcom G5 Mobile app. (Please note: The G6 system will not work with the G5 Mobile app.) It is available for free from the Apple App or Google Play stores. The app is named “Dexcom G6”

Once I actually find the app, that is reported as being developed by Dexcom, I actually find Dexcom G6 mmol/L DXCM1. What on Earth, folks? Yes of course the mmol/l is there because it’s the UK edition (the Italian edition would be mg/dl), and DXCM1 is probably… something. But this is one of the worst way to dealing with region-restricted apps.

Second problem: the login flow uses an in-app browser, as it’s clear from the cookies popup (that is annoying on their normal website too). Worse, it does not work with 1Password auto-fill! Luckily they don’t disable paste at least.

After logging in, the app forces you to watch a series of introductory videos, otherwise you don’t get to continue the setup at all. I would hope that this is only a requirement for the first time you use the app, but I somewhat don’t expect it to be as good. The videos are a bit repetitive, but I suppose they are designed to help people who are not used to this type of technology. I think it’s of note that some of the videos are vertical, while other are horizontal, forcing you to move your phone quite a few times.

I find it ironic that the videos suggests you to keep using a fingerstick meter to take treatment decisions. The Libre reader device doubles as a fingerstick meter, while Dexcom does not appear to even market one to begin with.

I have to say I’m not particularly impressed by the process, let alone the opportunities. The video effectively tells you you shouldn’t be doing anything at all with your body, as you need to place it definitely on your belly, but away from injection sites, from where you could have a seatbelt, or from where you may roll over while asleep. But I’ll go with it for now. Also, unlike the Libre, the sensors don’t come with the usual alcohol wipes, despite them suggesting you to use it and have it ready.

As I type this, I just finished the (mostly painless, in the sense of physical pain) process to install the sensor and transmitter. The app is now supposedly connecting with the (BLE) transmitter. The screen tells me:

Keep smart device within 6 meters of transmitter. Pairing may take up to 30 minutes.

It took a good five minutes to pair. And only after it paired, the sensor can be started, which takes two hours (compare to the 1 hour of the Libre). Funnily enough, Android SmartLock asked if I wanted to use to keep my phone unlocked, too.

Before I end this first post, I should mention that there is also a WearOS companion app — which my smartwatch asked if I wanted to install after I installed the phone app. I would love to say that this is great, but it’s implemented as a watch face! Which makes it very annoying if you actually like your watch face and would rather just have an app that allowed you to check your blood sugar without taking out your phone during a meeting, or a date.

Anyhoo, I’ll post more about my experience as I get further into using this. The starter kit is a 30 days kit, so I’ll probably be blogging more during February while this is in, and then finally decide what to do later in the year. I now have supplies for the Libre for over three months, so if I switch, that’ll probably happen some time in June.

FreeStyle Libre and first responders

Over on Twitter, a friend asked me a question related to the FreeStyle Libre, since he knew that I’m an user. I provided some “soundbite-shaped” answers on the thread but since I got a few more confused replies afterwards, I thought I would try to make the answer a bit more complete:

Let’s start with a long list of caveats here: I’m not a doctor, I’m not a paramedic, I do not work for or with Abbott, and I don’t speak for my employer. All the opinions that follow are substantiated only by my personal experiences and expertise, which is to say, I’m an user of the Libre system and I happen to be a former firmware engineer (in non-medical fields) and have a hobby of reverse engineering glucometer communication protocols. I will also point out that I have explicitly not looked deeply into the NFC part of the communication protocol, because (as I’ll explain in a minute), that crosses the line of what I feel comfortable releasing to the public.

Let me start with the immediate question that Ciarán asks in the tweet. No, the communication between the sensor and the reader device (or phone app) is not authenticated or protected by a challenge/response pair, as far as I know. From what I’ve been told (yes I’m talking through hearsay here, but give me a moment), the sensor will provide the response no matter who is asking. But the problem is what that response represent.

Unlike your average test strip based glucometer, the sensor does not record actual blood glucose numbers. Instead it reports a timeseries of raw values from different sensors. Pierre Vandevenne looked at the full response and shed some light onto the various other values provided by the sensor.

How that data is interpreted by the reader (or app) depends on its calibration, which happens in the first 60 minutes of operation of the sensor. Because of this, the official tools (reader and app) only allows you to scan a sensor with the tool that started it — special concessions are made for the app: a sensor started by a reader device can be also “tied” to the app, as long as you scan it with the app during the first hour of operation. It does not work the other way, so if you initialize with the app, you can’t use the reader.

While I cannot be certain that the reader/app doesn’t provide data to the sensor to allow you to do this kind of dual-initialization, my guess is that they don’t: the launch of the app was not tied with any change to the sensors, nor with warnings that only sensors coming from a certain lot and later models would work. Also, the app is “aware” of sensors primed by the reader, but not vice-versa, which suggests the reader’s firmware just wouldn’t allow you to scan an already primed sensor.

Here is one tidbit of information I’ll go back to later on. To use the app, you need to sign up for an account, and all the data from the sensor is uploaded to FreeStyle’s servers. The calibration data appears to be among the information shared on the account, which allows you to move the app you use to a new phone without waiting to replace the sensor. This is very important, because you don’t want to throw away your sensor if you break your phone.

The calibration data is then used together with non-disclosed algorithms (also called “curves” in various blogs) to produce the blood glucose equivalent value shown to the user. One important note here is that the reader and the app do not always agree on the value. While I cannot tell for sure what’s going on, my guess is that, as the reader’s firmware is not modifiable, the app contains newer version of the algorithms, and maybe a newer reader device would agree with the app. As I have decided not to focus on reversing the firmware of the reader, I have no answer there.

Can you get answers from the sensor without the calibration data? As I’m not sure what that data is, I can’t give a definite answer, but I will note that there are a number of unofficial apps out there that purport of doing exactly that. These are the same apps that I have, personally, a big problem with, as they provide zero guarantee that their results are at all precise or consistent, and scare the crap out of me, if you plan on making your life and health depend on them. Would the paramedics be able to use one of those apps to provide vague readings off a sensor? Possibly. But let me continue.

The original tweet by Eoghan asks Abbott if it would be possible for paramedics to have a special app to be able to read the sensor. And here is where things get complicated. Because yes, Abbott could provide such an app, as long as the sensor was initialized or calibration-scanned by the app within the calibration hour: their servers have the calibration data, which is needed to move the app between phones without losing data and without waiting for a new sensor.

But even admitting that there is no technical showstopper to such an app, there are many more ethical and legal concerns about it. There’s no way that the calibration data, and even the immediate value, wouldn’t be considered Sensitive Personal Data. This means for Abbott to be able to share it with paramedics, they would have to have a sharing agreement in place, with all the requirements that the GDPR impose them (for good reason).

Adding to this discussion, there’s the question of whether it would actually be valuable to paramedics to have this kind of information. Since I have zero training in the field, I can’t answer for sure, but I would be cautious about trusting the reading of the sensor, particularly if paramedics had to be involved.

The first warning comes from Abbott themselves, that recommend using blood-based test strips to confirm blood sugar readings during rapid glucose changes (in both directions). Since I’m neither trained in chemistry nor medicine, I don’t know why that is the case, but I have read tidbits that it has to do with the fact that the sensor reads values from interstitial fluid, rather than plasma, and the algorithms are meant to correlate the two values. Interstitial fluid measurements can lag behind the plasma ones and thus while the extrapolation can be correct for a smooth change, it might be off (very much so) when they change suddenly.

And as a personal tale, I have experienced the Libre not reporting any data, and then reporting very off values, after spending a couple of hours in very cold environment (in Pittsburgh, at -14°C). Again, see Vandevenne’s blog for what’s going on there with temperatures and thermal compensation.

All in all, I think that I would trust better a single fingerprick to get a normal test-strip result, both because it works universally, whether you do have a sensor or not, and because its limitations are much better understood both by their users and the professionals. And they don’t need to have so many ethical and legal implications to use.

Diabetes Software: the importance of documented protocols

You may remember that just last week I was excited to announce that I had more work planned and lined up for my glucometer utilities, one of which was supporting OneTouch Verio IQ which is a slightly older meter that is still sold and in use in many countries, but for which no protocol is released.

In the issue I linked above you can find an interesting problem: LifeScan discontinued their Diabetes Management Software, and removed it from their website. Indeed instead they suggest you get one of their Bluetooth meters and to use that with their software. While in general the idea of upgrading a meter is sane, the fact that they decided to discontinue the old software without providing protocols is at the very least annoying.

This shows the importance of having open source tools that can be kept alive as long as needed, because there will be people out there that still rely on their OneTouch Verio IQ, or even on the OneTouch Ultra Easy, which was served by the same software, and is still being sold in the US. Luckily at least they at least used to publish the Ultra Easy protocol specs and they are still available on the Internet at large if you search for them (and I do have a copy, and I can rephrase that into a protocol specification if I find that’s needed).

On the bright side, the Tidepool project (of which I wrote before) has a driver for the Verio IQ. It’s not a particularly good driver, as I found out (I’ll get to that later), but it’s a starting point. It made me notice that the protocol was almost an in-between of the Ultra Easy and the Verio 2015, which I already reverse engineered before.

Of course I also managed to find a copy of the LifeScan software on a mostly shady website and a copy of the “cable drivers” package from the Middle East and Africa website of LifeScan, which still has the website design from five years ago. This is good because the latter package is the one that installs kernel drivers on Windows, while the former only contains userland software, which I can trust a little more.

Comparing the USB trace I got from the software with the commands implemented in the TidePool driver showed me a few interesting bits of information. The first being the first byte of commands on the Verio devices is not actually fixed, but can be chosen between a few, as the Windows software and the TidePool driver used different bytes (and with this I managed to simplify one corner case in the Verio 2015!). The second is that the TidePool driver does not extract all the information it should! In particular the device allows before/after meal marking, but they discard the byte before getting to it. Of course they don’t seem to expose that data even from the Ultra 2 driver so it may be intentional.

A bit more concerning is that they don’t verify that the command returned a success status, but rather discard the first two bytes every time. Thankfully it’s very easy for me to check that.

On the other hand, reading through the TidePool driver (which I have to assume was developed with access to the LifeScan specifications, under NDA) I could identify two flaws in my own code. The first was not realizing the packet format between the UltraEasy and the Verio 2015 was not subtly different as I thought, but it was almost identical, except the link-control byte in both Verio models is not used, and is kept to 0. The second was that I’m not currently correctly dropping out control solutions from the readings of the Verio 2015! I should find a way to get a hold of the control solution for my models in the pharmacy and make sure I get this tested out.

Oh yeah, and the TidePool driver does not do anything to get or set date and time; thankfully the commands were literally the same as in the Verio 2015, so that part was an actual copy-paste of code. I should probably tidy up a bit, but now I would have a two-tier protocol system: the base packet structure is shared between the UltraEasy, Verio IQ and Verio 2015. Some of the commands are shared between UltraEasy and Verio IQ, more of them are shared between the Verio IQ and the Verio 2015.

You can see now why I’ve been disheartened to hear that the development of drivers, even for open source software, is done through closed protocol specifications that cannot be published (or the drivers thoroughly commented). Since TidePool is not actually using all of the information, there is no way to tell what certain bytes of the responses represent. And unless I get access to all the possible variants of the information, I can’t tell how some bytes that to me look like constant should represent. Indeed since the Verio 2015 does not have meal information, I assumed that the values were 32-bit until I got a report of invalid data on another model which shares the same protocol and driver. This is why I am tempted to build “virtual” fakes of these devices with Facedencer to feed variants of the data to the original software and see how it’s represented there.

On the bright side I feel proud of myself (maybe a little too much) for having spent the time to rewrite those two drivers with Construct while at 34C3 and afterwards. If I hadn’t refactored the code before looking at the Verio IQ, I wouldn’t have noticed the similarities so clearly and likely wouldn’t have come to the conclusion it’s a shared similar protocol. And no way I could have copy-pasted between the drivers so easily as I did.

Glucometerutils News: Continuous Integration, Dependencies, and Better Code

You may remember glucometerutils, my project of an open source Python tool to download glucometer data from meters that do not provide Linux support (as in, any of them).

While the tool started a few years ago, out of my personal need, this year there has been a bigger push than before, with more contributors trying the tool out, finding problem, fixing bugs. From my part, I managed to have a few fits of productivity on the tool, particularly this past week at 34C3, when I decided it was due time to start making the package shine a bit more.

So let’s see what are the more recent developments for the tool.

First of all, I decided to bring up the Python version requirement to Python 3.4 (previously, it was Python 3.2). The reason for this is that it gives access to the mock module for testing, and the enum module to write actual semantically-defined constants. While both of these could be provided as dependencies to support the older versions, I can’t think of any good reason not to upgrade from 3.2 to 3.4, and thus no need to support those versions. I mean, even Debian Stable has Python 3.5.

And while talking about Python versions, Hector pointed me at construct, which looked right away like an awesome library for dealing with binary data structures. It turned out to be a bit more rough around the edges than I’ve expected from the docs, particularly because the docs do not contain enough information to actually use it with proper dynamic objects, but it does make a huge difference compared to dealing with bytestring manually. I have started already while in Leipzig to use it to parse the basic frames of the FreeStyle protocol, and then proceeded to rewrite the other binary-based protocols, between the airports and home.

This may sound like a minor detail, but I actually found this made a huge difference, as the library already provides proper support for validating expected constants, as well as dealing with checksums — although in some cases it’s a bit heavier-handed than I expected. Also, the library supports defining bit structures too, which simplified considerably the OneTouch Ultra Easy driver, that was building its own poor developer version of the same idea. After rewriting the two binary LifeScan drivers I have (for the OneTouch Verio 2015 and Select Plus, and the Ultra Easy/Ultra Mini), the similarities between the two protocols are much easier to spot. Indeed, after porting the second driver, I also decided to refactor a bit on the first, to make the two look more alike.

This is going to be useful soon again, because two people have asked for supporting the OneTouch Verio IQ (which, despite the name, shares nothing with the normal Verio — this one uses an on-board cp210x USB-to-serial adapter), and I somehow expect that while not compatible, the protocol is likely to be similar to the other two. I ended up finding one for cheap on Amazon Germany, and I ended up ordering it — it would be the easier one to reverse engineer from my backlog, because it uses a driver I already known is easy to sniff (unlike other serial adapters that use strange framing, I’m looking at you FT232RL!), and the protocol is likely to not stray too far from the other LifeScan protocols, even though it’s not directly compatible.

I have also spent some time on the tests that are currently present. Unfortunately they don’t currently cover much of anything beside for some common internal libraries. I have though decided to improve the situation, if a bit slowly. First of all, I picked up a few of the recommendations I give my peers at work during Python reviews, and started using the parameterized module that comes from Abseil, which was recently released opensource by Google. This reduces tedious repetition when building similar tests to exercise different paths in the code. Then, I’m very thankful to Muhammad for setting up Travis for me, as that now allows the tests to show breakage, if there is any coverage at all. I’ll try to write more tests this month to make sure to exercise more drivers.

I’ve also managed to make the setup.py in the project more useful. Indeed it now correctly lists dependencies for most of the drivers as extras, and I may even be ready to make a first release on PyPI, now that I tested most of the devices I have at home and they all work. Unfortunately this is currently partly blocked on Python SCSI not having a release on PyPI itself. I’ll get back to that possibly next month at this point. For now you can install it from GitHub and it should all work fine.

As for the future, there are two in-progress pull requests/branches from contributors to add support for graphing the results, one using rrdtool and one using gnuplot. These are particularly interesting for users of FreeStyle Libre (which is the only CGM I have a driver for), and someone expressed interest in adding a Prometheus export, because why not — this is not as silly as it may sound, the output graphs of the Libre’s own software look more like my work monitoring graphs than the usual glucometer graphs. Myself, I am now toying with the idea of mimicking the HTML output that the Accu-Check Mobile generate on its own. This would be the easiest to just send by email to a doctor, and probably can be used as a basis to extend things further, integrating the other graphs output.

So onwards and upwards, the tooling will continue being built on. And I’ll do my best to make sure that Linux users who have a need to download their meters’ readings have at least some tooling that they can use, and that does not require setting up unsafe MongoDB instances on cloud providers.

Diabetes management software, online apps, and my projects

So my previous post with glucometerutils news got picked up by Hackaday, and though the comments ended up mostly talking about the (more physical, less practical) note about fiddling with the glucometers hardware themselves (which would suggest me the editor should probably have avoided moving the spotlight in the post, but never mind), I ended up replying to a few comments that were actually topical, to the point that I thought I should be writing about this more extensively.

In the comments, someone brought up Tidepool, which is a no-profit in California that develops what to me appears to be its own data storage and web application for diabetics. This is not far from what Glucosio is meant to be — and you might remember that an interaction with them, had me almost leave open source development, at least for what diabetes is concerned.

The problem with both projects, and a number of others that I’ve been pointed to over the years, is that I find most of them either not practical or web-oriented, or a mixture of the two. With not practical I mean that while building an “universal glucometer” capable of using any random strip is an interesting proposal, it does nothing to improve the patients’ life, and it actually can significantly increase the risks of misreading values and thus, risk the life of the user. For this reason, plus the fact that I do not have enough of a biochemistry understanding to figure out how to evaluate the precision of the meters that are already certified, I don’t invest any time looking into these projects.

Web-based applications such as Tidepool and similar are also far from my interests. I do not have a personal problem with accessing my blood sugar readouts for the sake of research, but I do have some concerns about which actors are allowed access to them. So in particular a startup like Glucosio is not someone I’d be particularly fond of giving access to my data to. Tidepool may be a no-profit, but that does not really make me feel much better, particularly because I would expect that an US-based no-profit would not have gone through all the possible data processing requirements of EU legislation, unlike, say, Abbott. I have already written a lot about why I don’t find self-hosting a good solution so I don’t think I need to spend much time on it here.

Except, there is one extra problem with those apps that require you to set up your own instance — like some of the people who have not been waiting some time ago. While running an app for my own interest may sound like an interesting thing to do, particularly if I want to build up the expertise to run complicated web app stacks, my personal ultimate goal is to have my doctor know what my blood sugar levels are over time. This is the whole point why I started that tool, I wanted to be able to output a PDF that my doctor could see without having to jump around a number of hoops to produce it — I failed to do so, but in part because I lost interest after I started using the awesome Accu-Chek Mobile.

If I were to tell my doctor «Log in on this site here with these credentials and you can see my readouts» he might actually do it, but mostly because of novelty and because he entertains my geekery around trying different meters and solutions. If he started to get this request from dozens of his patients, not only he’d have to keep a password managers just to deal with credentials, but he’d probably just couldn’t have the time to deal with it. The LibreLink app does have the ability to share data with a few services, and he did suggest me to look into diasend, but it looks like it got merged into something else that might or might not work for now, so I gave up.

Now, here is an interesting prospect, and why such apps are not completely worthless in my opinion. If the protocols are open to be used, and the apps are open source and can be set up by anyone, there is space for the doctors to have their own instance set up so that their patients can upload their data. Unfortunately, the idea that being open source this does not involve a significant investment in time and money is patently false. Particularly for important data like this, there has to be proper security, starting from every session being encrypted with TLS, and the data encrypted at rest (it is ironic that neither Tidepool nor Glucosio, at the time of writing, use TLS for their main websites). So I still don’t expect doctors in the public sector to be using these technologies any time soon. But on the other hand, there are more and more apps for this being built by the diabetes tech companies, so maybe we’ll see something happening in the future.

Where does this leave my project? Well, to begin with it’s not a single project but two of them. glucometerutils was born as a proof of concept and is still a handy tool to have. If someone manages to implement output to HTML or to PDF of the data, that would make it a very useful piece of software that does not need to interact with any remote, online application. The protocols repository serves a distinct need: it provides a way for more people to contribute to this ecosystem without requiring each of them to invest significant time in reversing the protocols, or getting in bed with the manufacturers, which – I can only guess – involves NDAs, data-sharing agreements, and similar bureaucracy that most hobbyist developers can’t afford.

Indeed, I know of at least one app, built for iOS, proprietary and commercial (as in, you have to pay for it), that has built support for meters thanks to my repository (and the author gave back in form of corrections and improvements on the documentation!). This is perfectly in line with my reasons to even have such a repository. I don’t care if the consumers and contributors to the repository build closed-source tools, as long as they share the knowledge on how to get to the data. And after that, may the best tool win.

As I said before, smartphones are no longer a luxury and for many people they are the only way they can access the Internet. It makes sense that the same way, for many diabetics it is their only way to analyse their readouts. This is why Contour Next One comes with Bluetooth and a nice app, and why there even are standard Bluetooth specification for glucometers (GLP/GLS) and continuous monitors (CGMP/CGMS). If my work on an open-source tool brings more people the ability to manage their diabetes, even with closed-source software, I’ll consider myself satisfied.

Now, there is one more interesting bit with Tidepool, though: they actually publish a Chrome-based uploader app that is able to download data from many more glucometers than my own tool (and the intersection between the two is minimal). This is great! But, as it happens, it comes with a little bit of a downside: the drivers are not documented at all. I confirmed the reason is that the access to the various meters’ protocols is subject to NDA — so while they can publish the code that access those meters, they cannot publish the specs of the protocols themselves, and that appears to include in-code comments that would make it easy to read what’s going on.

So, one of the things I’m going to do is read through those drivers, and try to write a protocol spec for the meters. It appears that they have a driver for Contour Next meters, which may or may not work for the Contour Next One which I’ve been trying to reverse engineer — I know there is at least one other open-source implementation of accessing data from Contour Next meters, but the other one is GPL-2 and, like OpenGlucose, I’ve avoided looking too closely to the code.

Projects such as Tidepool are extremely important to provide a proper alternative to the otherwise closed-garden of proprietary cloud diabetes management software. And if they become simple, and secure enough to set up, it is possible that some of the doctors will start providing their own instances where their patients can upload the readings, and that will make them also practical. But for now, to me they are only a good source of confrontation to figure out a way forward for my own tools.