OmniPod 5 + G7 = 0

Type 1 and LADA
21

Short version of the above for @SherryAnn to translate the tech speak:

  1. Try not connecting your phone to the G7 until the pod has connected.
  2. The pod you just removed may still be connected to the G7 and that prevents the new pod from connecting. Try blocking the old pod by sitting on it, putting it in a coffee can, putting it in the outside trash, drown it in a sink or bucket, or try a paperclip in the pod’s stop screaming button. Edit to add or put it in the microwave.

@John_Bowler and @Dave26
Since the G6 and it seems to have carried over to the G7, Dexcom programmed the sensors to only be able to connect to one medical device at a time. Dunno why. Maybe its so one person can’t wear two pumps connected to the same sensor or two people’s pumps can’t accidently(?) pair to the same sensor. It’s the reason the Dexcom receiver can’t connect to the same sensor a pump is connected to. But! I’m sure you are both yelling at me. A pod lasts 3 days and a sensor lasts 10ish. How does the sensor know to allow a new pod to connect? The sensor has to fail to communicate with the pump during one (two? I can’t be sure) commination event. On the next communication interval the sensor allows pairing with a new medical device.
Order of connection is not how the sensor determines what is a medical device. What @Dave26 is seeing is what @John_Bowler talked about earlier, the sensor is… chatty? responsive? until the first device connects then it goes into its sleeping for 5 minutes between BG announcements. I’m mostly sure Loop/xdrip/nightscout/etc aren’t able to register with the sensor as medical devices.

Sherry Ann was multiplying 3 days times 3 pods to make 9, and pointing out to me that site rotation makes making sure the pod and sensor can talk without being blocked by her body tough. It’s extra tough with the G7 because the “antenna” is really low to the body, just like the pod’s. The things people with diabetes have to deal with.

22

Ooh, you are The Dude. I never thought of that. What’s that phrase, “Think outside the box.” I’ve heard that all my life but I didn’t.

For those who don’t understand: 10 days G7, 3 days pod. New pod, same as the old pod, connecting on slot 1. Does not work in the normal Dexcom world until the old pod has timed out (hours).

So the PDM has to, somehow, tell the old pod to drop out and only after that (or the timeout) can the new pod connect on “slot 1”. That certainly requires a backdoor from Dexcom; I’m pretty certain that xDrip+ cannot do that.

It’s a tech challenge but it’s all created by the “slot” restrictions; if the G7 would allow a second connection on a temporary slot it would be possible to do a secure negotiation to remove the original slot 1 controller and replace it. This is hardly difficult but almost certainly not done.

EDIT: just to be clear @spdif the new pod cannot connect to the current G7 immediately, it really does take hours for the G6 or the G7 timeouts to expire.

That’s clearly unworkable so there has to be some way for the new pod to override the normal G7 protection mechanisms and simply displace the old pod.

This may explain why the PDM allows entry of the actual G7 serial number; once the pod has established the connection to the G7 it knows the serial number so this can be passed on to the next pod as a “secure secret” to allow the new pod to bypass the normal G7 security.

If that’s the way it is being done it sucks but it is maybe the best Insulet could get out of Dexcom. I hope that in fact the PDM or the app maintains a secret key for the G7; that’s certainly not perfect but it is better than just using the serial number.

23

Wish I could help with references, but didn’t save anything while I was googling. I had a brief discussion with someone on the xdrip Github discussion where it was mentioned, and I encountered it elsewhere in many hours of searching to try and find a solution.

For me, it was updating from O4 to O5 that triggered my problem… I’d been monitoring G7 from my Android phone and watch for years, using the Dash PDM to control the O4 pods. When I went to O5 I started out pairing xdrip first, then got the message from Omnipod that it couldn’t connect to a sensor already paired with another device. After finding the info about the multiple G7 channels, I tried a different order of pairing and it worked! Didn’t look any deeper, although I’m a software engineer that has curiosity about it.

