Dealing with Anubis transmitters in CamAPS

CamAPS FX is the AID software that Ypsomed provides to use with the YpsoPump. It uses Dexcom G6 as its CGM. Some CamAPS users use the unofficial Anubis transmitters with G6 sensors.

The Anubis cost advantage in Australia has shrunk with the NDSS CGM Subsidy, but still the advantages of faster warmup (50 minutes rather than 2 hours), longer sensor life (cut off at 60 days instead of 10), easier restarts (when required), and ability to rebattery on the fly (e.g. when travelling) are still significant. Things like not having to restart a sensor exactly 10 days after you started it (e.g. if you’re going to be asleep) are a massive win in terms of fitting diabetes in our lives!

The transmitter reports to the application software what the sensor lifespan is (e.g. 60 days) and almost all software copes with that. Also each glucose data packet includes information about the age of the sensor at that point. In general this works fine:

  • The Dexcom G6 app keeps running until the transmitter stops the session. As do all the opensource programs that communicate with G6.
  • The Tandem t:slim X2 pump runs fine.
  • The Dexcom G6 Receiver gives spurious warnings about the sensor being about to expire as we approach 10 days, but then it realises that the sensor is still running, and goes back to normal operation.

CamAPS and Anubis

CamAPS is currently the only exception to this. It gets very upset when a sensor passes 10 days in age!

Here you can see the system in Auto mode just before the 10-day mark. As an aside, the low readings here were a deliberate step in a clinical trial where we were testing a prototype CGM sensor and they needed readings in specific ranges. While these screenshots were taken I was sitting in a hospital room with a cannula in my arm having blood samples taken regularly to measure against that CGM. I just happened to also have a G6 sensor on that was reaching 10 days (the YpsoPump wasn’t actually delivering insulin to me at that point). After I’d run low for a while I got to have breakfast and we sent the BG up to get some high readings also (which you’ll see later).

When it gets close to 10 days it starts warning that the sensor is going to expire. And then when we reach 10 days it lies to us that the sensor session has ended. It has not.

It turns out that the software is upset that the age of the sensor is >10 days, and it keeps giving us that message. The main CamAPS screen no longer shows the BG value, and keeps prompting us to Start Sensor.

Auto mode keeps running

Note however that the app stays in Auto mode. The insulin delivery still gets adjusted by CamAPS. The dots still appear on the screen. Also the BG number is still captured by xDrip+ if it’s in Companion App mode.

We don’t see the BG number or trend arrow on the main display. We don’t get low/high CGM alerts, and we get frequent repeats of the alert telling us to replace the sensor.

Some people leave their systems running like this for a while, as they get numeric display and CGM alarms via xDrip+, and there seems little reason to disrupt a sensor if it’s running reliably.

Unable to restart?

Unfortunately if you simply press the Start Sensor button this doesn’t resolve the issue.

  1. The app sends a Start Sensor command to the transmitter. Actually it gets queued up and sent at the next 5-minute boundary.
  2. The transmitter knows it still has a valid sensor session running, and discards any sensor code that was included in the start command.
  3. The transmitter returns the current data.
  4. CamAPS immediately gets upset again because the sensor age is older than 10 days.

Even if you physically remove the sensor and place the transmitter in a new sensor, the existing sensor session is usually still running.

The tricks to stopping the sensor

It turns out there are 3 ways of working around this. They all involve getting the transmitter to stop the session and starting a new one so that CamAPS is happy with the sensor “age”.

Note that once the session is stopped, restarting a sensor with an Anubis transmitter is a lot easier than with an original Dexcom unit. No gymnastics are required to convince the transmitter that it’s a “new” physical sensor.

Option 1. Using another device

If you have something like a Dexcom Receiver that’s also connected to the same transmitter, you can issue a Stop Sensor from there.

Option 2. Resetting the Anubis

You could use Anubis Reader (iPhones), AnubisT00L (Android), or xDrip+ (on a separate phone, using Manual Slot 1 or 3 so it’s being a Receiver) to issue a hard reset command to the transmitter.

This puts the transmitter to sleep.  Because the transmitter is still in a sensor it will then immediately wake up, but the sensor session won’t exist any more.

Also the Bluetooth pairing information will no longer be valid, and you will have to re-pair CamAPS with the transmitter. This usually involves switching to a different “transmitter” such as the imaginary 800000 then re-selecting the Anubis’ ID.

Option 3. Tricking CamAPS

It turns out this is simpler to do than the above methods.

Keep in mind that the transmitter only wakes up to talk to the host every 5 minutes. It’s still doing that and connecting to CamAPS. Each time it does you should see a new dot appear on the graph.
Also if you have xDrip+ listening to CamAPS it will actually say how many minutes ago it received the last number (if it says 4 minutes that implies that the transmitter’s about to wake up again).

The steps are:

  1. Wait until new data arrives. This gives us the most time to get the following steps done.
  2. Press the Start Sensor button. It does not matter what sensor code you enter this time, so you can leave it blank.
    The app will then say the sensor is warming up.
  3. At the bottom of the CamAPS menu select Stop Sensor. This wasn’t accessible before you “started” the sensor.

At this point there will be two commands queued to send to the transmitter:

  • A Start command (which the transmitter will ignore), and
  • A Stop command (which will have effect).

The screen will look like this. When the transmitter wakes up and connects, then CamAPS will revert to saying you have to Start Sensor. At this point it’s because the transmitter’s sensor session actually has ended.

Restarting the sensor

This time when we Start Sensor, we definitely want to supply a Sensor Code. If we don’t then the transmitter will keep asking for calibration data every day.

Ideally we have the original sensor code recorded (I take a photo of mine when inserting a sensor). If we don’t, the best option may be to use sensor code 9117. This is equivalent to the code that was used in the early generations of G6 before they used sensor codes. Essentially it references the “average” mid-point of the calibration values.

CamAPS will say it’s going to take 120 minutes to warm up the sensor, although things will change after 50 minutes (the counter will be around 70) when the Anubis starts returning values.

In general when I’ve restarted sensors after 10 days the values have come in fairly close, but sometimes I’ve had to put a single calibration in after a while.

In the following graph the restarted sensor is the top number. The one below it is a separate 3-day-old sensor (being used as a control for the clinical trial). In this case the original code was 9311, but as an experiment I did the restart (after 10 days) with 9117.

The two sensors seem “fairly close”!
Incidentally, at this point the trial “meal challenge” for the day was over and my BG was starting to return to normal.

Hopefully this information makes CamAPS use a little easier to deal with at those times people get caught by the 10-day boundary!

1 thought on “Dealing with Anubis transmitters in CamAPS”

  1. Alison Twemlow

    Thank you. I’ve been caught out a couple of times in the past. This will definitely help.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.