CamAPS FX talks directly to Dexcom G6 transmitters, and uploads data to the Diasend and Dexcom cloud servers.
xDrip+ can also talk directly to G6 transmitters, and can upload to a variety of servers, implement a wide variety of alarms, display CGM data on a wide variety of watches, etc. As an example, in my own setup I have xDrip+ feeding BG data to my Garmin watch where it’s displayed during exercise as well as recorded within the FIT file for later exercise analysis.
When experimenting with CamAPS FX, by default my CGM data would no longer be uploaded to my Nightscout server and leave a big gap in my historical data (which currently goes back to 2016). But there are ways of using CamAPS FX and xDrip+ in parallel, so I’ve been able to have xDrip+ continue to upload my data to Nightscout uninterrupted.
xDrip+ “eavesdropping”
If you’re running a recent version of xDrip+ on the same phone as CamAPS FX, you can select a new Hardware Data Source in the settings: Companion.
After granting xDrip+ permission to read system notifications, it will essentially “eavesdrop” on CamAPS FX and grab the last BG reading.
Misses back-filled data
The G6 transmitter wakes up every 5 minutes to send data to the phone. If the phone has missed previous data CamAPS will back-fill the readings (usually filling in up to 3 hours worth!) and the graphs on-screen (and uploaded to the servers) won’t have gaps.
However it won’t send that extra data through to xDrip+. One of the statistics that xDrip+ can calculate and display in its “Extra Status Line” is the “Packet capture percentage”. This can tell you a lot about the performance of your system.
Obviously it is ideal if the system can react to changes as soon as they occur, and not have to wait 10-15 minutes to react to BG changes. So as close to 100% as possible would be good. But some phones don’t have as good Bluetooth implementations as others, and sometimes sensor and phone placement on the body causes gaps. My experience over years of looping says that 98% is acceptable. 95% is “OK”, but anything lower than that can have a noticeable impact on the performance of the system.
CamAPS FX doesn’t display this statistic, but it’s just one of the extra things xDrip+ can do for you in the background.
Sensor sessions longer than 10 days
Currently CamAPS FX has a bug in that it assumes that sensor sessions end after 10 days. Some transmitters (including Dexcom’s own G6+ as well as Anubis) have different sensor lifespans, and they all actually report the lifespan if the software checks for it. This includes all of Dexcom’s apps.
So if you’re using an Anubis and your sensor goes beyond 10 days, CamAPS FX will constantly display warnings that the sensor has expired and asking you to start a new one.
However, while it no longer displays a BG number or trend arrow and doesn’t provide CGM alarms, it does stay in auto mode (keep looping) and adjusting the insulin flow based on the CGM readings. If you tilt the screen on its side you can see it keeps working. It also continues to pass the numbers to xDrip+.
This bug has been reported to CamDiab and we can only hope it is fixed soon. In the meantime if you are using CamDiab with Anubis, life is much simpler if at 10 days you stop and restart the sensor (which at least doesn’t require physically disturbing the transmitter). After an hour when the warmup is finished, a single calibration should bring the readings (which would be artificially high) back into the correct range, and from then on CamAPS continues without complaining.
If CamAPS starts reading the lifespan data from the transmitter like all the other apps do, we should be able to just continue uninterrupted.
xDrip+ on other phones
There is another way that xDrip+ can run in parallel with CamAPS FX, and it’s related to the way a phone and a “receiver” (for example a Tandem pump) can share the same transmitter.
Ever since the G5, Dexcom transmitters have had two “slots”: one for receivers (slot 1) and one for phones (slot 2). When the transmitter wakes up every 5 minutes, it will talk to both devices before going to sleep. You can start, stop, calibrate, in fact do everything from either device, and the other device will see the results when it talks to the transmitter. The software on each device is responsible for managing its own backfill of any missing data.
I have used this when experimenting with Control-IQ on a Tandem pump, with my phone still gathering data and populating my Nightscout server.
Recent versions of xDrip+ allow you to specify the slot number instead of always using slot 2. You do need to enable Engineering Mode in xDrip+ to access this setting. So if you have a second Android device with you, that can talk to the G6 transmitter at the same time as CamAPS.
After changing the slot, you will need to forget the DexcomZZ Bluetooth device and re-pair so the transmitter associates this phone’s Bluetooth address with the new slot. And because the transmitter will probably still have this phone’s Bluetooth address also associated with slot 2, you may need to turn this phone off until CamAPS on the other phone is able to claim slot 2.
Incidentally, Anubis transmitters also have slot 3 available in case that’s useful.
Conclusions
Overall, you don’t have to give up all the advantages of opensource CGM management if you’re in a position to use CamAPS.
It’s good to have some flexibility.
Am I right in thinking CamAPS is Android only? I am eagerly awaiting Australian Ypsomed’s loop system but am a very committed Apple user.
For now, yes. I’m not sure what CamDiab’s plans are regarding iOS.
I’ve been a committed iPhone user since 2009, and with all my home and work computers running Apple operating systems since years before that. But I’m more than happy using a tiny Android device to manage my diabetes alongside that.
This is a great article , thanks .
Do you have any recommendations on the smallest android device available that will run camaps and dexcom6 closed loop?
Thanks.
I know a few people who have been using the Cubot Pocket phone (an Android 11 machine with a 4″ screen).
Hi David, thanks for all the great information you public. So helpful to me just getting starting. I was wondering if you had any experience with the Jelly 2 or feedback that influenced you choosing the Cubot Pocket phone? I am considering both for my controller.
Thanks.
I haven’t used the Jelly 2, although I’ve heard good things from friends who are users.
The Pocket is newer (and with longer battery life I think).
Hello,
thank you for the Informations. This is a great article
I’ve been using the CamAPS with the G6 for 2 weeks.
After your introduction, I installed the latest version of Xdrip on my cell phone and made the necessary settings.
Blood glucose values are now transferred from CamAPS FX to Xdrip. However, the trend arrow is largely incorrect. eg. CamAPS Fx shows 120 ↓ and Xrdip 120 →. Should further settings be made in this regard.
I have two more questions regarding using the 2 slot of the G6.
1.) Would it be possible to use a full Android smartwatch like Kosept Prime2 as another main device or just as the only main device.
I mean install CamAPS fx on android smartwatch and just loop with smartwatch?
2.) Would it be possible to use the pure Android smartwatch as a collector. By that I mean leave your cell phone at home and watch the G6 values via smartwatch. eg. at swimming?
Thank you very much in advance for your feedback.
I think xDrip+ is inferring the trend from the change in data, whereas CamAPS should be getting the trend arrow from the G6 directly? That might explain it.
Running CamAPS on a full Android watch might be an interesting experiment. However I expect the UI might be a struggle on a round watch like that, as some of the control buttons are in the corners of the CamAPS screen.
If the watch was running CamAPS you could keep looping (except when you had to take the watch off because it wasn’t waterproof for swimming). If the watch was running xDrip+ on slot 1 in parallel with CamAPS on your phone, that would at least tell you your BG in the same conditions.
Hey,
thank you for your advices.
Let me compromise for Dexcom6, CAM APS FX, Samsung smartphone, Samsung galaxy 4 watch.
Data send from Dexcom transmitter to CAM APS Fx.
From APS Fx to slot 1 in xdrip.
From xdrip Slot 2 to smartwatch (showing the blood-glucose)
Is this correct?
Thank you!
Seb
G6 to CamAPS FX.
From CamAPS to xDrip+ (using Companion mode, where “slots” don’t exist).
From xDrip+ to watch (again, no “slot” involvement).
Otherwise yes.
Just wondering, what are these “slots”….
Think of them like “channels”. It’s how a transmitter can talk to a receiver (or Tandem pump, or Omnipod 5) at the same time as a phone app.
Hello, thank you for the article. xdrip+ works fine for me in companion mode with camaps, but it does not seem to collect the treatment data, cabohydrates etc. am i missing something or is it impossible to display this data too?
thank you!
You are correct. CamAPS only sends that data to Diasend, not anywhere else.
Would this also work for XDrip+ and myLife App connected to the G6? I have just got the Ypsopump and prior to paying them for CamAPS (not free in the UK unless you are lucky) I would like to move to have xDrip+ work outside of it using slot 2 itself. I also have the Dex Receiver so it will be slot 1 and then myLife App on slot 2 (replaced I guess by myLife CamAPS).
I don’t know. I suspect not, but it could be interesting to find out for completeness.
Using the mylife App with G6 seems fairly rare around here though. It’s a bit pickier about which phones it runs on for a start.
I tried it on my Galaxy S22 but it did not work. I also tried the other work around of having the Dexcom interface within myLife App have a follower from Dex as the source, but that is also not working at the moment although Yposmed are working on it. Last resort will be a cheap old android phone running xDrip+ and using a manual slot number instead of the Dex receiver I have. Mind you my version on the S22, 2022.08.03, has the manual slot greyed out even in Engineering mode. Never straight forward…. the life of a diabetic
for those that get this thread and to my comments above, don’t forget the ‘enable’ in front of ‘enable engineering mode’. Only then will you actually be in engineering mode and can change the slot number…..
Sorry newbie here , how do I find give Xdrip+ Permission to read sys notifications for Cams. Thanks.
After you select Companion method, xDrip+ should prompt and ask you about it?
If using the Anubis with CAMAPS and xdrip as follower, will CAMAPS only see readings after 2 hours even with the transmitter set up to start sending readings after 50 minutes?
At the moment, xdrip and CAMAPS dont get readings until 2 hours for me?
As long as your Anubis is in Enhanced mode, it should return data after 50 minutes. CamAPS will realise it’s getting data (it doesn’t ignore it for the 2 hours to be up) and it should all fall into place.
“Currently CamAPS FX has a bug in that it assumes that sensor sessions end after 10 days.”
I think you mean “CanAPS FX uses an official implementation of the Dexcom app, and is an approved system, so has to adhere to the official lifespan of sensors”.
While I don’t disagree that there are plenty of ways around this, I think we have to bear in mind the constrains that approved systems need to work under ?
I am aware of that issue, but my words were carefully chosen.
Various Dexcom G6 transmitters have used various lifespans. For example the Dexcom+ in SA used 14 days.
The official Dexcom app works with all of these: why shouldn’t CamAPS? The transmitter tells it how long the sensor lasts.
Great article. I’m new to xdrip but managed to get it working with cams app & then onto my garmin 1030 bike computer which is great…….. but…..xdrip drops out for hours on end & randomly comes back, don’t know why? Also as xdrip is getting readings from cams app do I have to re start new sensor on both or just cams app? Thanks
I leave xDrip+’s “sensor” running for aeons.
You may want to turn off Play Protect and tweak some battery optimizations. There may be useful info in the “xDrip” group in FB.
Thanks for this great article David. I’ve recently started using camaps with an Anubis G6, and found that when trying to restart a sensor, after a minute or two it come up with the ‘your sensor session has ended’ message and doesn’t allow a restart. The only way I could get it to restart was using the Anubis tool to reset the transmitter? Did you find this issue? I wonder if they might have updated the camaps app to make restarting a sensor more difficult?
The problem there is that the Anubis doesn’t end the session when CamAPS expects it to (at 10 days) but then CamAPS doesn’t give you a way to send a Stop Sensor command. And thus when you do a “Start Sensor” the transmitter thinks you want to join the currently-running sensor session, and then CamAPS complains because it’s older than 10 days.
The easiest solution is to stop (and possibly restart) the sensor when CamAPS gives you the warning that it’s going to expire soon. Do it before it reaches 10 days!
Ah! Thanks for the tip, I’ll try that next time. Liking camaps, less traumatic on my phone battery than androidAPS and getting a year of free dexcom G6 while using it so will probably stick with it until then, but keen to move towards fully closed looping after that.
I know this is an older article now, but I have just (today) transitioned to the new version of the Ypsomed Pump. In order to make CamAPS FX work I have had to buy a second phone (Samsung Galaxy Z Flip 4, in my case) as it won’t run on my iPhone. This is a compromise I have already resigned myself to (Please CamDiab – release the iOS version Ypsomed promised for 2022!). This also means I can no longer have my BSL display on my Apple Watch. Is there anyway of using the 2 “slots” on the transmitter to send data to an app on my watch and, if so, what app do you recommend? Thanks.
CamAPS always uses Slot 2 (the “phone” slot) and so does everything I’m aware of that can talk to a G6 from an iPhone.
So no.
You can have xDrip+ on your Z Flip4 uploading to either (or both) a Nightscout site or Dexcom Share/Follow.
Then you can use an assortment of apps for your Apple Watch to retrieve the data from either.
That does however depend on active internet connections for both phones to get updates through.
Hello,
today I will switch to the CamAPS FX, Over the last months (or years) I used the following setting:
G6 -> xDrip+ (Samsung Phone) -> Garmin Smartwatch
Apart from a great Bluetooth issue, Samsung produced with an One UI Update a couple of months ago and fixed, this worked very well. I appreciate especially the alarm push and the overall reduction of phone use required.
After reading your description I am afraid, that alarms won’t work the same way any more: If I get it right, xDrip+ cant’t backward push to CamAPS, so that if an alarm occurs, I have to turn it off in CamAPS and thus using my phone and not only my watch. Is this correct? That would be a great downgrade for me, apart from the great advantages CamAPS evidently has.
The watch can display and acknowledge/clear notifications/alarms on the phone.
However I know that some of the CamAPS alerts require you to go into the app and acknowledge them directly for communications to continue. I had this recently with some CGM outages. Was very frustrating that it didn’t auto-resolve the problem when things came back into range. It seems to assume we’re going to wake from our sleep and always interact with the system even when it should be able to keep us alive and let us sleep.
So yes and maybe no.
Thanks for your fast answer.
So apparently, we need an interface between CamAPS and Smartwatches. I wonder, why seemingly nobody considered this to be important, yet.
Thanks so much. Works a charm!
Hi David.
I have managed to get xdrip working on my phone that is displaying my bgls. But I still can’t seem to work out how to get my new galaxy 7 watch to display bgls. I have tried several ways and nothing seems to work. Any ideas?
The usual method is to use tools like Wear Installer to install the “wear” component of the app onto the watch. Unfortunately because xDrip+ wasn’t installed on the phone via the Play Store you need to use developer tools to load the wear component.