After connecting to the O5 pod and getting a reading on the PDM, then connecting to xdrip on my phone with the pairing code, I do get a pairing request on the phone after a bit that I have to accept for xdrip to communicate with the G7. Both my phone and the pod then work fine with the sensor.

24

@spdif, not so sure about your explanation regarding connection by xdrip and Android to the G7, which already connected to the O5 pod. As I mentioned in my reply to John, I get a pairing request from the G7 sensor on my phone after setting the pairing code in xdrip, while the pod is already connected to and getting readings from the G7. It’s an Android system level pairing request, not some artifact of xdrip, and the sensor shows in the Bluetooth list of paired devices on my phone.

As I mentioned above, I came across – in more than one place – mention of the 3 bluetooth channels supported for closed loop, G7 receiver or phone, and watch. Didn’t look any further after I got things to work, but finding these hints are what inspired me to try connecting my phone after the pod as a secondary channel.

Perhaps the medical device restriction is only on the first device connected?

Regardless, I’ve got xdrip collecting data with all it’s wonderful features, and glucodatahandler sending the readings to my Galaxy 7 Watch, where I can display graphs, BG, trend info, delta, and a ton of other xdrip info available as complications for watch faces.

Very happy… now, if only Insulet would support my phone (Galaxy Fold 7) for the O5 app everything would be perfect. The O5 PDM is a monster to carry around.

25

This does not match my experience. I go through 3-5 pods per G7 sensor lifetime (T2). New pods are a very smooth and simple experience.

Keep in mind I’m using xdrip on my Android phone as the second connection to the G7, not an “official” device like the Dexcom receiver, phone app, or Apple watch. This could make a difference, don’t know.

Anyway, each time my pod runs out of insulin and starts screaming, I disable it via the PDM – which I have to to set up a new pod – and then fill, prime, attach, and start a new pod. The new pod simply connects to the existing G7 with no interaction from me. Xdrip keeps right on reading the G7 without interruption.

If I start a new sensor during the life of an existing, non-empty pod, I just use the PDM to “add” a new G7 sensor, very simple and straightforward with the camera on the PDM reading the QR code on the sensor applicator. I wait for the sensor warm up until I get the first BG reading on the PDM, then set the new pairing code printed on the G7 applicator in xdrip, and within a few minutes I’ll get a pairing request alert on my phone from the sensor. Accept it, and the new sensor is registered as a Bluetooth device on my phone and xdrip starts getting readings.

It works every time. Never have any problem with old pods seeming to still be paired/connected to the G7. They seem to be removed from the G7’s sensor’s list of paired devices when deactivated.

26

Found it. @Tnyc figured this out.

27

You can pre-soak so that there is no interruption. I.e. attach the new G7 (which starts it) then wait 30 minutes or more, as convenient, until you attach the PDM. This is what I normally do with xDrip+ and I get near instant connection. I just have to stare at the xDrip+ “do not leave this page” screen for a few seconds until the pairing request (from Android, as you say) comes in.

What doesn’t work for me is if I pair the Dexcom G7 receiver first, then getting the xDrip+ connection can take a very long time. That’s a variation on what @SherryAnn seems to see; a very slow, difficult, connection. However in my case it only happens to the second connection.

I have a lot more understanding of what is going on at the hardware/Bluetooth level now, so some of it is still guesswork, but I cannot see why the first connection to a new sensor would not work pretty much instantly.

I’ll put the technical stuff in a separate post, it’s on topic but technical :slight_smile:

1 Like
28

There are a lot of not-very-good descriptions of Bluetooth on the web. The G7 and, IRC, the G6 use “BLE” (Bluetooth Low Energy). Eventually I found this quite complete and believable description:

That, just that page, is almost enough to have a pretty good idea how the G6 and G7 transmitters work. There are a lot more details in the rest of the document, the other pages; enough to tell a hardware engineer or a software programmer how to make it all work.

