This is a quick overview of my first impressions of CamAPS FX. In it we look at some of the features of the system and how various bits of it appear to work. It’s a bit of a hodge-podge of things I’ve noticed, the way things operate and a number of other factors.
Glucose Targets, Boost and Ease Off
These are three of the immediately obvious features that you want to get to know in CamAPS FX. Note that in the video, the glucose levels are not the result of the system failing to do its job, rather that the cannula I initially chose to use with the DanaRS didn’t work for me (4.5mm steel). As soon as I had changed to a more appropriate one (7mm steel), it worked out very well.
Personal Glucose Targets
One of the main highlights of CamAPS FX amongst commercial systems is that it allows for a very wide range of personal glucose targets to be configured, at multiple points throughout the day. The range available is from 4.4mmol/l to 11mmol/l, which obviously enables a lower overnight target for sleep, but also gives you a lot more flexibility as a user with what you want to set up. As the video shows, it’s fairly straightforward to configure, and gives you a way that you could adjust targets for running a marathon, for example. As a result, it’s a lot more flexible than some of the other commercial systems out there (with maybe the exception of Diabeloop, which also allows some flexibility, but not as much), and is pretty much on a par with the DIY systems.
Having said that, the targets that I tend to use aren’t particularly stressful for an AID system, sitting in a reasonably “average” range. I’m not sure what the standard is if you don’t configure targets. I assume it’s around 6.5mmol/l.
Boost and Ease Off modes
Boost and Ease Off modes are similar to the “Eating Soon” and “Exercise” ideas in the DIY world. And as a DIY user that’s probably all you need to know, although I’m not 100% clear on how much more or less aggressive they make the system. I think I recall someone saying that it was effectively a 30% increase or decrease in target value (within the allowable range) when doing this. You have no control over how much this value is.
For those who aren’t familiar with DIY systems, Boost is a mechanism to tell the system that you want it to give you more insulin, while ease off is one to reduce the amount you receive.
Both options can be set from “Now” or scheduled in the future, however it’s not possible to do what I use with OpenAPS, which is add them to a calendar so that you have a boost or ease off at a specific point in time relating to when you might normally eat or exercise.
Managing with only Weight and Total Daily Dose (TDD)
One question that might arise is “How does it manage with only Weight and TDD” given the challenges many people find with setting up the appropriate settings on basal, ISF and CR for DIY systems.
As the image below shows, overnight last night, it managed to keep me pretty much in range. Okay it was a bit below target, but given that I’d had no involvement in the decisions it made, that’s pretty impressive.
As you can see, I was up fairly late last night, so it looks like the slight drop below 4mmol/l was generated by the meal boluses at midnight and 01:45am. Nothing to much to see there, given the earlier cannula issues that I’d had.
At this point it’s worth noting that I’m using Fiasp with this system, which Professor Hovorka has stated the system is licensed to use. I assume it is using an observational basis to determine the peak time of the insulin it delivers and determine the tail.
From overnight, this suggests that the performance when in a “Basal Only” mode is very similar to that of a DIY system, and with more nights ahead, I’ll get a better impression of how we get on.
The other thing I noticed is that when you bolus, the system connects to the pump before you enter details into the bolus calculator. Intrigued at this, I started to play around.
It turns out that the bolus calculator in the app is initially using the Carb Ratio that you enter into the pump to calculate your bolus. Remember I said yesterday that pump settings weren’t important? Well it seems to be that they are more important than I thought. If you haven’t set up your pump fully before starting, you will almost certainly have the wrong factors in use in the Bolus Calculator.
Both the Carb Ratio and “Insulin Sensitivity Factor” or “Correction Factor” that the bolus calculator uses is initially based off the numbers entered into the pump
In the two pictures below, the first has pump settings of Carb Ratio = 13g/U and ISF = 2.6mmol/l/U; the second uses Carb Ratio = 26g/U and ISF = 3.9mmol/l/U. The number in brackets is the Active Insulin at the time of using the bolus calculator.
As can be seen here, there’s quite a difference. What it highlights is that in relation to meals, you initially need to set the pump up correctly and have reasonable settings before you start using CamAPS FX. It will be interesting to see whether these get adjusted over time as the system learns more.
It also begs the question as to what the system is doing in relation to basal insulin. Is it simply using a some sort of circadian basal rate calculated using TDD and Weight, or is it also factoring in the basal rates that are already set in the pump? I hope that it’s the former.
Right now, there is only one way to monitor this system remotely and one and a bit ways to monitor it locally.
You have to use the phone. You can configure the system to add your “Diabetes Info” in the notifications bar of Android, which means that you don’t have to open the app every time, and it can also be enabled on the lock screen (as shown below), meaning you don’t have to fully unlock the phone. As this functions by pushing a notification every five minutes or so, you can also use this with notifications on a Fitbit or Garmin (where you can enable notifications in the Fitbit or Garmin apps), but I was unable to link the CamAPS notifications to my WearOS watch (Huawei Watch 2).
Given that I’ve been able to access glucose data on my watch for the past five years, this does feel like a bit of a retrograde step, and is really quite frustrating. I would also like to have been able to interact with the system through my watch, but that is, at the moment, a step too far.
I’d also like a widget that contained glucose data, so that I could put this on the home screen, like you can do with xDrip.
As it stands right now, CamAPS only speaks to Diasend remotely. This means that the only data you can see is the graphs like the one below. It doesn’t give you the ability to remotely monitor what’s happening in real time. The Diasend graphs are updated real-time, but you do need to refresh the page to see this.
Having said that, you can configure five SMS followers in the app to receive alerts, so if this system is in use on a child or vulnerable person, they can receive alerts for high, low, urgent low “urgent low soon” (notifies you that your glucose level is falling quickly and will hit the Urgent Low level within 20 mins) and fast rise or fall via SMS. They could then log into Diasend to check what is happening.
Okay, it’s not a real time updating web page, but it does offer a hands off approach to monitoring and potential intervention.
How does it work?
I’ve not really dug too far into that one yet, but as you can see in all the graphs that I’ve shown in this article, it looks like the system is adjusting basal rates. Here’s another example:
Looks can be deceiving. The blue line isn’t showing a basal rate. CamAPS is working by setting extended boluses while setting the basal rate to zero. Whilst this isn’t too difficult to understand, it differs slightly from how the DIY systems work, relying mostly on Temporary Basal Rates (TBRs), or a combination of TBR and Extended Bolus, dependent on the pump in use.
What has proven to be interesting is what it does after meals. Unlike oref0/oref1 or Loop, it doesn’t zero temp after a bolus. It makes a different decision, which with more observation, and perhaps reading Roman’s papers, I hope to be able to understand better.
The number of apps
This might seem like an odd thing to raise, but with the integration of the Dexcom receiver app into the CamAPS app, and CamAPS working on seemingly most phones (let’s face it, a Xiaomi Mi 9 Pro 5G isn’t a particularly common one) there are no longer the same issues about whether the phone you’re using can install the Dexcom app. That’s a big change for Dexcom users.
It also makes installing the system easier. Unlike AndroidAPS, where you have to install a receiver app that’s one of many options, and ensure it can communicate to the APS system, this is a one stop shop. For many DIY users this isn’t a good thing, but for many other potential users, it makes life a lot easier and reduces the concerns people have about setting up a system like this.
Admittedly, that does lock you in to a single CGM system, however, when you consider that, right now, Dexcom’s G6 is the only system with the iCGM designation, it also makes sense. I’m sure that as others come along, they will also be usable with this an many other systems.
The key point here is that the simplicity of set-up is maintained by running only the single application.
Given the short amount of time I’ve spent with it so far, there isn’t much else to highlight. What remains the most interesting part of this is to see what the Time in Range outcomes over a longer period of time are, and to see if there are any of the features or way the system work that I either really like, or cause me frustration. There are already one or two that I think will become more obvious as I use the system.