Building a Dexcom-powered glucose monitor with a Raspberry Pi Pico 2 W

tl;dr I built a little desk gadget that shows a current glucose reading and trend arrow using a Raspberry Pi Pico 2 W and a Pimoroni Display screen. It talks directly to the Dexcom Share API and shouts at you (in red) when something’s wrong.

So what is it?

If you, or someone you know, wears a Dexcom G6 or G7 continuous glucose monitor (CGM), you’ll know the drill: the sensor connects to a phone every five minutes via Bluetooth, which then sends the reading back to Dexcom. And if you have a kid wearing one, most likely you’ve installed the Dexcom “Follow” app that also sends the readings to you. I can’t overstate how incredible relieving this has been having the reading accessible even when she’s at school, friends’ houses, etc.

My daughter was diagnosed with Type 1 diabetes at the back end of 2025. It was one of those things that even though it was brewing for months, maybe years, the transition from “everything is OK” to “hang on something’s wrong” felt like it happened instantly, and one trip to the docs and then A&E later, we had the diagnosis. We’re quite lucky in the UK, and especially in Leeds, that we have somewhat of a diabetes research hub here so there were plenty of experts on hand and no delay on her getting set up with a Dexcom sensor, and later an Omnipod insulin pump. We won the postcode lottery, so to speak. People have their issues with the NHS but in this case I can’t fault a thing, they were incredible and still are now a year later.

So once this bit was out of the way and we’d had time to process things, my dev brain kicked in and I went looking for something I could build to help the kid take ownership of her condition. After discovering Dexcom had an API, I knew there had to be something I could do with that.

So after some research I decided on a Glucose monitor screen for her bedroom. I opted for getting a Raspberry Pi Pico 2 W (a tiny, cheap computer on a board about the size of a stick of gum, with Wi-Fi built in for literally a few £££) and clipped a Pimoroni Display Pack 2.8 on top of it. That gives me a 320×240 screen and four buttons. The Pico logs in to Dexcom every 30 seconds, grabs the latest reading, and draws it big and bold, along with an arrow showing which way the readings are trending.

It can show mmol/L or mg/dL, and anything above or below your chosen limits turns red. The arrows are all there too: up, down, flat, the diagonal ones, and the double arrows for when things are moving quickly.

How does it work?

Put simply, it boots, connects to a preset WiFi network, then connects to the Dexcom Share API, and checks for new readings periodically. A standard API consumer service, for anyone whos worked on reporting software fed by remote data, except this is running on a microcontroller. Very cool!

Cutting out the middleman

The first version of this was a bit of a failure, and actually nearly led to the whole thing being abandoned. After applying for API access from Dexcom and waiting weeks for a response I finally got a small web service running on a server that fetched the readings from Dexcom, and the Pico just asked my server for the latest number.

But then – disaster. It turns out I missed the part of the documenation that noted that data was on a 3 hour delay (1 hour in the US). So this made it effectively useless as a real time glucose monitor.

So the project was shelved. I don’t know what made me think to revisit, but I seem to recall months later I had a lightbulb moment like, wait, if the Dexcom Share app can pull in real time data, then an API must exist somewhere right? This led me to the excellent pydexcom Python library by Gage Benne, who had conveniently done all the reverse engineering so I didn’t have to. The project was back on!

So I binned the dexcom microservice and set to work integrating the API calls directly on the board.

The most important feature is knowing when not to trust it

Once I’d got the data pulling in, one of the first things I realised I had to consider was a display showing a “critical” number is only useful if that number is current. A screen that says 6.2 with no indication that it’s actually twenty minutes old is worse than no screen at all.

My first attempt at “how old is this reading?” simply measured how long ago the Pico last received one. It worked, but then it occurred to me that Dexcom can hand over readings that are already several minutes old by the time you get them. So a reading that was really 9 minutes old could look like it was only 4. Not great if your last glucose reading was 4.2mmol on a double arrow downwards trend.

The simple fix was to use the timestamp from the sensor itself, and compare that against the actual time. Which meant the Pico needed to know the actual time, and so the Time library was installed and a sync with an NTP server at boot time was added.

Once a reading is more than 6 minutes old, the number is replaced with ---, the arrow disappears, and the little RGB LED on the display goes solid red. The “Last reading N mins ago” text stays put, so you can still see how long it’s been, and the last known value moves down to the corner as “Previous”. This makes it much more difficult to glance at it and mistake stale data for fresh data.

The LED has three states: off when everything’s fine, flashing red when the reading is below/above range, and solid red when the data is stale.

The thirty year bug

While I was getting the time stuff working, I was caught out by something I read on reddit. Of course Linux timestamps are seconds since the “Epoch”, which in most cases is 1970. But I had it under good authority that some versions of Micropython count from 2000, and the Pimoroni’s flavour of Micropython was apparently one of them. Turns out this was completely wrong, and for a while I was scratching my head over why times were being reported back as 30 years old. Which, admittedly, is quite stale.

So what’s next?

So there we have it, I have a live Glucose reading running on my desk, with visual alerts for low/high readings and plenty of contingency for handling stale readings. I’ve put the source on Github (see below) but my intention now is to run it for a few months and see what happens.

Once I’m finished dogfooding it and happy it’s working as expected, I’ll probably work on some sort of settings management functionality. Because a) Americans don’t use mmol/L as a unit of glucose measurement, they use mg/dL, which means different readings, recommended ranges, etc, so it’ll be cool to add support for this. Also, more importantly, WiFi management, because currently your options are to either manually edit the settings file and reflash the library every time you change location. I’ll probably follow up with another post when I do this.

A quick word of caution

This is a hobby project. It uses Dexcom’s Share service, which isn’t an official, supported API for this sort of thing, so it could stop working if Dexcom change something. It’s not a medical device, it hasn’t been tested as one, and it should never replace your actual Dexcom app or receiver, or be used to make treatment decisions on its own. Treat it as a handy second screen.

Build your own

Everything’s on GitHub under the MIT licence: github.com/chrismou/dexcom-pico. You’ll need a Raspberry Pi Pico 2 W, a Pimoroni Display Pack 2.8, Pimoroni’s MicroPython firmware, and a Dexcom account with Share turned on and at least one follower added. Copy across main.py, reboot, and the phone setup does the rest.

If you build one, or have ideas for what it should do next, I’d love to hear about it! Contact me here, or on the github repo above!