This post is very long. Bits are well known but many parts are hypothetical so I attempt to explain my reasoning. For the techies out there try reading the Silicon Labs documentation and working out how it could work first. For everyone else, TL;DR.

The Dexcom “slots”

Both the G6 and the G7 use a “slot” concept. This is nothing to do with Bluetooth; it’s about the software inside the transmitters. The G6 supports two “slots”. Originally slot 1 was used by the Dexcom receiver and slot 2 by the Dexcom SmartPhone app. With the advent of insulin pump integration slot 1 was also used by the pump, allowing the app to keep working. However each slot can only be used by one device at a time (this is a feature of the Dexcom design) so with an insulin pump the Dexcom receiver becomes useless.

This is how the “timeout” issue arose with the G6. People who tried to swap a smartphone on a running Dexcom transmitter, e.g. as a result of a 'phone upgrade, found it didn’t work. After some experiment it was suggested that if the old phone is turned off for sufficient time the new phone can connect. Figures ranged around half an hour, I used an hour and never had any problems. @Tnyc 's figure of 15 minutes, meaning three missed readings, is consistent with this. That’s the only figure I can remember where anyone timed the process.

The Dexcom G7 changed things very much but it seems the Dexcom software remained substantially unchanged:

  1. The G7 adds a slot, “slot 3” for SmartWatches.
  2. The G7 integrates the transmitter and the sensor, now the transmitter only lasts 10 days not 90 or more (up to 115 for the G6 IRC). Each new G7 sensor requires receivers to pair to a new transmitter.
  3. The G7 eliminates the need to “start” a sensor and along with that the need to start the transmitter either. The G7 starts when it is inserted; no other action is required.
  4. The G7 also does not need to be “stopped”. Indeed I know that it never stops until the cell that powers it runs out of juice and I hypothesise that it cannot be stopped.

I think the above is all pretty clear. The slot stuff has been stated many times by many different people and the G6/G7 differences are, I believe, self evident.

The remainder of this is my hypothesis of how this is implemented and of how the implementation can fail in such a way as to leave the O5 or xDrip+ (in my case) hanging for hours. I can’t explain any difference between the G6 and G7 beyond the obvious that the G6 is only changed every 90+ days whereas the G7 gets changed every 10 days.

The new transmitter

For the G7 this also means a new sensor, for the G6 I really do mean a new transmitter, not a new sensor.

The G6 powers up when it is connected to the first sensor, the G7 powers up when it comes out of the inserter (the inserter contains a small but powerful magnet to make this happen).

At this point the transmitter starts Advertising. I suggest it does this continuously through maybe it backs off if there is no connection for a while; I haven’t tested either of these hypotheses though it’s pretty easy if I remember when I swap to a new G7.

Anything that is Scanning sees the Advert but attempts to connect through the standard Android or iOS mechanism fail; try it on an expired G7, it still appears every 5 minutes.

The Dexcom receiver, the O5 and other insulin pumps however known how to make a connection. The Dexcom app and xDrip+ will also initiate scanning on the 'phone and make the connection.

At this point the G6/G7 is a “peripheral device”:

Peripheral devices advertise and wait for connections.

The Dexcom receiver, the insulin pumps and the Dexcom app and xDrip+ are all “central device[s]”:

Central devices scan for other devices, and initiate connection.

The peripheral (previously referred to as the “slave”) has to be advertising and the central (previously referred to as the “master”) has to be scanning, both at exactly the same time.

In my experience this happens rapidly, within a few seconds. There is no significant delay. The process is also extremely reliable. I’ve seen it fail once recently requiring a few more minutes to get everything set up but apart from that the only other problems were caused by sensors that started out failed.

BG readings

