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.
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.
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.