Close
0%
0%

Continuous Glucose Monitoring Backup

Backing up cloud-based CGM, and waking my kid when she gets an alert

Similar projects worth following
My daughter is diabetic and wears a Dexcom continuous glucose monitor (CGM). It talks to her phone via Bluetooth, which then uploads data to a Dexcom server, and an app on our phones can be used to monitor her blood glucose level in real time. As long as the Dexcom servers are up, which they weren't for over 48 hours this weekend.

I want a simple system that cuts out the cloud part of this loop and sounds alerts locally. And I want them to be LOUD alerts - my daughter sleeps like the dead, and she sleeps right through alerts meant to save her life if she goes low in the middle of the night. I may have to resort to electromechanical means - Nerf darts, spraying water, or a servo that dumps her out of bed onto the floor. Seriously - she sleeps that soundly.

There are two ways to go about this. The easier route would be to use the spare Dexcom receiver we have - we got upgraded from the original receiver that we had to a receiver with "Share", which enables the Follow app on our phones. I'd use a Pi or something similar to read the data coming from the receiver in realtime over the USB port, and use that to sound local alerts, send text messages, etc.

The other, and perhaps more interesting, approach would be to sniff in on the RF signals coming from the Dexcom transmitter. The transmitter works on the 433 MHz ISM band, and that might make it easy to tap into and make it as seamless as possible for my daughter. I'm envisioning this as a nightstand system, and I want it to "just work" when she lies down to go to sleep. No remembering to plug anything in, nothing to do except be near it and have it work.

Brief Dexcom topology lesson: the G4 CGM system that we have consists of three physical parts:

  1. A sensor. This is the electrochemical bit that gets injected in her skin and creates a current proportional to the level of glucose in her interstitial fluid. That's replaced every week or so - we usually stretch that out to two weeks or more since they're so expensive;
  2. A transmitter. This is a little battery powered bit that snaps onto the sensor and drives it, encodes the data, and transmits it as packets on the 433 MHz ISM band; and
  3. A receiver. Our G4 system - two generations old now - has a separate, dedicated receiver, which turns the data into pretty graphs and sounds alarms when setpoints are exceeded. It also has a Bluetooth connection to her phone, which runs the Share app that lets us see her numbers on the Follow app. 

woot17-paper-reverberi.pdf

Analysis of RF comms used by Dexcom transmitters

Adobe Portable Document Format - 996.82 kB - 12/04/2019 at 04:45

Preview
Download

  • Building a Test Setup

    Dan Maloney12/05/2019 at 16:21 0 comments

    No matter which way I choose to go, I'm going to need a test rig - I can't realistically follow my kid around all day to use her transmitter to test with, and waiting till she's asleep would be inconvenient, especially since my lab is nowhere near her bedroom.

    Luckily, I have most everything I need to build a test rig. As I mentioned, we have a spare Dexcom receiver, and we have plenty of dead transmitters to play with. I even took one apart to get at the long-dead batteries, exposing the battery leads:
     

    I can either slot new SR1120 silver-oxide batteries in there, or use a bench supply to apply the 1.55 V each battery produced, Which means I'll need a bench supply, preferably a current-limiting one, and one that can be dialed down really low so I can simulate different states of battery discharge, as battery state is something that's encoded in the packets sent out by the transmitter every five minutes.

    Good reference for battery replacement on the G4 transmitter: https://www.ifixit.com/Guide/Dexcom+G4+Batteries+Replacement/55536

  • Dexcom Receiver Hacking

    Dan Maloney12/04/2019 at 05:05 0 comments

    Possibly useful: https://github.com/openaps/dexcom_reader. That's the keys to the kingdom for reading data off a Dexcom receiver over the USB port. Certainly the easiest implementation since we have that spare receiver.

    But the USB route might pose an expensive problem. I've been told that the Dexcom transmitter somehow increases its signal output strength in response to how far away the receiver is. Not sure how this is accomplished technically - seems like the receiver would have to send back an RSSI or something - but we have seen evidence of this. G4 transmitters are only warranted to last six months, but we routinely get a year out of them because the receiver is always on my daughter's person. For this last transmitter, we tried being super diligent about distance, keeping the receiver in bed with her at night rather than across the room, where we could easily pop in and check it. This transmitter lasted 14 months, a record for us.

    Transmitter life is no joke - these things cost $600 a piece, and our insurance doesn't cover them. So using the spare Dexcom receiver might cause a problem, since the transmitter will think the bedside receiver is out of range most of the time. For that matter, I don't know if I can assign one transmitter to two receivers - each transmitter has a unique serial number that you have to enter into the receiver. Keeps your data private if you happen to be near another Dexcom user.

    Seems like sniffing the RF might obviate those problems. I don't care about dealing with multiple transmitters, and if there's something about the conversation that controls transmitter strength (and therefore battery life), I can probably control that in software. So I need to learn more about the packet structure and maybe start playing with an RTL-SDR to see what's going on between the transmitter and receiver.

