More Work than Updates

I hope you'll forgive me. Collectively, the OpenOmni folks have been banging away on all of the various permutations of PDM-POD communication, and deciphering all of these conversations, as well as working to make RileyLink compatible with a Pod. Personally, my family is gearing up to move in just a few weeks, so I've been distracted to say the least. 

Here's the short version:


Code continues to happen. With the release of the G6, and the scheduled release of the latest generation pods, things will be in flux. As always, thanks for being part of the project. 

We're Getting Closer

It's been a while. A long while, but we're getting closer, and had a major breakthrough last night:


What does that mean? I asked one of the folks working on this to put it in layman's language: 

We've determined how the POD and PDM verify the origin and destination of insulin delivery commands, which are protected with a "nonce," a semi-random number generated from the POD's lot number and serial number. Now we can generate our own insulin delivery commands, and thus have complete control of a POD, without the necessity of a PDM. We still have some basic detective work left to do, which is to analyze every command thoroughly, so that we have complete "coverage" of the protocol. There are a few commands which we have yet to fully reverse, but they should become clear to us in rather short order.

There's still plenty to do, and I'm hoping we'll have confirmation today of some other folks generating nonces. Keep the faith! 

A Little Movement, But It's Slow

The past couple weeks, there has been a little movement on the OpenOmni efforts, and we've been very quiet about keeping this site up to date, so let's try and catch up.

  • Thanks to some help from a generous donor and the Nightscout Foundation, a donation was made to Dr. Sergei Skorobogatov in the University of Cambridge Computer Laboratory to begin dissembling the pod code at a low-level. 
  • The OpenOmni bounty pledge has risen to almost $30,000. To date, we've spent around $200 collecting and sending pods and PDMs around to folks. There is still a ton of money on the table...

Peeling the Onion

This week, there's been some discussion on the Slack channel ( about how to get a bit deeper into the radio packets involved in the communication protocol. I'm semi-technically literate, but no where near the group of folks that are actively banging away on this problem, so I asked for an explanation of the current problem. Dan was kind enough to reply: 

Think of the radio packet like an onion. it has several “layers.” the network layer is the outermost layer. we understand all of those fields. inside that layer is the data layer, which we understand many of the commands and fields. but there are a few bits of data that are used to verify the integrity of the command. think of this like a wax seal from the middle ages, used to verify the integrity of a letter from a king. we need to be able to re-create that wax seal, (the verification bytes) in order to reliably craft packets of data which the pod will accept.  
There is an algorithm, which we think is a CRC style algorithm, that is used to generate that wax seal. I believe it’s a 16-bit CRC. Pete has pointed out that there is some "bit-masking” going on, which makes it hard to crack.

This is the state of the state. We are discussing now if putting this data and the problem out on some of the freelance sites might lead to the breakthrough needed to get to the next phase. It may be time to start calling in your initial stake in the bounty, I'll let you know. 

Thanks for being part of the hunt. 


We Knew It Would be Slow

Right now there's a lot of listening happening as folks try to understand how the PDM and pods communicate. And one developer managed to get some firmware, but it seems to be English only, so there's some hangup. I'll keep updating as I see more, but honestly I'm not sure what I'm seeing half the time as the RF engineers talk wave forms and hashes.

Well Damn.

In less than a week, the T1 community has pledged over $12,000 to this effort. If there was any doubt how much people want OmniPod as an option, I think we can put those to rest. In case you missed it, I've also updated this page to include a running total, answered some questions, and swapped out the front page to be a static introduction while I put these updates at the back.

This will be a slow road, but as things happen, I'll try to post here. In case you were ever curious, here's the inside of your PDM. More to come!

Put Up or Shut Up

Understanding that the Open Source world is based on scratching your own itch, here's some scratch. We have placed an initial $1,000 bounty on a working, accepted plug-in for the Insulet OmniPod into the OpenAPS Project. 

To be complete, this means that the project would use COTS hardware and Open Source software to communicate with the OmniPOD device placed on a T1 patient, controlling temporary basal rates to control blood glucose levels. This work will be delivered open source and will be shared and reviewed by existing members of the OpenAPS community. If multiple people are part of the submittal, they can agree on a split, or on a charity to receive the funds. 

To learn more about OpenAPS, visit

To join the OmniAPS Slack channel to discuss this project and understand work to date, visit here

To add to the bounty, join