The transmitter transmits new BG readings and probably sensor errors every five minutes. It’s difficult to be sure how this is done in BLE terms but I’m pretty certain that it happens as follows:

  1. The transmitter powers down after the first connection has been established and only powers up when a new BG reading is available; about once every 5 minutes/300s.
  2. At this point the transmitter opens a connection to each paired device and transmits the new information to each device. I think it also accepts requests from the device for extra information such as backfilled glucose data (from readings the device missed) and battery (cell) voltages.
  3. I suspect that while it is powered up it also Advertises and handles new connection requires from additional devices, precisely as above.

If this is correct the connections to the paired devices are initiated by the transmitter so it is the “Central/Master” device; the roles have been swapped. It’s still a Peripheral/Slave when it Advertises of course. The roles are connection, not device specific.

It is possible to conceive of a way in which the various paired receiver devices wake up every 5 minutes in lock-step with the transmitter and establish a connection but that’s complicated, error prone, and requires the transmitter to be powered on for longer, waiting for an incoming connection. That doesn’t make sense to me.

The second connection

After the first connection has been made the transmitter seems to go into a new mode of operation where it only accepts additional connections every few minutes; this is explained by the transmitter only Advertising when it is powered on to deliver new BG readings.

Dexcom say that a connection may take “up to 10 minutes”, that’s two successive connections, but if one or both of those connections are missed it would take longer.

The Dexcom Receiver and the Omnipod and probably other insulin pumps regard this as a high priority task so are unlikely to miss connections because they are busy elsewhere! The same cannot be said of a SmartPhone, what if your mother calls?

However there is another more serious issue which I have seen. If there is another Dexcom transmitter active in the immediate vicinity it will be Advertising every 5 minutes as well. The receiver can tell the Advertisement is from a Dexcom transmitter; the BlueTooth ID starts “DXCM”, but it doesn’t have enough information to know that this isn’t the transmitter it needs to connect to.

I have seen xDrip+ do this; it connects to an old G7 and goes through the whole “authorization” process (which fails) and by the time that has completed it has missing the Advertisment of the new sensor. This does not happen, or hardly ever happens, for the first connection because then the G7 is Advertising much more often.

This particular instance of the problem may be xDrip+ specific and might be fixed (see the new “DexPairKeeper” messages in the events log.)

Reading the QR code might help with this; it might give the full DXCM bluetooth ID. Knowing the bluetooth ID of the old transmitter certainly should help, that’s the most likely transmitter to still be around (particularly with the G6). Knowing the MAC of the new device should help a lot. Yet it seems tricky because the Advertising data is limited:

The slot problem

Regardless of whether there are problems in reliably connecting a second or subsequent device to the transmitter the Dexcom slots create their own problem.

A single slot is dedicated to a single device. At some point a connecting device has to state what slot they want and if it is in use the Dexcom software itself fails the pairing attempt. It’s not a connection problem to the transmitter itself; the BLE connection has to occur anyway for the new receiver to see the Advertising data!

It would be easy enough for Dexcom to have allowed a new receiver to take over a slot. That would not decrease security because the pairing code is still required. It’s not clear why they didn’t allow that but it is clear that they don’t.

It’s also not clear why the Omnipod PDM requires the serial number, but maybe having the serial number allows the new Omnipod to take over slot 1 from the old one.

Maybe the old pod explicitly disconnects from slot 1 when it fails/expires or when the PDM tells it to for a new pod. Maybe the PDM stores some “secret” that allows the new pod to take over from the old pod.

There are many, many, possibilities here but it seems from @Dave26 and @SherryAnn 's experiences that the “takeover” process is more reliable than the connection to a new transmitter! The new pod certainly does not seem to have to wait for the slot 1 connection to time out.

The reliability could simply be because the old pod and therefore the PDM know the precise 5 minute interval when the transmitter wakes up. On its own that is sufficient to avoid most false Advertisments however the old pod also knows the exact Bluetooth ID (all 6 characters of DXCMxy) and maybe the serial number is in the Advertising data too (clearly the pairing code is not :slight_smile:

Knowing when to connect is particularly important in an app which must otherwise “scan” for Advertisements continuously. This requires continuous foreground activity; the actual connection from a Dexcom transmitter only lasts for a second or so. Android at least is notoriously nasty to apps which do this.

The timeout

The G6 timeout is very short; even if it is more than 15 minutes it is almost certainly less than one hour. Dexcom transmitters frequently time out and at that point anything with the pairing code and a good guess at the slot (1 or 2) can connect to the transmitter.

What does having a timeout, as opposed to allowing connection with the pairing code regardless, achieve? The G6 timeout is so short that I don’t believe it achieves anything compared to just allowing connection at any time.

Does the G7 even have a timeout? If it doesn’t the security and safety of the system increases quite a lot. A connected device cannot accidentally lose a connection for good. If the timeout is hours rather than minutes that helps too because that is longer than the typical alarm time for a missed connection. Why allow a slot to be taken over before the user has been notified of the dropped connection and had adequate time to fix it?

However it doesn’t matter for this topic because the problem is with new transmitters.

29

According to Insulet, the OmniPod 5 Pods last for 3 days + an 8 hour “grace period” to allow a person a convenient time to change to a new Pod. Real-life use has shown that in some cases, the Pod lasted the allotted 72 hours and the user got an additional 12 hours of “grace period” before the Pod quit delivering insulin. I would not know if that claim is true, since the longest I have gone into the “grace period” without changing to a new Pod is about 5 hours. If one really wanted to push the limit on each Pod (the 72 hours + the full 8 hours) one could get the full 96 hours out of each Pod. If the O5 Pods really CAN go an extra 12 hours, then a user could get a full 108 hours, but I really cannot say if anyone could get that reported extra 12 hours from each Pod.

30

That’s certainly correct for the Dash pod, which I use. I run every one of my pods to 80 hours, unless the dog chews it off first.

Sounds like the O5 is exactly the same. The timeout on the Dash is precise; it invariably stops within a few minutes, maybe milliseconds, of 80 hours.

The breakpoint where the game changes is 96 hours.

The G7 lasts for 252 hours - 10 days plus 12 hours - so I could get 21 days out of two but I don’t because of the warm-up (which I can avoid by overlapping two sensors) but I won’t skip hours to cover failures on the CGM. The consequence of that is that I change every 10 days.

With the pump it’s different; I’m happy skipping an hour after the thing stops for convenience. It doesn’t harm my overall control. So if I could run 4 days (or more) I almost certainly would. Maybe Insulet know that :slight_smile: Changing after 80 hours is slightly inconvenient because I sometimes end up doing it while I am asleep but I got an extra 8 hours without doing the change so I’m fine with that.

1 Like
31

That is correct…I have run the O5 pod to the end of the 3 days + 8 hour many times and none have gone longer. (That is one way to match up the G7 10 day wear with 3 pods although at least one pod of the 3 will die at an in opportune time).

I suspect the rumored 12 hour grace period is a mixup with the Dexcom G7 which does have a 12 hour grace period after expiration. But the Omnipod 5 pod only goes 3 days plus 8 hours and then it stops.

32

This has been kind of touched on but is worth emphasizing.

Even after you remove your dexcom sensor, it is still transmitting and attempting to connect with your devices.

Dexcom specifically says old sensors should be something like 10 to 15 meters away while you’re connecting a new sensor. I don’t know how you’re supposed to do that if you live in a small apartment or house. Maybe a lead box or a homemade faraday cage would be a solution.

Personally I try putting as much space as possible as our small townhouse will allow. Sometimes it connects quickly and other times it takes 20 minutes.

33

You may have facetiously come upon a very viable solution! I was surprised to learn that one can purchase a Faraday box online (the ones I saw were on Amazon) inexpensively – somewhere between $14 - $20 depending on what other items are grouped with the box. I actually may do that. I usually change my sensors and Pods in my bedroom, so if I take off a sensor and carry it into another room or even the garage and put it in a Faraday box, that should stop the transmission. Then once a week, I could just empty the Faraday box into the trash to be hauled away. For that small price, I might just try that to eliminate at least one Bluetooth hurdle.

34

That may be specific to the G7 but that was certainly part of the issues I have seen; I have seen xDrip+ connecting to “expired” G7 sensors. It’s less of an issue with the G6 because the G6 lasts 90+ days and that is close to the battery life, so the things tend to die before a new G6 is connected. I think I can prove that the G7 lasts a lot longer than 30 days but I certainly have proof that it keeps going for at least 30 days on average.

35

Microwave oven. Microwaves use almost exactly the same radio frequencies as G7s (and G6’s and Omnipods and some WiFi bands…) Most people advise not turning the oven on while you are doing this; remember what happens with a CD!

A microwave oven implements a moderately effective Faraday cage to prevent excess microwave radiation (i.e. the G7 Bluetooth transmissions) getting out into the kitchen.

Wrapping a G7 in aluminum foil will also very substantially reduce its ability to transmit. Probably cancel it. Dropping a G7 into water is pretty effective too; the G7 can only penetrate about 6 inches of water.

It should only matter for the second connection. I’ve never had problems with the first, for reasons extensively speculated upon above… However it is conceivable given the extremely inappropriate placements of the G7 and the O5 that a removed G7 may be a big problem.

This is because the removed G7 is probably more line-of-sight of the O5 than the new one. In my case the removed one sometimes sits on the bathroom counter while the new one hides behind me (back of the arm). I don’t use the O5 so I can, and do, move my 'phone to achieve better connection to the new G7. I also don’t remove the old one until I have connected the new one; in principle if there is a problem I can go back to the old one.

36

While this doesn’t necessarily apply to the O5 I’ve worked out what the problem is with xDrip+ to a fair degree of confidence. The same bug might occur within the O5 but it will only show with the second connection to a new transmitter.

The problem does arise because of a change in the transmitter pairing between the G6 and the G7. In the G6 the pairing information was the G6 bluetooth ID; DXCM??. This was insecure. With the G7 a pairing code is used, this is secure because the pairing code is not advertised by the transmitter, unlike the bluetooth ID, but is checked later on in the pairing process.

Unfortunately because xDrip+ and the Dexcom receiver do not know the bluetooth ID of the transmitter they both have to check every Dexcom transmitter that advertises. It turns out that all G7 transmitters (and probably G6 transmitters) do this at least every 5 minutes and sometimes every minute except when starting up (until the first connection) when they seem to advertise continuously.

In the xDrip+ case the actual check takes a number of interactions with the Android operating system and ends up taking a significant number of seconds to reject the wrong transmitter based on the pairing code. I assume the Dexcom receiver has a lesser problem because it is simply just faster. Neither has a problem if the new transmitter is advertising continuously because even a “bad” connection to the wrong transmitter is resolved and then the software will immediately find the correct one.

This seems to have been fixed recently by addition of code to xDrip+ which remembers the old transmitters. I can see that xDrip+ now has a long list of all the transmitters it has ever seen. For each transmitter it uses it stores the bluetooth “MAC” (a massive number) along with the pairing code; this is much better than the DXCM?? ID because it is always unique and is in every bluetooth message. This means it can reject incorrect transmitters without even trying to authenticate. I can see it doing this in the xDrip+ log when I swap to a new G7.

It’s not clear if the QR code has extra information to make the connection more reliable but it seems possible. My current G7 has a pairing code of 3576 but the QR code is 250401172609302403576. The bit in italics is not the serial number (the (21) code) but there clearly is extra information in there. It’s not the Bluetooth MAC either, at least not in clear.

There’s no work round for this in xDrip+; it is (or was) a software bug. The O5 might be able to deduce the Bluetooth MAC from the QR code, or possibly even the serial number, but I couldn’t see how to do that (it might require a backdoor from Dexcom).

I did try this deliberately with my latest sensor; I paired the receiver first. That’s something I did originally but the connection failures force me to stop doing it.

For this first sensor I deliberately powered the receiver down for, in fact, around an hour (15 minutes should be enough); this causes the G7 to go into a mode where it advertises every minute, not every 5 minutes. This is a probable work round for the O5; power off the other, already connected, device and wait at least 15 minutes before trying to connect with the PDM.

Next sensor I will try without this step and maybe do some more accurate timing. I’m confident at this point that I can get the pairing to work although my last resort is to walk up the hill far enough that I will be out-of-range of any other G7 or G6 transmitter :slight_smile: Since I do this every day it won’t be a big problem, I hope.

(c) John Bowler

1 Like
37

You asked about Libre Plus 3 CGM which i have had for 2 years or more. I would have gone insane or be dead had my dietician not advised me to try. I constantly check and look at BG, make notes ab out correction doses. It usually works well with the exception of 3 or more sensors stating “alarms unavailable” which makes readings unattainable also. Has said, sensor needs to reset wait 10 minutes….which hasn’t always worked. They sent me two replacement sensors and wanted the “defective”ones mailed back to them. I am answering a comment in a previous post which I couldn’t find. Abbott has been pretty reliable.

2 Likes
38

@SherryAnn did you get anywhere with this?

I’m sure you have a valid customer support call to Insulet because everything you are doing seems to be completely supported; ignore the xDrip+ comments later they are relevant in general but not to the iPhone case.

I also encountered another very similar report elsewhere, but the OP was using Android systems. I was getting somewhere with that but alas the conversation was deleted by the moderators on the channel so I’m still at a loss as to why this should be occurring on an apparently completely supported configuration.

There clearly is a problem.

John Bowler

39

With the latest G7 change, I tried to connect to the OM5 first, then to the G7 app. I don’t think I waited long enough for the OM5 connection though, because when it did not connect after about 5 minutes, I just went ahead and tried to start the new G7. At any rate, the G7 warmed up and was fine after the required 30 minutes, but once again the OM5 was on-again, off-again for a full 24 hours. I will have to readjust the timing of this all. The problem is that I hardly ever change both the G7 and the OM5 Pod on the same day. I DO have a Faraday box where I stash whatever I have just taken off and supposedly have deactivated, but I still just play the waiting game for the OM5 to reconnect to the whole system.

40

The connection should be immediate but depending on how they do it it may take up to 10 minutes for the first reading to show. It’s also possible that the 'pod may delay the initial results until it has seen that the values are stable. It doesn’t matter; this is a customer support call. You aren’t using anything other than Insulet supplied kit and the G7, which is supposed to be supported, so what your 'phone is or what version of the Dexcom app you might use is irrelevant.

The only way forward is to call them and asked what is wrong.

So you do get readings then, just not reliably. That’s somewhat different from your original report:

If you get a single BG reading from the new sensor it is paired. In fact it is paired before the first reading; doesn’t the PDM report whether the new sensor is paired, or connected, or something like that? (On a 'phone the information is in the bluetooth settings dialog.)

It sounds like the original pairing problem was fixed by doing the pod-O5 connection first.

I don’t think that’s the root of the problems. I had one other report (on Reddit) of someone who had a very similar problem but that seemed to be a pairing issue in xDrip+, not the O5.

It really does sound like the pairing is working fine but you are having connection issues between the O5 and the G7. Remember both are on your skin and bluetooth doesn’t travel much more than a few inches (“about 6”) through water, so the bluetooth has a really difficult path; it has to bounce off two separate objects to get between the O5 and the G7 (assuming back of the arm).

Connection issues will make pairing unreliable if the G7 is already paired.

This is still a customer support call; they will be familiar with this issue and will probably have suggestions for alternative sites where the two devices can, effectively, see each other.