View all 2 project logs

Enjoy this project?

Share

Discussions

Dan Maloney wrote 12/10/2019 at 18:31 point

I think my main stumbling block now is no practical way to power the torn-down transmitter I have. A credible bench power supply has been on my wish list for a while now - looking for a variable dual-output supply with CC and CV that can do up to 30V with a fixed 2V4/3V3/5V output. Suggestions happily accepted.

For this project it might also behoove me to have a precision adjustable supply that can dial down from 3V very precisely, so I can simulate the battery going dead and perhaps develop a calibration curve. We're always taken by surprise by the low battery indicator - it gives you two weeks heads up so you can order a new one, but at $600 a pop it's be nice to have a little more lead time to save up a bit.

  Are you sure? yes | no

Andrew Kowalczyk wrote 12/11/2019 at 04:25 point

I've had great luck at hamfests finding used brand-name bench supplies. We did a 'work trip' to a hamfest and 4/5 of us came home with decent supplies (the 5th saw a nice Tandy CoCo and went for that instead). The one I ended up exactly meets your description, it's a BK 1760. There's also the new Riden/RD ones on Ali that could make a great bench supply. Won't quite do the fixed voltage outputs, but adjustable LDOs/switchers could do that too

They sell battery emulators that do exactly what you're trying to do, but they are prohibitively expensive. Seems like a neat application to build something for using individual parts, just no idea how you'd qualify it without the pricey equipment

  Are you sure? yes | no

Dan Maloney wrote 12/10/2019 at 18:18 point

I wish I needed to get that fancy, but someone has already done all the hard work for me. A group looked at the Dexcom G4 system a while back in terms of vulnerability and found that security is appalling on these things. The wireless system is based on a TI CC2510, which actually uses the 2.4-GHz ISM band, not 433 MHz like I expected. They completely characterized everything about the connection - modulation, frequency-hopping intervals, channel spacing, data rates. 

So thanks to them I have the keys to the kingdom, as well as a prototype receiver. They used a Polulu Wixel 2.4-GHz USB module and an ESP8266. They found that the Dexcom packets are just wrapped into TI's general purpose protocol, SimpliciTI. Every five minutes it sends out a packet that encodes raw and filtered (five-minute moving average) glucose readings, battery level, and a checksum. They even worked out the checksum algorithm. So there's nothing left for me to do but plug and chug.

PDF of their paper is in the files section, BTW. I was really hoping I'd be able to justify a HackRF and/or a Salae with this project, but alas...

  Are you sure? yes | no

Tom Nardi wrote 12/10/2019 at 17:50 point

I've had very good luck using Universal Radio Hacker and RTL-SDR on 433 MHz. I'd say you should get into one of the old transmitters and see if you can put a logic analyzer before the TX chip to see what it's sending out. But by the looks of that thing, I'm guessing getting inside isn't easy.

Capture from logic analyzer makes it a lot easier to fine tune the SDR capture because you'll already know what the content of the packets should be. Been meaning to write up something about that since I took apart those 433 MHz restaurant pagers. But, you know...

  Are you sure? yes | no

Mike Szczys wrote 12/10/2019 at 16:34 point

If the RF is on 433 MHz that would be by far the easiest way to tap into this (assuming the data is being transmitted in the clear). @Elliot Williams has a ton of advice on these little receivers but you should be able to grab a module and your microcontroller of choice and just echo out data to a serial terminal rather than digging down into rtl-sdr.

He had a bunch of recommendations in this episode of the podcast (second interesting hack of the week):

https://hackaday.com/2019/01/25/hackaday-podcast-ep3-igloos-lidar-and-the-blinking-led-of-rf-hacking/

Perhaps most useful would be this:

https://hackaday.com/2018/03/18/speaking-the-same-language-as-a-wireless-thermometer/

  Are you sure? yes | no

Mike Szczys wrote 12/10/2019 at 16:40 point

Also, have you seen the work that's been done on Omnipod?

https://github.com/openaps/openomni

  Are you sure? yes | no

Dan Maloney wrote 12/10/2019 at 18:23 point

Yeah, we considered the Omnipod when we first were shopping for pumps. It certainly has its strong points, but the thing that bothered me is QC testing. With a refillable pump like the Tandem or Animas Ping that we used to have, each pump is physically tested before being sent out. With the OmniPods, each unit can't be tested, because each unit is a disposable pump meant to last only a couple of days. So they manufacture WAY more OmniPods than they can test, and even with good statistical process control, eventually some bad units are going to make it through to the patient. We decided that getting assembly right once was more likely than getting it right every few days.

Still, those little fellas seem so hackable.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates